Deploying a Lookout Application

There are two distinct cases where you may need to move a Lookout application from one computer to another. In the first case, you would move the application from the computer where you developed it to another computer that will host the final application. The second case of deployment arises when your server computer does not change, but you want to add a client computer to your system. This document outlines some general architectural details relevant to either of these scenarios and discusses the special requirements of each case.

Background: the importance of the application architecture in the deployment process

We cannot over-emphasize the importance of separating the server and client processes in your Lookout application. You can write a simple application that performs both server and client functions in a single process; while this is a workable solution, it severely limits your options of networked connectivity. You are either limited to using NetDDE for networked connectivity for a process like this, or you will have to write your networked client application separately. In contrast, a well-designed Lookout application that has server and client functions separated out in distinct processes will require little additional work for deployment to multiple client computers.

When an application is architected as shown in the following figure, you do not need to do any additional Lookout application programming to deploy a client to a target computer. You can also test the client process on the same computer as the server without any client computers.



In the figure, the physical device (such as a PLC) is connected to the server computer. This mode of connection will depend on the device: it could be serial RS 232 or RS 485, Ethernet, or any other specialized bus (such as Profibus).

You would typically have an object in the server that communicates with the device. In this example, the name for this object in the server application is DriverObject. The server process name is ServerProcess and it resides in a computer called Mach1. You are interested in the various data members in this object.

Instead of using the data members exclusively in the server process (thereby making it difficult to set up multiple clients), use a separate client process. In this example, the separate client process is called ClientProcess, and it also resides on Mach1. To make the connection to the server process, create a symbolic link on ClientProcess. In this example, the symbolic link is called ServerLink, and it is set up for a static URL,\\Mach1\ServerProcess. You use data members from the DriverObject in the client process by referring to [ServerLink]\DriverObject.Datamember. Notice that this gives the complete path to the data member in question to the Server process. Also, this gives an absolute path that should work from any computer in the network. This feature makes it possible to take your client process to any other computer on the network, and it should work without any modifications.

It is possible to use the Driver object data members in the server process itself. You should use them for calculation, control, and interlocks in the server process. You should try to avoid creating a user interface in the server process. A good rule of thumb to keep in mind is to have only a troubleshooting panel, if necessary, in the server process and no user interface panels. You should also use the server process to exchange information from multiple user interfaces. For instance, you may have a Pot that is used to select a setpoint on your PLC. It is a good idea to create a Pot in your server process (that is remoted to your PLC data member); this Pot on the server process does not need to be displayed. You can then remote your user interface Pot (in the client process) to the Pot in the server process through the symbolic link.

Using a symbolic link also has other benefits -- if you are planning to change your server computer, you will have to change the reference one time in the symbolic link and not in every single place that you refer to the Driver object data member from your client process.

Another strength of the symbolic link is the ability to use a dynamic string as the URL. You can change the value of the path contained in the symbolic link, thereby “switching” your server. For example, if you have a server process and a simulator process, you can use the dynamic expression for your symbolic link to be something like TIF(SWSelectServer, “\\Mach1\ServerProcess\DriverObject.”, “\\Mach2\SimulationProcess\SimulatorObject.”). Here SWSelectServer is a switch in your client process. You can refer to a value through the symbolic link by using a reference link [ServerLink]PValue. Assuming that both the DriverObject and the SimulatorObject have a data member called Pvalue (or an alias for a native data member with that name), you will be able to switch where your data is being sourced by the flip of a switch.

While the above was not intended to be a complete explanation of the symbolic link object, it illustrates the importance of using the correct Lookout application architecture for easy deployment of applications on the field.

Deploying the Lookout server process in the field

The primary function of a server process is to communicate with the hardware and to implement user interface interlocks that are common between all the user interfaces (clients). If you have a server that works fine on your development computer, and you want to transfer the server process to the target computer, here are some things you want to keep in mind:

Lookout Process Files
There are four basic Lookout process files: the .L4P, .L4T, .LKA, and .LST. You have to copy all four files to the target computer -- they should typically go in the same directory.
Note: When you create a process, you have the option of choosing where your state file (.LST) goes. Remember to put the state file in the same relative location.



Security
If you are using security features in your server, you need to copy your Lookout.sec file out of the system folder (typically \Windows\System in Win9x and \Winnt\System32 in NT) to the same place on your target computer. This file should also be copied over to all client computers. Most of the process-specific security information is contained in the .LKA file and should be copied with your process file (see above in the Basic Lookout Process Files section).

.INI Files
You may have one or more .INI files in your development computer. This includes your lookout.ini file as well as any object-related .INI file that you may have used (for example, Modbus.ini, allbrad.ini, and so on)
Note: If you have used the serial diagnostic file feature, make sure to turn it off by removing the appropriate line from the .INI file; otherwise, you will continue creating a text diagnostic file with all serial traffic on your target computer.

While you can duplicate important elements of system configuration by copying the Lookout.ini file, you should first delete the keycode section from the copy before opening Lookout on the new computer. National Instruments recommends that you register each copy of Lookout individually through the System Options dialog box.

