C bit staying on with no program code execution.

[franji1]

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

Retentiveness is a design decision.  Assuming after a power cycle (or PGM->RUN transition), all the control memory should be OFF (by design), then you are correct.  But if after a slight power glitch, you expect your machine to run where it left off, keep everything retentive.  It appears even a slight power glitch you expect everything to be OFF (i.e. just about everything needs to be non-retentive).

It's the C bits that also need to be non-retentive, i.e. they need to turn OFF after a power cycle or PGM->RUN transition.  Realize that with the AUTO program NOT running after a power cycle, its logic CANNOT turn the C bits OFF (or ON) - they will just be in their retentive state after a power cycle.  Hence, why C bits probably need to be non-retentive.  It's the same as an unused retentive C-bit - it will be OFF or it will be ON after a power cycle - there is no logic driving it ON or OFF, the retentive value just "is".  Just make most things non-retentive (i.e. go to a state of 0) after a power-cycle or PGM->RUN transition.

[jrayb]

I always set a RSTR for in first scan for any C-Bits that are powering an output for any motor on all of my programs. It solves many issues & I have never had a motor turn on when there has been a power outage.

[RBPLC]

Realize that with the AUTO program NOT running after a power cycle, its logic CANNOT turn the C bits OFF (or ON) - they will just be in their retentive state after a power cycle.

I understand this to mean that with AUTO in retentive, after a controller power cycle, AUTO will pick back up running even if RUN has not been initiated for AUTO. This would essentially pick back up where it left off and potentially be able to terminate bits of interest. I guess I see the problem with this being that if you have a power glitch/controller cycling, all of your outputs are dropping out. Upon restart you're potentially jogging all of your equipment and potentially in an unsafe manner.

Then I ran the program again and this time 3 bits stayed on after stopping execution, leaving 3 big motors running!

This doesn't sound like a reboot/power cycle issue.

[franji1]

Then I ran the program again and this time 3 bits stayed on after stopping execution, leaving 3 big motors running!

This doesn't sound like a reboot/power cycle issue.

Agreed.  When you say "stopping execution", what do you mean?  Do you mean that AUTO program EXITs (i.e. you executed an EXIT instruction from AUTO.) or ?

[BobO]

Then I ran the program again and this time 3 bits stayed on after stopping execution, leaving 3 big motors running!

This doesn't sound like a reboot/power cycle issue.

Agreed.  When you say "stopping execution", what do you mean?  Do you mean that AUTO program EXITs (i.e. you executed an EXIT instruction from AUTO.) or ?

He's got a mix of EXITs and HALTs. Without more info on how the machine runs, it's difficult to say what may or may not be an issue, but you have to peel the onion. Having retentive C bits directly driving outputs, where the only thing driving the C bits are OUTs in a non-retentive program block is a formula for trouble. He needs to start with that.

[BobO]

I understand this to mean that with AUTO in retentive, after a controller power cycle, AUTO will pick back up running even if RUN has not been initiated for AUTO. This would essentially pick back up where it left off and potentially be able to terminate bits of interest. I guess I see the problem with this being that if you have a power glitch/controller cycling, all of your outputs are dropping out. Upon restart you're potentially jogging all of your equipment and potentially in an unsafe manner.

Correct. This is first issue I'd like him to resolve. Either AUTO needs to be retentive, or the C bits need to be cleared by some other method (make non-retentive or clear on startup). It's up to the developer to decide which makes best sense, but retentive C bits driving physical outputs without any logic driving them at startup is at least one formula for trouble.

I agree that there is likely more to the issue, but you gotta clean things up as you identify them. I don't see how it could happen in the code, but I'm wondering if there is some unexpected interaction between HALT and EXIT. HALT was really intended as an ESTOP, and it is generally my preference that if the supervisor wants to end execution early, that it sets a request and lets the program itself EXIT. With that said, they should work the same, and as far as I know they do. I'm just wondering if there is some subtle interaction that I'm not seeing. There is an answer and we'll figure it out.

[RBPLC]

As many have said, the best way to avoid unexpected behavior is to get the stuff set the way it needs to be on first scan. A while back, I had been using HALT but after reading through the documentation (like you said) it was advised against using HALT in favor of EXIT. I was wondering if he was using HALTs in the Program.

By the way, I hope you guys are getting back up on production. I've placed an order for 24 EBCs, 24 DM1Es and about 150 various analog/digital modules.

[Greg]

A couple of things:
1. I can duplicate this kind of bad behavior by inserting a REBOOT instruction and randomly rebooting the PLC while having retentive C-bits and yet non-retentive Program code block using OUTs for the C-bits.
2. If you make a program change to this type of situation, you will get a Warning from Do-more Designer on the Program Check. It will say something like:

AUTO#3(@3)   W424 Using retentive element (C109) in OUT coil within a non-retentive stage (AUTO.S1)

This warns you of a potential issue you need to address or at the very least be aware of.

[BobO]

As many have said, the best way to avoid unexpected behavior is to get the stuff set the way it needs to be on first scan. A while back, I had been using HALT but after reading through the documentation (like you said) it was advised against using HALT in favor of EXIT. I was wondering if he was using HALTs in the Program.

I don't mean to suggest that it won't work or should be feared, it's really more of intent. HALT is like killing a process. Brute force. Prevents the program from deciding the best way to end. Requesting the EXIT allows the program to do whatever it wants to get to shutdown.

By the way, I hope you guys are getting back up on production. I've placed an order for 24 EBCs, 24 DM1Es and about 150 various analog/digital modules.

Combination of factors. Parts, COVID, retirements, etc. There are bright spots and dark spots. Intel has told us not to expect any of certain parts for a while, but we think we may be getting others. We already have a large supply of parts to build CPUs, so that's one bright spot. Reps have suggested that it will start improving by summer, but who knows. It's really frustrating for everyone.

[BobO]

Gary may or may not post, but he confirmed via email that it was because the operator was killing power. Since these posts hang around forever, just wanted to make sure that was entered into the record. It's working fine now.

[RBPLC]

What was the resolution? AUTO to retentive or other?

[BobO]

What was the resolution? AUTO to retentive or other?

He's clearing the Cs on startup. Do-more is a little different than DL, in that Cs are retentive by default. They are cleared on program to run, but not at powerup. We probably should've done that differently, but once things get done, we try not to change them.

[Garyhlucas]

Yes it was the default retentive bits that caught me off guard.  On this project I had no need for the program to remember any states, and I thought default was non-retentive. One of the hazards of long stretches with no programming.

Thanks everyone for help.