Latching One shots?

[steveb1475]

Just curious, have your cross referenced all of your osr's to make sure they are only used once. I know that may sound silly, but I've made every mistake in the book (at least once) and I've used the same address for more than one osr and have had this result.

Steve

[steveb1475]

Oops, just read the part where you said that you don't have any double addressed.... It's late, and I'm tired.

[Ron Beaufort]

Greetings Sportster,



first things first ... let me assure you that I don’t mean to be offensive - but maybe we need to talk about the way an OSR works ... now you might - in fact you PROBABLY DO - know everything about these little critters ... if so, I’m about to waste a few minutes of your time ... but ... the way that you have phrased some of your comments about the operation of the OSRs makes me think that a quick review might be a good thing ... if nothing else, this should at least get us all “on the same page” with the terms we’re using to describe your program’s operation ...



first let’s take a simple rung ... this is basically just a “big counter” ... one which will go much higher than a standard CTU counter ...






let’s run through a couple of program scans ...



first suppose that the input device (a part sensor) is OFF in the field ... when the processor comes to the XIC for the part sensor, it finds that the sensor is OFF ... so the XIC is evaluated as FALSE ... the processor then comes to the OSR with FALSE logic ... when FALSE logic comes to an OSR, two things happen ... first, the processor writes a ZERO into the OSR’s bit/box ... we usually call this “reloading” the OSR ... specifically, the OSR is now ready to fire when - and if - TRUE logic ever does come in ... the second thing that happens when FALSE logic comes to an OSR is that FALSE logic flows out ...



nailing this down: when FALSE logic reaches an OSR, the OSR is reloaded and ready to fire ... and FALSE logic flows out ...



continuing on ... FALSE logic reaches the ADD instruction ... the ADD instruction does nothing when FALSE logic comes in ... so the number stored at F8:0 remains unchanged ...



time marches on ... the processor makes many, many scans ... as long as the field device (part sensor) remains OFF, the OSR will have a ZERO stored in its bit/box ... and the ADD will not increase the value stored at F8:0 ...



now suppose that the input device (the part sensor) comes ON in the field ... when the processor comes to the XIC for the part sensor, it finds that the sensor is ON ... so the XIC is evaluated as TRUE ... the processor then comes to the OSR with TRUE logic ... when TRUE logic comes to an OSR, the processor checks the OSR’s bit/box to see if there is a ZERO stored there ... if the processor finds a ZERO, then he knows that the OSR has not already been fired ... next, the processor writes a ONE into the OSR’s bit/box ... we usually call this “marking” the OSR ... specifically, the processor is writing himself a little note that he is firing the OSR ... next, TRUE logic flows out of the OSR ... we usually call this “firing” the OSR ...



nailing this down: when TRUE logic FIRST reaches an OSR, the OSR is marked as fired (by writing a ONE in its bit/box) ... and TRUE logic flows out ...



continuing on ... TRUE logic reaches the ADD instruction ... the ADD instruction increases the number stored at F8:0 by one ...



time marches on ... on the next scan, the part sensor is still ON ...



when the processor comes to the XIC for the part sensor, it finds that the sensor is still ON ... so the XIC is evaluated as TRUE ... the processor then comes to the OSR with TRUE logic ... when TRUE logic comes to an OSR, the processor checks the OSR’s bit/box to see if there is a ZERO stored there ... this time the processor finds a ONE stored in the OSR’s bit/box ... this tells him that the OSR has already been fired ... next, the processor leaves the ONE in the OSR’s bit/box ... and FALSE logic flows out of the OSR ... specifically, the OSR is now FALSE - EVEN THOUGH THERE IS A ONE STORED IN ITS BIT/BOX ... many people miss this idea ... you may - in fact you probably do - already understand this ... but even so, this basic information might come in handy for others in the future ...



nailing this down: when TRUE logic reaches an OSR that has already been fired, the OSR stays marked as fired (by leaving a ONE in its bit/box) ... and FALSE logic flows out ...

side trip: in the PLC-5 processor, the nearest thing to an OSR is an ONS instruction ... this animal actually HIGHLIGHTS IN GREEN whenever there is a ONE stored in its bit/box ... this is EXTREMELY confusing to most maintenance techs who have repeatedly been told that “green means true” ... that ain’t so with an ONS ... it’s only TRUE for one scan ... EVEN THOUGH the screen paints it green ...

so that’s the rundown on the behind the scenes operation of an OSR ...

(continued in next post) ...

[Ron Beaufort]

(continued from previous post)


now let’s go back through some of the things you’ve posted lately ...

The NEQ rung with the OSR would work one time and that is it. The data in F8:15 would change and be different than that in F14:0, but the OSR would stay true or loaded. The data in F14:0 would stay the same.

