Hi,
I have the following use case: There is a DPE that is a readback of an OPC UA variable. There exists another DPE that indicates whether the value of the first DPE is valid or not (let's call it heartbeat status). Since it is the driver (OPC UA Client) that invalidates the value in case of a connection loss (and lets assume there isn't a pv_range set), is it possible to invalidate the value of the readback DPE based on the heartbeat status, and what would be the correct approach to achieve that?
Best regards
Is it possible to invalidate a DPE value based on the value of other DPEs?
Search
Re: Is it possible to invalidate a DPE value based on the value of other DPEs?
Based on the configuration of th config entry setInvalidForConnLoss the OPC UA client can set the elements invalid if the OPC UA connection is lost.
Why do you need an additional function to set the input elements invalid if no heartbeat is received?
When you need an additional function to set the elements invalid you can do it
-- with a CTRL script which connects to the heartbeat status
-- with a DP function at an additional element which connects to the element with the _address config and the heartbeat status
Best Regards
Leopold Knipp
Senior Support Specialist
Why do you need an additional function to set the input elements invalid if no heartbeat is received?
When you need an additional function to set the elements invalid you can do it
-- with a CTRL script which connects to the heartbeat status
-- with a DP function at an additional element which connects to the element with the _address config and the heartbeat status
Best Regards
Leopold Knipp
Senior Support Specialist
Re: Is it possible to invalidate a DPE value based on the value of other DPEs?
Thanks for replying Leopold,
Why do you need an additional function to set the input elements invalid if no heartbeat is received?
- I was hoping to use trend tool to display the values as invalid (out of the box trend functionality) in case of connection loss or invalidation of the values (e.g. heartbeat) from PLC side.
About the approach that you are proposing:
- is it not possible that a new VC would arrive and get written into the DPE before the suggested logic would set invalidated bit for the previous VC (in this case it would set it for the new value)?
- also I assume that going for such logic that would be applied to most DPE's in the system, could actually double the load onto WinCC OA (which is not what I would want to trade just to display a value on a graph) ?
BR,
Matevž Žugelj
Why do you need an additional function to set the input elements invalid if no heartbeat is received?
- I was hoping to use trend tool to display the values as invalid (out of the box trend functionality) in case of connection loss or invalidation of the values (e.g. heartbeat) from PLC side.
About the approach that you are proposing:
- is it not possible that a new VC would arrive and get written into the DPE before the suggested logic would set invalidated bit for the previous VC (in this case it would set it for the new value)?
- also I assume that going for such logic that would be applied to most DPE's in the system, could actually double the load onto WinCC OA (which is not what I would want to trade just to display a value on a graph) ?
BR,
Matevž Žugelj
Re: Is it possible to invalidate a DPE value based on the value of other DPEs?
The trend tool can only display the status information written to the DP element displayed in the trend.mzugelj wrote: ↑Thu Apr 23, 2020 1:08 am Thanks for replying Leopold,
Why do you need an additional function to set the input elements invalid if no heartbeat is received?
- I was hoping to use trend tool to display the values as invalid (out of the box trend functionality) in case of connection loss or invalidation of the values (e.g. heartbeat) from PLC side.
There is no functionality which displays the values as invalid based on information from another DP element.
Not receiving the heartbeat will be similar to the information in the driver that the connection is lost.
Therefore, I do not see a benefit in implementing an additional function which will have the same effect as the available driver functionality.
No, it cannot happen that a wrong value (the next value) is marked as invalid when the loss of connection is detected.mzugelj wrote: ↑Thu Apr 23, 2020 1:08 am About the approach that you are proposing:
- is it not possible that a new VC would arrive and get written into the DPE before the suggested logic would set invalidated bit for the previous VC (in this case it would set it for the new value)?
- also I assume that going for such logic that would be applied to most DPE's in the system, could actually double the load onto WinCC OA (which is not what I would want to trade just to display a value on a graph) ?
The messages are processed in the correct order.
-- Loss of connection detected in the driver
-- Elements are set invalid
-- Connection is established
-- Next value is written without invalid information
Best Regards
Leopold Knipp
Senior Support Specialist