SLC's "Overflow Trap" fault and STI

Craig P said:

Hi Mickey,

I found that S:21 does exist in the ML1100, but rslogix is telling me that the selected word is not readable at the word level. I am literally trying to MOV S:21 to N34:1. If it cannot be moved, can I just access S:21 direclty for my query?

Thank you again,
Craig

Click to expand...

Really ?? Hmm?

Hi Mickey,

I saw the same thing.. I agree that it's not in the literature.. I double checked that I have a ML1100, Series B, Build 1763... and there is an S:21 that says "Debug Fault/Powerdown File" in the description field...it's in the S2 datafile.

Thank you again for your help,
Craig

Mickey said:

Really ?? Hmm?

Click to expand...

Craig P said:

...I found that S:21 does exist in the ML1100,...

Click to expand...

The meaning of the Status Words in ML1100 is different than in the SLC; so even though S:21 exists in ML1100, it does not mean the same thing S:21 means in a SLC.


AFAICT (see the hot mess below), another difference is that the ML1100 does not store the file and rung of the trap; all you get are the Major Fault code (S:6) and an option to write and call a fault handler (S:29).


The code here is a demo of this capability; it generates a math overflow (S:5/0) every rising edge of bit 14 of the free-running clock i.e. every 3s+. That minor fault triggers a major fault (S:1/13) at the end (I assume?) of [LAD 2 = MAIN], which in turn triggers a call to the fault routine [LAD 10 = HANDLFAULT; cf. S:29].



This HANDLFAULT routine increments the counts of the MSBytes and LSBytes of any current Major Error code (S:6) in files N100 and N101, respectively. HANDLFAULT then checks that there was a Math Overflow Trap (S:5/0), and if so then finally clears the major and minor fault bits so the program can continue.


Of course if you know where your traps would occur, you could check closer to that point and save and clear the minor (S:5) or major (S:6) error codes, and also note where they occurred, without using the fault handler scheme.



All of this behaviour can be found in the help files for MicroLogix 1100, though it may take a bit of imagination, trial, and error to convert the terse help text into usable code.

Thank you, guys. I got it to work the way I wanted.. but I obviously couldn't tie into the file/rung data that I wanted because of the limitation of the ML1100.
Thank you,
Craig

Most people are saying they check the overflow trap bit after execution of instructions that could cause a processor error.

However, the trap bit could have been set hundreds of rungs before you look at it.


Perhaps there is confusion between the overflow trap bit, and the overflow status bit. These are two separate entities, and the status bit is the one that you should be interrogating, as it is updated by all instructions that could generate an overflow error.

The trap bit is also set at the same time as the overflow status bit, and it will remain set until the processor detects it on at the end of the scan of ladder file 2, when it will fault out.

As I have already stated, the trap bit is pretty useless, so most people put an OTU of it as the last rung of file 2.

If you have any "interrupting" code, such as an STI, or a DII, then you should put an unlatch at the end of those files also. It is the End rung of file 2 that triggers the major fault.

It could be years before an STI, by example, is executed after the OTU is performed, and before the End rung is processed, but it could also happen today, tomorrow, or whenever.