T3-BB Controller Restarts Automatically

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.

image

1 Like

Updated the firmware, all programs exit each scan but issue remains.

We just removed all the programs from the controller and rechecked unfortunately problem is still there.

FYI: Other T3-BB which is in operation with the same program, runs correctly.

We may have to get the controller back from you and we’ll get it on the test bench.

Please write via email and we will discuss the options in more detail.

image001.jpg

Program.txt (360 Bytes)

10 TEMP_SET = 49
20 RH_SET = 55
30 H01_SET = 48
40 H02_SET = 47
50 H03_SET = 46
60 OUT1 = PID1
70 OUT2 = PID2
80 OUT3 = PID3
90 OUT4 = PID4
100 TEMP_ER = ABS ( Z_TEMP - TEMP_SET )
110 RH_ER = ABS ( Z_RH - RH_SET )
120 IF TEMP_ER = MAX ( TEMP_ER , RH_ER ) THEN VAL_CMD = PID5
130 IF RH_ER = MAX ( TEMP_ER , RH_ER ) THEN VAL_CMD = PID6

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 full *.prog file, you can save it by going to T3000 → file → save as.

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

image001.jpg

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.

2 posts were split to a new topic: Saving variables through a power cycle

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

Fandu will check this, thanks for good feedback once again.

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.

We have Ted’s program but have not seen the reboot so far, testing for several hours now. You could send on your program and we’ll watch it too.

@tdawgtoo: I notice you sent 4 programs, any particular one we should watch?

It’s the Chiller.prog that is the most critical. Although the Hotwater.prog reboots sometimes too.

Ted

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.

We’re not supposed to have to deal with loops, solution is supposed to be transparent. It will be soon.

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.

2 posts were merged into an existing topic: Fixing a Bricked Device