Remote pump control ideas.

[stj]

Re: Remote pump control ideas.

so it freezes after changing io state.
look at what your driving and if it can create a spike or voltage drop.

[Dannyx]

Re: Remote pump control ideas.

Ok, my bad: I missed an important detail: we're trying it out on ANOTHER set of boards in the shop - not "the real deal", so the only think I got attached is a dumb toggle switch on the "server" and a multimeter on the "client" to read when various pins change states - not even LEDs, since we don't have them on hand We're powering them via USB, though it's worth mentioning they're powered from the same PC....not sure if this would cause stuff like ground loops or other electrical nasties that may cause ONE of them to freeze - always the client though !

For reference, THIS is the thread I launched over at Arduino to see if someone pitches in. I haven't yet updated it with these last findings though, since they all happened today as we speak...

[Dannyx]

Re: Remote pump control ideas.

My buddy messed with the code some more today, mostly on the "client" side, though this mostly consisted of adding "checks" here and there, in the form of Serial.println(""); to imitate a debugger (since the Arduino IDE doesn't have one) to see where the code halts or what some of the functions return, so it wasn't meant to be a "fix" by any stretch of the imagination, but ironically today it started working after he added a "client.available();" after the "reply" the "server" sends over to the client. It makes no sense, because he added this line AFTER the reply the server sends out, so it makes zero sense as to how this affects resuming from a connection drop ! Even if the function HAD some sort of relation to this, the server would not be able to send it to the client, because they're already disconnected at that point (either by unplugging the network cable or cutting the power to the server) !

I DID notice one thing: while we were stress-testing this, still not quite sure how it just managed to fix "itself", I started contemplating the possibility of noise or electrical interference again ! To check if the client manages to connect back to the server after a connection drop, I of course unplugged the "server" board from the USB charger we were using. Sure enough, the connection dropped, the "client" went into its "comErr" loop, then I plugged the "server" back in, it did its thing, grabbed an IP and the client reconnected ! I did this by unplugging the micro-usb cable from the board end, but left the charger itself plugged into the power strip. However, when I attempted the same power-cut thing by unplugging the whole charger from mains this time, the connection didn't resume ! Instead, the "client" once again detected the drop, went into its "comErr" loop where it's supposed to try to reconnect every x seconds to the server as it should, but when I plugged the charger back into the mains and powered the "server" back up, the "client" board froze ! This time though Ethernet continued working and I could still ping the board ! Still, the main loop was frozen, as we were no longer seeing the Serial.println("FAIL"); message which was supposed to roll after each failed attempt at connecting to the server ! In other words, when if (client.connect(server, port)); is called, we get either a fail or a success and this is inside a loop, so if the connection fails, my buddy added a Serial.println("FAIL"); to the "else" part of client.connect, to let us know if the code is at least looping and trying to connect. This time, we were not getting ANYTHING in the serial monitor ! I think what happened this time is the "client" board (which WAS attempting to connected to the "dead" server as it should), was a little too close to the power strip and the spark that occurs naturally when the plug of a SMPS is inserted into a mains plug MAY have just messed it up enough to halt the code, so even though my "server" was now up and running, my "CLIENT" was not even attempting to connect to it !

The same thing happened yesterday: we had both boards plugged into the same desktop PC via USB. I'm not sure if some sort of ground-loop occurred or whether it had something to do with the switch we had the LAN patch cords plugged into (which is the same one we used today, so NVM) or whether there was some software bug related to having two COM ports going on at the same time, but basically it DID - NOT - WORK - AT ALL that time: it'd only get like 1-2 replies from the "server", then the "client" would quit, to the point where not even pinging it would work ! Today, this chap brought in his own laptop to work on, so one of the boards was plugged into his laptop.....This is grasping at straws, but again: maybe there IS something going on there beside just code bugginess.......:|

[sam_sam_sam]

Re: Remote pump control ideas.

This might be a stretch but depending on what type microcontroller that you are using
There is a difference between endif and exit commands so if there are different ways end a programming loop and then you want to exit the loop because a input is true or false depending on what you want to do try different way to jump to another command line or loop until the statement is true or false depending on what you want it to do

I have had this kind of issue before and some time one command works better than other command depending what you are trying to do

I hope this helps you

[Dannyx]

Re: Remote pump control ideas.

As a refresher, to bring this discussion up to date again, we are using two Nucleo144 boards. The chip on them is the STM32 F767ZI. We're doing the code in Arduino's IDE. I know ideally we should be using Cube32 (or was it Eclypse ???) to play with ARM boards, but the time was rather short and since I was the one who started this whole ordeal, we committed to Arduino for now, at least until this crisis is over and we can actually start learning Cube....

I'm not sure how well these boards were "ported" to the Arduino, so there may be bugs right there, since they're NOT meant to "work" with the Arduino IDE - it's mostly a shorthand for us beginners

[stj]

Re: Remote pump control ideas.

technically you should be using GCC and a text editor - but nobody has time for bare metal programming anymore

[Dannyx]

Re: Remote pump control ideas.

technically you should be using GCC and a text editor - but nobody has time for bare metal programming anymore

True - I noticed in Cube or whatever, you have to define EVERYTHING, every "device" like SPI or Ethernet requires explicit code to be added - NOT beginner friendly indeed, but a lot more powerful in the long run indeed....I WILL persevere with this and try to do it the way the smart guys over at ST intended to !

[stj]

Re: Remote pump control ideas.

CUBE is bloat.
what most people use is OpenCM3
https://libopencm3.org/

[Dannyx]

Re: Remote pump control ideas.

Thinking the power situation at the tank side is a bit funny with that whole "power coming on at night and going out in the morning", I thought I'd update on how I ended up working around that too. Thing is, this solar controller uses common positive, also confirmed by its instruction sheet and by measuring (all + terminals are tied together), so I had no choice but to toggle the negative wire between the cell and the supply I added via a relay. It works, but I noticed the charge controller doesn't actually regulate the output to the load - same voltage that goes in to the "cell" terminals, goes out to the "load" terminals. So if I set my power supply to put out 15v, 15v come out the "load" terminals, which concerned me a bit, since it means it's also being pumped directly into my Nucleo board, which although IS set to use the onboard regulator which can tolerate it, it has to work harder and dissipate more heat. I was hoping the charge controller would do some regulation of its own, so I could raise the voltage on my SMPS a bit more to like 15v+, while still getting stable 12v at my load terminals and enough juice to charge the battery, but I can't quite do that without stressing the onboard reg......

The reason I'm even mentioning this is because I'm more concerned about this behavior occurring due to power issues and the "server" may be locking up...

[stj]

Re: Remote pump control ideas.

solar charge controllers are usually pulsed dc and they regulate current rather than voltage.

you should make a small board with a bridge rectifier and some smoothing caps - electrolytics for bulk and film/ceramic for speed.
put it between your power and the nucleo and any other electronics your running.
use a bridge instead of a single blocking diode because it gives you full blocking together with protection from some dick in the future putting a replacement battery in the wrong way!!

and dont power from the solar - those panels can go well over 30v on low load.

[Dannyx]

Re: Remote pump control ideas.

Good idea. I DID plop a single diode in series with the supply to the board + a single electrolytic, but I guess I should be increasing that capacity, add ceramics too and switch over to a FULL BRIDGE RECTIFIER ! Not sure what the values of the caps should be though...

[stj]

Re: Remote pump control ideas.

probably 470uf is enough - your relay coil will draw far more than the nucleo!!

[Dannyx]

Re: Remote pump control ideas.

I will not even run the relay through my "filter" here - just the Nucleo. I sure hope my changeover idea is "decent" enough

[Dannyx]

Re: Remote pump control ideas.

I can now definitely confirm there's a power issue messing us up. There's some situations in which the client board locks up and no longer loops and these can be replicated each time, so they're too much to be coincidences

Case no.1: both boards are connected via USB to the same computer host. In this case, the client connects to the server, but they only manage to exchange 1-2 messages before the entire thing breaks down and the client freezes...

Case no.2: that thing I described where the server is unplugged from mains together with the USB power adapter that powers it - not just from its USB connector. Plug it back in and, annoyingly enough, it's the CLIENT loop that freezes ! I say "annoyingly" because the client isn't even powered off to begin with - instead, it just telepathically knows the entire brick got unplugged....HOW ??? EMI most likely, though I WILL try moving the boards farther apart. However, try the same exact thing, but by unplugging just the USB cord from either the charger or the board end and leave the brick plugged in and the code resumes just fine (and also keeps looping if there's a connection error, as it should)...WTF ?

From a factual standpoint, I installed the "client" board in its own enclosure, what I consider to be a pretty good distance from the three phase contactor at the actual site where the pump is, so I'm hoping this doesn't turn out to be a problem there, though as far as I remember, I could still hear the buzzer buzzing away when the connection was "dead", so the loop was not stuck - there was still a code bug at that stage...If we get that out of the way, we should be good. My programmer buddy made some mods to the code here and there and it starts to look a whole lot nicer now. He stress-tested it all day while I was away, but when I came back I wanted to do the all-important power-cut test and did it by unplugging the wall-wart, letting the client board go into its comErr condition and lo and behold, nothing else happened when I plugged the server back in - the loop had frozen and we had a "uuughhh....f*ck" moments :|

[Dannyx]

Re: Remote pump control ideas.

We hit a snag yet again (this project's just not meant to be): the board which had died the first time which I fixed, died again today
This time, the chip appears to have shorted out, because I get the "overcurrent" LED come on and sure enough, the resistance is very low on the 3.3v pin. I will proceed to inject some voltage to blow out whatever's busted - maybe I get lucky and it's a ceramic cap...I've seen it happen on laptops before.

[Dannyx]

Re: Remote pump control ideas.

So: replacement board arrived, we messed with it some more on the bench and my programmer buddy managed to comb through my original code and mix and match stuff to make it a bit better, both in terms of formatting and functionality. It now "waltzed" back and forth no problem and recovered from any network drops we threw at it - both on the "client" side (pump) and the "server" side (tank). We stress-tested it as much as we could on the bench and thought we were done with it, BUT:

When we went to test this out on the real deal, we ran into more problems once again. I REALLY need to redesign the power section, I think. It appears the three phase contactor is causing enough EMI to freeze my "client" board, since although the boards never froze once back at the shop, now the client is VERY unstable and would often crash following the contactor opening, though not always. Either the main loop freezes, so it never even attempts to re-connect to the "server" over at the tank side, OR something happens to the LAN chip and the link drops altogether (LEDs go off on the RJ45 jack and the GPON it's connected to) ! I have no idea how to deal with this, sadly The contactor is roughly 70cm away from the Nucleo board and they're both in separate boxes !

To recap what my setup is: I'm powering the Nucleo via its VIN pin with 12v and I set the selection jumper accordingly. The 12v comes from a Meanwell power supply which sits in the same box as the contactor, quite close in fact. I tried to separate the board from the "power" side as much as possible, so I used optocuplers and transistors to drive any 12v indicator lamps and also the 12v relay which in turn controls the big 230v contactor. To hold all these, I build the PCB in the picture. It's a perf-board, since it's all quick and dirty - no money spent of printing PCBs, plus I am clearly not a pro at designing PCBs either. Still: I added a diode in series with the 12v input and dropped a cap on it as well. The wires on the left where the screw terminals are go to the various components of this system, including the GND and 12v input. From there, I go through a diode and I also threw a cap there. From there, we go to those IDC connectors which I used to make my own "harness". The one on the left is mostly for power: 12v, GND, 3.3v and the reset pin (since I have a big reset button on the front panel). The plug on the right is for indicators and the relay. All have a resistor>optocoupler>transistor.

The latest thing I tried was sticking a Schottky diode 1n5819 between the 3.3v pin of the Nucleo itself and its GND. Not having an oscilloscope to actually test all of this hodge-podge the idea behind this was to clamp any negative spikes the chip itself might experience on the 3.3v supply pin....it's not the end of my concerns though.....clearly. It could very well be a bad choice of diode entirely and the least of my worries.

I am not sure what is generating the interference to begin with and what part of my board picks it up: is it the three phase power arcing in the main contactor, or perhaps the small 12v relay itself arcs when it cuts the power to the contactor, since it's pretty big and runs on 230v, so that may also be it. Is it picked up by the power pins, all those exposed pins the Nucleo has, the network cable itself ??? Who knows......there's so many variables here that I can't test and I admit I bit off more than I can chew...

Guys, please bare with me as I am NOT an expert - just wanting to learn from my mistakes for future projects.

[stj]

Re: Remote pump control ideas.

you can put snubbers across the relay contacts or maybe even the contactor.

[Dannyx]

Re: Remote pump control ideas.

you can put snubbers across the relay contacts or maybe even the contactor.

I've always been afraid of these, though I KNOW what they are and they SHOULD be used, but don't know how to DESIGN them.

The three phase Siemens bastard is a 230v coil and the smaller one driving it is a 12v coil. I'm always afraid something in that R-C snubber may go poof and f*ck up something else....possibly injuring me in the process, tripping breakers, etc....

For instance, I found THIS, but I'm not sure about the diagram: which one is it ? Is it showing two ways in which this snubber can be "deployed" (across the contacts OR across the load), or is it case-specific ?

[stj]

Re: Remote pump control ideas.

they cant really blow up because while the cap can short, it has the series resistor to limit the current.

[redwire]

Re: Remote pump control ideas.

I think you have to chisel away and deal with each EMI source/problem one by one.

The contactor's coil does have a huge back EMF which would make the little relay contacts arc.
The relay's contacts are high voltage and dirty (EMI) - and that wiring must be kept as far away from all the low voltage wiring.
The arc at the contacts can radiate EMI and capacitively-couple it to the coil's 12V connection. This path gets it into your 12V system.

What is usually done is either a MOV (i.e. 275VAC) across the contactor's coil (limits back EMF) OR an RC snubber across the little relay's contacts like 0.1uF X2 275VAC and say 33R 1/2W.

Suppressing arcing at the motor contactor is expensive and hard to do. It's a big motor and nasty high voltages there. Not really feasible. Best is to keep the MCU away from it, or in a metal box.

The opto-board looks OK. How is the earth-grounding to the 12V side done? Or is it floating? You can add a 0.1uF cap from 12VDC(-) to earth ground and that usually helps, if the EMI is present there.