Using Elipse SCADA’s 32-bit version
With Elipse SCADA’s 32-bit version, each I/O driver can work separately, which will enhance the application’s performance greatly. This can be noticed especially when working with slow modems or I/O drivers (1200, 9600, or 19200 bps, for example). To put I/O drivers in background, click Advanced button on the driver’s settings page (inside Organizer), uncheck Keep behavior 16-bits option, and decide whether the driver will write in background. Please notice that some I/O drivers cannot be put in background.
Using tag blocks
Creating as many block tags as possible instead of PLC tags is highly encouraged. Block tags are sets of PLC tags that transfer more information (tags) in less time. They are used especially to monitor alarms and tags recorded in historics (which are always communicating) or screens loaded with data, thus streamlining the communication process. Block tags are usually memory (or input/output) sequences where the block’s initial and final addresses are indicated. Unused block elements can be deleted in the Organizer. Use Cross-Reference page to check which elements had been used.
Scan time
The application’s scan time for block and PLC tags require careful planning. For each block or PLC tag in the system, ask yourself, “What is the ideal update time for this tag?”. This question will usually lead to other questions, such as “What is the system’s/PLC’s update time?”, or “Does this variable really need to be updated every 1 second? Could it be updated every 5 seconds instead without compromising the system?”. The answer to these questions will lead high-priority variables to be read more frequently than the others, which will make Elipse SCADA work smoothly. Another point worth making is that write-only variables do not need to have their Enable scan reading or Enable automatic reading options checked, thus keeping them from being read unnecessarily.
Communication speed
Communication speed must be set up, whenever possible, for the maximum value allowed by the device, thus enhancing the performance in the system being monitored. If several communication errors are found (occasional errors can be suppressed with 1 or 2 communication retries), you must first try to set up the communication time-out (usually between 20 and 50 ms) and, if necessary, decrease speed gradually until the ideal condition is reached. Distances and installation conditions are decisive factors for data communication between the computer and the data acquisition device.
Tags’ “advise”
Elipse SCADA does not communicate periodically with all tags in the system at the same time; this would mean chaos in terms of performance. Its communication is managed and prioritized then on what we call the “advise” mode. If a certain tag is said to be on “advise” (tag property), it means it is ready to be periodically updated by Elipse SCADA, and to have its value informed to the objects linked to it. For example, when a screen is activated, Elipse SCADA shows all objects on this screen and starts the “advise” mode of all the tags linked to those objects. In other words, each tag referenced on that screen will be read automatically, in the frequency informed in the tag’s scan. Other objects that can force the tags’ “advise” mode are activated historics and alarms enabled for the object. This is how Elipse SCADA manages tags communication, thus avoiding communication with unnecessary variables under certain circumstances.
OnCommError script
Whenever a communication error occurs, Elipse SCADA will automatically call an OnCommError script to perform specific, user-defined tasks. A communication error will only be generated after the number of retries set up in the driver’s communication parameters is reached. Examples of this script’s user-defined tasks can be deactivating the driver, or deactivating reading/writing the tag that caused the communication error, in case a certain device in the system breaks down. To do so, you must filter the desired tags via the I/O driver’s AddFilter() function.
Windowed screens
Please notice that windowed screens have a distinct behavior: tags belonging to an open screen in the system have their communication activated according to the scan defined for each tag, so whenever windowed screens overlap, more communication “windows” are opened, and communication with the active variables on the hidden screens is still sustained. This will needlessly degrade the whole system’s performance, not only regarding communication, but also because of the amount of memory required in this situation. To fix this, you must close the overlapping windows (Hide function) with the same command that opens the other windows. Another option is using full screens instead of windowed screens, because these are deactivated automatically whenever a new full screen is open.
Active screens
The initial screens of an application are all of those whose Visible property is on. Therefore, they are all going to be loaded alongside the application, thus slowing down this process, and using up unnecessary resources. Also, those screens will overlap, which clutters the system’s appearance. That is why it is recommended that you activate only the screen to be displayed at the beginning of the application while keeping all other screens closed. The same must be done when setting the application, because once an application is saved and closed, all screens that were open at that moment will open again the next time the application is opened by the configurator. Then, close all windows (or keep only one open) before saving your application. Following these procedures, loading your application will surely be easier the next time.
WhileRunning scripts
These scripts run constantly whenever the application is executed or a screen is opened, and they usually spend more processing time than other scripts. With ScriptWindow() function, you can check, at runtime, how long will each script take to be executed. The better this time is estimated, the better the system’s performance is.
Compile Script, Build Scripts, and Rebuild All Scripts buttons
Before executing an application in Elipse SCADA, you must check it for scripts errors. This task is really important, since scripts with syntax errors will not be executed. To check them easily, use Compile Script, Build Scripts, and Rebuild All Scripts buttons, located on the lower half of the Organizer. Compile Script button checks for errors in the script being currently edited; however, you must notice that this button does not check for errors in the other scripts in the application. Build Scripts button verifies only unchecked scripts. Rebuild All Scripts button checks all scripts in the application, whether they have been already edited or not. Though the operation generated by Rebuild All Scripts button takes considerably more time than the one generated by Build Scripts button, especially in larger applications, this extra time is very useful for preventing errors in script execution.
Historics
The recording time for Historics must be set up according to the application’s real needs, and taking the tags’ scan time into consideration: it is no use recording the Historic every 1 second if tags’ scan is every 5 seconds. Since the Historic accesses the disk, you must avoid smaller scan times whenever possible. An option in such cases is having event-activated Historics, that is, Historics that are activated whenever WriteRecord() function is activated in a script, which avoid scan times (you must uncheck Use the Write Time to Save Records option).
Please remember that all tags belonging to an active Historic update constantly, communicating at every scan period.
Animation
Animation objects, such as large, colorful (high or true color) bitmaps, slow down system execution. Animation bitmaps must be developed with the exact size they will be used and with as few colors as possible for better performance.
