Latching One shots?

sportster

Member
Join Date
Mar 2005
Location
WI
Posts
113
Hey,

This may sound strange...I does to me. I am currently writing a program where I have many OSR's. Some seem to "stick on" once and a while and I have to put in an Unlatch right after the rung that contains the OSR to get the OSR to work properly. Has anyone else seen this before? Not all of them in the program do this. And I don't have any double addressed. Hopefully it is just me and my no sleep.

Sportster
 
Is this a large program or do you have any STIs or JMPs that may be causing long scan times? Maybe you can post some of the affected logic and we can take a peek.
 
Rube:
I have 65 rungs in Lad 2. Lad 3 is STI set for 6 ms with 35 rungs.
4 JSRs to routines have 5 rungs each (3 in Lad 2, 1 in Lad 3). Average scan time is between 10 and 20 ms with it leaning more towards 10 ms.

Alaric:
Thanks for the link. I looked it over quickly. I think maybe because my data is changing so fast; the OSR's are not going setting to zero fast enough and that's where I'm loosing. Or maybe not. I'll play aroung some more and see what I can find.
 
weird things like this really make my day ...

Greetings sportster,

I'm not sure that I understand exactly what you're saying ... but ... I would dearly love to take a look at your program ... is there any reason why you can't post the .RSS file? ... or if you don't want to post it on the open forum, maybe you could e-mail me a copy? ... I promise that I'll treat it confidentially ...

and if you can't make the whole .RSS file available, can you at least give us an example of one of your "problem" rungs? ...
 
sportster,
Believe me, I wouldn't dream about an offer like the one Mr. Ron Beaufort offers!
He is an expert in AB and have great skills in "Teaching".
 
Ron:

Well, I don't think my boss would like me to post or send away the whole program (although it is probably not much good to anyone else). However, I could send a couple of rungs your way for you to look at. PM me with where to send them and how. I'm not to keen on how to send a couple of rungs.

Thanks,
Sportster
 
sportster said:
Ron:

Well, I don't think my boss would like me to post or send away the whole program (although it is probably not much good to anyone else). However, I could send a couple of rungs your way for you to look at. PM me with where to send them and how. I'm not to keen on how to send a couple of rungs.

Thanks,
Sportster

I wonder what your boss would say if he knew that once it leaves your building its basically public domain to anyone that wants it. :)
 
you can't hit 'em if you can't see 'em ...

Greetings sportster,



well, if you want to give it a try, here’s how to send a series of rungs by PM (Private Message) ...



click on the rung number of the first rung you want to send ... the number should be highlighted with a big red box ... then scroll down to the last rung you want to send ... hold the Shift key while you click the rung number of the last rung you want to send ... the whole series of rungs should now be highlighted with a big red box ... now right-click on the red box and select Copy from the popup menu ... go to a PM message ... right-click on the message and select Paste from the popup menu ... something like this should result:



SOR TON T4:0 0.01 4000 2924 EOR SOR GRT T4:0.ACC N7:25 OTU O:4.0/0 EOR SOR XIC T4:0/DN BST RES T4:0 NXB NEQ N7:25 0 OTL O:4.0/0 BND EOR SOR XIC N10:0/13 BST MUL N10:24 T4:0.PRE N7:25 NXB DDV 16383 N7:25 NXB CLR S:5 BND EOR



I can Copy and Paste that into RSLogix500 and duplicate your rungs ...



I’m going to be offline until tomorrow but I’ll see what I can come up with ...



if you or your boss are concerned about proprietary and super-secret issues, then don’t send anything - it won’t hurt my feelings at all ... I’m just offering to try to help if you need it ...
 
****attachment removed by Phil at the request of sportster****

Ron:
You have mail.

Need anything else, just ask.

Sportster
 
Greetings sportster,



I haven’t had time to go completely through the program you posted ... work is keeping me pretty busy right now ... but here are some things that I’ve noticed so far ...



let’s look at rung #35 in ladder file #2 as an example ... you have an NEQ comparing the values of F8:15 and F14:0 ... I’ve gone through your logic to see where those values originate ... as near as I can tell (with the time I’ve had so far) F8:15 is calculated as the result of an ADD instruction in ladder file #3 ... ladder file #3 is an STI with a setpoint of 6 milliseconds (pretty doggone fast) ... let’s just skip over the STI part for right now ... but ... we’ll HAVE to come back to it sooner or later ... for now let’s just say that the ADD in ladder file #3 has just calculated a new value and stored it in F8:15 ... for this discussion, let’s say that the new value is 83.0 ... and let’s say that the value stored in F14:0 just happens to be 83.3 ...



eventually the processor will scan rung #35 in ladder file #2 ... when the NEQ compares the new value of F8:15 (83.0) with the value of F14:0 (83.3) the values will not be equal ... so the NEQ will be evaluated as a true condition ... the OSR will fire and pass true logic ... the true logic will cause each of the rung’s ten MOV instructions to execute ... the first nine MOVs apparently are used to “ripple” data through an array ... let’s ignore that operation for right now ...



