Remote pump control ideas.

[stj]

Re: Remote pump control ideas.

https://www.carminenoviello.com/2016...nucleo-f746zg/

thid guy is a master - he writes books on this stuff

and this link should be bookmarked - it's the firmware updates for the stlink section.
https://www.st.com/en/development-to...w-link007.html

[stj]

Re: Remote pump control ideas.

arduino doesnt upload the INO - ever
that's "c", it compiles it into binary before upload.
you can save that compiled version.

[Dannyx]

Re: Remote pump control ideas.

btw, to flash code into nucleo's you just copy your bin or hex into the virtual usbdrive and the stlink will instantly flash it to the main board over the debug interface.
it's disgustingly simple!!

I think this only works for sketches you write with Cube (or is it Eclipse....couldn't quite figure out which is which yet, since there's so many pieces of software required to get this thing going it gets confusing ). Since I'll be using the ino. file my Arduino IDE spits out, or rather "uploads", I won't be able to use this feature, at least yet, since I plan on doing it right with the next ones when I'll hopefully have more time to learn. I watched some tutorials, like I said, but I'm the kind of guy who really sucks at retaining large chunks of information all at once if I'm not actually DOING that thing, so I have to practice on my own, mess it up, fix it, break it again, fix it some more and so on....

[stj]

Re: Remote pump control ideas.

the pre-load is in the virtual-usbdrive on the stlink part.
or it will have a weblink.

it's all in the cube software anyway.

btw, to flash code into nucleo's you just copy your bin or hex into the virtual usbdrive and the stlink will instantly flash it to the main board over the debug interface.
it's disgustingly simple!!

[Dannyx]

Re: Remote pump control ideas.

That goes slightly over my head, but speaking of which: these are much nicer packed than I expected and the packaging mentions something about them coming pre-loaded with some stuff, and it would be a shame to lose that if it CAN be used in any way for my project here. I haven't even plugged them in to see what they do, so I don't know anything about them yet.

Like I said: since I'm pressed for time, I'll just go ahead and "sacrifice" and butcher these two to run my POS Arduino code so I can get it off the ground already, but in the future, I'll DEFINITELY want to play around with the more advanced features of these, since they look really capable and it would be a shame to waste that potential. What's funny here is that Arduino, which is a dumber version for beginners, is actually more expensive than these Nucleos ! I was going to go with two Arduino Yun for this project, but the price is nearly double, for less the performance ! ! Sure, you need to KNOW how to unlock that performance to make full use of it, but it's there if you need it...kinda like having a supercar: it can go slow for city driving, but it certainly can also go to the tracks if need be

[stj]

Re: Remote pump control ideas.

NICE!!! - SEND ME ONE!

btw, there is a web-server running on an rtos on nucleo144 you can use as a base.

[Dannyx]

Re: Remote pump control ideas.

Ok, here we go ! Let's DO this

[Dannyx]

Re: Remote pump control ideas.

just remember the i/o is 3.3v

That might be an issue in more "industrial" applications where they risk getting zapped easier, but I'm sure it can be dealt with...

[stj]

Re: Remote pump control ideas.

yes - a big stm chip - not like the bluepill.
bluepill is a good step forward from AVR's, but there are some fakes around now.

btw, you can get stm boards with standard arduino size boards with the usual headers if you have a shield already.
just remember the i/o is 3.3v

[Dannyx]

Re: Remote pump control ideas.

No RJ45 connector on that guy, so I guess I'd have to hack in a shield to get it online. Haven't looked into it, though the form factor is appealing - it's like a Nano, just with an STM chip on it.

[stj]

Re: Remote pump control ideas.

You mean THIS ?
At first I thought it was some sexual innuendo or something, since that's what I got among the first results on dear Google It wasn't until I punched in "STM" in the search that the board came up

no,
https://stm32-base.org/boards/STM32F...lack-Pill-V2.0

[Curious.George]

Re: Remote pump control ideas.

