Remote pump control ideas.

[stj]

Re: Remote pump control ideas.

did you check that paperwork? it may have said when the battery was installed.

[Dannyx]

Re: Remote pump control ideas.

did you check that paperwork? it may have said when the battery was installed.

No and I forgot to ask the chap when the system was deployed, since I'm betting it hasn't been replaced since. I'll use our battery tester to check it the next time we go there. It will need charging first, which will not be easy on top of a hill with no utility power available. Will probably have to get it back down, charge it, then return it to the top...sounds fun

[Dannyx]

Re: Remote pump control ideas.

Another thing just dawned on me: any way of implementing some sort of "out of band" access on these STM boards ? I know that's not actually the proper name for what I'm trying to achieve: I need a way of uploading code and viewing the serial monitor from the boards remotely, just as if I were sitting next to it with my PC.

I got the idea from another project which was passed down to us, where some serial-to-LAN adapters allow otherwise purely serial alarm control panels to talk to a head office over the network - something like that, so I don't have to be in close proximity to the board to alter the code, upload a new idea or simply view the serial monitor. Those use Lantronix Xport modules to do the job, but they're pretty expensive....

[redwire]

Re: Remote pump control ideas.

Both ends look not so great. The tank end has a cooling fan but the intake grille is blocked by the battery. Who has extra power to run the fan? I got longer battery life putting insulating foam on the battery bottom as the metal box gets hot in sun and is like a hot plate so the battery was hot at the bottom and cold up top.
The pump end is stupid having mains and other wires 1" away from the GSM cell modem antenna pcb trace, or going underneath. It's going to make tons of noise. Oh and ANOTHER COOLING FAN? There's not so much heat here unless this is the middle east.

I would find out what the USB port does on these boards, maybe read out the program?

[Dannyx]

Re: Remote pump control ideas.

The enclosures are actually plastic, if not clear from the pictures, and they're both located inside shacks, so they're not in direct sunlight, though I imagine the one with the battery, located at the top of the hill, CAN get pretty warm in the summer when the sun's beaming down on the shack directly. The water tank located nearby may have a nice cooling effect though.

I think the fan is a good idea in the long run, though not ideal for energy conservation. There are plans to wire the tank shack to utility power as well, but it won't happen in the near future, so battery power is the way to go for now I'm afraid. I'll definitely tidy stuff up once I actually get started, like actually moving that battery towards the middle of the box

Now that you mention it, a 400v contactor carrying several amps opening right next to my STM32 would not be a very bright idea....I may have to install a separate box after all. These guys won't like the extra expenses, because everything has to be done on a budget, but it HAS to be done....

Speaking of which, I was a total d!ckhead and forgot to take a picture of the model of that contactor, since as it stands I have no idea if the coil is 230v or 12v. I think it's 230v, because I see a small intermediary relay to the far left (next to that phase monitoring thing) which I think drives the 230v for the coil...

[stj]

Re: Remote pump control ideas.

you could write a bootloader in flash to load the main code from usb/sd into ram and run it.
then you just need to remotly overwrite the usb/sd and reboot the board.
but you shouldnt - security is important.

[Dannyx]

Re: Remote pump control ideas.

These Nucleo boards seem to only play nice with their ST-Link programmer - not sure if it's possible to program them some other way - the way you can an Arduino via serial for instance, though on page 75 of the datasheet in post #32 (kudos) I do see STLK RX and TX on the right there, connected to pins 77/78 USART3 RX/TX, so maybe the ST-link portion is like the programmer found on most Arduinos which come with a programmer (the Mini doesn't, hence why an external one is required). This would enable me to actually get one of those serial to ethernet adapters to enable this sort of remote programming....otherwise, I can't, at least not easily, I imagine...

[Dannyx]

Re: Remote pump control ideas.

Let's talk code now Having a look through my code and wanting to learn to do it better instead of just "good enough to work", I started looking at parts which seem overly-complicated for doing just a simple thing and looked into ways of doing them properly. Some of them I was able to do, but others not so much and I need help

One such instance is using millis() to count down since the start of an even. The way I do it works but seems messy and it may not be the best practice.

