Introducing GRX

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:-

• Shared Database. This holds the data common to all parts of an application.
  
• Comms Handlers. Handlers provide the interface to PLCs and instruments.
  
• Alarms Subsystem. This provides the recording and display of alarm events.
  
• GRX Projects. Each application will consist of one or more GRX project. GRX provides the bulk of the processing and user interface functions.
  

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:-

• Shared Variables. These can be read and written to be all parts of an application.
  
• Local Variables. These can only be read and written by a single GRX project.
  

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.

GRX

A GRX project is divided into two parts:-

• Graphics. This is split up into a number of drawings. Each can display animated graphics, text and data. A typical project might use one drawing as menu, with buttons choosing other displays.
  
• Evaluation Code. The code section can be used for any purpose. Code will be inserted into a project automatically when specific animation effects are chosen, but the main pupose of the code is to provide all the processing required by an application.
  

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.

Programming

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'.

Project Skeletons

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:-

• Login/Logout support
  
• (Live) Trend graph displays and data logging.
  
• Replay graphs (from logged data).
  
• Data conditioning.
  
• Recipe handling.
  

When an application is created from a skeleton, all the code and graphics are copied and you can modify it as required.

Libraries

Three basic library groups are available:-

• Image Libraries. A large number of bitmaps are supplied for use in applications. Any bitmap you create can also be stored for later use in other projects.
  
• Function Libraries. These libraries hold all the function blocks used when programming.
  
• Drawing Libraries. A drawing library contains both the graphics and the code required for a specific function. For example, a toolbar button would include the basic graphics for the button plus the code required to light up the button as the cursor moves over it and to generate a click event.
  

Note that the graphics and code inserted from a drawing library become part of the application, and can be changed as and if required.

Wizards

No matter how comprehesive the development system, some tasks can be tedious. Wizards provide some help in performing repetative tasks:-

• Variable Creation Wizard. A real boon when there are a lot of similar items to be named. If we have a number of pumps each with running and fault inputs, all we need to do is create the first group, calling it something like Pump[1].Running and Pump[1].Fault and the wizard can 'clone' these variables any number of times.
  
• Variable Edit Wizard. A mis-spelt name is always confusing. This wizard will change a variable name throughout an application. Even better, it can unscramble the (all too common) problem of two different variables being used for the same thing.
  The project skeletons use conventional names for various items of data, assuming that the wizard will be used to change the names to something meaningful within the application.
  
• Project Copy Wizard. Good for the repeat order with a few changes or to make a copy before making modifications.
  
• PSD/PSB Import Wizard. Allows you to import a drawing file or evaluation code from another project. The neat bit is that it gives a list of variables used by the file and you can then decide what variables should actaully be used.
  
• Local to Shared Variable Wizard. When programming an application it can be quite difficult to work out what should be local and what shared. The simple answer is to make everything local to start with, and then 'promote' what is actually required. The whole trick can be done with a text editor, but is a lot easier to let the wizard do it.