Siemens Portal Inputs Read Before or During Scan

I am working with a Siemens 1500 in portal, and I want to know if my Profinet inputs can change during the scan of the PLC code. When do local and remote inputs get read into the PLC? Before the logic scan or during? Also I know that in classic step 7 you could add a to an address to access the input at the moment in the scan it is being used. Is that possible in portal with a 1500?

Thanks in advance

The scan sequence is:

1. Write Process Image Outputs to the output modules (including Profinet)
2. Read Process Image Inputs from the input modules (including Profinet)
3. Execute Code

If you use after your input or output addresses, it is read or written immediately at that spot in the code. Yes it is possible in S7-1500.

The short version is that the inputs will only change during your PLC scan if you tell them to.


The longer version:
S7-1500 essentially combines the speed of asynch updates with the consistency of the traditional synchronous scan.

Local inputs and outputs are read/written on command over the backplane. Remote IO (PN/DP) are transmitted at the defined update interval, which is typically much faster than the PLC cycle.

HOWEVER. The Process Image automatically buffers these values for you during the PLC scan. At the beginning of OB1, the PLC copies the latest values for all the inputs into the Process Image, either remembered from the last packet recieved from remote IO or over the backplane for local. When you create a tag pointing to IW10, it reads from this buffered Process Image, not the most up to date value. To read the most up to date value, you use "Tagname", as you suggested. There is no need to use the older PIW10 from the S7-300 world.

When the PLC scan ends, the values for the outputs in the process image are either sent over the backplane to local cards, or sent to the comm interface to be sent to the remote IO at the next appropriate interval. The "" notation can similarly be used for a peripheral write. This is immediate for local IO, but as far as I know, for remote IO, it still waits for the next scheduled packet.

This means, essentially, that in most cases many of the PN packets sending values to Output cards carry duplicate data, because they are sending the data from the end of the last scan multiple times, until the next scan ends.


Extra Advanced Note:
You can actually split up the process image into Process Image Partitions, and have different IO racks updated in the process image with different OBs. This is automatically done for Motion/IRT/Technology Objects, but can sometimes also make sense when Cyclic OBs are used.

Thanks for the info. Exactly what I was looking for.

You can also link the update of the values with a specific OB by assigning the hardware to a different Process Image. It's a bit strange functionality and I've never had to use it, but it's there if you don't need to update certain instruments at the same rate as OB1 or if you structure your program outside of OB1 (as PCS7 does).

cardosocea said:

You can also link the update of the values with a specific OB by assigning the hardware to a different Process Image. It's a bit strange functionality and I've never had to use it, but it's there if you don't need to update certain instruments at the same rate as OB1 or if you structure your program outside of OB1 (as PCS7 does).

Click to expand...

Besides the system automatically using them for motion, I've only ever really seen it make sense for IO linked to PID loops that are called in a cyclic interrupt. And even then, you can just use instead.

mk42 said:

Besides the system automatically using them for motion, I've only ever really seen it make sense for IO linked to PID loops that are called in a cyclic interrupt. And even then, you can just use instead.

Click to expand...

Never thought about that particular use case... perhaps it's something that was put there to begin with for motion and made available for the user.

cardosocea said:

Never thought about that particular use case... perhaps it's something that was put there to begin with for motion and made available for the user.

Click to expand...

Process Image Partitions were an S7-400 thing (like you said, PCS7), and they were one of the things that stuck around when the features of the 300 & 400 were smooshed together to make the 1500.