Support | Order Placement | ProScada Home Page | Download Demos
Tips on Optimizing Most Drivers
FIX IO drivers are highly configurable, compared to other systems that perform automatic configuration of Polled data. FIX IO Drivers will always be as fast or faster than an automatic configuration when properly configured.
Please Note that All FIX drivers achieve the Maximum throughput or bandwidth that your IO system allows (The IO is always the bottleneck). The notes below will help you get the most of a limited bandwidth system. SCADA systems generally do not use enormous amounts of IO, the Following is more for extreme cases with either a Slower PLC system OR a narrow band channel, like a radio telemetry system.
The first step to optimizing your system is to measure this maximum IO bandwidth, then make changes bearing in mind what can realistically be achieved.
How Not to setup Your Pollrecords
The worst way to setup the pollrecords is to add a new pollrecord for each Tag in the database, resulting in 50+ pollrecords each attempting to poll at 1.0 Seconds.
How to Measure Driver performance
Create a minimal configuration with 1 Pollrecord and 1 variable & a polltime of 0.0 Seconds
Open the Mission control & note how many pollrecords per sec you get
Still in Mission Control press the "period" button & change the default of 5 to 1. Check if speed improves. If it does improve add the following option on the commandline of ioctrl.exe in the SCU|Startup settings. "/SxxxP1" where xxx is the driver acronym.
Repeat Step 2 but this time set the pollrec length to a longer value (choose a typical length)
After measuring the speed, you can calculate the update time of your full configuration. e.g. If you get 10 pps (Pollrecords per second), you can have
1 pollrecord updating 10 times a second or
10 pollrecords updating at 1.0 seconds
5 pollrecords updating at 1.0 seconds + 10 pollrecords updating at 2 seconds
If you configure more pollrecords , no errors will occur but you are not actually achieving your configuration update time. In this case the driver just processes each pollrecord in turn. This is not a problem most of the time but as you add more pollrecords your system will slow down & If you need faster update on a specific pollrecord, changing its polltime will achieve nothing.
Optimization techniques
To make a limited bandwidth system appear faster, you have to slow down the updating of less time critical data to give more bandwidth to the critical data. (increasing the pollrate of a pollrecord when the system is already at full stretch will have no effect) The basic principle is - poll only the data that the operator needs for a given picture & at the minimum rate he is prepared to accept. It is usually better to set slow polltimes at the start of a project which leaves plenty of room to expand, this sets a lower expectation and if you need more speed later you have spare bandwidth resources.
Setpoints, Outputs, controls or any value that never changes in the PLC(only changes when modified from SCADA) can be setup so that they hardly use any channel bandwidth at all. Set the polltime to a large value like 60 seconds. If a value is written the driver automatically forces the pollrecord to update.
Prioritize your data, find out how fast the data changes in the PLC. Do not poll faster than necessary especially while you are constructing your system. You can always speed up certain pollrecords later once your system is fully configured. Generally analog values can be polled slower e.g. 5 sec but Digital Inputs may need 1 sec.
With most drivers it is more efficient to poll large blocks of data even if some of the data is not being used. If a chunk of data is Setpoints then rather break it up into 2 pollrecords polling the Setpoints at a slower rate.
How to design Your PLC memory map for optimum SCADA driver performance
Try to make large contiguous blocks of data with the same data type (analogs with analogs etc.). These blocks will of course become the pollrecords you configure in the driver.
Separate "Setpoints & Outputs & Controls" from Process Input data & separate data that does not need to update at the same rate. All these may be polled at different rates.
Leave lots of spare space for later additions
Optimizations When Writing data down to the PLC for Continuous Control applications
On most systems writing data down to the PLC occurs so rarely that there is no effect on performance. The only setups where writing occurs continuously are where you need to perform continuous control e.g. a PID loop in the SCADA driving an output in the PLC. Another more common requirement may be to write a value coming from another IO driver e.g. from one PLC to another. In all cases AVOID continuously writing the same value, unnecessarily. Only write changes of state. This normally dramatically reduces the writing overhead.
If you chain an AO/DO block to an AI/DI, writes will occur at the Scan rate of the AI/DI Block optimise as follows.
Reduce the AI/DI scantime OR
setup the AI/DI to be exception based
write a program block that compares the value to be written with input feedback from the PLC then write if the two differ by a specified deadband.
Read performance will inevitably suffer when continuously sending updates to the IO device. All drivers write data only when the operator changes something OR whenever an AO/DO block is scanned. On Most drivers Reading & writing have equal priority, so READ speed will suffer if you have a lot of writes.
©Copyright 2004 ProScada CC. All Rights Reserved