We have 2nos T3-BB controllers in two different DDC panels which are identical to each other (same IO mapping & same program, etc…) and both the systems are in operation.
One of above T3-BBs restarts automatically once in every 20-25 mins.
Behavior of the T3 while restarting;
LCD goes off with no light/texts. No communication with the PC during this time. All LED bulbs including the bulbs at AO & DO switch off. (Values which are assigned for AOs/DOs now equal to 0% /off)
Right after, all LED bulbs (including all AO & DO) and LCD begin to light up. (Values which are assigned for AOs & DOs now equal to 100% /on)
After few seconds, Outputs shows the actual values what it should be as per the program. LEDs are also lit up correctly.
This entire process takes about 1 min time period.
Controller runs again for another 20-25 mins and automatically restarts again. Programs work correctly after above restart.
However no communication between T3 & PC after this automatic restarting process. (To re-establish the communication, manual power restart is required)
No. That email refers to the problem we had regarding the communication issue of T3 controllers. Pls refer the relevant forum post; Trouble in Connecting to T3-BB & T3-TB (Controller goes offline) and glad to say that communication is now strong after upgrading to the latest firmware.
This post is for a new issue as T3-BB restarts automatically and the problem remains even after firmware is updated.
Make sure all the programs exit each scan. Gotos and Gosubs cannot loop back on themselves.
The reason behind this is that the outputs are buffered till the program exits and only after the exit is the state of the output written out to the hardware. If the program never exits this will cause problems.
Please update the firmware, if there are infinite loops in your programs the relevant program will be automatically turned off so you can at least log in and edit the programs. When you’re done you turn the program back on. In the next release we’ll put up a dialog to alert you to any infinite loops as well.
Appreciate if you could check the program what we have loaded in subject T3 for any unforeseen errors, before sending the Controller back to you to test for hardware failures.
Send on the whole *.prog file, which includes all settings, the inputs and outputs, variables and PID loops, a complete backup of the controller. You can generate the *.prog file from T3000 → File → Save as
auto-reboot on new firmwares (51.0+) too. Downgraded to V49.0 solved the reboot problem (with all others variables and prgs identical but communication problem could occur - that was my problem: unable to reach the T3-XX through my network).
Have you sent the whole *.prog file yet. What you posted up above is just the single program but we’d like to get the whole thing including the inputs, outputs, variables and so on which are stored in the *.prog file. Go to file → save as to dump all the settings in a particular controller to this file.
Maurice,
It seemed like it made more sense to put my problem here instead of a direct email. This Sunday, I went out on a limb and took my stable T3-LB’s and loaded firmware 51.3 over 49.x. I saw Fan’s fix on the Ethernet reset and just had to have it. Today, at 4p, my Chiller T3-LB went crazy. It rebooted itself, and switched all the programs to OFF. This had the result of shutting down our chiller. I know Fance built a routine into the Firmware to check for programs with loops and turn them off on reboot. Mine don’t have any loops. I am sure you’ll find the code is not as efficient as what you would write, but there are no loops. And I did not initiate today’s reboot. As I write this at 21:15, my Chiller T3’s time tab on the settings screen says it’s been running for 21 minites. Can I assume that it has rebooted again just 21 minutes ago?
I have attached the Chiller.prog file as well as the prog files for my other 3 interlinked T3’s. I would encourage Fan to put together 4 LB’s on a busy network ethernet network and load these four program back-ups on them. I realize you dont have a spare Carrier chiller there to furnish RS485 info, but maybe he will see an auto reboot in a few days of letting them run.VFD.prog (65.0 KB) chiller.prog (65.0 KB) hotWater.prog (65.0 KB) CoolingTower.prog (65.0 KB)
I am pretty sure I can reflash the 49.x firmware back on all these T3’s if that’s what you recommend.
Ted
I
I had the same problem until I downgraded the firmware to 49. No more spontaneous reboot.
Is Fance able to reset the communication chip (if the unit loose its connection within the network) without rebooting the entire unit ?
Note: my T3-LB with the latest firmware 53.1 has no reboot BUT this unit is connected directly to my router, so I assume there is no network communication problem with this one (so, no reboot)
For sure we will have implemented this to just reset the Ethernet chip without rebooting the whole controller. We just re-initialize the chip itself when the condition is detected, which is not that often but can happen.
I understand the idea but since firmwares 51.X, it seems that units with network weaknesses (…) are rebooting instead of just trying to recap the network access. My T3-TB behaves like this, and it seems that @tdawgtoo has the same kind of problem.
I like the concept of what Fandu is trying to accomplish with detecting loops and then shutting programs that he suspects are looping. But… I think it would be safer if he could develop a separate tool to do that function. I think most of the users (including me) would be happy to run that diagnostic tool if we suspected a problem. Or even if we didn’t suspect a problem.
