Studio 5000 TON enable bit stuck

[michaelpappas]

I'm using one TON (called SystemTimer) throughout a program that I change the .PRE given different conditions. I'm porting an IDEC ladder over to be used on an AB PLC The IDEC ladder used one global timer that was reset in a similar way. When the program moves to a different phase of the process it will MOV the new timer PRE and a new set of conditions will enable this same timer, thus making it reset.

The issue is that the timer will hit the .PRE amount and the DN bit will go true but it will not stop being enabled. I looked at all of the cross references for SystemTimer.EN and found that one rung is causing the issue. I for the life of me can't figure out why this rung which is not true is still causing the timer to be enabled.

cross references

rung in question

When I swapped the SolenoidRetract XIC and Autoswitch1Bottom XIC for a bit that I could toggle on and off I could get the SystemTimer.EN to go false and the timer would reset as I expect.

Am I missing something here? Could there be some phantom bit that is enabling the timer that I can't see in cross references?

Thanks,
Michael

 

[OkiePC]

If you are using the TON instruction with the same Timer address in multiple locations, if any of those rungs have a "rung-in-true" condition preceding the TON, the EN bit will be set. You should probably only need one TON instruction for the timer as long as it is always being scanned, and can use the RES (reset) instruction where ever you want to reset it after loading a new preset (just don't hold the RES instruction true or it will keep it from timing).

Since you also need a different set of conditions to operate the timer for various functions, you may want to OTE different bits based on those condition for each machine state, then put those bits on parallel branches to enable a single instance of the TON. You also need to be sure that there are not overlaps where more than set of conditions is staying true when it shouldn't. If those were all branches on a single TON rung, it would be easy to find if more than one was true.

This sounds like a case of machinery control with conditional subroutines which sounds good on paper to a computer programmer, but is a bigger PITA for a PLC guy than it is worth 99% of the time. When you stop calling a condition routine with an OTE instruction, what happens to its address? Nothing. If it was on, it stays on. What about a TON? Same. It stops being evaluated, but if it was ENabled or DoNe those bits will still be set until the PLC encounters another destructive instruction that operates on that element.

Conditional subroutines in ladder logic should be reserved for data handling, not machinery control, but if that is not what is going on here, ignore my last paragraph.

 

[dmroeder]

The first problem I see is that the same timer tag is used in 7 TON instructions.

 

[michaelpappas]

I understand that it might not be the best logic design decision to use the same timer tag in 7 places but I was instructed to try to mimic the IDEC code.

Digging into what's enabling the timer a little more, here's what's happening to enable the timer. I added a unique bit on a branch next to each time I was providing instructions to enable the SystemTimer to see where it was being enabled. SolenoidRetract is false which should mean that this rung doesn't evaluate as true for the timer or the retractTimer bit right?!

 

[michaelpappas]

When I look at the cross references for retractTimer the only place it's being written to is on this rung.

 

[OkiePC]

It looks like you are seeing the result of a conditional routine that stopped being scanned. When you monitor it, the states of the addresses are being updated by your programming software, and it shows your new test bit is true, but the SolenoidRetract bit is not.

The PLC is no longer being told to do anything with your test bit so it left it as it was last told to leave it (on).

 

[PreLC]

I understand that it might not be the best logic design decision to use the same timer tag in 7 places but I was instructed to try to mimic the IDEC code.

Digging into what's enabling the timer a little more, here's what's happening to enable the timer. I added a unique bit on a branch next to each time I was providing instructions to enable the SystemTimer to see where it was being enabled. SolenoidRetract is false which should mean that this rung doesn't evaluate as true for the timer or the retractTimer bit right?!

View attachment 68223

In this rung, try Ctrl+T on retractTimer to check if you can turn it on or off. If you can freely manipulate it, then this routine is not being scanned.

Can you also post screenshots of other references to the TON? Also, are these separate routines being scanned at all times, or are there conditional JSRs in the main routine?

 

[joseph_e2]

I think they're probably on the right track, but another thing to do is run a cross reference on SolenoidRetract. If it's being turned on above this rung and off below it, Studio 5000 will read it as "off" but it will be "on" while the TON's rung is evaluated.

 

[drbitboy]

Two possible solutions:

• As has already been suggested, use eight separate timer objects (SystemTimer_01, SystemTimer_02, etc.). With this there would probably be no need to update the presets. While it is a change from the IDEC code, it does mimic in spirit, and memory is cheap.
• Wherever the code updates the .PREset for the single timer, issue a corresponding RES SystemTimer; that will reset the .DN bit and prepare that timer object for the next routine in which it will be used (I assume that on any one scan cycle, only one of the _NN_... routines will typically be called).