the final MOV is a little bit different ... notice that it moves the value of F8:15 (83.0) into F14:0 ... this, of course, overwrites the old value (83.3) which had previously been stored in F14:0 ...



let’s think about that last operation for a second ... the key issue is that every time this rung executes (as true), then the values stored in F8:15 and F14:0 are ALMOST guaranteed to be equal ... (we’ll come back to why I said ALMOST in a few minutes) ...



so now let’s continue with the current scan of ladder file #2 ... the XIC in the next rung finds a one stored in the OSR bit (B3/85) and so we have a true condition ... the OTU is executed with true logic ... this writes a zero into the OSR bit ... in other words, the OSR has just been “reloaded” and is ready to fire again ...



sidetrip: by unlatching your OSR bit this way, you have effectively removed the OSR from the program ... specifically, it will pass true logic each and every time its rung is scanned as true ... in other words, your OSR might just as well be lying out in the parking lot for all the good it will do you ... I don't mean to sound brutal ... just trying to make a point



and now let’s come back around to rung #35 on the next scan and see what happens ... this time when the NEQ compares the value of F8:15 (83.0) with the value of F14:0 (83.0) the NEQ will be evaluated as false ... this false condition would (all by itself) reload the OSR by writing a zero into its bit ... but you’ve already reloaded it with that OTU rung ... one question is: why did you find it necessary to do that? ...



one issue: as near as I can tell so far (but I’m still working on it as time permits) it looks like the “unlatch” rung for the OSR should have no effect on your program’s operation ...



specifically, by moving the value of F8:15 into F14:0 each time you store the data, then you’ve ALMOST (there’s that word again) guaranteed that the NEQ will be false on the next scan ... in other words, even without the OSR, rung #35 should execute one time - and one time ONLY - whenever the value of F8:15 changes ... specifically, if everything worked “normally” then the OSR wouldn’t be required at all ...



but wait a minute ... you ARE having problems aren’t you? ... so that means that we have to look deeper than “normal” operation ... now let’s look at that STI setup ...



you’ve got your STI executing once each 6 milliseconds ... that’s pretty fast ... and when we look at your processor’s scan time, we see a maximum of 40 milliseconds ... and an average of 10 milliseconds ...



so here’s something to think about ... remember that the value of F8:15 is calculated within the STI ... and remember that the STI can INTERRUPT the execution of the normal program scan ANYWHERE within the scan ... so maybe (just maybe) the value of F8:15 is being recalculated to a new value at an “unfortunate” time during the scan of ladder file #2 ... and this new value is “confusing” the normal operation of the NEQ instruction ...



that’s why I keep saying “ALMOST” about the way your program should work ... by putting half of your logic in the STI and the other half in ladder file #2, you could be setting yourself up for some serious problems ... in other words, the values that you’re trying to compare with your NEQ could be changing “behind your back” so to speak ...



that’s the best I can come up with so far ... but I’m still working on it ...



suggested plan of attack: CUT one of your “problem rungs” (for example, rung #35 out of ladder file #2 and PASTE it into ladder file #3 (the STI ladder file) and then delete the OSR completely ... see what happens ... if I’m on the right track, things should start to work more along the lines of what you had in mind ...



I’ll continue to look through this as time and work permits ... I’ll let you know if I come up with anything new ... good luck ...

PS note to Ayman ... thank you for the kind compliments in post #6 ...
 
Ron;

... one question is: why did you find it necessary to do that? ...
Answer: 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. For some reason; maybe caused by the fast STI time; those OSR's just wouldn't go false. So I put in the unlatches and it worked; just not the way I'd like. I think you may be right about the logging done in the slower Lad 2 and the origination of the data in the faster Lad 3 causing problems.

I will try that suggestion once I get to work Friday afternoon and post some results as soon as possible. Thanks for your insight and time!

Sportster
 
As usual, Ron has the issue nailed. F8:15 is changing between the time the program moves the value of F8:15 to F14:0 and the time the program comes back around to evaluate the NEQ in the same rung. So the OSR never sees the NEQ as false, the OSR never goes false and there you sit. This isn't just an STI issue. If F8:15 is changed anywhere between the MOV at the end of the rung and the NEQ at the beginning of the same rung the issue occurs. You would run into the same problem if you unconditionally added 1 to F8:15 somewhere in the program.

Like Ron said, get rid of the OSRs and use the MOV at the bottom of the rung effectively as your OSR. This should be much more stable for you.

Keith
 

Similar Topics

I am curious why my latches do not work and maybe someone here has some insight. I have created two AOIs. One AOI latches an output on (ON)...
Replies
5
Views
1,753
I'd like to get some feedback on the use of latching/unlatching relays. (Something I've never used in my limited programming experience.) I've...
Replies
15
Views
4,813
I figured out a solution to a vfd issue... at least in theory. Yaskawa has a program called Drive Works EZ that you can have PLC-type functions...
Replies
15
Views
3,775
How get steady latched from HMI push button without doing any program in PLC for latching and after pressing second it is unlatched in connected...
Replies
4
Views
1,597
I am looking at some AB RSLogix5000 controllogix code. A very simplified sample of code written within the same ladder...
Replies
14
Views
2,940
Back
Top Bottom