Acyclic access for pressure value of a PA Profile APL pressure transmitter

[AlfredoAtSherpa]

Hello PROFINET Forum experts.

I have a customer who intends to use a PROFINET controller capable DCS (not a Siemens DCS) to monitor some PROFINET APL devices (pressure transmitters, etc.), in a pretty much plain-vanilla PROFINET over APL application. The devices are of course PA Profile compliant.

But even though the devices support HTTP server, FDI and FDT and these kind of fancy stuff, he has asked if it would be possible to have a second PROFINET controller (I guess it would be more like a supervisor, what used to be call master class II in PROFIBUS technology), for them to be able to monitor process value from the APL devices acyclically, even during downtime of DCS.

I have been investigating and testing the issue, and since I have no formal PROFINET training and what I know is from seminars, forums and PI publications, I think I have reached the limits of achievement for my epistemological transgression, so I hope one of the many of you far-more-learned than me in PROFINET technology can read this and confirm or correct my conclusions.

The APL device does not support shared device, and this is why the customer has thought about using acyclic.

After a lot of testing and inquiry through Copilot, as well as colleagues in Japan, here is my conclusion. Will be most grateful for confirmation of my conclusion:

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ In this true? ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
<<<The PROFINET APL does not allow acyclic access to the pressure value>>>
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑ Is this true? ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑

(Copilot also tells me that "this is consistent with PA Profile 4.02 behavior". I have not enough understanding to the PA Profile 4.02 standard, but this shocked me. Is this true?)

I wish this conclusion is wrong and that there is in fact a way to acyclically get the pressure value, in which case it will be grat for me if you can explain how to do this.

Thanks for reading down to this point!

[benja_m]

Hello PROFINET Forum experts.

I have a customer who intends to use a PROFINET controller capable DCS (not a Siemens DCS) to monitor some PROFINET APL devices (pressure transmitters, etc.), in a pretty much plain-vanilla PROFINET over APL application. The devices are of course PA Profile compliant.

But even though the devices support HTTP server, FDI and FDT and these kind of fancy stuff, he has asked if it would be possible to have a second PROFINET controller (I guess it would be more like a supervisor, what used to be call master class II in PROFIBUS technology), for them to be able to monitor process value from the APL devices acyclically, even during downtime of DCS.

I have been investigating and testing the issue, and since I have no formal PROFINET training and what I know is from seminars, forums and PI publications, I think I have reached the limits of achievement for my epistemological transgression, so I hope one of the many of you far-more-learned than me in PROFINET technology can read this and confirm or correct my conclusions.

The APL device does not support shared device, and this is why the customer has thought about using acyclic.

After a lot of testing and inquiry through Copilot, as well as colleagues in Japan, here is my conclusion. Will be most grateful for confirmation of my conclusion:

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ In this true? ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
<<<The PROFINET APL does not allow acyclic access to the pressure value>>>
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑ Is this true? ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑

(Copilot also tells me that "this is consistent with PA Profile 4.02 behavior". I have not enough understanding to the PA Profile 4.02 standard, but this shocked me. Is this true?)

I wish this conclusion is wrong and that there is in fact a way to acyclically get the pressure value, in which case it will be grat for me if you can explain how to do this.

Thanks for reading down to this point!

Profinet defines an acyclic object that can be used to access the cyclic data: RecordInputDataObjectElement (index 0x8028)
Using ReadRequest service (either DeviceAccess AR or ReadImplicit) on an Input submodul should return the input data plus IOxS of the submodule.
A brief description of the service is given in Profinet Service specification document, section "Read Record Input Data Object Element".

As far as i know this needs to be implemented by every Profinet device. However, i am not familiar with PA Profile and do not know if that defines some exception here.

[AlfredoAtSherpa]

Hello PROFINET Forum experts.

I have a customer who intends to use a PROFINET controller capable DCS (not a Siemens DCS) to monitor some PROFINET APL devices (pressure transmitters, etc.), in a pretty much plain-vanilla PROFINET over APL application. The devices are of course PA Profile compliant.

