ABSLC Math Overflow in STI file

[jdbrandt]

Can a math overflow in an STI file be automatically reset?

Over the years, I've taken to adding one final rung in my
MAIN (LAD:2) file, that is an XIC S:5/0, OTU S:5/0, to
reset any minor fault, math overflow error.
(I also have a counter on this, just in case.....)

Anyway, recently I had an STI file (*) that had an instruction
that caused an overflow (ADD N7:1 1 N7:1), and the processor
shut down with a minor fault.

I suppose it makes sense, in that, even though program 2's
last rung is supposed to clear it, that the STI file might
take control <just after> the OTU, but <just before> the -[END]-
marker.

Does this all make sense, or am I missing something?

(*) STI file set for 1.0 seconds.

[93lt1]

I think the STI can "take charge" even in the processor's I/O update or housekeeping time, because the "STI time" is very accurate. I would put the same (XIC S:5/0, OTU S:5/0) rung at the end of the STI file also.

[Ron Beaufort]

you've already got it figured out ... but for those who need more detail ...

link to a previous thread on the same subject

[93lt1]

Ron-
I went to that link and I see that you state that for this to happen, that the STI would have 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?

I suppose it doesn't need to be able to, if the housekeeping or I/O update portion of the scan is fixed time or anticipate-able.

[jdbrandt]

Ron:
You link to your previous post was really awesome. Its a lesson
to us all, specifically:

Search THIS archive for previous posts dealing with your issue.

Not to re-direct your career, but, you really write well...have
you considered Technical Writing?????

[Ron Beaufort]

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

[kamenges]

I think I'll toss in an opinion here just to add another thought. Actually, this thought is pretty esoteric, but it's kind of fun. As stated above, if the STI could generate a "bad math" condition you need to put the OTU of S:5/0 at the bottom of the STI or you run the risk of the STI hitting that small piece between the OTU and the END in the main file no matter what happens during housekeeping.
That said, I think there is a chance that you could fault on a "bad math" condition in an STI if it occurs during housekeeping. I think the fault that is caused by the S:5/0 bit is triggered during housekeeping. So there is most likely a specific piece of housekeeping code that evaluates this. If the STI happens to trigger after the OTU in the main file but before the S:5/0 evaluation code in the housekeeping firmware you would still get a fault.
Again, this is an opinion since I haven't found anything that says either way.

Keith

[Ron Beaufort]

greetings, keith,

i'm glad to see that there are others out there who share my interest in these types of things ... i've been trying to come up with some type of test to prove or disprove my theories ... but nothing (so far) which will be absolutely conclusive ... there is so much that goes on in the housekeeping part of the scan and precious little of it is available to the "outside" world ... so i suppose we'll never really know ... and anyway, i'm sure that most people will never really care ...

[panic mode]

I've seen this quite oft and I cannot say that I like it.
It's just like hiding **** under the carpet (imho).
Why not test the logic and make sure that PLC will not trip
in first place? If this is not practical due complexity
of the algorythm or calculation or whatever other reason,
at least display warning or error with the address of
troubled file/rung so someone will know that overlow did
happen even if it is automatically cleared.

"Sure it's still ok, it's even closer to the ocean..."

I AGREE. WHO NEEDS LIFEBOATS? JUST MAKE SURE THE SHIP IS UNSINKABLE.

[PhilipW]

On the contrary. There are plenty of situations where it is convenient to allow a math overflow error to occur in the logic, and to have no need to cause the processor to fault.

Certainly I have no argument with someone who wants to add the extra logic to test the result of every math operation, capture the offending rung and devise the correct response, BUT for most applications it is perfectly ok to just "sweep them under the carpet" with a single rung. Consider it optional.

PS # 1. I end to use a < CLR S:5 > to tidy up the whole minor error word. Anyone see any issue with this?

PS #2. In answer to Ron's question:

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

:

I have been placing most of my logic within STI's for about 2 years now, and I KNOW that there are minor math errors being generated in the STI and yet despite literally billions of accumulated scan cycles, none of the systems have faulted. Not a conclusive test, but statistically suggestive.