Since the T3 controllers are fully programable you can wire any output to any terminal of the thermostat. Just give the outputs a name, set the range and write the program according to your IO list and your sequence.
The REAL problem I have is that the DO are not closing. Although the programming is working, and the LED is turned ON when each of the DO’s are triggered, the DO’s do not close, there is no continuity in all of the 8 DO’s. All the 6 AO’s are good and working well.
To ADD to the situation, I have four (4) T3-TBs that suddenly and at the same time, simply the DO’s stop working.
This was a project that was already commissioned and delivered.
I need help in troubleshooting.
Sorry for the urgency, I know you have a lot in you plate.
One of the T3-TB was cleared to factory default and updated to MCU Ver. 62.9.
Of the eight DO’s, now DO1 to DO3 works.
DO4 to DO8 does NOT works.
AO1 to AO6 works.
DO4 to DO8 where the original output used to control the RTU.
I’m incline to conclude that these outputs are fried and the T3-TB needs to be replaced.
Also, because the T3 outputs are so robust, I’m incline to conclude that the problem arises from the ethernet connection. (All T3-TB are connected via ethernet).
Is there a device to protect the T3-TB from electrical surges coming through the ethernet connection?
The previous mentioned controller, after sending the new firmware again, started working correctly again. That was on Nov 2022.
This week, the same controller suffered the same original issue. It stop responding and the DO’s lock in the CLOSED position.
Send a firmware update to 63.2 (if I remember correctly) and It started working again.
My concern is that it is a repetitive pattern occurring only in one of the four T3-TB controllers installed in the facility.
Havent seen any cases similar to this to be honest. Maybe send on your prog file and we can check through that. Also could show us the ‘basic information’ screen shot, that will show us which CPU and hardware version you have there.
There is indeed hardware to protect the board from static that could enter the system through all terminals and ethernet connection as well. The issue about relays not enabling, then enabling after an update, then disabling again later… sounds like some subtle interaction between the hardware and the firmware or your program. One idea would be to swap out the controller and see if the problem crops up again at the same location.
I found that the controller is dropping variables on the variable list.
Also, a persistent error about a reappearing “coma” in a program.
Basically what I think was happening is that at some point, while the outputs where ON, the controller drops variables from the variable list leaving the output ON without any way for the programmed sequence to turn them OFF.
This even happen once to me while monitoring the system. In one of the refresh the VAR are gone!
I added additional variables duplicating the missing ones, and so far haven’t have any issue.
The “coma” error is not affecting functionality in any way. It is more of an annoyance, and is isolated. I haven’t seen this error in any other program, in the same controller or any other controller.
What happens is that after writing and saving this program, and opening the program again, a coma appears at the end of line 20. Now when I try to save the program and error occurs because floating coma’s are not allowed.
Please send us the prog file if you dont mind. We’ll delete it after testing of course. I notice you havent given names to any of the inputs, variables or outputs. This can really make debugging your programs a lot easier. Give everything a name in the ‘label’ field and it will show up in your programs to make your life much easier.