sorry ... not so ... here’s a pseudo-code breakdown ...



scan 1 ...

F8:15 is different from F14:0 ...

the NEQ is TRUE ...

the OSR fires ...

store the data ...

make F14:0 equal to F8:15 ...



scan 2 ...

F8:15 is the same as F14:0 ...

the NEQ is FALSE ...

the OSR reloads ... (this is the tricky part)

do not store the data ...

do not make F14:0 equal to F8:15 ...

(but F14:0 and F8:15 remain equal anyway) ...



scan 3 ...

F8:15 is the same as F14:0 ...

the NEQ is FALSE ...

the OSR remains reloaded ... (oh, yeah ... ready and waiting)

do not store the data ...

do not make F14:0 equal to F8:15 ...

(but F14:0 and F8:15 remain equal anyway) ...



scan 4 ...

the data in F8:15 has been changed (by instructions in the STI) ... F8:15 is different from F14:0 ...

the NEQ is TRUE ...

the OSR fires ... (oops! ... there goes your plan)

store the data ...

make F14:0 equal to F8:15 ...



and go back to step 2 for subsequent scans ...



and now ... let’s take the OSR completely out and see what happens when we run through EXACTLY the same conditions ...



scan 1 ...

F8:15 is different from F14:0 ...

the NEQ is TRUE ...

store the data ...

make F14:0 equal to F8:15 ...



scan 2 ...

F8:15 is the same as F14:0 ...

the NEQ is FALSE ...

do not store the data ...

do not make F14:0 equal to F8:15 ...

(but F14:0 and F8:15 remain equal anyway) ...



scan 3 ...

F8:15 is the same as F14:0 ...

the NEQ is FALSE ...

do not store the data ...

do not make F14:0 equal to F8:15 ...

(but F14:0 and F8:15 remain equal anyway) ...



scan 4 ...

the data in F8:15 has been changed (by instructions in the STI) ... F8:15 is different from F14:0 ...

the NEQ is TRUE ...

store the data ...

make F14:0 equal to F8:15 ...



and go back to step 2 for subsequent scans ...



so do you see what I (and others) have been trying to tell you? ... the “meat and potatoes” storing of the data is EXACTLY the same whether the OSR is included or not ...



finally ... for your “unlatch the OSR” rungs ... by forcing the processor to overwrite any possible ONE condition in the OSR’s bit/box with a ZERO, you are, in effect, manually “reloading” the OSR each and every time it fires ... in that case, the OSR might as well be a “straight piece of wire” ... specifically, it will ALWAYS fire and pass TRUE logic whenever TRUE logic comes in on subsequent scans ...



I hope this helps ... but even if it’s stuff that you already knew, I’ve got a hunch that it will eventually come in handy for someone else down the road ...

[sportster]

I do not think you were being offensive. I appologize if I come off a little harsh; I know I do that sometimes...

Anyway...It finally makes sense. I did what you suggested in your one of you previous posts. Cut out rung 35 and put it in Lad 3 and removed the OSR. Works like a charm. I then went back and re-read (several times) your explaination on how the OSR works.
It was my bad habit of thinking that the OSR was only loaded for the one scan that the OSR passes true logic. When, as you pointed out, it is loaded (or marked) until the logic before the OSR is read as false. At that point it is reloaded to fire again. I was seeing the one there and thinking it should be doing something; when in fact, it shouldn't be doing anything until it goes false again.

Did I get all that right?

And my original problem with the OSR's wasn't a problem anyway because I don't need them. Don't now why I put them in there.

Thanks again and I appologize, Ron.

Patrick

[Ron Beaufort]

no apologies needed ... it's often difficult to convey a "tone of voice" in the written word ... I've often been accused of sounding "impolite" when I intended nothing of the kind ...

glad we were able to help ...

[Ken Moore]

Another fine explanation Ron, I'm sure it will help some of the newcomers.

[rta53]

Originally Posted by Ken Moore

Another fine explanation Ron, I'm sure it will help some of the newcomers.

And even some of us who aren't newcomers. Not to give Ron too big an ego, but whenever I see a post from him I'm reminded of the old commercial that said "When E.F. Hutton talks, people listen". When Ron talks, people should listen.

[GMc]

...and his fine explanation skills are just one of the reasons his PLC classes are the best.

Gary

[rta53]

Originally Posted by GMc

...and his fine explanation skills are just one of the reasons his PLC classes are the best.

Gary

I am hoping to take a CLGX class at Ron's company. We have used SLCs for many years but recently quoted 2 jobs that require CLGX processors. Not sure if or when these jobs will come down but I'm hoping I don't have to take one of the Rockwell courses and can wait for when Ron offers them.

[GMc]

Rta53,

It would be well worth the wait. I'm hoping to take a PID coarse one day.

Gary