PLC Interrupt Code Handling/Programming

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.

Is this an educational exercise for yourself?


If you are using an interrupt then the action required when the interrupt occurs should be processed in the interrupt routine - in your case the output should be turned on. The output being on is in itself a mechanism for signalling to the non-interrupt code that an interrupt has occurred and that the 5 second timer can be started and the next value from the array is loaded into the counter and the counter re-armed.


As long as you only examine the output in one place at the start of your processing in the cyclic program, the interrupt occuring will not affect your processing - given you are turning the output on for 5 secs another interrupt is not going to occur whilst you are in the middle of the existing interrupt processing.

A good source of learning interrupt basics are microprocessor sites or data sheets, because then it's more critical to get everything right and not so much is handled automatically.

You've realised that the interrupt can happen at anytime, and that you need a dedicated memory, flag, counter or something to notify your main program unless all your actions happen inside the interrupt code.

Actions inside interrupt routines must be fast and minimal, because the main program scan time required will be the interrupt processing time multiplied by the interrupt frequency.

I didn't understand exactly what you wanted to accomplish, but check if interrupt is a good way.

Thanks for the responses.


Yes this is purely educational for myself.


LD, what you’re saying makes sense, so I’ve implemented that in the pseudocode below, but I have a question about the outputs, as technically I’m using the same output more than once in the program.


Here’s the new tentative program methodology:
1) Interrupt triggered, call OB40. Write Q2.0 to 1 in OB40, nothing else.
2) At the beginning of the program cycle, if Q2.0 = 1, set “Interrupt Triggered” bit.
3) If “Interrupt Triggered” & “Array Index = max”, “reset array index counter” = 1.
4) If “Interrupt Triggered” = 1, Count “Array Index” +1.
5) If “Interrupt Triggered” = 1 or First Scan, move Reference Value to NewReference1 and NewUpperLimit. (This enables rollover and interrupt trigger on same value)
6) If Q2.0 Pos-Edge, then start pulse timer. Output of Pulse timer is Q2.0.


This index array counting part is fine, but what I’m not sure about is the effect of the peripheral write on the process image output table.



I haven’t tested it yet, but what I envision happening is:
1) Q2.0 physical output turns on but the PIOT value for Q2.0 is still low immediately after OB40 is called.
2) At the end of the scan cycle, Q2.0 PIOT is still low, so it overwrites the Q2.0, turning Q2.0 physical output back off again.
3) The rest of the code is never executed, because Q2.0 = 0, so “Interrupt Triggered” never = 1.


Am I correct that the peripheral write has no effect on the PIOT? If so, can I read the Q2.0 value directly in the program? Or how would you suggest modifying this code to deal with the overwriting outputs?

Write to Q2.0 as well as Q2.0 in the interrupt OB so the PIOT is up to date.

Thanks, added the PIOT bit and it's working as expected now.


Is it safe to say that generally it's a good idea to set both the PIOT bit as well as the peripheral bit when switching something on or off in an interrupt routine, or is this too general of a statement?


I'm guessing that you would want to do this at least in the case where you need to read the output bit value in the cyclic code.