Message exchange mechanisms in PcVue 

Most of the Equipment drivers are based on the request/response communication pattern where PcVue is the master/client that sends requests and the field device is the slave/server that respond to requests.
This topic explains how message exchanges are scheduled, what trigger communication errors and what you can do to optimize the request/response flows.

There are three time periods used to control message sending and detect communication errors:

• Device time-out - Configured at the device level, it is the maximum time PcVue waits for a reply from the field device after having sent a request.
• Polling period - Configured at the frame level, it is the interval at which PcVue sends a frame request to the field device (except for write-only frames).
• Message time-out - Configured at the device level, it is the minimum interval that PcVue must wait, after receiving an answer, before sending any other request. This is not used for many of the drivers. It set to 0 except for drivers over a communication media that requires such an inter-request delay (typically radio only).

Request/response and error management

For each configured frame, the sequence for exchanging messages (not taking into account the message time-out) is as follows: Show picture

1.  PcVue sends a request message for the frame and waits for a reply.
2. If a reply is received, PcVue waits for the polling period and sends the next request.
3. If the field device does not reply within the device time-out period, the request is retried up to three times, in an attempt to get a reply.
4. If, after the third retry, there is still no reply (or an invalid one), the frame is flagged in error and the device is flagged as unhealthy. The frame and device status are updated.
5. Subsequent requests for the frame are processed at the frame polling period, but only tried once. If no reply is received (or an invalid one), the error count is incremented.
6. When a reply is received, the frame is flagged Ok, and the device is flagged as healthy. The frame and device status are updated.

The read and write queues

 PcVue processes frames using a queue mechanism. Frame requests are added to the end of the queue. Frames requests are processed from the front of the queue, ensuring frames are processed in strict order. This is known as a first in first out mechanism.

The frame queues are organized in pairs, one for read frames and one for write frames. The Communication Manager toggles between the two queues processing a read request and then a write request. If one or other of the queues is empty, it is omitted from the sequence.

• For a serial driver there is one read queue and one write queue for each network. The frames for all devices on a network are managed by the two queues.
• For a TCP/IP driver there is one read queue and one write queue per device.

Frames that have the Priority mode property ticked go to the front of the queue bypassing the queuing mechanism.

What you can do to optimize

It is necessary that you design the format and tune the handling of messages, to sustain the data flows required, for PcVue to function effectively. Tuning consists in playing with:

• Polling periods - Choose the right polling period in the frames configuration to fit your data freshness needs
• Device timeouts - Choose the right device timeout depending on the field device (and network) responsiveness
• Frame sizes - In general, avoid many small frames, prefer a few large ones

The importance of correctly configured frames

It is especially important to configure the frames correctly. Incorrectly configured frames (incorrect address, incorrect size etc.) will, depending on the field device and driver, cause an overhead due to error processing. While errors are being processed, communication using healthy frames will be delayed with a consequential reduction in performance.

• When using a serial driver, incorrect configuration will have an impact on the entire network.
• When using a TCP/IP driver, incorrect configuration will affect a particular device.

Tune the polling period

The Communication Manager sends out requests to the field devices cyclically. The period at which the requests are sent is specified by the frame polling rate. The default value is set to 1 second, but you should change it to a value that reflects the rate of change in your process. If for instance, you were monitoring a temperature setting, a polling period of 1 second would normally be too frequent. You might set the polling period to 1 minute or more to reduce the message traffic on the network. Show picture

Tune the frame size

You should minimize the number of frames transferred between field devices and PcVue. It is preferable to use one large frame than several small ones, even if not all frame addresses are mapped to variables. Show picture

However, you must also balance this with the polling period. For example, if just one variable is required at a 1-second rate and the others at a 1- minute rate it is better to have two frames, one small frame scanned once per second and one large frame scanned at once per minute.

SCADA Basic communication optimization

When you are developing a SCADA Basic script and you want to send several values to equipment variables you must use the SET and SENDLIST instructions rather than try to write the values directly one by one. So instead of coding commands this way:

@VAR1 = 10;
@VAR2 = 11;
@VAR3 = 12;

It is best practice to code them this way:

SET("VAR1",10);
SET("VAR2",11);
SET("VAR3",12);

Then issue one SENDLIST command:

SENDLIST("BLOC");