Ladder Clarification

[J. Feldman]

Hi All,

I am looking over some Ladder Logic, and struggling to understand it fully. I know essentially WHAT it does, but not HOW it works. Here's the logic in question:



So to my understanding:
So this rung is used to control a pyrometer checking the temperature of a furnace. It checks the temp for 10 seconds, and records it. Based on the recorded temp, the setpoint temperature for the furnace, and a known temp increase per minute, it then calculates how long before it should check again, and feeds that value into the preset for Timer[16].

The part that is confusing me is the TOF timer (Timer[16]). I know it is being used to check when the pyrometers should check the temperature again, but it is confusing how this actually happens. The parts I highlighted are where it's hard to parse in my brain; TOF timers are confusing to me. If anyone could help explain better what is fully happening here, I'd be very appreciative!

 

[J. Feldman]

Ok, I know I JUST posted this but I think I had a realization! I guess I'll think out loud here and people can jump in if I'm wrong/right?

When the furnace is not in HOLD (first condition), and is in the right step (2nd condition), and TOF timer (T16) is NOT DONE, then the pyrometer opens and takes its measurement. The TON Timer (T15) also starts counting.

Once 10 seconds pass, the TON timer is DONE, so the temperature is recorded, the time until next check is calculated, and sent to .PRE for T16. Now, because T15.DN is TRUE, all conditions are met, and T16.DN is turn ON, which makes the rung condition FALSE, closing the pyrometer, and causing T16 to count up, until the set .PRE, which will cause the whole loop to repeat.

At least I think?

 

[plvlce]

Generally correct as far as I can see.

When the furnace is not in HOLD (first condition), and is in the right step (2nd condition), and TOF timer (T16) is NOT DONE, then the pyrometer opens and takes its measurement. The TON Timer (T15) also starts counting.

The one comment I have is that the actual measurement appears to take place at the moment Timer[15] finishes counting, not as soon as the rung as a whole becomes true. (ie the value is examined when pyrometer has been energized and open for ten seconds)

 

[drbitboy]

Generally correct as far as I can see.

The one comment I have is that the actual measurement appears to take place at the moment Timer[15] finishes counting, not as soon as the rung as a whole becomes true. (ie the value is examined when pyrometer has been energized and open for ten seconds)

I agree, also note that

1) T[15].DN is a one-shot, so the measurement is made and used only once; this is another aspect of what @plvlce wrote.

2) The T[15] TON timer, once started, will reset and not complete IFF either of the first two rung conditions (hold and step 50 tests) change before that TON timer completes. The T[16] TOF timer, on the other hand, will always complete once it has started, so there is no way to shorten that 15-minute cycle, once started. For that matter, there is no way to lengthen it either, since T[15].DN is a one-shot.

3) I am pretty sure the [XIO T[16].DN] will evaluate to True on the first scan (e.g. after a power recovery), but maybe not (there may be some special pre-scan magic?); it is probably unlikely that those hold and step 50 tests will be true so it may not matter, but an [XIO <first_pass S:1/15?>] would be one way to prevent this from firing until the second scan.

 

[J. Feldman]

Thanks for the feedback and clarification!

I misspoke on when the temp. is saved, it is indeed once T[15] is done.

1.When you say it's a one-shot, you mean per loop, correct? Once the rung goes FALSE, then TRUE again, a new measurement is taken once T[15].DN goes true.

2. FWIW T[16].PRE will update based on Temp, so as the furnace heats up, it should get to T[16].DN faster! I believe you are right about the true on first scan, but as you pointed out, it will not be at step 50 yet, so I think it is ok that way.

On this front, I am running into an issue where, once the Furnace gets to ~1 minute from its Setpoint Temp, the Pyrometer is continuously on! I am not sure why, any thoughts? Thank you again for helping out this newbie! I've learned so much the past 4 months and can't wait to learn more!

 

[OkiePC]

Be aware that with a TOF (I sorta hate them) the DN bit is true at the moment the TOF is enabled and remains true until the TOF is not enabled plus the duration set by its preset.

So after that TOF branch (or the whole rung) goes false, the timer starts timing and sets the TT bit. When the timing is complete, the TOF will turn OFF the DN bit. Backwards as hell when you are studying them live.

In most cases you can switch a TOF to a TON and make it easier to follow online without cluttering up the logic much if any.

In your case, keeping that understanding in mind, do a cross reference on Timer[16] and see where all of its bits are used in the code.

 

[drbitboy]

1.When you say it's a one-shot, you mean per loop, correct? Once the rung goes FALSE, then TRUE again, a new measurement is taken once T[15].DN goes true.

