Follow Us.
Become a Fan! 
The question often comes up among people using ACP Thin Clients - "How do I make the client's transition to a backup server as seamless as possible?" Windows 2000 is the most stable operating system that Microsoft has ever released, but every now and then the underlying hardware or a renegade application can still lockup up the server. This article discusses some of the practices you can implement today that will result in a more reliable system tomorrow.
When we started providing Thin Client management software about 5 years ago we realized right away that the server was the key piece in any centralized system. Lose the server, and because of the centralized nature of the model all of the attached Thin Clients cease to function. Unlike units made for the commercial market, Thin Clients used for factory automation cannot wait for the operator to recognize a server problem and then reboot the device himself. Many industrial displays show a similar status and alarm screen all the time, and if the display simply froze (as it does on most office Thin Clients) the operator may never know that anything is wrong.
To bring to market a system that could continue to function even if the server failed we installed a special intelligence in the Thin Clients themselves. Each ACP Enabled Thin Client watches its Terminal Server looking for signs that the server has stopped responding. If it finds a problem, it automatically moves over to another server from its list of available hosts. Once it finds one that is responsive it will log on and display the new screens - all without any operator intervention.
Once the Thin Client has moved to a backup server, it is important that the user and application not become lost in the process. If the Thin Client were to simply log into the next available server, the new session would be sitting at the Windows 2000 desktop. This could be an abrupt shift for the user who had "drilled down" several screens to watch for a particular manufacturing event.
The first thing that has to be considered is how to start the application. No matter what application software is being used to display the interface screens (Wonderware, Intellution, RS-View, or even Visual Basic or Excel) the system needs to be configured so that when the user logs on with his Windows login it will start the correct application. If the system is using ACP ThinManager, then the interface application can even be identified as the primary application and the Windows desktop will not be displayed at all.
But this doesn't solve the problem of having the new display come up with the right screen. That must be done in software, and there is actually a fairly simple trick that will ensure synchronization between the two HMI applications.
Most machine interface software is designed with a number of screens that are selectable by "clicking" on selected regions of the displays. The most common method of displaying the desired screen is with some type of show screen command. If, however, the mouse our touchscreen click changes a point in a common database instead of loading the screen directly, the synchronization of any number of displays is a snap. Many developers have two variables in an application, one called something like current_screen and one called desired_screen. If the button press simply sets the value of desired_screen to the page number that needs to be shown, then each application looking at those variables can see that current_screen is no longer the same as desired_screen, and it can independently change to the new desired screen. If desired_screen is a global variable and current_screen is local to the application, then each application can make the display change and then update its copy of current_screen.
The idea of a Primary and a Backup server is not best for the industrial market, and we prefer to think of multiple servers as "Server A" and "Server B". A user running 20 Thin Clients will get better performance from the clients if he runs 10 on Server A and 10 on Server B. As the servers are sized for 20 clients each, the performance is outstanding with half that many, and if the clients from Server B have to move over to Server A it can still easily handle the load.
In addition to performance, there is another reason to keep all of the Terminal Servers active - human nature. If all clients are on a single server, changes to the underlying software sometimes will not be made to both servers. It is also possible that someone needing a keyboard, mouse, monitor or memory ("just for a second, I promise") will take it from the backup server. Either of these or countless other scenarios result in the backup server not being ready to run, and when needed it cannot host the Thin Clients. Keeping it always running eliminates this problem.
For more information on ACP Industrial Thin Client computers, please visit our web site at http://www.thinmanager.com
To sign up for the E-mail newsletter go here: ACP newsletter signup
For an archive of past newsletter articles go to: ACP Newsletter Archive
Copyright © Automation Control Products, Inc. All rights reserved.
