Question about interrupt handling: having never used interrupts when programming PLCs, I am doing an educational exercise with a Siemens S7-1200 PLC, triggering a hardware interrupt to turn a peripheral output on for 5 seconds when one of the built-in high speed counters reaches a specified reference value. This reference value comes from an array of a values, and after the interrupt is triggered, the counter rolls over, the next reference value is loaded from the array, and the cycle repeats with up to 10 different reference values.
Since the interrupt OB (code block) is only called once, trying to count the array index within the interrupt code doesn’t work since any bit I set high in the block just remains high, and the software counter needs to see both positive and negative edges at its input over at least 2 scan cycles to count.
If I write the array code in a separate function, the interrupt can execute at any time, potentially somewhere in the middle of my array code. If I use, for example, a bit that says “interrupt triggered” as a condition to execute the array code, upon returning from the interrupt, this could leave the rungs to be processed outside of their intended order (and it could skip counts possibly if the “interrupt triggered” bit was reset out of order). This could be fixed with some type of state machine I suppose, ensuring the steps execute in the proper order, but this is a simple example, and I’m thinking there may be other more complex examples where this could be an issue.
I read on another site where it was suggested to set an “interrupt triggered” bit within the interrupt code that could be used in the program, but I’m curious if I could get some feedback on what the typical way is that they might structure interrupt code (and any code around it) most effectively, considering that interrupt code isn’t called every scan.
Since the interrupt OB (code block) is only called once, trying to count the array index within the interrupt code doesn’t work since any bit I set high in the block just remains high, and the software counter needs to see both positive and negative edges at its input over at least 2 scan cycles to count.
If I write the array code in a separate function, the interrupt can execute at any time, potentially somewhere in the middle of my array code. If I use, for example, a bit that says “interrupt triggered” as a condition to execute the array code, upon returning from the interrupt, this could leave the rungs to be processed outside of their intended order (and it could skip counts possibly if the “interrupt triggered” bit was reset out of order). This could be fixed with some type of state machine I suppose, ensuring the steps execute in the proper order, but this is a simple example, and I’m thinking there may be other more complex examples where this could be an issue.
I read on another site where it was suggested to set an “interrupt triggered” bit within the interrupt code that could be used in the program, but I’m curious if I could get some feedback on what the typical way is that they might structure interrupt code (and any code around it) most effectively, considering that interrupt code isn’t called every scan.