Question on Logix5000 Scan Sequence

[notredamon]

This should be a pretty easy question, would just like to have it explained a bit so I can understand it.

In the attached program, why does the output_latch bit never get latched?

 

[widelto]

Welcome to the forum.

Is the same Output_Latch used in any other part of the program ?
Is the Test_Timer used in any other part of the program ?
Is this routine activated ?

 

[mylespetro]

Welcome to the forum.

Is the same Output_Latch used in any other part of the program ?
Is the Test_Timer used in any other part of the program ?
Is this routine activated ?

These are the ones that always get me. Is the rest of the routine definitely running? I often forget to put in the JSR in the routine before it (or in a routine with all JSRs if that's the way the program is built).


EDIT: Don't know if this is the issue, but you have a 0 in the preset of the timer, not sure if that would just instantly be considered "DONE" or if it just won't work. Try putting an actual value in there.

 

[Ken Roach]

Welcome to the PLCTalk Forum community. I like your username, I have family and friends who went to ND Maryland, if that's the reference.

One reason that a similar rung would not turn on that bit is that the .EN and .DN output bits are mutually exclusive. Once a Timer is Done, the Enable bit turns off.

The other reason is that a timer always requires at least two scans of the PLC program to complete.

On every scan after the Timer is enabled, the operating system compares the elapsed number of CPU clock cycles to the Preset in milliseconds. If the accumulated time is equal to or greater than the preset, the .DN bit is set.

But if the Preset is zero, the operating system doesn't evaluate the accumulated time instantaneously and set the .DN bit on the very next instruction.

Because your sequencer increments the Sequence Step on the very next rung, the Timer is disabled on the next scan, and never compares its accumulated cycles to the Preset.

 

[Phrog30]

The other reason is that a timer always requires at least two scans of the PLC program to complete.

Unless you put two timers in series with the same address. Then it will update in the same scan. We use this when it's important to get a DN bit the same scan with a zero preset. PlantPax uses this "trick" a lot.

 

[notredamon]

One reason that a similar rung would not turn on that bit is that the .EN and .DN output bits are mutually exclusive. Once a Timer is Done, the Enable bit turns off.

The other reason is that a timer always requires at least two scans of the PLC program to complete.

Thanks much for explaining this!

 

[Ken Roach]

We use this when it's important to get a DN bit the same scan with a zero preset

OK, now you've got me curious.

What possible reason could you have for needing to get a .DN bit output from a Timer instruction in the same scan, without a measurable amount of elapsed time ?

That's literally an identity function, 1=1.

My guess is that "because we need to account for times when the preset is zero and don't want a branch where we use "EQU TimerTag.PRE 0".

 

[blftech]

After studying the logic I thought the output bit should latch, so I loaded it into my Trusty Logix controller and lo and behold it does.

Makes sense to me. As soon as the controller goes into run mode it loads the 5 with the move and the done bit is true at the same time the timer is enabled.

This latches on the output and then moves the 6 into the Sequence_Step tag.

 

[bernie_carlton]

Ken, don't you mean that .TT and .DN are mutually exclusive?

 

[OkiePC]

The TON instruction in and of itself does not have a rung out condition, so the next in series instruction is executed even though it "looks like" the line is attached to the EN bit.

I suspected that the rung should evaluate true all the way across, but don't have hardware to test it.

 

[Ken Roach]

Can I go back and delete that post in embarrassment ? Nah, better to leave it up as learning experience.

This specific code doesn't make a lot of sense, but I mis-thought a basic principle: the .EN stays on any time the instruction is true. .TT and .DN are mutually exclusive, but .EN and .DN are both true if the instruction stays true and the elapsed time completes.

Because the first instruction moves a 5 into the Sequencer, the middle rung is true every time it executes, so the timer does complete, because it scans more than once.

Moral of the story: If someone shows you code that doesn't work the way they expect, run it in a controller to be sure your assumptions are right.

 

[AustralIan]

Grey power rail when you are online means you aren't calling this routine anywhere in your code.
This hasn't always been the case, older versions would have it always green.
Let us know if calling the routine gets it to work as you (and we) expected.

 

[parky]

Looking at the code it does not make any sense to have a timer as 0, if the pre set was put to say 10 then on seq. equals the timer would start but as the next rung increments the seq. number on the next scan the the compare would be false so timer would reset as it is a normal TON. so why have a timer anyway.

 

[Phrog30]

My guess is that "because we need to account for times when the preset is zero and don't want a branch where we use "EQU TimerTag.PRE 0".

Exactly. Using a compare would work. If you needed multiple places in the program, using two timers would be better in my opinion, cleaner as well.

Just one example, a motor AOI with horn timer (horn before start), with zero preset and one timer the horn will blip. With two timers in series and zero preset it will not. Photo from PlantPax.

 

[ASF]

I have learned two things today.
1. Timers take a minimum of two scans to complete, regardless of preset
2. PlantPax makes my OCD cry