When using it over TCP (as opposted to RS485), it seems to operate "backwards": a client commands a server, though this is only mentioned very briefly

That's how a client-server system operates. The server exports a service. Clients make demands on that service.

DNS is a service. A client sends a request to the DNS server: "Give me the IP address associated with Google.com". The server responds with the appropriate "answer".

HTTPd is a service. A client (someone using a web browser) issues a request to a particular HTTPd server: "Give me your top level index.html page". The web server responds with a copy of that page.

I hit a snag right away though: I had no idea how much memory the Modbus library would eat up, so I ran out of space on the Pro Mini "Global variables use 2207 bytes (107%) of dynamic memory, leaving -159 bytes for local variables. Maximum is 2048 bytes"

The reason many applications dumb down to run on UDP -- instead of TCP -- is the cost of the network stack. (UDP can be implemented in hundreds of bytes vs. kilobytes for TCP -- plus timers, etc.)

[Dannyx]

Re: Remote pump control ideas.

You mean THIS ?
At first I thought it was some sexual innuendo or something, since that's what I got among the first results on dear Google It wasn't until I punched in "STM" in the search that the board came up

[stj]

Re: Remote pump control ideas.

get yourself a blackpill

[Dannyx]

Re: Remote pump control ideas.

I decided to have a look at Modbus as well, since like I said - it's always been a confusing topic to me. I woke up feeling motivated today and managed to understand it a bit better I downloaded an example for the Arduino library to mess with. It seems to do what I need it to do: it even checks if the commands were accepted and reports back if there were errors. When using it over TCP (as opposted to RS485), it seems to operate "backwards": a client commands a server, though this is only mentioned very briefly HERE, so I'm not sure if I understood it wrong. Either way, I'll play with it for the OTHER project, which I won't mention here again

I hit a snag right away though: I had no idea how much memory the Modbus library would eat up, so I ran out of space on the Pro Mini "Global variables use 2207 bytes (107%) of dynamic memory, leaving -159 bytes for local variables. Maximum is 2048 bytes"

[Dannyx]

Re: Remote pump control ideas.

I'm confused if the network is GSM cellphone or Wifi or Ethernet or RS-485 etc

It's Ethernet over fiber - the same kind we have in our homes. I don't know the correct terminology for this stuff In complete layman terms, it gives each shack access to the internet through those ZTE GPONs the guys installed, so I think it's a "network drop", the way Curious.George refers to it.

When the pump is running there needs to be a com link verification, like a ping and response or the pump shuts off by itself if the link goes down for XX seconds.

Yes, it does this too, exactly as you describe, even when the pump's not on: each failed ping adds +1 to a counter. When it reaches 10 failures (or however many I feel like it's a sensible number), the pump turns off and also sends an SMS message to whoever's in charge, since I'll be keeping that GSM alarm module at the pump end and use it for this purpose (the one this whole setup originally ran on). I pull one of its input pins LOW, which the micro can successfully do, since I'll be powering them both off the same supply and it sends out an SMS message to a specified number. I'll also use it to monitor the mains, since I'll be installing a MeanWell ADD-155A supply which has a battery backup, so communications can stay on even with no mains, enough to alert someone.

Now: Modbus has always been confusing AF to me, now that you brought it up, because I can't work out how to implement it: I understand the principle, but how does it work physically ? I'm talking about the hardware. Can I use it over ethernet just like that ? Do you have to run a wire between the master and slave ? Take my scenario for instance...how would any of you go about this project ?

[redwire]

Re: Remote pump control ideas.

