Hi

I have more and more project with a lot of I/ODevice on Profinet.
The last one is 250 I/O Device, with 64octet Input and Output each
I read a lot on manual, but I want to be sure what I understood.

For the choice of the CPU, I need to pay attention to :
- the max I/O device acceptable (example : CPU1510 =64, CPU1517=512)
- the max number of module/submodule (seems OK with the max I/O device in my case)
- the max process image (32Ko for each CPU 15xx, but limited to 8Ko on I/O Device before the 1517, which is 32Ko)
- the cycle time when running 

That's it ?

After that, I can declare the devices, and start the code.
For each Device, TIA reserve an adress range %I and %Q that I can use (the process_image).
I check the property of my ethernet, and the send_clock is set to 1ms (by default)
My cycle time is minimum 10ms, so I can easily put my send_clock to 4ms (the max) ? half of my cycle time, right ?
The calculated bandwidth is 30% with 1ms, and 11.8% with 4ms, so we have reserve. Seems correct.

Now, to manage data, I use DPRD_DAT and DPWR_DAT.
To manage this, I class IOdevice by number (1 to max), I complete an array[1..max]of HW_INPUT and OUTPUT the constant one, for each device :
"DB_Device".#Device[#key].HW_INPUT := "constant system of device n°key";
"DB_Device".#Device[#key].HW_OUTPUT := "constant system of device n°key";
And call a FC with a loop, which use in input, the two HW_submodule, in in/out an array[1..max] with the data that I want to use (I don't need the 64octet) with the help of DPRD/WR_DAT
I can separate this FC in two, to check the INPUT at the beginning, and put the OUTPUT at the end (to not lose 1 cycle to update the output)

But, I read here
https://support.industry.siemens.com/tf/WW/en/posts/dprd-dat-dprw-dat-instructions/157957?page=0&pageSize=10
that this function communicate directly with the device.
So, if I understand correctly, the "update" will be done twice (one automatically every send_clock and one by program with DP_DAT).
If it is correct, it also means that the bandwidth calculated by the CPU will not be the real one ?
It will be wiser to use PEEK and POKE directly on the process_image, right ?
If I misunderstand, it's just that using DPRD_DAT take cycle_time, but as much as PEEK and POKE ?

Thanks in advance

First, thank you for your time for this discussion, really thank you

fritz

 As luck would have it, https://www.felser.ch/profinet-manual/t_-_timing.html contains a table that is based on 60 Bytes I/O data per IO Device (close enough to your 64 Bytes) and different update times. As you can see (or extrapolate from it), with 8ms update time per IO Device, you'll end up with ~30% Netload. A quick check with PI's Netload calculation Excel tool as attached confirms this too (I assumed 4 I/O modules per Device).

 Yes, I declared different hardware configuration, and that's what I observed :
TIA adapts itself, the devices (when 240) go to 8ms, because TIA respects, precisely, the 20%

fritz

Can't say I agree with the post you referenced and will argue that using DPRD_DAT and DPWR_DAT will NOT lead to additional PN traffic. Instead these will simply read/write the latest values from/to the PN I/O Controllers buffer as and when called. If your process Image is large enough (and you don't need to have the most current values throughout the cycle) there's no need for DPRD_DAT or DPWR_DAT.

 That is what I thought. DPRD_DAT increases the cycle time (necessarily with 64Bytes * the number of devices + the function itself), but does not modify the process_image, nor its operation.

It's just that this function is handy, since it "tackles" with the HW_IO uniquely, rather than having to use the %I address range ; which, in my opinion, is one less source of error (at the expense of cycle time...)
At least, we have the choice. See this discussion in parallel :
https://support.industry.siemens.com/tf/ww/en/posts/improve-block-and-have-only-one-input-in-fb-with-hw-id-of-device/273664?page=0&pageSize=300