T3-TB Output wiring to control RTU

I need to control a RTU via it’s R, G, Y1, Y2 and Y3 terminal inputs (only cooling)

I have connected R to DO4(28) and jump the R to DO5(29), DO6(30), DO7(31).
Then connected DO4(42) to the G, DO5(43) to the Y1, DO6(44) to the Y2 and DO7(45) to the Y3.

Is this wiring correct?
Is there any other wiring scheme that may work?

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.

Thanks Maurice.
I understand that.

Question, How can I check that the output is working?
When the Output is ON, Can I check for continuity between the two connections of the Output?

The problem is the output is ON, but no cooling stage is turning ON.
When I check for continuity, there is none.

Another thing is that all DO presents the same issue. AO does not present any problem.

Thanks Maurice;
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?

Please advise

1 Like


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.

Any advice?

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.


Sorry for responding so late …


  1. I found that the controller is dropping variables on the variable list.
  2. Also, a persistent error about a reappearing “coma” in a program.


  1. 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.

  1. 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.

Note that reseting the controller, updating to new firmware did not solve any of these issues.

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.

1 Like


I replace the misbehaving controller. It started to drop variables again.
I would like for TEMCO to check the hardware under it’s warranty.

Can you provide instructions for sending the controller back?

We can certainly repair the device if there’s a hardware problem but I would really like to get to the root cause here. If we receive the unit and it works just fine as I expect then we have wasted a lot of $ on shipping. Please send us on a copy of the prog file and we will get to the bottom of this.

1 Like

Program file was sent on May 15.
I’m including it again here.

RTU1_BKUP_41723.prog (65.6 KB)

Hello Maurice:
Did you got a chance to check the programming?

We have loaded your prog file before and found no problem. I will continue to observe and see if there is any problem.

I’m still having this problem (missing variables) and is interrupting the normal operations of some areas in the building, requiring several service calls per month.

Question, Does the T3-TB controller MUST have communication to the T3000 software all the time?

T3000 doesn’t have to be online, the T3 controllers can run fine for years on their own including through power cycles.

Are there other controllers in the system, particularly ones writing to the outputs of the T3 devices? I ask because we had one project where our controller was doing what it was supposed to but there was an external master, one of his other devices in the system, which was using priority arrays with unexpected results.

Losing the vars though, this is very unusual. If its just a single controller doing this then try swapping it out please. We can arrange a replacement if you dont have one on hand.