Developing libraries in Elipse E3.

1) INTRODUCTION

Using libraries in Elipse E3 is highly recommendable, because they can represent more productivity for your application. Some advantages of using ElipseX are:

• Reusing code.
• Less tests during development.
• Default interface for developed objects.
• Less time required for developing new projects.
• Protection for project’s contents.

2) WHEN TO CREATE AN OBJECTS’ LIBRARY

Libraries are recommended for most applications. However, some criteria indicate when new objects need to be created:

• Use repetition: when a certain device or process is used more than once in the same project.
• Restricted knowledge procedures: usually, a process created by a certain company must be protected against being unproperly  copied or edited. This is a common practice among service integrators or hardware manufacturers.
• Controllers: a process controller, whose memory mapping is fixed, can be implemented with all available functionalities. Creating and using objects in Elipse E3 is made flexible to allow for further use of only the needed variables, while the others can be ignored.

3) CASE STUDY

To illustrate the use of libraries in Elipse E3, we will create an engine’s control, whose data is:

• One tag for the operation’s temperature.
• One emergency tag, for blocking the engine.
• One command tag to turn the engine on/off.

Both the command and the engine status should be shown via displays and color changes. In addition, the tags to be used for the engine’s command must be external to the library.

Creating the Project

First, you must create a default application via Elipse E3’s Application Wizard. When asked about drivers, storage, and alarms, answer “no” in all cases.

Creating an XObject

Next, create a new component libraries called Engines, and insert a new XObject called LibDataEngine into this library. The XObject is a data object and has no interface, which means it can’t create a message box for events, for example. To establish an interface with the user, you will need to create an XControl.

Insert a data server into LibDataEngine, and rename it to Data. Inside this folder, insert a Demo tag and edit the following items:

• Name: EngineTemperature
• Type: 0 – Random
• Maximum: 100
• Period: 1000
• Scan: 1000

This tag returns the engine’s operation temperature.

Next, create the following properties, which will be used to command and return the engine’s status by double-clicking the XObject:

• OnOff (Boolean)
• Status (InternalTag)
• Temperature (Integer)
• Emergency (InternalTag)

These properties will be used to edit the engine’s behavior when the project is being executed.

At EngineTemperature tag, create a linke between Value property and LibDataEngine.Temperature.

Whenever any XObject’s internal value must be available for external access, you will need to create a link between that data and its property. To do so, the link’s structure should be analogous to XObjectName.Property.

Then, set up the following restriction: OnOff property must be used to command when the engine should be on or off. However, the engine can only be turned on if the value of Emergency property is “1”. Otherwise, the engine can’t be turned on.

To implement this restriction, right-click OnOff property and access the other properties. At OnPropertyChanged event, write the script below:

Save the object and register the library via right click. To illustrate how to use the library without an XControl, we will work on a project previously created, accessing the properties via buttons and scripts. Then, we will create a control object for the engine being developed.

Using the XObject in the project

First, insert a folder called Engine1 inside the Data folder created in the default application. Inside this folder, create two internal tags called EngineEmergency1 and EngineStatus1.

Then, insert a LibDataEngine object into the project. Link Emergency property to EngineEmergency1 tag, and Status property to EngineStatus1 tag.

On the InitialScreen created in this project, add displays and a command button as seem below.

For Temperature and Status properties, use displays; for Emergency, use a setpoint.

The display used for Status property must be linked to LibDataEngine1.Status.Value expression (this expression will appear in red when displayed on the connections tabs). The OnOff command button must have an Invert Value script pointing to OnOff property, and whose values are False and True.

The two lower displays which indicate if the script is working are auxiliary ones. Therefore, the first display should point to Data.LibDataEngine1.OnOff expression, and the second one to Data.Engine1. EngineStatus1.Value. These displays don’t exist in the definitive control object.

To check the functionality of LibDataEngine object, run the project, switch the Emergency variable between 0 and 1, and try turning the engine on or off.

Creating an XControl

An item from Symbol Factory library (in Engines folder) will work as the interface of the engine being developed: it’s 3DISAMotor1, the first figure in the library. This allows the example described here to be developed even if the E3Studio is on Demo mode.

To implement links and actions, create the object’s structure. To set up this XControl’s Engine property as LibDataEngine, write this type’s whole name, or then right-click to browse the available types. Setting up the proper type is very important, because you will need to use all properties set up for LibDataEngine object, such as Emergency property, for example.

For the 3DISAMotor1 engine, the OverrideFillMode property must be set up as 2 – SolidFill, and the fill color should be green, whose values are 87, 255, 87.

The display’s value must be linked to LibEngine.engine.Temperature expression, where:

• LibEngine: XControl’s name.
• Engine: property indicating the data source to be displayed.
• Temperature: Engine property’s characteristic, which is a LibDataEngine datatype.

Any links or scripts created in an XControl must follow the structure seen above.

The script for On/Off button is this:

The 3DISAMotor1 figure must be linked to its OverrideFillColor property via a table link, and the LibEngine.engine.Emergency*2+LibEngine.engine.Status.Value expression must have the following values:

• Minimum and maximum values = 2 (green)
• Minimum and maximum values = 3 (red)
• Minimum = 0 and maximum values = 1 (yellow/blue blinking)

These are the possible results for the expression linked to OverrideFillColor property. Then, save the library and register it. To view the developed XControl, access the previously created project and, on InitialScreen, insert a LibEngine object, and link the LibDataEngine1 XObject to its Engine property. Run the project and check the result. Notice that the setpoint for Emergency variable must be kept, since the tag is not inside the developed objects.

4) FINAL REMARKS

The use of internal and demo tags helps understand the mechanism for creating objects. However, any type of tags (PLC or OPC, for example) can be used for the same purpose.

There are two ways of retrieving or controlling tags from devices with XObjects: by making the I/O driver and all tags internal to the object, or by creating tags externally and linking each one of them to an XObject’s property. Your choice will depend on how many IODrivers are available and on how the object will be used.

For example, to retrieve data from a temperature controller, you can use an IODriver internally to the XObject, because all tags refer to this controller. For a substation’s breakers, on the other hand, it’s best to create tags externally and then create links for tags in the XObject, because usually the data from a remote unit (PLC for the electric sector) are grouped in the same outlet (Ethernet or serial port, for example) and should be kept separately. The same logic applies to formulas or historics, which should be kept in the database.

As seen in this example, an XObject can work as property for another XObject or even to an XControl.

You should keep your libraries from using resources from the applications, so it won’t need to be altered when using another project. For example, if the library uses a historic, the database can be passed as parameter, that is, the historic can be saved in any database, as long as it is used as parameter in the library.

Other examples of libraries are available in the Demo project that comes alongside Elipse E3’s complete installation.

Attachments:

5254