C bit staying on with no program code execution.

[Garyhlucas]

My boss came in this morning and asked why a blower was running that was not needed after I installed a BRX36 to replace an AB1400 in a scrap grinder.  I hooked up a PC and looked at program code and could see a C9 bit turned on driving the output for the blower.  No programs were running except Main and Top and Bottom of scan.  I use indirect addressing for all I/O.  There are just two programs and neither one was running.  In the program with stages all the stages were off.  Yet that bit stayed on.  I was able to force it off and when I unforced it stayed off.  Then I ran the program again and this time 3 bits stayed on after stopping execution, leaving 3 big motors running!

I was taught back in the days of the TI405 about using OUT in stages instead of SET and turning on the same bits as you jump stage to stage to keep them on as needed or they just go off.  I have dozens of programs over 30 years that work that way, this is the first time I have seen a failure like this.  It could be hazardous.

I cleared the PLC completely and reloaded the program and so far it seems to work correctly over the past hour.

[Greg]

No HMIs talking to this BRX36? Is the REST API feature ON? Could another PC be doing this? You might consider whitelisting valid IP addresses that have access to the BRX36's network.

[BobO]

No HMIs talking to this BRX36? Is the REST API feature ON? Could another PC be doing this? You might consider whitelisting valid IP addresses that have access to the BRX36's network.

The only way to write C bits remotely is through the native Do-more protocol, so unless it is an HMI or some other PLC doing it through RX/WX, it isn't possible through REST, Modbus, or DL RX/WX.

[BobO]

My boss came in this morning and asked why a blower was running that was not needed after I installed a BRX36 to replace an AB1400 in a scrap grinder.  I hooked up a PC and looked at program code and could see a C9 bit turned on driving the output for the blower.  No programs were running except Main and Top and Bottom of scan.  I use indirect addressing for all I/O.  There are just two programs and neither one was running.  In the program with stages all the stages were off.  Yet that bit stayed on.  I was able to force it off and when I unforced it stayed off.  Then I ran the program again and this time 3 bits stayed on after stopping execution, leaving 3 big motors running!

I was taught back in the days of the TI405 about using OUT in stages instead of SET and turning on the same bits as you jump stage to stage to keep them on as needed or they just go off.  I have dozens of programs over 30 years that work that way, this is the first time I have seen a failure like this.  It could be hazardous.

I cleared the PLC completely and reloaded the program and so far it seems to work correctly over the past hour.

That's concerning. SET leaves the state active, OUT gets shut off through termination. If you have an example of a program that is leaving OUT coils enabled after termination of the stage, program, or task, I would really like to have the code.

One major thing happening when you cleared and reloaded the PLC is the clearing of all retentive memory. I have seen cases where stuff was just a little off until image register was cleared, and then everything was fine. I have had my suspicions as to why it might be, but I've never been able to prove anything, things related to how run mode edits try very hard to not bump things. If it were to happen again, please use the retentive memory manager to make a snapshot of the entire image register.

[Greg]

...it isn't possible through REST...

Oops. Yeah, I keep forgetting that.

[Garyhlucas]

Bob,
No HMI, No networking, just my PC to the ethernet port, no switch.  I'll send you the program.

This all started because the grinder manufacturer built the machine with 5 start and stop buttons to start 5 motors.  You had to start in one sequence and stop in reverse, and you had to wait several minutes for chips to clear out.  Stop quickly or in wrong sequence and bad stuff happens, at least 5 times so far!  Manufacturer wanted $6000 to come out and reprogram.  AB wanted $700 for software to talk to AB1400, only one in the plant.  Manufacturer wouldn't give us the program, it was "proprietary"  With just the wiring diagram I wrote a new program in one day, two days to install a BRX36 and 3 input modules and convert outputs to 24vdc.  $620 for the BRX and modules, sell the AB1400 and two modules for $600 on Ebay.  I no longer need an oddball spare PLC for like $1100.   Win Win Win!!! 

We now have 8 BRX36 plcs in the plant and one spare, with 3 more coming soon.

[BobO]

Nothing you are doing should be sensitive to known issues, but for reference, what firmware version are you running?

[Greg]

We now have 8 BRX36 plcs in the plant and one spare, with 3 more coming soon.

Do the other 8 BRX36 PLCs have a similar function as this one that is failing? If so, do they leave C-bits ON as well?

[Garyhlucas]

All programmed in the same way and no problem.  It got worse last night, 4 bits stayed on, even through a power cycle, and tripped a 200amp 480 volt breaker when 4 large motors started at once.  I have another PLC here,  I am thinking replace this one with another and see if the problem goes away.

[franji1]

All programmed in the same way and no problem.  It got worse last night, 4 bits stayed on, even through a power cycle, and tripped a 200amp 480 volt breaker when 4 large motors started at once.  I have another PLC here,  I am thinking replace this one with another and see if the problem goes away.

If they're retentive, they will stay ON.  If you expect them to turn OFF after a power cycle, make them NON-retentive.

[RBPLC]

Which instructions are you using to turn the bits on? OUT I assume. If you're using something other than OUT, the termination behavior could be doing this.

[Greg]

All programmed in the same way and no problem.  It got worse last night, 4 bits stayed on, even through a power cycle, and tripped a 200amp 480 volt breaker when 4 large motors started at once.  I have another PLC here,  I am thinking replace this one with another and see if the problem goes away.

Sorry about that. I tried being very mean to your program and test programs in attempt to duplicate your issue. I was running some things by BobO and he had a look at your program too. He noticed your AUTO Program code block was set to non-retentive. If it so happens that the BRX power cycles, or better yet, reboots for some reason, while AUTO is running, it could possibly leave the C-bits on the OUTs in the ON state when it comes back up. So, you might check your System Log to see if there have been any PLC reboots, or you might want to set AUTO to retentive and try again, or you might want to at least utilize the $tFirstScan System Task to reset those C-bits to zero on first scan.

[RBPLC]

while AUTO is running, it could possibly leave the C-bits on the OUTs in the ON state when it comes back up

Not seeing the code, are you saying C-bits would potentially be active when controller comes back up? How would this be possible if they're non-retentive?

[BobO]

while AUTO is running, it could possibly leave the C-bits on the OUTs in the ON state when it comes back up

Not seeing the code, are you saying C-bits would potentially be active when controller comes back up? How would this be possible if they're non-retentive?

He sent it to us.

No. AUTO is his program block that is driving the C bits. It is marked as non-retentive, which means if it was running when the PLC rebooted or power-cycled, it will be off when the PLC restarts. C bits are retentive by default, so since the program block ends (by restarting the PLC) without clearing the bits, they will still be on at startup. Either mark AUTO as retentive, set the C bits to non-retentive, or clear the associated C bits in $tFirstScan.

[RBPLC]

After reading through the help file, I can't determine how setting the AUTO Program to retentive would solve the issue.