What I'm trying to achieve is this: say I have a push-button and I want to turn on an LED with it, but only after the button's been held down a number of seconds. When I started playing with millis() for the first time, I tried it like this (this is just a snippet - the variables are declared at the start of the code in the Arduino IDE):

if ((bitRead(PIND, 5)== 1))
 {commandTime = millis(); 
  if (millis()-commandTime >= waitTime)
     {run = true;}
 }

I now know this doesn't work because as long as the button is held down, the variable commandTime is being CONSTANTLY fed the value of millis() in real time, so the subtraction below constantly equals zero and never reaches reaches the value of waitTime. This is the issue: I can't figure out a way to "capture" millis() into a variable.

I WAS able to do it like this, by using a second boolean, commandStarted, to kinda sort-of "freeze" the execution of commandTime=millis() so it only runs once *BAM*, capturing the current millis():

if ((bitRead(PIND, 5)== 1))
 {if (commandStarted == false)
    {CommandStarted = true;
     commandTime = millis();} 
  if (millis()-commandTime >= debounceTime)
     {run = true;}
 }
 else {stopCommandStarted = false;
}

This works, but I wonder if it can be even easier and cleaner - somehow this doesn't seem particularly professional code-writing to me....not that I ever claimed to be a pro, like I said. I'm learning as I go. Also, I'm aware that using ports like that in the code itself is not ideal either - they should probably be declared too

[Curious.George]

Re: Remote pump control ideas.

What I'm trying to achieve is this: say I have a push-button and I want to turn on an LED with it, but only after the button's been held down a number of seconds. When I started playing with millis() for the first time, I tried it like this (this is just a snippet - the variables are declared at the start of the code in the Arduino IDE):

if ((bitRead(PIND, 5)== 1))
{commandTime = millis();
if (millis()-commandTime >= waitTime)
{run = true;}
}

I suspect the environment you're coding in is sorely crippled (single-threaded, etc.).

If you can afford to spin in a routine that just watches a button press, then the easiest way to do this is to watch for the button to be depressed ("was=OFF, is=ON") and store that "time". Then, when you see the button released ("was=ON, is=OFF") look at the elapsed time (now - pressedtime) and, if it exceeds your limit, do "whatever".

I.e., you initiate the action when the button is released (like how windows does things when a mouse is "unclicked" instead of "clicked").

The downside of this is that if you hold the button for an eternity, nothing will happen until you release it -- even if that's hours after your "time limit" has expired.

[A smarter way of doing this is to have a dedicated thread that just watches the button(s) and captures the "current time" when it notices certain "events". Then, set timers that trigger actions when they expire. If something happens that causes you to NOT want that action to occur (e.g., the button is released "early"), then you kill the timer.]

