Remote pump control ideas.

[stj]

Re: Remote pump control ideas.

so use fixed i.p.
or set the lease timeout to a month or something

[Dannyx]

Re: Remote pump control ideas.

so use fixed i.p.
or set the lease timeout to a month or something

I will try that too - it's just a speculation ATM. I'll have to ask my buddy to teach me how to dig through libraries to work out stuff like that. A debugger would really help, that's why meanwhile I'm trying to work out how to do it the "official" way, as opposed to using Arduino's IDE...this is where it gets complicated and requires a lot of time to work out sadly

[stj]

Re: Remote pump control ideas.

run the ethernet through a pc and run Linux and Wireshark.
https://www.wireshark.org/

[Dannyx]

Re: Remote pump control ideas.

So as to see what's being transmitted ?

[stj]

Re: Remote pump control ideas.

yes, and what the response is.

[Dannyx]

Re: Remote pump control ideas.

I don't have the latest code my buddy worked with - it's on his laptop at work where the boards are currently chillin'. I set up a baby monitor camera to watch them over the weekend, that's how I know what they're currently up to

Ok, get this: the client managed to somehow get itself unstuck and actually shut off the output to the relay like it's supposed to, to keep the place from flooding if it loses connectivity. There's an LED on the relay which I can see on the camera, in case you're curious how I know that. No idea why it happened after so many damn hours though and where it got stuck...

Moving past that, it's like the client's currently got no network cable plugged into it, because it's stuck in the "errBeep" loop. Again, this will all be easier to follow once I actually show you guys some code, but my buddy and I created an errBeep function to have some feedback. Basically it's a bunch of calls to tone() and noTone() to make that buzzer sound like a PC POST code when it fails to detect a GPU or memory - some pattern like that. In this case, it's calling the errBeep function because it can't get through to the server board next to it.

The reason I say it's like it's got no cable plugged in is because of how fast the errBeep function is looping, which happens if the board's got no IP to work with, such as when the cable's not plugged in. If the cable IS plugged in and it HAS an IP but still can't connect to the server, the errBeep function loops more slowly, at around 10s intervals, because the client.Connect(server, port) function hangs for a while trying to do its thing and THEN calls errBeep function if it returns false (fails). Then it tries again - halts for a few seconds - fails again - calls errBeep.

I think the board is somehow smart enough to know there's no network to work with and immediately returns a false on client.Connect(server, port) function, hence calling my errBeep in rapid succession. We were aware of this and it's a good side-effect. Still, no idea what's happening in the background right now. This is where a debugger would be really handy, though I'm not sure how easy it will be to port this code of ours (good or bad) over to STM32 Cube IDE.

[stj]

Re: Remote pump control ideas.

set a fixed i.p. for both ends.
then you can remotley ping them to check for life.

[Dannyx]

Re: Remote pump control ideas.

set a fixed i.p. for both ends.
then you can remotley ping them to check for life.

I'll try that too, to at least check if it's a DHCP issue or something wrong within the code. For instance, through experimenting, me and my buddy discovered some time ago that you're supposed to handle disconnecting the client from the server after each "poll" in a rather specific way, otherwise the same exact thing happens - code freezes to the point where it no longer PINGS. It seems where you call the client.stop() function on both the server and the client is critical to this. He found a combination which sort-of works now, which is running on the boards right now, but apparently something is still crashing...we won't know for sure if it's this or something else, or it wasn't related to this at all this whole time....

[televizora]

Re: Remote pump control ideas.

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.

There is alternative. Using SSR or Tyristor. But these are much more expensive than a relay.

[Dannyx]

Re: Remote pump control ideas.

There is alternative. Using SSR or Tyristor. But these are much more expensive than a relay.

Yeah, that's way beyond the scope of this project at this point - we're still struggling to get the control side out of the way...

[Dannyx]

Re: Remote pump control ideas.

The randomness continues: woke up today, checked my camera, client was connected and relay output was on....go figure. It somehow managed to get through....after like 10+ hours for some reason...