Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Relay not switching
#1
Hi Rob,

Weird one for you. 
When my controller starts up, the water temperature is low so the heaters try to come on. The icons on the right of the display light up green, but the relays don't click on. When I manually turn the heaters off, and then on again, they click on. They then click off when I press the icons again. So all the AC devices work manually. When I press Resume on the home screen, the little 'M' goes away on the icon and the controller tries to turn the heaters on again, but the relays don't engage. I haven't tried any other AC devices yet. I tried a Sync but it didn't make any difference.

Is there a difference somewhere in the software when manually turning an output on vs. the controller doing it?
Reply to top
#2
Hi Jared, that does seem a little odd, there is only one section of code to turn the outlets on/off, if they work manually they should work in auto mode. Did you ever do the "restore defaults" after having the I2C issues? If you have no need to do it again. With the controller in auto mode (no small M on outlet icons) and you heat up / cool down the temp sensor will the relay click? Can you try a couple outlet schedules, on to turn on and off. Also if you have a float switch create 2 custom rules using it, one rule turns the outlet on and one to turn off. Then flip the float back and forth and the relay should click on/off every time.
Reply to top
#3
Nope, I never did a "restore defaults", but that did the trick! The heaters go on and off by the controller, as well as the return pump shuts off when the "display high" float closes and turns on when the float opens (separate rules).

Thanks!!

(Just out of pure curiosity, what does the "restore defaults" do, besides change all the manually entered settings back?)
Reply to top
#4
Great, glad to hear. This issue was caused because of that I2C issue you had, some of the eeprom data must have been erased on controller, because display still had the correct settings they didn't match. In the next update I'm changing things so this can't happen.

The restore defaults only does that, restores original values on display and controller eeprom. The sync will read all settings on display and send them to the controller so everything matches but since I moved the RTC to controller these settings aren't on display anymore so didn't get synced, I'll be fixing this on v5.
Reply to top
#5
Maybe a new related issue?

Everything was going okay and I noticed I never updated the time and date. I did that, and now all kinds of weird stuff started happening. Now the outlets pretty much do whatever they want. Every 3 or 4 minutes, everything will come on, then only a few things. Then everything will go off. When everything goes off, I can't manually control anything. When some things come on, I can manually control them, but sometimes only when I turn more than 2 or 3 things on. And pretty much all the time the heaters try to come on but the relays don't click, as before. My return pump/float switch rule doesn't do anything either.

I changed the controller Due to a brand new one with a fresh sketch installed (and installed a 10k resistor as shown in that other thread), reinstalled the display sketch, tried multiple I2C adapter boards, restored defaults and re-sync'ed multiple times, probably over 6 times. If I manually switch the relay board it works, so I'm fairly confident that it's not the relay board.

Any suggestions?
Reply to top
#6
New sketch on new controller Arduino, new sketch on display arduino, new installs of SD cards, and problem persists even after restoring defaults. And I forgot, the display is still locking up on boot, with buffer removed and even after restoring defaults, but only when the I2C adapter is plugged in (either USB connector or spare pins). I've tried multiple I2C adapters so I hesitate to find fault with those, so I'm thinking it's the EEPROM? But I don't know the functionality of that, so I'm hesitant to blame that either..
Reply to top
#7
Hi Jared, sorry for taking so long to reply, I think the problem is because there's no buffer. Once the capacitance rises to a certain level the I2C devices can start acting strange. I experienced the same thing when I was testing 6ft of cable without buffer, the I2C scanner see's it but in operation there's a long delay between action and response and random things occur. It's definitely not the eeprom, just too much on the bus. I thought you would be ok with 1ft of wire but obviously not. Also when the bus gets overloaded it'll lock up causing the eeprom and other devices to not work.

I'm still scratching my head on this whole situation, I have 7 other boards out there and no issues with I2C so I'm wondering if it's in the board which doesn't make sense though because without the buffer it works if not overloaded, after the buffer there is only an inch or so of trace and the USB ports and we know those are ok because bridging the buffer doesn't cause the bus to be shorted. I also agree your I2C adapters are ok, this is only happening because bus is overloading.

Originally I was thinking I would send you an expander with buffer mounted to plug in the USB but now I'm wondering if that'll work because you're near the limit on capacitance, if you want we can try that. Another option is to the send the controller back so I can go over it and do what's needed to get it working, I don't know what else you can try apart from another buffer IC.
Reply to top
#8
Hi Rob, no worries! Hope you enjoyed your weekend :-) Happy Canada Day!

I actually measured the USB cable I was using and it's closer to 31". It goes: male USB end, 30" of cable soldered right into the I2C adapter board, and then a 3 inch ribbon cable with headers to connect from the output of the adapter to the relay board. The strange part is that this cable was working fine for a couple days (with the exception of the long boot) before everything got really weird. I also have another cable terminated the same way with the same brand of I2C board that is only 14" long, and it does the same thing.

Before sending the board back, I'll change my set-up a little bit. I'll solder the USB cable right to the adapter with maybe an inch or two of cable. Then I'll use longer ribbon cable to go from the adapter to the relay board. Maybe that way we can rule out the length of the cable. If that still doesn't work, I'll put the buffer IC back on.

Do you know how the other user's boards are configured, i.e. cable lengths and whatnot? And can you explain the configuration of the expander that you mentioned? I'm not sure what that is, does it have the buffer closer to the USB connector?