[[I don't play with arduinos and their ilk so I can't tell you what you can or can't do in those environments]]

[Dannyx]

Re: Remote pump control ideas.

The downside of this is that if you hold the button for an eternity, nothing will happen until you release it -- even if that's hours after your "time limit" has expired.]

This is the issue I was facing, as described.

I don't know squat about advanced programming stuff (like threads), hence why I'm using layman terms most of the time. The Arduino IDE uses C++ and from what I understand it's fairly potent, by my standards at least, if you know how to do it. I did it by ear, so stuff is not up to snuff...

[stj]

Re: Remote pump control ideas.

These Nucleo boards seem to only play nice with their ST-Link programmer - not sure if it's possible to program them some other way - the way you can an Arduino via serial for instance, though on page 75 of the datasheet in post #32 (kudos) I do see STLK RX and TX on the right there, connected to pins 77/78 USART3 RX/TX, so maybe the ST-link portion is like the programmer found on most Arduinos which come with a programmer (the Mini doesn't, hence why an external one is required). This would enable me to actually get one of those serial to ethernet adapters to enable this sort of remote programming....otherwise, I can't, at least not easily, I imagine...

read the chip datasheet.
you can program those chips through any port by setting the boot jumper
so you can upload via usb,serial, even canbus

the stlink uses a serial version of jtag to not just program the chip but let you communicate with running code.
(without messing with the boot0 jumper)

[Dannyx]

Re: Remote pump control ideas.

Not sure whether I should post my code here for others to see or not It's a mess and I'll probably get roasted good but it's the only way one learns and gets better at something I guess....

[Per Hansson]

Re: Remote pump control ideas.

^^Well if you do please use CODE tags in your post, so the formatting is not lost.
I added them to your post #48, looks much prettier at least

[Dannyx]

Re: Remote pump control ideas.

^^Well if you do please use CODE tags in your post, so the formatting is not lost.
I added them to your post #48, looks much prettier at least

True, but I was planning on uploading the INO files anyway, not the code as text....not sure if that's the way to go around here.

[stj]

Re: Remote pump control ideas.

if you do that, you need to zip them to get round the attachement filter.
then people have to download them to view!

copy/paste is better

[Curious.George]

Re: Remote pump control ideas.

This is the issue I was facing, as described.

I don't know squat about advanced programming stuff (like threads), hence why I'm using layman terms most of the time. The Arduino IDE uses C++ and from what I understand it's fairly potent, by my standards at least, if you know how to do it. I did it by ear, so stuff is not up to snuff...

"Language support" is like advertising you have shiny hubcaps on your old klunker. The most powerful/effective programming tool is the environment supported by the "OS" (or, "RTOS" -- to use a often abused misnomer).

Here's a "program" (thread/task) to control an LED. It allows "something" to indicate whether the LED should be OFF, ON or BLINKING (at some predetermined rate).

extern state;

Drive_LED() {
  state = OFF;
  while (FOREVER) {
    switch (state) {
      case OFF:
        LED = OFF; break;
      case ON:
        LED = ON; break;
      case BLINK:
        LED = ON;
        sleep(1000);   // ON time, in milliseconds
        LED = OFF;
        sleep(500);    // OFF time, in miliseconds
        break;
      default:
        break;
    }
  }
}

Note that there's no mention of ANYTHING else in your "device" ("system") other than the issues that are of interest to driving the LED. Even someone completely ignorant of the language chosen and the actual details of what the statements actually DO (or how they do it) can suss-out what is happening. (in order to make code "accurate", you really want to make it easy to understand)

You can embellish this to handle any number of LEDs and ensure that they blink in "unison" (instead of each coming on "whenever" and winking off some time after that).

The above code snippet can be bound to C, C++, ASM and be equally obvious. I.e., the language doesn't buy you squat!

OTOH, try doing this in a single-threaded environment regardless of language AND making sure those times (1000, 500) are guaranteed.

[Dannyx]

Re: Remote pump control ideas.

Another thing came to my mind about the hardware: would it be wise to drop some sort of zener protection on the input of the MCU ? The Meanwell PSU I proposed outputs 12v AND 5v, so I have the option of powering the Nucleo with either....not sure which would be better. Regardless, would a resistor+ a 13v zener be a waste of time or mandatory ?

The "sump" end is powered only by 12v for now, since it's solar powered and I'm not sure how much that controller overshoots, so it's the same thing there: I should probably design some sort of basic protection...maybe even better: with a PTC fuse so it resets by itself after a spike.....didn't think it through yet. The datasheet doesn't quite make it clear how much these nucleos consume - I think it's 300mA....either that, or I'm plain stupid and don't see it, which is the more plausible explanation, as always

[stj]

Re: Remote pump control ideas.

the nucleo is actually 3.3v - it has an onboard regulator.

[Dannyx]

Re: Remote pump control ideas.

I know that, but the absolute maximum rating is nowhere to be found. The datasheet simply says it can accept up to 12v on its 12v input (which is naturally then stepped-down by that regulator tot 3.3v), but there's no mention of how hard you can overvolt that 12v input before something pops (the regulator probably)....wonder if it can take up to like 35v like most regulators can, at the expense of maximum current you can then draw from it. I imagine it's pretty resilient...

[stj]

Re: Remote pump control ideas.

the schematics are in the pdf's,
you can see the regulator and caps used and work out the max input from that