Verify the Write?

When writing to hardware, you can be assured that the SCADA system will attempt to send the signal you requested. Ensuring that the signal arrives is another question, and it is the role of the driver to answer that.

For nearly all protocols supported by VTScada, including Modbus, DNP3, CIP, DF1/PCCC, Step 7, etc., the messages sent to a device will receive one of the following three results. (These are inherent to the protocol, not the VTScada driver.)

• The device responds with a positive acknowledgment that the command was received and accepted.
• The device responds with a negative acknowledgment that the command was received but NOT accepted.
• The device does not respond at all

 

For case #1, the VTScada driver will receive the acknowledgment and know that the write succeeded. (The success count in the driver will increase, the error count will not, and the value of driver will remain 0.) Nothing more needs to be done.

For case #3, Most VTScada drivers will invoke their retry logic and automatically attempt the write a predefined number of times before giving up and declaring an error. This error is set into the value of the driver and you can then alarm on it to indicate that there was a problem. This varies by driver. For example, the Modbus protocol does not send a response to writes and therefore there is no point in using retry logic. Refer to the standards for your selected protocol. (Communication Driver Alarms)

Case #2 is more difficult in that it tends to be protocol-specific. For example, if you attempt to write to a non-existent address using a Modbus Compatible driver, you can expect a Modbus exception code response from the device. Attempting to write the same value again to the same address would not accomplish anything because the device has already signaled that it cannot do what is being asked (write to a non-existent register). As with case #3, the value of the driver will be set to the appropriate error code and can be used to generate an alarm.

In other drivers (for example, the Allen Bradley DF1), the device can respond with a NAK response if we send a message that becomes scrambled, as indicated by a bad CRC. In this case we DO want to retry the message and the retry logic is invoked. If the condition persists for the number of defined retries, the value of the driver tag is again set to an error code that can be alarmed on.

Beyond monitoring driver error codes and quality values, you can also ask the PLC to confirm your request. This is done by programming the PLC to set a verification value on a separate address when it receives a command from the SCADA system. By monitoring that address, you can be sure that the PLC received the command that you sent.