Instrument Connectivity > Increasing Speed of Instrument Communications

To improve the performance of instrument communications so that the rate that instrument variables are updated is increased:

For values on the screen adjust the Medium scan rate using File->Preferences: Runtime tab.

SpecView's maximum rate of update of a value on the screen is once every 1 tenth of a second.

SpecView's maximum rate of update of a Trend chart is once a second. However, check the resolution of the Trend Chart.

The fastest rate that values can be logged to SpecView's Data Log files is once per second. Although it is possible to write values to a separate file at a faster rate using FastCount.

However, the different parts of SpecView request values at rates that are specified below:

Screen Preferences - Runtime - Medium scan rate (default 20 tenths of a sec).

To adjust the rate at which individual variables on a GDW are sampled

edit the Dynamic Attributes.

Data Logger Preferences - Logging - Rate (default 60 secs, maximum 1 sec).

Parameter List Preferences Runtime - Parameter List PPS (Points Per Second, default 15).

Strategy Preferences - Strategy - Rate (default Medium, as defined above).

DDE DDE (default Medium, as defined above).

When the mouse isn't being moved the rate that instrument variables are being read is displayed in Points Per Second (PPS) in the 'status bar' along the bottom of the screen (GDW).

pps

If the instrument is using the Modbus protocol then the maximum points per second (PPS) that SpecView can obtain from a single COM port at 9600 baud is about 30 individual points & at 19200 baud the maximum is between 40 & 50 PPS.

The maximum speed that SpecView can obtain over a good TCP/IP connection from a fast Modbus instrument can be many hundreds of points per second. However, the 'bottleneck' is often the instrument itself.

However, SpecView also has to read Alarms & request all variables marked for logging as well as anything which is being used by the Strategy Controller. So the 30 PPS isn't just reading the ProcessValue of each instrument.

SpecView's Instrument Views & Parameter lists have been designed to request data in blocks where possible to increase comms throughput. The amount of time that a block of data is stored can be changed using the Driver Command 'TTL' (Time To Live). The difficulty is tuning the setting of Time To Live; too long & the data on the screen won't get updated from the current instrument values; but too short & the block could have timed out before SpecView has had a chance to use the data in the block & so will have to re-request it. This is especially the case if a number of instruments are turned off, or if there is a poor comms connection.

It is well worth creating a 'test' Project with just one or two instruments defined & just the minimum number of parameters out on a screen, together with GoodComms, CommsErrors, CommsErrorCode, CommsErrorItem & CommsErrorDescription, as detailed below, and noting the PPS rate.

The load can be spread over more than one COM port by using SpecView's Multiport option.

When SpecView fails to read a parameter the 'Comms Back Off Multiplier' (default value 30) is used as a delay factor before retrying. This is set from Preferences - Runtime. If instruments are intentionally turned off then to avoid SpecView repeatedly checking them set the 'Comms Back Off Multiplier' to a high value, such as 200. Although this will mean that when they are then switched back on SpecView will take longer to notice.

To see whether SpecView is having trouble reading instrument values because of a poor communications link, put these SpecView Pre-defined variables onto a screen:

SpecView.GoodComms

SpecView.CommsErrors

SpecView.CommsErrorCode

SpecView.CommsErrorItem

Specview.CommsErrorDescription

CommsErrors should be showing zero for a good communications link. Any error codes can be referenced in Error Codes.

More detail can be found in Troubleshooting Instrument Communications.

While a Project is being developed, & so maybe not all the instruments are available, the 'missing' instruments can be re-addressed in SpecView to those instruments which are present, for example, if only 2 instruments are available (which are Modbus instruments at addresses 1 and 2):

1,0J

2,0J

3,0J readdress to 1,0J

4,0J readdress to 2,0J

5,0J readdress to 1,0J

etc…

This will allow the Project to run at full speed rather than wasting time trying to gather data from instruments that are not connected. Remember to set the addresses back when all the instruments are connected.

The design of a Project can effect the apparent speed of variable update, as the more parameters which are on 'open' screens (GDWs) then the more data requests are made by SpecView. Consider whether the buttons which are being used to navigate between screens should use the action:

GDW Control: Swap to another GDW

or:

GDW Control: Close this & swap to another GDW

The 'Swap to' action leaves screens open, so these continue to request data for the variables which are on them. Whereas 'Close this & swap to' will close the screen, so use this to ensure that only the necessary screens are left open. Although, screens which contain Trend charts should be left open so that the charts continue to update.

Similarly, check which screens have 'Auto-open on Runtime' enabled on them from the File menu.

The rate that variables update when using SpecView Remote can be altered by editing the Remote connection and changing: Update rate, Packet size, Packet timeout & Packet count.

For OPC connections the OPC Server itself can be tuned, please refer to the documentation supplied with your OPC Server.

If all these items have been checked & yet the update rate is still inadequate then contact your SpecView Representative. They will be able to check that the driver commands in SpecView's communications driver, such as the timeout & number of retries, are correctly set for the specific instrument(s) being used. This is done by using the Setup COM Port menu command from the Options menu.

The fastest rate that values can be logged is once per second.

If a faster rate of logging is required then the SpecView variable FastCount can be used together with the Line Writer.