Yes: "one-shot" means true for exactly, and therefore not more than, one contiguous scan at a time.

 

[OkiePC]

I overlooked the Timer[16]/DN bit at the beginning of the rung. That would effectively mean that you take a reading after the 10 second delay, then after the calculated delay set by Timer[16], wait ten seconds and take another reading so long as you are still in this same step.

 

[drbitboy]

On this front, I am running into an issue where, once the Furnace gets to ~1 minute from its Setpoint Temp, the Pyrometer is continuously on! I am not sure why, any thoughts? Thank you again for helping out this newbie! I've learned so much the past 4 months and can't wait to learn more!

We don't know the details of the rest of this process, but from what we can see and interpret from comments is that the temperature remaining between the last measurement and the target temperature is divided by Operation_Variables[70], which I am guessing is an expected (or maximum?) degrees/minute rate of temperature rise, so (target - current, deg) / (rate deg/min) predicts a minimum number of minutes in the future, call it MNM, when it would be wise to check the temperature again, and (MNM*1000*60) converts that to milliseconds for T[16].PRE.

So as the temperature gets close to the target, that number gets small, and if the divide by Operation_Variables[70] is placed into an integer value (Operation_Variables[34]), the result will be rounded to 0 once the remaining temperature difference to target (Operation_Variables[33]) is less than half of Operation_Variables[70].

 

[J. Feldman]

We don't know the details of the rest of this process, but from what we can see and interpret from comments is that the temperature remaining between the last measurement and the target temperature is divided by Operation_Variables[70], which I am guessing is an expected (or maximum?) degrees/minute rate of temperature rise, so (target - current, deg) / (rate deg/min) predicts a minimum number of minutes in the future, call it MNM, when it would be wise to check the temperature again, and (MNM*1000*60) converts that to milliseconds for T[16].PRE.

So as the temperature gets close to the target, that number gets small, and if the divide by Operation_Variables[70] is placed into an integer value (Operation_Variables[34]), the result will be rounded to 0 once the remaining temperature difference to target (Operation_Variables[33]) is less than half of Operation_Variables[70].

Thank you so much for your help/feedback! You're exactly right with the function of the rung. I watched it run live and arrived at the same conclusion you just laid out, about it rounding to 0. I am going to add a rung that checks if the T[16].PRE would be <= 0, and if so, puts in 90 seconds instead. I think this should clear up the issue.

Also, shoutout to a fellow Rochesterian; I just moved from there!

 

[drbitboy]

Also, shoutout to a fellow Rochesterian; I just moved from there!

Hey, cool! I like Rahch'str, but I am a wee bit jealous of your proximity to the ADKs. I grew up in Schenectady (Dad was GE).


Huh, so Operation_Variables is an INTeger file then. You realize that 90s will be the .PRE for only that case then? The only possible values from the calculation are 0, 60, 120, ...

 

[J. Feldman]

Hey, cool! I like Rahch'str, but I am a wee bit jealous of your proximity to the ADKs. I grew up in Schenectady (Dad was GE).


Huh, so Operation_Variables is an INTeger file then. You realize that 90s will be the .PRE for only that case then? The only possible values from the calculation are 0, 60, 120, ...

I am from the area originally, and it IS nice to be back by the ADKs and family!

Any chance you could elaborate here a little bit, and what you mean? Operation_Variables is a DINT, but I am confused about the limited values you lay out. For example, the last live calculated value was T[16].PRE is 17 minutes (1020000). I appreciate the help/feedback!

 

[plvlce]

I am from the area originally, and it IS nice to be back by the ADKs and family!

Any chance you could elaborate here a little bit, and what you mean? Operation_Variables is a DINT, but I am confused about the limited values you lay out. For example, the last live calculated value was T[16].PRE is 17 minutes (1020000). I appreciate the help/feedback!

I suspect drbitboy is referencing the fact that if all tags and constants involved are integers, the CPT instruction will round intermediate values.

EDIT: That is to say, the CPT instruction as shown will normally only output increments of 60s; your proposed addition of forcing it to 90s would be the only possible way a time of 90s could ever occur.

17 minutes is a multiple of 60s, no inconsistency there.

 

[drbitboy]

I suspect drbitboy is referencing...

exactly.

(OpVar / OpVar[J]) * 1000 * 60

​

will yield a result that is rounded to the nearest minute, which is different than, say,

(OpVar * 1000 * 60) / OpVar[J]

​

 

[J. Feldman]

Ah, understood, thank you for the clarifications. Learning something new every day!