Is DPRD in S7-1500 still usefull?

• In the control program you need input values that are more recent than those available in the process image (...you can use decentral peripherie with DPRD). Link

But now for the S7-1500 CPU's, all IO is available in the process image. Link

Does anyone know what this means for using DPRD in an S7-1500?

For example: When I call function DPRD_DAT during my program to read 8 bytes of data from a profinet device. Will the progrem get it's data from the PIPI, or is the CPU going to send out a new profinet telegram, to get data that is newer than the data already in the PIPI?

AutoGen_9314060

Hi all,

I'm confused about decentral peripherie in the S7-1500.

In the S7-300 CPU's, it used to be true that:

• In the control program you need input values that are more recent than those available in the process image (...you can use decentral peripherie with DPRD). Link

But now for the S7-1500 CPU's, all IO is available in the process image. Link

Does anyone know what this means for using DPRD in an S7-1500?

For example: When I call function DPRD_DAT during my program to read 8 bytes of data from a profinet device. Will the progrem get it's data from the PIPI, or is the CPU going to send out a new profinet telegram, to get data that is newer than the data already in the PIPI?

 Even in 300/400, if you use DPRD_DAT, it executes with the normal program execution, so it's not updating just like it is in a 1500.  The whole concept is a little different in 1500, since the whole I/O area is in the Process image, it's just enought to read and write the I/O.

If you need to use updated I/O status during program execution, you need to address the PIW/PQW in a 300/400 or use :P on a 1200/1500.

Hello,

if I could say my personal opinion also, if you look at DPXX_DAT blocks you can also see that RECORD parameter help you handle data more effectivelly. I mean that there is no problem with bigger consistent area defined as store place, some memory defined like P#M100.0 BYTE 64 can be set directly and you can then have stored data there without to do any conversions from PI areas to your expected buffer/memory in your code what can be in some situation hard to do, also with more space used in your code. All depends to your actual situation but consistency and error free data exchange in case of interrupt can help here probably, compared to typical access to PI areas from code.