Do cyclic interrupt OBs use the process image to read input signals?

[plcnoob69]

Hi,

When I use an interrupt OB (let's say OB38 which is processed every 10ms), does it read the state of the inputs at the time it is called, or does it use the process image for inputs' state? Let me give you an example:

I have a sensor on input I1.0, and when the process image was created this input was in a low state. Immediately after that, it got to a high state. The next time OB38 is called (assuming this happens before PLC cycle is completed), will it process the code with I1.0 in a high or a low state?

And as long as I'm here, I think this goes without saying because this is the point of interrupts but I want to make sure... If I turn an output to a high state in OB38, it will be activated immediately when the OB38 is processed (there will be actual voltage in the output wires?)

 

[L D[AR2P#0.0]]

Which CPU?

 

[plcnoob69]

Which CPU?

Hmmm it matters?
Siemens s7-400 let's say

 

[mk42]

Hmmm it matters?
Siemens s7-400 let's say

Welcome to the rabbit hole! Which PLC it is affects the details, even if most of the concepts carry over. Reading IO is probably way more complicated than you think it is.



All the discussion about OB1 before was accurate, for all the S7 CPUs I've used (300/400/1200/1500). It is not necessarily true for all PLCs from all brands. The Logix processors from Rockwell, for example, don't do any buffering of the inputs at all, and all IO access is immediate (either direct to the IO card in the rack or whatever the last update from the fieldbus was). Most programmers have mapin and mapout routines that manually buffer everything, if the PLC doesn't. ANYWAY....


To dive a bit deeper, each S7 PLC has what's called the process image, where the IO values are buffered. For the S7300s (not sure about 400), only a certain specified range of the IO end up in the process image, say up to I255 and Q255. For the 1200 and 1500, all IO is in the process image. How do you read IO that isn't in the process image, you ask? Via Peripheral reads and writes, which grab the most recent version of the input, or immediately write the output. In 300/400 you use PIW100 instead of IW100 to read the tag; in 1200/1500 you add a "" to the tagname. Peripheral access can be used to get access to data that isn't in the process image, or to get faster access to data in the process image.


What does all this have to do with cyclic interrupts? Well, it means that by default, you get the value of the input from the start of OB1 (if it's in the process image) in your OB32. BUT in 400 & 1500, you can use a PIP (Process Image Partition) to split out certain IO to be imaged at different points. Maybe some IO goes with OB1, and some other IO goes with OB32, where it is read at the start of OB32 instead, and written at the end.


Another wrinkle: local IO access vs remote IO. Local IO is usually directly read/written from/to the card in the rack, either for a peripheral read/write, or to buffer it in the Process Image. Remote IO doesn't do immediate requests though. The PLC stores the last value sent as the "peripheral read", and then uses that for the process image, when it's time to buffer. The PLC might store and then discard an input 10 times during the PLC scan, but the PLC code won't "know" about any of them unless it asks for it with peripheral access. An interesting side effect of this is that it is actually faster to do a perihpheral read/write to remote IO than it is for local IO, because it doesn't actually have to send any request, it just reads/write memory.

 

[plcnoob69]

Welcome to the rabbit hole! Which PLC it is affects the details, even if most of the concepts carry over. Reading IO is probably way more complicated than you think it is.



All the discussion about OB1 before was accurate, for all the S7 CPUs I've used (300/400/1200/1500). It is not necessarily true for all PLCs from all brands. The Logix processors from Rockwell, for example, don't do any buffering of the inputs at all, and all IO access is immediate (either direct to the IO card in the rack or whatever the last update from the fieldbus was). Most programmers have mapin and mapout routines that manually buffer everything, if the PLC doesn't. ANYWAY....


To dive a bit deeper, each S7 PLC has what's called the process image, where the IO values are buffered. For the S7300s (not sure about 400), only a certain specified range of the IO end up in the process image, say up to I255 and Q255. For the 1200 and 1500, all IO is in the process image. How do you read IO that isn't in the process image, you ask? Via Peripheral reads and writes, which grab the most recent version of the input, or immediately write the output. In 300/400 you use PIW100 instead of IW100 to read the tag; in 1200/1500 you add a "" to the tagname. Peripheral access can be used to get access to data that isn't in the process image, or to get faster access to data in the process image.


What does all this have to do with cyclic interrupts? Well, it means that by default, you get the value of the input from the start of OB1 (if it's in the process image) in your OB32. BUT in 400 & 1500, you can use a PIP (Process Image Partition) to split out certain IO to be imaged at different points. Maybe some IO goes with OB1, and some other IO goes with OB32, where it is read at the start of OB32 instead, and written at the end.


Another wrinkle: local IO access vs remote IO. Local IO is usually directly read/written from/to the card in the rack, either for a peripheral read/write, or to buffer it in the Process Image. Remote IO doesn't do immediate requests though. The PLC stores the last value sent as the "peripheral read", and then uses that for the process image, when it's time to buffer. The PLC might store and then discard an input 10 times during the PLC scan, but the PLC code won't "know" about any of them unless it asks for it with peripheral access. An interesting side effect of this is that it is actually faster to do a perihpheral read/write to remote IO than it is for local IO, because it doesn't actually have to send any request, it just reads/write memory.

Thank you so much for the extensive answer... let me see if I understand correctly. I was actually aware of peripheral reading of analogue IOs, but didn't know how to do it for digital.
Let's say I want a specific input to be read at the beginning of OB38. I need to go to the hardware configuration of this IO module and set the process image to PIP1, and then also I need to set the process image of OB38 to PIP1. Will this do it?
And will it negatively affect the other inputs on this card?

Because I actually do have an input that is very short and normal PLC cycle is not able to read it most of the time.

 

[JesperMP]

Let's say I want a specific input to be read at the beginning of OB38. I need to go to the hardware configuration of this IO module and set the process image to PIP1, and then also I need to set the process image of OB38 to PIP1. Will this do it?

If you only need to read one or a few inputs, simply read them with direct peripherial access.
In S7-300/400 you precede the address with a "P", PIW300 for example.
In S7-1500 you add "" to the address, IW300 for example.

Notice that the smallest size you can read by peripherial access in S7-300/400 is one byte, i.e. PIB300. If you need to read just a single bit, you have to copy from the peripherial input byte to an intermediary memory address, then read the bit from the intermediary address, i.e. to read I300.2:
L PIB300 // read IB300
T MB10 // transfer to intermediary address
A MB10.2 // querying I300.2
..

Not sure if the same applies to S7-1500.

 

[L D[AR2P#0.0]]

Transfer it to IB300, no need for intermediate register.

 

[plcnoob69]

If you only need to read one or a few inputs, simply read them with direct peripherial access.
In S7-300/400 you precede the address with a "P", PIW300 for example.
In S7-1500 you add "" to the address, IW300 for example.

Notice that the smallest size you can read by peripherial access in S7-300/400 is one byte, i.e. PIB300. If you need to read just a single bit, you have to copy from the peripherial input byte to an intermediary memory address, then read the bit from the intermediary address, i.e. to read I300.2:
L PIB300 // read IB300
T MB10 // transfer to intermediary address
A MB10.2 // querying I300.2
..

Not sure if the same applies to S7-1500.

Jesper my friend, this is gold.
So if I do this code in the OB38, every 10ms I will be reading my input and writing it into MB10.2?
Would it work if I use temp byte in order not to waste M area?

 

[JesperMP]

Ah, I made a typo.

L PIB300 // read IB300
T MB10 // transfer to intermediary address
A M10.2 // querying I300.2

Yes, L D's suggestion would allow you to not waste Merker memory.

 

[drbitboy]

If there is a discrete input electrical signal that is too fast, i.e. is high or low for such a short time that a PLC program scan cycle could miss it, it will require a different strategy than one read per scan cycle.

One approach might be an signal-driven interrupt, if available, that detected every edge and calls an interrupt routine, and that routine sets a persistent bit that the continuous scan cycle examines and resets. This would only be able to detect that there was at least one edge, not multiple edges, per scan cycle, of course.

The interrupt routine could alternatively increment a counter to detect multiple edges, but that would require some concurrency gymnastics. Actually even the set-bit approach could have concurrency issues.

Another alternative would be a High-Speed Counter module, where the program in the continuous scan keeps track of the counter accumulator from the previous scan cycle, and when the count on the current scan cycle is different, it declares one or more edge "detections."

Yet another alternative would be a circuit to electronically stretch the pulse signal duration; I suspect a search for the terms 555, pulse, stretcher would yield several suitable circuits, along with formula for calculating the component values (Ohms, Farads, etc.).

As noted in the other thread here, it's the Nyquist Theorem as mentioned by @Tinine and @mk42, and if the PLC scan cycle cannot meet the requirements of that theorem for a pulse with a duration of 2ms, then another way must be found.

 

[parky]

On the S7-400 there is an I/O interrupt I think it's OB40 so you can configure an input that if it goes false to true (or the other way round) it calls OB40, then you run your code in that OB.

 

[plcnoob69]

On the S7-400 there is an I/O interrupt I think it's OB40 so you can configure an input that if it goes false to true (or the other way round) it calls OB40, then you run your code in that OB.

I think this can be done only if the I/O module allows hardware interrupts, mine doesn't

 

[parky]

Yes I believe so, it needs an input card with a fast response time, however, I think it works on most DC input cards but the filters will affect it's response I once tried it on an older S5 155 CPU & it worked with a standard 32 way 24v dig in

 

[Ken Moore]

Not sure about Step-7, but in PCS7, you can define PIP's (process image partition) and assign each PIP a specific OB, such as OB35. Then when you are laying out your hardware, and assigning addresses, you also assign a PIP for the image updates. The PIP OB and the logic OB should be the same. You can use OB1 for everything, but it is not recommend.

 

[L D[AR2P#0.0]]

Ah, I made a typo.

L PIB300 // read IB300
T MB10 // transfer to intermediary address
A M10.2 // querying I300.2

Yes, L D's suggestion would allow you to not waste Merker memory.

It's not to save memory, it's so you can use the symbolic address at IW300 or I300.1 etc. without having to generate replicas for no good reason.