Don't forget the tank side does not have unlimited power.
It has to wake up a do a session when the tank empty switch is asserted, or every say 1/2 hour as well, get on the network and try send a message to the pump station. (I'm confused if the network is GSM cellphone or Wifi or Ethernet or RS-485 etc).

After the tank is full, that message goes out to cause the pump controller to shut off the pump. If ACK then we're done and go back to sleep.
When the pump is running there needs to be a com link verification, like a ping and response or the pump shuts off by itself if the link goes down for XX seconds.

DannyX you have to try not to do too much here. Even moving to a new MCU and hardware platform is a huge leap. If you are pushed for time then the Arduino platform works well enough. Learning STM32 and the IDE is a lot of work unless you have the time.

I use MODBUS for the simplest network, ASCII if you really want to be able to snoop on the message traffic for debugging. The CRC checksum helps with scrambled messages. I add a back-door so I can send my own remote queries/commands such as battery voltage, signal strength RSSI (for antenna alignment), number of com fails etc. without driving to the site.

[Curious.George]

Re: Remote pump control ideas.

No - the network side is already in place. Fibers terminate somewhere in our datacenter, or whatever.... I was hoping it'd be a simple Media Converter box at each end, with the fiber link simply running between them (so a layer 1 setup, if I'm not mistaken - no "brains") where I could simply assign static addresses to both the client and server and that would be it - case closed - but instead, some routing has to be done for them to see each other, since the fibers each run somewhere in our head office where God know what happens next - probably goes to some "OLT" (if I'm calling it right)...

My point has to do with whether the end of the fiber is "the other end of the link" (dedicated between "switches" and "pump") or, just a "network drop"?

In the former case, you "own the wire" and can do whatever you want without worrying about interference. In the latter, you can't directly control what is pushed down the "wire".

Yes, I did this, though in a very crude way, like I said: I set up the server to send out "ping" messages to the client every X seconds. If there's no reply after Y retries, it means something went wrong (fiber broke...etc) and the server should stop the pump to keep the tank from overflowing (since it won't know at this moment if the float switch has done anything). Same goes for the run/stop commands - after sending one, the client waits for an "acknowledge" message back from the server. If it doesn't get one, it send out the run/stop command again and again until it does. I worked this out on my own because I noticed sometimes the commands get corrupted and don't come in "loud and clear" - parts of it go missing and the code doesn't know what to do with it...Please see post #23 where I talk about what happens. It's all based on an example sketch I found somewhere, which I then adapted, hence why I said it's not too advanced...

You want to ensure the "wire" is correctly carrying the "state" of the system: switch=on, pump on vs. switch off, pump off. The other states are normally transitional (switch on, pump off -- i.e., the switch was JUST turned on and the pump hasn't yet received the command to turn on; switch off, pump on -- switch was just turned off and pump hasn't yet been told to turn off)

However, there are other cases where these "illegal" states can persist. For example, if the commands don't get through intact (because the link is flakey) or if the pump decides to "fault safe" (despite being told to stay on).

So, there's a third party involved that you need to validate -- the link itself.

To do this, you want to pass messages that each side should EXPECT to encounter and let them verify that all is as they EXPECT it to be.

["turn pump on" and "turn pump off" might be LEGAL messages but neither side KNOWS when to expect either of these!]

If, OTOH, you regularly exchange messages (or, portions of messages) that contain EXPECTED content, it lets the two ends convince themselves that the link is functioning properly.