But even though the devices support HTTP server, FDI and FDT and these kind of fancy stuff, he has asked if it would be possible to have a second PROFINET controller (I guess it would be more like a supervisor, what used to be call master class II in PROFIBUS technology), for them to be able to monitor process value from the APL devices acyclically, even during downtime of DCS.

I have been investigating and testing the issue, and since I have no formal PROFINET training and what I know is from seminars, forums and PI publications, I think I have reached the limits of achievement for my epistemological transgression, so I hope one of the many of you far-more-learned than me in PROFINET technology can read this and confirm or correct my conclusions.

The APL device does not support shared device, and this is why the customer has thought about using acyclic.

After a lot of testing and inquiry through Copilot, as well as colleagues in Japan, here is my conclusion. Will be most grateful for confirmation of my conclusion:

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ In this true? ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
<<<The PROFINET APL does not allow acyclic access to the pressure value>>>
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑ Is this true? ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑

(Copilot also tells me that "this is consistent with PA Profile 4.02 behavior". I have not enough understanding to the PA Profile 4.02 standard, but this shocked me. Is this true?)

I wish this conclusion is wrong and that there is in fact a way to acyclically get the pressure value, in which case it will be grat for me if you can explain how to do this.

Thanks for reading down to this point!

Profinet defines an acyclic object that can be used to access the cyclic data: RecordInputDataObjectElement (index 0x8028)
Using ReadRequest service (either DeviceAccess AR or ReadImplicit) on an Input submodul should return the input data plus IOxS of the submodule.
A brief description of the service is given in Profinet Service specification document, section "Read Record Input Data Object Element".

As far as i know this needs to be implemented by every Profinet device. However, i am not familiar with PA Profile and do not know if that defines some exception here.

Benja_m:

Thanks so much. If I use Profinet Commander communicating cyclically, I am able to access the RecordInputDataObjectElement acyclically from the Profinet Commander.

But if I setup an S7-1200, without configuring the the Cerabar as a Profinet IO, the Cerabar ignores the acyclic requests from the S7-1200. I wonder whether by S7-1200 program is wrong. Below is the Profinet Commander and the S7-1200 program. The S7-1200 is taken without the Profinet Commander running.

[benja_m]

Hello PROFINET Forum experts.

I have a customer who intends to use a PROFINET controller capable DCS (not a Siemens DCS) to monitor some PROFINET APL devices (pressure transmitters, etc.), in a pretty much plain-vanilla PROFINET over APL application. The devices are of course PA Profile compliant.

But even though the devices support HTTP server, FDI and FDT and these kind of fancy stuff, he has asked if it would be possible to have a second PROFINET controller (I guess it would be more like a supervisor, what used to be call master class II in PROFIBUS technology), for them to be able to monitor process value from the APL devices acyclically, even during downtime of DCS.

I have been investigating and testing the issue, and since I have no formal PROFINET training and what I know is from seminars, forums and PI publications, I think I have reached the limits of achievement for my epistemological transgression, so I hope one of the many of you far-more-learned than me in PROFINET technology can read this and confirm or correct my conclusions.

The APL device does not support shared device, and this is why the customer has thought about using acyclic.

After a lot of testing and inquiry through Copilot, as well as colleagues in Japan, here is my conclusion. Will be most grateful for confirmation of my conclusion:

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓ In this true? ↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
<<<The PROFINET APL does not allow acyclic access to the pressure value>>>
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑ Is this true? ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑

(Copilot also tells me that "this is consistent with PA Profile 4.02 behavior". I have not enough understanding to the PA Profile 4.02 standard, but this shocked me. Is this true?)

I wish this conclusion is wrong and that there is in fact a way to acyclically get the pressure value, in which case it will be grat for me if you can explain how to do this.

Thanks for reading down to this point!

Profinet defines an acyclic object that can be used to access the cyclic data: RecordInputDataObjectElement (index 0x8028)
Using ReadRequest service (either DeviceAccess AR or ReadImplicit) on an Input submodul should return the input data plus IOxS of the submodule.
A brief description of the service is given in Profinet Service specification document, section "Read Record Input Data Object Element".

