Support | Order Placement | ProScada Home Page | Download Demos
RP5 Driver performance
RP 570 Protocol commands Supported By the FIX RP5 Driver
SCI & RTU responds with EXR
Polling (SCADA -> RTU)
ERMI (logged to Relational DB)
AI's (RTU->SCADA) (Max 256 objects)
The Analog inputs are 12 bits ranging +/- 2047, scaleable to any engineering units
DO's & AO's & Controls (SCADA -> RTU)
SPM (16 bits) (Max 256 objects)
GOM (1,8 or 16 bits), for 1 bit use GOMS in RTU for 8 use GOM8, 16 available for Virtual IO (Max 256 objects)
IXC (Pulse start Pulse stop commands drives 2 outputs) (Max 2048 objects)
Time Synchronisation (SCADA -> RTU)
RTU Status Bits (RTU->SCADA)
Pulse counter messages(RTU->SCADA)
The pulse counters contain the analog value (Current Count of the Counter) & the 8 Status bits of the counter
Commands not supported
All messages not mentioned here, most of these are RTU configuration messages like FTAB & FCOM
Polling performance of RP5 driver
I am making the following predictions based on a system running with a baud rate of 9600 baud & a RTU response time of < 30 milliseconds. If the RTU comms is Program scan cycle dependent this could result in slower response times
This protocol is completely event driven, this means that the SCADA interrogates each RTU in turn for change of state data. Typically we have seen interrogation rates of 20+ interrogations per second (RTU responding with no change of state). Obviously when the RTUs have data to report this will slow down a little.
If you have 10 RTUs each RTU will be interrogated every 0.5 seconds. If the system is reporting several Change of state events, this may be reduced to 0.5 to 1.0 seconds. The response times are relatively independent of IO count size.
1/ It is assumed that the RTUs are properly set-up so that jittery Digital & analogue inputs are not reporting continuously.
2/ Increased baud rates
3/ RTU response time
4/ Splitting RTUs onto more serial ports
Update time performance from driver memory image to operator Screen
Inside the FIX System there are two Levels of update time,
Process database scantime
Picture update time
Process Database Scantime
Every AI & DI point in the database can have a Scantime (default 1sec) or can be exception based
If set to exception based the database scantime delay is negligible.
The RP5 driver allows all points to be exception based.
Picture update time
Each mimic file has an individual "Refresh rate", the default is 0.1 Sec
Disadvantages of high Picture refresh rate
If there are many IO points on the picture (< 30 is considered small) the VIEW application starts taking the lions share of the CPU time. Generally increasing Refresh period to 0.2 sec solves this
This is also the rate at which data is requested by VIEW nodes across the network. If you have many VIEW nodes OR your network bandwidth is limited The FIX networking may overload the WAN e.g. if you are connecting remote sites with narrow band WAN links (NS Carrier is implementing a narrow band WAN). Here we recommend increasing Refresh period to 0.5 or more sec.
©Copyright 2004 ProScada CC. All Rights Reserved