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.
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.
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.
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.
Ted: I wasn’t able to get our controller to do a reboot after I loaded your prog file and watched it for several days. I did add some code to avoid problems with looping programs
You can update rev51.4
To be done: Add rev notes for 51.4 here.