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 ...