The use of interrupts in PLC's

[PlasticsDude 0]

Maybe a very basic question, but when is the use of an interrupt warranted in a PLC? What are the common uses of interrupts? I am guessing that when a "STOP" button is pressed this would normally trigger an interrupt, and the reason for this is so that the entire STOP routine need not be polled every scan, is this correct?

[Sleepy Wombat 27]

Especially used in high speed counter operations to obtain repeatability of an operation... Eg a Form filling machine Go to your local 7 - eleven buy a pack of lollies... every pack is the same length right... this is achieved via an encoder on the plastic, at a specified length the bag is cut and thermo sealed ... this generally needs to be very accurate and thus must be not be affected by the PLC scan time to miss counts.

[PlasticsDude 0]

So basically using an interrupt to "STOP" a machine would in most cases be complete overkill?

[Sleepy Wombat 27]

You could do it.. but the question is will it leave the machine in a safe state... can the machine recover... will it not damage the machine mechanically... All depends on what you are trying to achieve...

[BobLfoot 301]

Keep in mind what we are talking about in terms of the real world. A stop button processed by the scan of the plc will take from 2 to 250 ms to stop the machine based on the size and scan time of the program. A stop button processed by the interrupt program will still take a ms or 2 to stop the machine. Your operator is going to take 750 to 2000 ms to decide "Jane Stop this crazy thing". Does the 2 to 250 ms you gain by using an interrupt really save anything or anyone? The lollipop packet use of the Interrupt is a good case though.

[paulengr 44]

That depends... If your program size is so enormous and unpredictable that scan time is in excess of 100 ms, then you probably need to reconsider how it is coded. For instance if you are doing some sort of huge block arithmetic or an equivalent (such as driving a FOR-NEXT loop) such as for a large amount of arithmetic, you should consider either doing a few runs of your loop per scan, or moving it onto a PC. If I/O is the issue, then you are clearly to the point where you should consider taking more direct control over your IO scans such that you don't do an IO scan of every device on every single scan. I rarely have PLC's with scan times over 50 ms by doing this kind of stuff where necessary. Even in process plants where they like to stick in one big PLC for an entire chemical production system with dozens of IO cards (never mind IO points). Usually a little tweaking can get this down lower. Button presses are almost never under 50 ms. Don't forget that the time to observe something happening, for that signal to travel to the brain for processing, and back down through all the nerve endings and finally get translated into motion (button pushing) is 350 ms at best. Also, if you are using AC (not DC) IO, the absolute fastest that you can trigger something is at a zero crossing or about 8 ms. Realistically, most people just calculate it at 60 Hz, or 17 ms. Since an E-Stop button has a detent (by NFPA Code), you can catch it any time if your scan times are not excessive. The majority of my interrupt routines are for predictability. If I need to execute some code not necessarily as fast as possible but on a very consistent, repeatable basis, an interrupt routine driven by a timer works very well. I'm thinking here of the "STI" routines in AB PLC-5's. Here are some examples. 1. The response of PID loops on AB PLC-5's is dependent on the scan time. You can either keep changing the time constant in the PID loop by monitoring a high speed timer, or you can simply put all your PID's in a ladder triggered by an interrupt with a fixed and reasonable timing interval. 2. Say you want to write a totalizer that is reading an analog input that gives you say "GPM" or "SCFM". There are three ways to do this. First, you can buy a hardware totalizer and add an extra analog input. Second, you can use a timer to capture the actual scan time and use this as either a timer or a multiplier. There is some "jitter" due to scan time obviously but almost nobody cares or notices. Third, you can just stick all your totalizer code into an interrupt ladder. For just a few totalizers, the timer thing isn't all that bad to do and you can always have multiple timers. If you are doing a lot of totalizers or similar rate/sum arithmetic, an interrupt can save your sanity. 3. A mix of high and low speed IO. The lollipop example is one issue. Another would be the previously mentioned chemical factory situation where there may be a few processes that demand response times of <5-10 ms while most of them work fine if the response times are 1-10 seconds. The choices are either to put timers in and trigger IO off of timers (scan XYZ only every so many milliseconds or perhaps every so many IO scans), or else trigger the high speed stuff off an interrupt, and let the chips fall on the low speed stuff. Don't forget that your overall scan times and frequently, the variability of those scan times INCREASES when you introduce interrupts, even if it's a timer-based interrupt. Hence just one of the reasons that it is strongly recommended to keep your interrupt ladders as short as practically possible.