GRX is a SCADA system for Windows. It is split into a development system and a runtime system.
The system is designed for rapid development. The example project used in the Complete Project Tutorial took under 3 (three) hours to program and test. The project itself is non-trivial, as it includes monitoring and control plus data logging.
There are four major components of a GRX system:-
The real-world interface may be via one (or more) of the comms handlers or may use OPC, ASI, third-party I/O cards, or the built-in RS232 functions of GRX.
Developing an application is through an IDE (Integrated Development Enviromnent) that provides a shell to access each configuration tool required, and a number of wizards to speed up development.
Tags and Variables
Some SCADA systems use the term tag to indicate data that comes from a PLC or instrument, sometimes introducing local tags to hold intermediate results of calculations.
To avoid confusion, a GRX application has only two sorts of data:-
A simplistic approach would be to make all variables shared, but even in very simple projects this rapidly becomes unwieldy. There is also a technical restriction that requires some variables to be local (e.g. cursor tracking variables).
Local variables mean that multiple GRX projects become easier to manage. Muliple GRX projects are used to provide complex facilites such as trend graphs.
A Shared Variable would be used for data read from a PLC. Suppose that a flow rate is read from an instrument. A shared variable (PumpFlowRate say) would be created and the comms handler configured to read the data required. The rest of the application would then use the PumpFlowRate variable without knowing where the data came from. Suppose that commisioning showed that the flow rate needed to be scaled. A second shared variable could be introduced (RawPumpFlowRate) and the data read into this. A small section of code can then scale that data, putting the result into PumpFlowRate. Nothing else in the application need be changed.
A GRX project is divided into two parts:-
GRX does not impose any specific structure or user interface. The developer can choose to implement any user interface. To make life easier however, project skeletons are available.
GRX does not use a classic or script-based system of programming - a graphical system is used instead.
The basic strategy is to join up function blocks, variables and constants to provide the program. The function blocks range from a trivial function such as add, all the way up to the complex blocks required to implement a multi-segment profile generator.
Most of the function blocks are defined in terms of other function blocks. For example, a function block that scales a value would be defined as a multiply block connected to an add block. By using the same editor to create function blocks, custom libraries can be created.
Many thousands of blocks are available and a comprehensive index and associated technical notes make finding a specific block simple. The same editor that is used to create and maintain function block libraries can also be used to create a 'favorites library'.
The project skeletons can be regarded as just a starting point for a project, but the complete project tutorial shows how the skeleton can become nearly the whole project.
Typically, a skeleton project will provide a number of blank displays and a toolbar menu. Seperate GRX projects are used to provide:-
When an application is created from a skeleton, all the code and graphics are copied and you can modify it as required.
Three basic library groups are available:-
Note that the graphics and code inserted from a drawing library become part of the application, and can be changed as and if required.
No matter how comprehesive the development system, some tasks can be tedious. Wizards provide some help in performing repetative tasks:-