Note that you can do this with content and timing. I.e., if you expect to receive a message every 10 seconds, then failing to receive one tells you that the link is faulty or the other end is having troubles. (OTOH, if you had no expectation of receiving a message until the switch state had changed, you would never know if the state had changed and you'd not been informed due to some problem!)

While a message may contain "unexpected" content (i.e., you don't know if it's going to say "on" or "off"), you can still reassure yourself by verifying other portions of the message contain the correct EXPECTED content.

Commonly, you add sequence numbers that let each end reassure themselves that they have seen all of the traffic that was destined for them.

"This is message #145. Pump on"
"This is message #146. Pump on"
"This is message #147. Pump on"
"This is message #148. Pump off"

So, if you last saw #146 and now see #142, you can assume something is wonky. (maybe the 2 should have been a 7? maybe the 6 really was a 1?)

The whole point is to reassure yourself that the link appears to be functioning correctly.

Note that you should also add common sense to your code. I.e., if you are told to turn the pump on, then off, then on, then off just a few seconds apart, something is likely not right. Likewise, if the pump is told to turn on and never told to turn off 300 hours later...

[Dannyx]

Re: Remote pump control ideas.

Or, do you have to design hardware to support the optical transducers (presumably via SFP)?

No - the network side is already in place. Fibers terminate somewhere in our datacenter, or whatever.... I was hoping it'd be a simple Media Converter box at each end, with the fiber link simply running between them (so a layer 1 setup, if I'm not mistaken - no "brains") where I could simply assign static addresses to both the client and server and that would be it - case closed - but instead, some routing has to be done for them to see each other, since the fibers each run somewhere in our head office where God know what happens next - probably goes to some "OLT" (if I'm calling it right)...

As you can't vouch for the integrity of the link at all times, the first thing you need to do is decide what the fail safe (or secure) condition will be at the far (remote) end. "Something" in your code will have to drive the pump controls to that condition when somethingelse has determined that the virtual link to the mechanical switch is no longer to be trusted.

Yes, I did this, though in a very crude way, like I said: I set up the server to send out "ping" messages to the client every X seconds. If there's no reply after Y retries, it means something went wrong (fiber broke...etc) and the server should stop the pump to keep the tank from overflowing (since it won't know at this moment if the float switch has done anything). Same goes for the run/stop commands - after sending one, the client waits for an "acknowledge" message back from the server. If it doesn't get one, it send out the run/stop command again and again until it does. I worked this out on my own because I noticed sometimes the commands get corrupted and don't come in "loud and clear" - parts of it go missing and the code doesn't know what to do with it...Please see post #23 where I talk about what happens. It's all based on an example sketch I found somewhere, which I then adapted, hence why I said it's not too advanced...

[Curious.George]

Re: Remote pump control ideas.

Yeah, it's my fault. I said I wouldn't shoehorn another project in here which has nothing to do with the original one, so let's fold back.

It all started with trying to control a three-phase pump based on inputs from a mechanical switch which is located kms away from the pump. What I have to work with is a GPON and internet connection in each shack, from a hardware perspective...

Presumably, the fiber is terminated into something "electronic" that presents a standard ethernet interface? Or, do you have to design hardware to support the optical transducers (presumably via SFP)?

Assuming you have some means of connecting an traditional "wired" interface...

I have no idea what the boys over at our ISP department actually DO with these, but it's their job to make the two boards "see" each other, while I on the other hand, have to make them "talk" TO each other....which I did successfully on the bench (even with some rudimentary checks to make sure each run/stop command was actually received, as previously discussed) though no programmer would hurry to praise me for the frankenstein I created

As you can't vouch for the integrity of the link at all times, the first thing you need to do is decide what the fail safe (or secure) condition will be at the far (remote) end. "Something" in your code will have to drive the pump controls to that condition when somethingelse has determined that the virtual link to the mechanical switch is no longer to be trusted.

[don't forget to figure in the possibility of active threats]

If this is a dedicated (optical) link, then you don't have to worry about other traffic on the "wire" unless YOU put it there! Nor any routing.

And, if it is dedicated, you can likely assume any datagram has an equal chance of transiting the link.

So, design some magic packets to encode your desired actions (state of switch, state of pump) and pass them back and forth over UDP. You can include an explicit packet number to reassure yourself that "this" is the correct "next packet" -- to guard against dropped/corrupted packets.

You can take advantage of the entire datagrams' payload to encode the information to ensure corruption can be detected. I.e., if you just encode the command in one bit -- on/off -- then that one bit being corrupted leaves you in an compromised state. By contrast, if you encode the one bit in a field of dozens (or hundreds) you can deduce its intended value even if a large number of bits are corrupted (google "Hamming Distance").

Or, you could opt to NOT act (or, drive the system to its "safe" state) if you don't receive an "ideal" datagram.