Property transfer- is it possible to give alarm when value is faulty?
We have 6.0 system AC800M with reuse library and customer want to make an alarm dynamic based on value from OPC-tag. Only solution I have found to solve this is to use Property transfer. I know it is not recommended to use property transfer in this case, however, they still want this solution if its possible to give an indication (alarm or something) when the value is bad.
How can we know and make it visible on the faceplate or HMI when the value is faulty/value overrun or "not reliable" ?
Thanks.
How can we know and make it visible on the faceplate or HMI when the value is faulty/value overrun or "not reliable" ?
Thanks.
Asked 2 months ago
Voted best answer
1
The only interaction possible with Property Transfer is via OPC DA.
If the input to a PT becomes with "bad" quality, the output will be set to (if defined) the Substitution Value (default empty). With no Substitution Value a "failed to convert to canonical datatype error" will be output to System Event List (really a stupid error to write there) and the destination will stay with the last good value that made it through.
Hence it is indeed possible to detect "bad input" by writing a specific key value via the Substitution Value function and mask it in PG2, etc.
Creating an alarm block in one PLC based on another different PLC's value transferred via OPC DA and PT is really bad... double up of everything that can possibly go wrong in Microsoft things... avoid involving OPC DA for transfer of alarm status information, use OPC AE capable PLCs. Alarm Expression is less awkward than PT.
Property Transfer is not ideal for many reasons, one of the biggest is the lack of write performance in most destination servers and what you need to take care of in case a transfer does not make it through the destination OPC server as your application expects. The PT service itself is feather weight in terms of CPU and memory.
Never transfer to a General Property. Use SoftPoint if the HMI need to store a value for you. Writing to General Properties drives the Aspect Directory Transaction count. You want to restrict aspect directory transactions to human interactions only, not automation.
If the input to a PT becomes with "bad" quality, the output will be set to (if defined) the Substitution Value (default empty). With no Substitution Value a "failed to convert to canonical datatype error" will be output to System Event List (really a stupid error to write there) and the destination will stay with the last good value that made it through.
Hence it is indeed possible to detect "bad input" by writing a specific key value via the Substitution Value function and mask it in PG2, etc.
Creating an alarm block in one PLC based on another different PLC's value transferred via OPC DA and PT is really bad... double up of everything that can possibly go wrong in Microsoft things... avoid involving OPC DA for transfer of alarm status information, use OPC AE capable PLCs. Alarm Expression is less awkward than PT.
Property Transfer is not ideal for many reasons, one of the biggest is the lack of write performance in most destination servers and what you need to take care of in case a transfer does not make it through the destination OPC server as your application expects. The PT service itself is feather weight in terms of CPU and memory.
Never transfer to a General Property. Use SoftPoint if the HMI need to store a value for you. Writing to General Properties drives the Aspect Directory Transaction count. You want to restrict aspect directory transactions to human interactions only, not automation.
Add new comment