Measured PLC response times are 275 µs ± 50 µs of jitter. This engineering brief describes how hardware interrupts are used to configure a Siemens G2 S7-1214C DC/DC/DC PLC with a simple program within the HardwareInterrupt[OB40] block.
We will see that fast response times do not equal fast scan cycles.
See Siemens Resource Hub.
Figure 1: Oscilloscope showing the PLC’s rising edge to rising edge response time.
Physical Setup
Two PLCs were used:
-
PLC #1 operates as a 24 VDC pulse generator providing the orange signal in Figure 1. This signal was sent from PLC #1’s %Q0.0 output to PLC #2’s %I0.0 input.
-
PLC #2 responds to PLC #1 by producing the blue output signal. This PLC has been programmed with hardware interrupts.
A Digilent ADP2230 mixed signal oscilloscope was used to perform the measurements.
PLC Device Configuration
The essential configuration for PLC #2 is shown in Figure 2.
Reduce the Input Filter Window
The input filter is reduced to its lowest setting of 0.1 µs. Note that the default setting is 6.4 ms for switch debouncing. By using a 0.1 µs setting we are assuming a clean input signal.
Be careful with this setting. It’s fine in this application, as PLC #1 provides a near ideal pulse. However, real-world signals such as switch bounce will trigger unnecessary hardware interrupts which could degrade the PLC’s real-time performance. The switch’s contact bounce can cause dozens of interrupts in a short period of time.
Enable Hardware Interrupts
The boxes for both rising and falling edge detection have been selected. Both interrupts will invoke the HardwareInterrupt[OB40] block and the interrupt priority is set to the default level of 16. Together they form a bidirectional edge detector that vectors to the hardware interrupt code.
Figure 2: The input filter time is reduced, and edge detection is enabled.
Hardware Interrupt Programming for the PLC
Figure 3 shows the ladder logic included as part of HardwareInterrupt [OB40]. It includes a single rung to read the input pulse and then set the output accordingly. Look carefully to see that each tag is appended with :P for Siemens Peripheral access. This is a critical distinction that breaks out of the normal PLC scan cycle to operate directly on the I/O. In essence, we tell the PLC to stop whatever it’s doing and immediately get the value from the input port. The PLC then sets the output without consideration of where the PLC is in the traditional scan cycle.
This is a powerful tool but ripe for abuse. Earlier we set the input channel interrupt priority level to 16. This overrides Main [OB1]. In effect, it steals time from the main tasks slowing down the PLC. Excessive interrupts could impact real-time performance.
![Figure 3: Hardware interrupt [OB40] program.](https://global.discourse-cdn.com/digikey/original/3X/c/0/c086f0294e3303a79e1a182d17265b969af4cf2a.jpeg)
Figure 3: Hardware interrupt [OB40] program.
PLC Cycle Time Consideration
Figure 4 presents the PLC cycle time history for the test PLC. For this demonstration, I added a massive 17 ms program to delay the PLC. With hardware interrupts, this has zero timing impact as [OB40] overrides [OB1].
But be careful, as [OB40] can starve [OB1] by extending the loop execution time. In an extreme case, the watchdog timer will activate placing the PLC into a fault state.
Figure 4: PLC cycle time when a large looping delay is added.
Default Performance Without Hardware Interrupts
Figure 5 shows the default performance with the PLC configured with the standard settings of 6.4 ms input filter and no hardware interrupt. There are two time domain clusters. The first is centered around 7 ± 2 ms. The second cluster represents the time delay when the array looping section is activated. We now see edge to edge delays between 25 to 75 ms with the statistical center at 35 ± 10 ms.
Figure 5: Default performance of the PLC.
Hardware Interrupts Break the PLC’s safe Cyclic Operation
Use the hardware interrupts sparingly for those select applications when time has top priority. The greatest hazard is the loss of the natural rhythm of the cycle scan. Specifically, the interrupt mechanism removes the protection of I/O consistency across the program for any given scan cycle.
One final warning, there is nothing preventing you from using a contact or coil in both [OB1] and [OB40]. Be forewarned as the resulting intermittent bug will be very difficult to locate. There is no longer a single source of truth when both [OB1] and [OB40] can write to the same output pin. You could end up with an output that is set by [OB40] only to be cleared moments later by [OB1].
Best wishes,
APDahlen
Related Articles by this Author
If you enjoyed this article, you may also find these related articles helpful:
- Emulating Enumerated States in Siemens PLCs for Module-to-Module State Transfer
- Building a State Machine in Siemens TIA Portal
- Thermal PID on the Siemens S7 PLC
About This Author
Aaron Dahlen, LCDR USCG (Ret.), serves as an application engineer at DigiKey. He has a unique electronics and automation foundation built over a 27-year military career as a technician and engineer which was further enhanced by 12 years of teaching (interwoven). With an MSEE degree from Minnesota State University, Mankato, Dahlen has taught in an ABET-accredited EE program, served as the program coordinator for an EET program, and taught component-level repair to military electronics technicians.
Dahlen has returned to his Northern Minnesota home, completing a decades-long journey that began as a search for capacitors. Read his story here.