As far as i know this needs to be implemented by every Profinet device. However, i am not familiar with PA Profile and do not know if that defines some exception here.

Benja_m:

Thanks so much. If I use Profinet Commander communicating cyclically, I am able to access the RecordInputDataObjectElement acyclically from the Profinet Commander.

But if I setup an S7-1200, without configuring the the Cerabar as a Profinet IO, the Cerabar ignores the acyclic requests from the S7-1200. I wonder whether by S7-1200 program is wrong. Below is the Profinet Commander and the S7-1200 program. The S7-1200 is taken without the Profinet Commander running.

It seems the request is too shorts. The IODReadReqHeader should contain 8 padding bytes after the TargetARUUID which seem to be missing in screenshot. That could be cause for completely missing reaction of the device.

[AlfredoAtSherpa]

It seems the request is too shorts. The IODReadReqHeader should contain 8 padding bytes after the TargetARUUID which seem to be missing in screenshot. That could be cause for completely missing reaction of the device.

Benja_m, hello again. I was not able to work on this issue in the last week or so, until today. I think I have fixed my S7-1200 program and now the request is being sent correctly (I think), as there is no malformed warning from the Wireshark add-in for PROFINET. And also because now there is a response from the field device.

Unfortunately it seems the field device does not support the "implict read" request. Can you please have a look and the Wireshark trace so you may confirm that the request is being sent correctly? If that is the case, I will contact the representative of the manufacturer here in Japan.

[AlfredoAtSherpa]

It seems the request is too shorts. The IODReadReqHeader should contain 8 padding bytes after the TargetARUUID which seem to be missing in screenshot. That could be cause for completely missing reaction of the device.

Benja_m, hello again. I was not able to work on this issue in the last week or so, until today. I think I have fixed my S7-1200 program and now the request is being sent correctly (I think), as there is no malformed warning from the Wireshark add-in for PROFINET. And also because now there is a response from the field device.

Unfortunately it seems the field device does not support the "implict read" request. Can you please have a look and the Wireshark trace so you may confirm that the request is being sent correctly? If that is the case, I will contact the representative of the manufacturer here in Japan.

I have also tried to access index 0xB00E, "PROCESS VARIABLE" parameter for Analog Input Block as per PA profile which is mandatory according to this standard. Tried slot/subslot 1/1 and 0/1, but in all cases I get nca_unk_if. I wonder whether I am doing something incorrectly or whether this device conforms to the PA Profile. Thanks for your advice.

[AlfredoAtSherpa]

I have also tried to access index 0xB00E, "PROCESS VARIABLE" parameter for Analog Input Block as per PA profile which is mandatory according to this standard. Tried slot/subslot 1/1 and 0/1, but in all cases I get nca_unk_if. I wonder whether I am doing something incorrectly or whether this device conforms to the PA Profile. Thanks for your advice.

Hello Benja_m:
I realize how clueless I am. The target_ARUUDI are set to zero. I need to fund out how to correctly set this parameters.
It seems this topic is not for this forum. Sorry about that.

[benja_m]

I have also tried to access index 0xB00E, "PROCESS VARIABLE" parameter for Analog Input Block as per PA profile which is mandatory according to this standard. Tried slot/subslot 1/1 and 0/1, but in all cases I get nca_unk_if. I wonder whether I am doing something incorrectly or whether this device conforms to the PA Profile. Thanks for your advice.

Hello Benja_m:
I realize how clueless I am. The target_ARUUDI are set to zero. I need to fund out how to correctly set this parameters.
It seems this topic is not for this forum. Sorry about that.

Unknown interface means that the ObjectUUID inside the DCE/RPC part of the request is unknown to the RPC layer of the device.
According to your screenshot, the ObjectUUID consists of only 0s which is obviously incorrect.

This error message is not related to the TargetARUUID, which is a different UUID used for other purposes in a different communication layer.