If you have ever been troubleshooting an automation system and needed to stop the plc from scanning at the occurrence of a specific event I've found something that works quite well.

Be advised that stopping a processor from scanning on a running system can have unexpected consequences. Make sure you know what running motors will do when suddnely turned off, etc before trying this.

Decide under what conditions you want to halt scanning and then use these to build a rung which load -1 into the preset of a timer. This will result in an instant major fault and halt the procesor. You'll have to clear the preset to 0 and reset the fault to resume scanning but you can capture all data at that instant as well as observe physical position of controlled devices.

Thislittle hint proved useful in commissioning a baggage system last year.

Thanks, that definitely seems like an acute way of doing it.

It works quite well, just allow for what your machine or process will do during a fault and all is well.

I often find that machines I work with will loose all inputs (due to power loss when the PLC 'crashes'. Is there some way of catching a major fault and clearing it, that way the program could detect a fault occured and stop scanning the program (i.e. TND on first rung) but keep the PLC running. It would also make it easier to continue running the machine.

Added:

I've just researched it and error


So a fault routine could clear the error and set a flag, when the program resumes the 1st rung of file 2 would see the flag and end execution, thus keeping the program in run mode, all I/O in it's current state. Clear the bit to continue running the program.

The only catch to this is you must know which preset has the negative value. I'm guessing that you are moving a value to your preset in your program to make this happen. If this is true, put a GRT statement before the move and make sure it is greater than 0

Its a minor detail, but just writing a -1 into a timers PRE will not fault the processor until the timer instruction is actually executed. If a timer instruction referencing the timer address does not exist, or if the timer instruction rung is false, no fault will occur.

Another way to stop the processor on the dime is to write a user defined error code 095h - 099h into the S:6 register and directly set the S:1/13 bit to cause a major fault and execute a TND. Use the user defined error codes to identify the portion of your code that generated the fault.

This rung, XIC B3/50 BST MOV 99h S:6 NXB OTL S:1/13 NXB TND BND,
will stop the processor on the dime when B3/50 is true and will place 99h in the error code register. By using multiple user defined error codes you can create several debugging statements.

If you do not use the conditonal TND then the processor will halt when it finishes scanning the current routine.

That's a better way, I was thinking that TND ends the current subroutine but it doesn't, that's what RET is for. I probably wouldn't bother faulting the PLC (unless it clears various status register before it starts a scan), I would just set a flag just before the TND instruction and catch it at the start of the next scan.

Greetings Spedley,



you said:

QUOTE

I was thinking that TND ends the current subroutine but it doesn't, that's what RET is for.

well, you're mostly right ... as you said, the RET (Return) instruction NORMALLY is used for ending a subroutine - and not the TND (Temporary End) instruction ... but to get right down to the nitty-gritty details, a TND (Temporary End) will indeed "end the current subroutine" ...



side trip: as you probably already know, you do NOT actually need an RET instruction to return from a subroutine file - but some programmers automatically put them there from force of habit ... the fact is that the processor scan will automatically "return" when it reaches the end of the subroutine file - even without an RET ... but going further: sometimes it's very handy to put a "conditional" RET rung before the very end of a subroutine file - so that we don't have to go all the way to the bottom in situations where some of the rungs don't need to be scanned ...



so as I said, a TND (Temporary End) will indeed "end the current subroutine" ... but now here's where things start getting tricky ...



quick question: are we talking about a PLC-5 system and RSLogix5? ... or are we dealing with something like an SLC-5/04 and RSLogix500? ... there's a little-known difference in how the TND works from one platform to the other ... here's the trick ...



first suppose that we're dealing with a PLC-5 ... suppose that you have a JSR rung halfway down through ladder file #2 to "call" ladder file #3 ... suppose that you have a TND rung halfway down through ladder file #3 ...



here's what happens ... the processor scans the top half of ladder file #2 ... then the JSR sends the scan over to ladder file #3 ... the processor scans the top half of ladder file #3 ... the TND ends the subroutine - so the bottom half of ladder file #3 doesn't get scanned ... the scan returns to the JSR rung in ladder file #2 ... the processor scans the bottom half of ladder file #2 ... the scan reaches the end of ladder file #2 and now the show's over for this scan ...



side trip: if you replace the TND in ladder file #3 with an RET, you'll get exactly the same results as the sequence I've detailed above ... nothing changes ...



now this time let's suppose that we're dealing with an SLC-5/04 ... again, suppose that you have a JSR rung halfway down through ladder file #2 to "call" ladder file #3 ... suppose that you have a TND rung halfway down through ladder file #3 ... (this is the same setup as with the PLC-5) ...



here's what happens ... the processor scans the top half of ladder file #2 ... then the JSR sends the scan over to ladder file #3 ... the processor scans the top half of ladder file #3 ... the TND ends the subroutine - so the bottom half of ladder file #3 doesn't get scanned ... (so far - so good) ... but THIS time the scan does NOT return to the JSR rung in ladder file #2 ... oops! ... this means that the SLC processor never scans the bottom half of ladder file #2 ...



another side trip: with the SLC-5/04 system, if you replace the TND in ladder file #3 with an RET, then you'll get exactly the same results as the normal/expected/makes-sense sequence that we saw for the PLC-5 ... but the TND is a different animal ...



and now from the "where-I've-seen-this-cause-a-problem-department": I once helped a fairly experienced programmer debug an SLC-5/04 program that he was writing from the ground up ... he was still in the "simulating-on-the-office-desktop" stage of things ... as I said, he was fairly well experienced - but all of his programming experience was based on the PLC-5 platform ... he was used to dropping in TND rungs here-and-there throughout his subroutine files in order to simulate and bench test his programs ... the problems that he kept running into drove him pretty well nuts for the better part of two days ... he just never realized that in the SLC platform, once the scan reaches the TND in any one of the subroutine files, the scan stops immediately and completely ... specifically, his new SLC system wasn't working the same way as his old familiar PLC-5 ...



moral of the story ... it's generally safer to use RET instructions inside your subroutines - and not the TND instruction ... just as Spedley said, that's the way it ought to be ...



now if you really want to skip scanning the end of your "main" ladder (usually ladder file #2) then the TND will serve you well ... secret handshake: if you do try to execute an RET in the "main" ladder file, then you'll cause a PLC-5 processor to fault ... the fact is that most (all?) versions of RSLogix500 won't even verify an RET in ladder file #2 ... but most (all?) versions of RSLogix5 WILL ...

what CPU we are talking about?
if one wants to intentionally stop cpu (as a last resort i guess), why not use SUSpend instruction?
i do remember seeing it on SLCs and I would think there must be something of that kind in Logix too.

I think you've got it there panic mode. I never new there was such an instruction - the number of times I would have found that useful (for seeing index register S:24 etc) !