1) Introduction
The Local Alias is an Elipse E3 feature which helps migrate objects from a local application to a Remote Domain, that is, you can set up all the local application’s server objects, such as Historics, Alarm Server, Alarm Config, Drivers, and Tags, with this tool. This happens because the Local Alias helps the local application to be set up in a way that its scripts and links comply with the syntax required for working properly when placed in a Remote Domain.
This article focuses on migrating screens from a Remote Domain’s server application to a client application.
2) Understanding the need for a Local Alias
Currently, Elipse E3 features the Remote Domains feature, whose settings establishes that there will be communication between different Domain Server, where on application can share information with another. The Domain supplying data is called Server Domain (local application); the Domain using this data, on the other hand, is called Client Domain (remote application). The Remote Domains allow a local application’s server objects to be accessed by a remote application. However, this feature doesn’t grant access to the local application’s screens directly via Remote Domain.
Then, how can I put these local application’s screens at the remote application’s Domain?
To be able to access the local application’s screens via remote application, you must add the local application’s .PRJ file that contains the desired screens to the Remote Domain. If the application’s drivers are in the same .PRJ file as the screens, you must make sure the drivers responsible for communication are eliminated, since the station running the Remote Domain may not be able to access the PLC. Therefore, we recommend creating a .PRJ file that is only for I/O drivers, and then you can add to the Remote Domain only the .PRJ file containing the local application’s screens.
Example: Local Application with a LocalAliasProject.prj file (containing the screens) and a DriverProject.prj file (containing the I/O drivers) incorporated to the local application’s Domain:
Figure 1: Local Application’s projects
Example: Remote Application with only LocalAliasProject.prj project (which contains the local screen’s application) incorporated to the Remote Domain:
Figure 2: Remote project
However, the links of the local application’s .PRJ file’s screen objects (SetPoints, Displays, etc.), which was added to the Remote Domain, is still pointing to I/O tags, alarm server, historics, and other server objects of the local application, and since some of these data objects no longer exist in the Remote Domain, a series of errors keeping the application from working properly will take place.
Figure 3: Error in the Remote Domain’s links
So, how can I make sure the remote application will work properly with the local application’s screens added to the remote application?
The best solution is to use Elipse E3’s Local Alias tool to set up the local application. This happens because this resource allows creating a Remote Domain in the local application that points to itself, that is, that points to the same Domain and to the machine where the local application is. When setting up the local application, you must link all screen objects and make all scripts access the tags passing through the added Remote Domain. Thus, when you add the local application’s screens to the remote application, all screen objects’ links point to the local application’s tags and data objects via Remote Domain, which in turn helps avoid errors and guarantees the system will work correctly.
Figure 4 shows LocalAliasProject.prj, added to the client Remote Domain, linked to a SetPoint pointing to the same Tag1 from Figure 3, but now via Local Alias:
Figure 4: Project in the client Remote Domain
3) Working with a Local Alias
To set up the local application via Local Alias, follow these procedures:
1. Create a new Domain, which will be the system’s local application. For this article, we created an application called LocalAliasProject, at D:\E3\LocalAliasProject.
2. Access the application’s domain options created in the previous step by right-clicking the E3Admin icon on Windows Taskbar:
Figure 5: E3Admin’s contextual menu
3. Access Remote Domains tab:
Figure 6: Remote Domains settings tab
4. Add a new Domain (in the figure below, it’s called Local_Domain):
Figure 7: Adding a new Remote Domain
5. Point to the local Domain file, which in this example is D:\E3\LocalAliasProject\ LocalAliasProject.dom:
Figure 8: Local Domain file’s specification
6. Write the name of the machine containing the local Domain file. In this article, the name of the machine on the networkd is Delio (don’t use the IP address):
Figure 9: Network machine’s specification
With these steps, the local Domain was set up via Local Alias. Therefore, when the local application’s screen objects are linked and their scripts are written, you will always use the local server’s objects via Remote Domain. This can be done via AppBrowser, as seen below:
Figure 10: Access to the local Domain via AppBrowser
Q: Can a local application’s alarm be acknowledged via a command fired by the remote domain?
A: Yes, this is possible, and can be done via a script similar to the one below, which can be done in a screen object’s or a remote server’s event:
Application.GetObject(“Local_Domain:AlarmServer1”).AckAllAlarms()
This script was written via the local application’s Alarm Server’s AckAllAlarms method, located via Remote Domain by the AppBrowser:
Figure 11: Local Alarm Server’s AckAllAlarms method
This is only one of the methods. You can also use specific areas’ acknowledgment via the Alarm Server’s AckArea method or via individual alarms’ acknowledgement directly in the alarm source.
After Elipse E3 v. 3.1, the local application’s alarms can also be acknowledged via E3Alarm on a client Remote Domain’s screen. This happens because E3Alarm can track down the server application’s Alarm Server:
Figure 12: Alarm Server’s settings
4) Final remarks
The goal of the Local Alias features is to make sure the application that will work as a Remote Domain’s server will be set up to migrate a .PRJ file (containing screens) as fast, easy, and reliable as possible to the remote application. This feature must always be implemented when starting the application, and all the steps illustrated in this article must be followed.