Thanks!!
Reply to top
#9
Thanks Jared, your big day is coming. :)

That could be long enough to cause issues, I was having problems with 3ft of cable as well. Any extra connections increase the capacitance so the fewer the better. That's why the header pins are better, one less connection. I was using a 6" patch cord on USB once that worked good, switched to 6ft and nothing worked. Cable length from I2C adapter to relay module can be much longer, but that gives you 8 wires instead of 2.

Whenever you get that long boot nothing will work properly, I assume that only happens if buffer is mounted or I2C adapter is used?

Other users probably don't have anything connected to the ports but the AC power bar, maybe one or two have an Atlas circuit connected but with the buffer it's not a problem. I've been shipping a 6ft USB cable to connect the power bar which uses the USB port, I've tested with 3 of these cables connected together and it was ok. Standard I2C can handle 400pf of capacitance, the buffer increases that to 1800pf on the output, they claim up to 18m of cable.

That I2C expander I was talking about has 4 USB ports, one buffer for 2 ports. This would plug into the controller USB but would need to be short cable, maybe only 6".
Reply to top
#10
The short cable did the trick, everything works perfectly now, and boots up quickly. I remember reading that you had trouble with 6m cables so I never thought a foot or 2 would be trouble but I guess so! Once I clean up my installation to something less than an embarrassing rats nest I'll post some pics in the Gallery forum.

Out of curiosity, because I'm a geek like that, what made you pick I2C vs. the UART ports on the Due? I imagine it would have made the power bar end a little more complicated?
Reply to top
#11
Great, glad to hear, hopefully it's smooth sailing from here. Cable is definitely the downside to I2C, when I started Gen3 I did some testing on Gen2 to see how much cable could be used. I uploaded the I2C address scanner sketch and connected more I2C devices and used about an 8ft ethernet cable, the scanner found all the addresses and when I changed the address on external device the scanner saw the changes so I figured ok no buffer is needed for a single power bar connected with 6ft cable. So my first set of Gen3 boards had no buffer and only 1 USB port. After connecting things the scanner still saw the changes but with real code to control the AC power bar there was issues just like you experienced, in the end I could only get it to work reliable using 1ft cable, so needless to say those boards were a waste and I then added that buffer that gave you trouble. Since your trouble I've made some changes to the circuit so next set of boards should be better in regards to USB ports.

I'm using a UART port for communicating with the display, originally I was using all 3 UART ports for display but now only using one. The other 2 are now redundant backups, in the code when the controller is turned on it scans the 3 UART ports and uses one that's available, if something was to happen on one of the ports it'll move to the next port. I used UART over I2C for this task because of cable issues, with UART 100ft ethernet cable has been tested with no issues. :) Also at one point I had an "expansion hub" for gen1 hardware which also communicated with UART to main controller, this became more difficult to manage as there was 2 devices using the same UART port, because no addresses for devices timing was important. Using UART for the power bar wouldn't be practical as there are only 2 UART ports remaining and I want ability to add many more devices which makes I2C the go to.
Reply to top
#12
Hi Rob,

I plugged a second I2C module into the first one (still on the 1" cable) and the long boot issue came back.. It seems weird that the one module would work, and then just adding maybe a half an inch of trace/header would overload the bus? I have some male PCB mount USB connectors on order, when they get here I'm going to directly solder both boards to the USB connector, maybe that will help. I haven't reinstalled the buffer yet, if the direct solder board doesn't work I may try that. I might try to find a greater-than-8-channel adapter board/chip as well.

Can you post the link to the adapter boards you originally used? I'd like to get a couple of those and see if the maybe the brand of board I'm using is causing issues..

Thanks!
Reply to top
#13
Hi Jared, that's no good and yeah that extra device could be the tipping point. Each device adds about 10pf of resistance and then the connections, traces and wire seem to make up the bulk of it, different quality wire also makes a big difference. I'll bet it's not your adapter boards, it's just the nature of I2C, unfortunately buffers are required with setups like this. I just had 2 power bars connected with 6ft USB each and no issues because buffer was doing what it should. I don't use the adapter boards, I made my own board for the power bars which has the IC mounted.

One option I should have mentioned long ago and sorry I didn't, because you're building you own power bars you don't even need those adapters, you could connect the relay boards directly to the controller boards by using the I/O pins on the Arduino. Originally I was using 16 pins for 16 relays, because lots of people are already using those pins I'm leaving that in the code so they don't need to upgrade. The downside though is obviously more wire required but cable length won't be a problem up to about 15ft per power bar. They use pins 32-42 and 44-48.

Of course you can try installing the buffer again or I can send you that external buffer that should work with a short cable to controller.
Reply to top
#14
Looks like reinstalling the buffer did the trick. I have both boards attached and everything seems to be running fine now. Thankfully I ordered two of the buffers when I did!

If I have any more trouble with the I2C (I mean, what else could go wrong??  Wink ) I'll figure out a way to add pins to the underside of the board to go directly from the arduino to the relay board. Good to know that's an option!

Thanks again!
Reply to top
#15
Ah wonderful, great job! Sorry for all the headaches it caused you, hopefully you can package it all up now, looking forward to seeing your setup.
Reply to top


Forum Jump:

Current time: 03-28-2024, 10:58 PM