greetings to all,
sorry it’s taken me so long to get back to this but things have been very busy around here lately ...
first to answer the question posed by 93lt1 ...
Can a STI interrupt the housekeeping or I/O update portion of the scan?
answer: yes, it can ... this is according to the book and I have no reason to doubt its accuracy in this particular case ...
link to SLC Instruction Set Reference Manual
book page 11-11 (Adobe page 229 of 582) shows a neat little chart which breaks down the processor’s scan into its individual steps ... and then shows the points within the scan at which the STI can take control and execute ... and yes indeed, some of those points certainly ARE located within the processor’s “housekeeping or I/O update portion of the scan” ...
so the quick simple answer to your question is “yes, an STI can interrupt the housekeeping or I/O update portion of the scan” ...
now to dig a little bit deeper ...
the main thrust of my earlier post (the one that I gave a link to in post #3 of this current thread) is that an STI which produces “bad math” could conceivable generate an “overflow fault” condition (and shut down the processor) if the STI just happened to execute during the very tiny slice of time BETWEEN the rung which “unlatches S:5/0” and the rung which marks the “end” of ladder file #2 ... I’m convinced that this is correct and I don’t think that you or anyone else is trying to dispute it ...
but in carefully reading your question above:
... you state that for this to happen, that the STI would have to interrupt between the S:5/0 OTU and the end rung. Can a STI interrupt the housekeeping or I/O update portion of the scan?
taking those two ideas together leads me to believe that there might be some small question in your mind as to whether a “bad math” STI could generate an “overflow fault” condition if it happened to execute during the “housekeeping” portion of the processor’s scan ... specifically, if the STI generated a math “overflow” condition AFTER the “end” rung, would we still get a fault condition IN SPITE OF the fact that our program contains a rung to unlatch S:5/0 at the bottom of ladder file #2? ...
(and please forgive me if I’ve misinterpreted what you meant ... but even if you’ve personally got this all nailed down, there might just be some others out there who would appreciate a little more detail on this subject)
continuing on ... in my opinion, the answer to this question is: “no, if the STI happened to generate a math overflow condition AFTER the “end” rung, we would NOT get a fault condition ... at least not as long as our program contained a rung to unlatch S:5/0 at the bottom of ladder file #2” ... the reason is that the actual “shut-down-the-processor-fault” condition would not occur until the end of the NEXT ladder scan (specifically when we reached the END rung of ladder file #2 again) ... and by the time that event actually occurs, we’ll have already cleared the “math overflow” bit (S:5/0) by means of our handy little “unlatch” rung located at the bottom of ladder file #2 ...
so yes, the STI could set the “overflow” bit during the housekeeping part of the scan ... but no, that would not result in a “shut-down-the-processor-fault” condition ... because the S:5/0 bit would be reset before we reached the end of the scan ... and (as I’ve pointed out in one of my earlier posts) it’s not the fact that bit S:5/0 gets set that causes the “fault” ... what actually causes the “fault” is that bit S:5/0 happens to REMAIN set when we reach the “end” rung of ladder file #2 ...
and so ... I’ll still stand by my original statement that a “bad math” STI could generate an “overflow fault” condition IN SPITE OF the customary “unlatch bit S:5/0” rung located at the end of ladder file #2 ... IF the STI just happened to execute within that very tiny slice of time BETWEEN the “unlatch” rung and the “end” rung ...
further, (in my opinion) executing the STI anywhere outside of that slice of time (including an STI execution which takes place during the processor’s housekeeping operations) would NOT generate an “overflow fault” condition ... just as long as we provide that “unlatch S:5/0” rung ...
now for that “in my opinion” qualifier to my last statement ... I really think that I’m correct on this but so far I haven’t been able to come up with any type of conclusive test which will absolutely prove that I’m right ... so I’m trying to leave myself some slack just in case someone comes up with a way to show me that I’m wrong ...
finally, thanks to jdbrandt for the kind compliments ... and actually I have been doing more and more technical writing since the middle of October when I changed jobs ... I’m no longer with the Allen-Bradley distributor and have moved on to working for a systems integrator ... most of what I do now is developing and conducting PLC training classes for our customers ... and along those lines, it’s amazing just how many of the tips, ideas, and other “real world” material covered in this forum I’ve been able to use in my courses ...
and as always, thanks to Phil for making this excellent resource available to all of us ...