Hi,
We have a project where the PLC code uses DPRD_DAT and DPWR_DAT to move data from peripheral IOs to a Data structure in a DB. he peripheral IOs are in this case Profinet servo data.
We are trying to validate the PLC code against an emulation model, but we have never read and write to ":P" addresses. When it comes to IOs, we usually disable the cards from the scan cycle and write directly into I and O memory.
The question is, is it possible to write in peripheral memory? what about if we use PLCSim or PLCSimAdv?
Thanks in advance!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It's possible, but not with the current Nettoplcsim version.
Plcsim for S7-300/400 has an API (ProSim), where you can access or simulate peripheral IO. In Nettoplcsim versions before v0.9 I was using this interface. But the interface is rather slow compared to the S7online interface I'm using now. I don't know if I implemented accessing the peripheral data in the network part of these old versions. But be aware that the old Plcsim didn't support Profinet IO, you had to modify the hardware configuration to other dummy IO periphery which provide the peripheral data.
The standard Plcsim for S71200/1500 hasn't any API at all. This is only available in Plcsim Advanced, but I haven't used it so I can't tell you what's possible with this interface.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mikel, as I'm just working on the old version which used the S7ProSim interface, I can add this feature too, if you are ok with some limitations of the old version.
Like it's not responding to all SZL requests as the new version does. And S7ProSim is limited, that peripheral inputs can only be written, and peripheral outputs only be read. And you can't access single bits, the smallest unit is 1 byte in this area.
And S7ProSim is rather slow. Every method call on S7ProSim takes about 0,7 ms. For example if you want to access 20 items of non-consecutive areas, only the Prosim calls would take 14 ms. I've done simulations using a game engine with a 16,7ms cycle (@60 FPS), for this S7ProSim is too slow if you want to update the data every cycle.
Last edit: Thomas Wiens 2023-10-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I just discovered, the S7 protocol doesn't differ between addressing peripheral inputs and outputs. Theres only one code 0x80 for periphery, it's the same as the area for an ANY-pointer in a S7 program. For example if you address in WinCC flexible PIW100 and PQW100, on the network the addresses are the same. I haven't a S7 with periphery for testing what value you'll get, if you have both addresses in your hardware configuration (PIW100 for an analog in, and PQW100 for an analog out).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Thomas,
We did try using 0x80 code but we get error responses even if we try to just write to inputs and read on outputs. We are using our code against PLCSim... We also realized that there is no different code for inputs and outputs ;)
Did you managed to read or write with code 0x80?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Are you using the current S7online version of nettoplcsim, or the old S7ProSim variant 0.7.2?
The S7ProSim variant doesn't allow area code 0x80. But if you write to an input 0x81, I'm using the S7ProSim method "WriteInputPoint()", which does also write to the periphery, if I understand the documentation correctly.
The same with reading outputs with 0x82 where im using the method ReadOutputPoint()".
When I'm adding the area code 0x80, my idea was to use ReadOutputImage / WriteInputImage, but I suspect they are doing the same as ReadOutputPoint / WriteInputPoint. Only with an option to access more then 4 bytes with one call.
When using the current version of nettoplcsim, what you can do for simulation is, to download an hardware configuration without and periphery for testing, and the write to the peripheral image. But this does not work if you are using direct periphery access like PIW 100 in your code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
We have a project where the PLC code uses DPRD_DAT and DPWR_DAT to move data from peripheral IOs to a Data structure in a DB. he peripheral IOs are in this case Profinet servo data.
We are trying to validate the PLC code against an emulation model, but we have never read and write to ":P" addresses. When it comes to IOs, we usually disable the cards from the scan cycle and write directly into I and O memory.
The question is, is it possible to write in peripheral memory? what about if we use PLCSim or PLCSimAdv?
Thanks in advance!
It's possible, but not with the current Nettoplcsim version.
Plcsim for S7-300/400 has an API (ProSim), where you can access or simulate peripheral IO. In Nettoplcsim versions before v0.9 I was using this interface. But the interface is rather slow compared to the S7online interface I'm using now. I don't know if I implemented accessing the peripheral data in the network part of these old versions. But be aware that the old Plcsim didn't support Profinet IO, you had to modify the hardware configuration to other dummy IO periphery which provide the peripheral data.
The standard Plcsim for S71200/1500 hasn't any API at all. This is only available in Plcsim Advanced, but I haven't used it so I can't tell you what's possible with this interface.
Thanks for your answers Thomas! We need to figure out another way to deal with that PLC code then.
Mikel, as I'm just working on the old version which used the S7ProSim interface, I can add this feature too, if you are ok with some limitations of the old version.
Like it's not responding to all SZL requests as the new version does. And S7ProSim is limited, that peripheral inputs can only be written, and peripheral outputs only be read. And you can't access single bits, the smallest unit is 1 byte in this area.
And S7ProSim is rather slow. Every method call on S7ProSim takes about 0,7 ms. For example if you want to access 20 items of non-consecutive areas, only the Prosim calls would take 14 ms. I've done simulations using a game engine with a 16,7ms cycle (@60 FPS), for this S7ProSim is too slow if you want to update the data every cycle.
Last edit: Thomas Wiens 2023-10-20
As I just discovered, the S7 protocol doesn't differ between addressing peripheral inputs and outputs. Theres only one code 0x80 for periphery, it's the same as the area for an ANY-pointer in a S7 program. For example if you address in WinCC flexible PIW100 and PQW100, on the network the addresses are the same. I haven't a S7 with periphery for testing what value you'll get, if you have both addresses in your hardware configuration (PIW100 for an analog in, and PQW100 for an analog out).
Hi Thomas,
We did try using 0x80 code but we get error responses even if we try to just write to inputs and read on outputs. We are using our code against PLCSim... We also realized that there is no different code for inputs and outputs ;)
Did you managed to read or write with code 0x80?
Are you using the current S7online version of nettoplcsim, or the old S7ProSim variant 0.7.2?
The S7ProSim variant doesn't allow area code 0x80. But if you write to an input 0x81, I'm using the S7ProSim method "WriteInputPoint()", which does also write to the periphery, if I understand the documentation correctly.
The same with reading outputs with 0x82 where im using the method ReadOutputPoint()".
When I'm adding the area code 0x80, my idea was to use ReadOutputImage / WriteInputImage, but I suspect they are doing the same as ReadOutputPoint / WriteInputPoint. Only with an option to access more then 4 bytes with one call.
When using the current version of nettoplcsim, what you can do for simulation is, to download an hardware configuration without and periphery for testing, and the write to the peripheral image. But this does not work if you are using direct periphery access like PIW 100 in your code.