Custom graphics files
Ideally, since your server process does not have any advanced user interface, you will likely not have any custom graphics in your server process. However, if you do have any custom graphics in your process, you will need to move them to the target computer as well, in the same relative position under your Lookout\Graphics directory. It helps to collect all your custom graphics under a folder that you create in the Graphics directory in your development computer (say Lookout\Graphics\custom). You can then take this one folder with all the graphics with you to the target computer.

Other Files
Other files that you can use include Excel files for your recipe and datatable objects and database files that you use with SQL in Lookout.

Adding Lookout clients to the system

You will often put a Lookout client process in a Lookout client package. The client package of Lookout does not allow editing and does not have any driver objects. Make sure that your client process works properly before trying to deploy it on a client package of Lookout.

A client process that is properly designed (see the discussion earlier on the application architecture) will not need any special programming to be transferred on a networked client computer. The same considerations for special files still apply (see the section above for information on the process, security, .INI, and graphics files)

Special considerations for deploying a Web client

A Lookout Web client is a special case of a Lookout client that exposes a process you specify to a Web browser through an HTML server. The typical process involves defining the Web export options -- like the directory where you want to export a process, and the URL that specifies how the process file is accessed via the HTML server. Once you export the process, it exports your process files as well as the supporting Lookout files (including the relevant .CBX files). It does not export .INI files. Most .INI files (other than perhaps lookout.ini) deal with driver objects. Typically a Web client will not be directly connected to a PLC, so the problem with not having the .INI file settings with your Web client is less acute than you would imagine. Another related issue is that the user connecting through a Web client has a security level of 0.

There are some other things that you should keep in mind while designing a client process that you know will be used on a Web client. It is typically a good idea to activate or maximize the home panel on startup (using a connection similar to HomePanel.activate = true). This is a good practice in general, however, it becomes more important on a Web client, because depending on the activeX control size that you specify while exporting the Lookout process and the resolution of the display on the Web client computer, the minimized panel may actually show up below the visible window in the Web browser. Of course, it is possible to scroll down and click on the panel icon to bring it up, but this may cause some confusion to the occasional user.

If you plan to use keyboard function keys in your Lookout application, you may want to remember that your Web browser may use some function keys for its own use. For instance, your browser may use F1 (or <shift>/<ctrl> F1) to bring up the help window. So, if you use F1 in your Lookout application to acknowledge an alarm (for instance), the effect of pressing F1 from a Web client may have a different effect than what you anticipate.

Alarm display is also somewhat different for a Web client. In a regular Lookout package (development, runtime, or client), the alarm window belongs to that instance of Lookout and you can choose what processes are monitored for alarms by the alarm window. If you have a Lookout server that communicates with your hardware, you will generate communication alarms from this server. You can view these communication alarms on the alarm window of a Lookout package. However, on a Web client, since you are looking at just one process, the alarm window will limit itself to all the alarms in that process. If you have exposed your client process from the Web server (which will normally not have communication alarms), then the Web client will not be able to view the communication alarms either. However, using the $Alarm object, you can build your own alarm display and handling scheme into your client process so that on the Web client you can have visibility and acknowledgement control for any alarms that you choose to handle this way.

Here are the basic steps for Web enabling your process. Assume that your HTML server (we used the Apache Web server for this example- any other should work as well; for more information on the use of the Apache Web server, see www.apache.org) uses the following path for its root: c:\program files\apache group\apache\htdocs\. Create a subdirectory under this root to put all Lookout Web client related files. Create a directory called “Lookout Web client” under htdocs. Set the Export Directory field in the Web Server Export Options to c:\program files\apache group\apache\htdocs\lookout Web client\. Set the Server URL field to http://<your computer name>/lookout Web client/.

Once you export your process, you should see an HTML file in c:\program files\apache group\apache\htdocs\lookout Web client\ (typically of the form <your process name>.htm). Start your HTML server and you can access your Lookout process from a browser using the URL:
http://<your computer name>/lookout Web client/<your process name>.htm.

For more information on this topic, refer to your Lookout online help.

Using third-party servers, hardware or drivers on the target computer

Follow the manufacturer’s recommendations on installing any third-party servers or drivers, or any interface hardware on the target computer. It is also usually a good idea to make sure that you have some diagnostic tools that came with your hardware available for use on your target computer to troubleshoot possible installation or communication problems.

Troubleshooting

My server process (that worked fine on my development computer) gives me alarms on my target computer.
This could be due to missing files, or a problem with the interface hardware, if any. Check the online documentation for recommendations on driver object alarms.

My client process does not open on my client package.
Make sure that your client process does not include any driver objects. The client package does not include any driver objects. Also make sure all your graphics files are available at the right location.

My client is not able to get data from my server process.
Try to run the client process on the same computer as the server process. If it still does not work, then you will need to debug your connections from the client process. Remember to use the correct server computer name in the client. If the client process runs as expected on the same computer as the server process, make sure that the server and client computers are properly registered. Refer to the online help for information on how to register a computer in the network.

Reader Comments | Submit a comment »