Is thin-client the answer?

In this installment of The Answer to Your Problems, CONTROL DESIGN readers weigh in on whether to take a thin-client approach as an alternative to other workstations in a harsh manufacturing environment.


e'll be responding soon to an RFQ to Supply updated operator terminals and control stations for a train of industrial machines. The customer wants the ability to present multiple applications and multiple-machine monitoring simultaneously and provide on-site monitoring and diagnostics that includes interactive maintenance files and even video and audio. We think we should pursue a thin-client approach. Any advice?

-- From the August issue of CONTROL DESIGN magazine. 

Thin Is PHAT
Two-and-a-half years ago I introduced thin clients to all non-NC machine tools in our metal forming shop as part of a move away from paper. The thin clients have performed exceptionally well, with only one failure over the past 30 months. Thin client has allowed us to eliminate the scrap previously produced by manufacturing based on obsolete drawings, by delivering the current electronic drawing files to each machine station instantly.

Training is a virtual non-issue. Each station was given a generic username and a null password. The operator simply turned on his monitor at the beginning of his shift. The stations were given read-only network permission, and ran a free CAD drawing viewer on a Windows platform installed on the network server. The only icons available were a file manager, an Internet browser, Acrobat Reader, a proprietary shear list program, and the CAD viewer.

Part numbers were already filed under an intuitive alpha-numeric file structure by the engineering staff. File extensions were set-up to default to the appropriate programs, so the operators only had to find the part file in the file manager and double click its icon.

Shear operators view the cut list on the proprietary program and then shear and label the required flat blanks. CNC punches automatically load the part program by part number; non-NC punch operators view the flat-pattern engineering drawing and proceed the same as they did when paper records were used. Forming operators also open and view the engineering drawings to find back-gauge settings and forming instructions. Photos and additional instructions are included in each part folder as required, so additional assistance is available by simply double-clicking on the appropriate icon. The internet browser is used to view photos, and the Acrobat reader opens .PDF files containing additional instructions.

Network cabling was already present in the machine area to run the CNC punch presses and the supervisor's workstation; individual terminals were simply spliced in. Metal boxes were fabricated in-house to protect the thin client [workstations], support the monitors (inexpensive CRTs), and provide a surface to use the mouse. The set-up was handled completely by our in-house IT department, and is no more complicated than setting up a workstation that runs network copies of any other software.

I would highly recommend the thin client [approach] as a robust and inexpensive alternative to other workstations in a harsh manufacturing environment.

Jim Reil, PE, NSPE, Business Development Engineer, H&K Dallas Inc.

Ask These Questions
The application of thin clients requires further consideration in this situation. There are many details that need to be clarified before a good decision can be made. Some key questions to answer include:
• How many terminals would be installed at launch and are their possible future expansion plans?
• What software is going to be used and does it support terminal services efficiently?
• Will machine displays include significant animations? 

All of these questions will help figure what the overall network load might be. If the terminals are to provide both extensive viewing/observing features and control features, the priority of the control features must be carefully considered.

You wouldn't want Machine X crashing because an operator somewhere was viewing some graphics-intensive application. Maybe a solution could involve two separate thin client networks. I would hesitate to send too much video or audio across a thin client network that has control responsibility. Not only will this tax the server, it will load down the network. I've seen some literature on efficient transfer of video to thin clients, but I haven't had a reason to test this out.

I don't believe that there is anymore training involved with thin clients than a standalone PC network. Your core engineers and IT personnel need to understand what goes on in the background, but in general, most of the environment is transparent to the operator. 

There is a definite need to be very diligent in setting security settings for users that will logon from thin clients. Otherwise, you will end up with plant floor operators deleting files on your precious servers or drawing obscene pictures in Paint. This, though, isn't impossible--in fact, it's fairly easy to restrict your thin-client users to having almost no rights and then open up rights as they are needed. 

Say what you want about Microsoft and their technology. Placing a continued reliance on their software may have its moral issues, but I don't believe it puts your project at any more risk than using any other software or hardware available. Microsoft isn't going anywhere any time soon and there is a good chance that the alternative to thin clients would rely just as heavily on Microsoft in some way, be it application editors or a standalone PC operating system. If the thin client/control network is kept isolated from the office network and the Internet, Microsoft-based security risks should be able to be dealt with before they are concern. Not to mention, I'd rather patch one thin-client server than 100 standalone PCs.

John Edwards, Automation Engineer, Automation Horizons Inc., Des Plaines, Ill.

Be Careful What You Wish For
Thin client architecture probably has some advantages in very large installations that have a significant number of machines running the same control software (but not necessarily the same user program on each machine), and if those machines are already planned to be connected to a central server.  

Some disadvantages or pitfalls that an OEM or end user of industrial machinery should consider when evaluating use of thin client architecture are:

What will be involved in debugging and testing the equipment in the equipment manufacturer's facility? Typically the equipment OEM will need to duplicate at least a part of the end user's supporting server and routing facilities. Who pays for this?

Thin client is a very poor reason to connect your control computers to a network. If there is no other need to expose the control or HMI computers to the extra risk of virus and hacker attacks, which comes with network connection, then I would steer clear of network connection and hence, thin client, in those applications.

Industrial control and HMI software traditionally has not responded well to many OS upgrades. In a thin client system, security protection of the network and patches needed by other remote applications will likely make frequent OS upgrades necessary on the server, which potentially can cause difficulties with the control programs which would not be a factor with isolated stand alone computers.

Further on the issue of upgrades. A standalone PC the control or HMI software it runs, once tested and validated for a particular control application should never need to be upgraded unless other parts of the machine also are undergoing modification.  My company has machinery manufactured years ago and happily running production every day with no down time using 286 PCs and even a few Apple computers. When you go thin client, upgrading of any part of the now interconnected mesh of computers will frequently drag all of the rest of the system along into upgrade land. As a controls engineer concerned with reliability of equipment which can take a life or cause injury if it malfunctions, I do not want to endure the expense and time of revalidating a control system (or worse, skipping that step), just because the IT guys want to buy a faster server.

Kim Ground, Sr. Controls Engineer, Surface Finishing Technologies, Clearwater, Fla.

Standards Make Thin Client Effective
When equipping machines, concurrent operation at different locations often is less important than alternating between different panels at different locations. Ethernet TCP/IP networking, i.e., using cost-effective standard components, is the main advantage of the thin-client solution. Thin client only is an input/output system; the actual application runs on a server. Therefore, the performance requirements for the hardware remain low.

Our panel devices with Windows CE are built to meet the requirements mentioned above, and the use of Compact Flash eliminates the need for a fan or any other rotating parts (e.g., hard disk). While other systems rely on expensive server operating systems for similar solutions, Windows XP Professional does the job as the server operating system for the solution we favor. 

An additional feature includes the ability to connect drives. As mentioned earlier, the actual application runs on the server. An explorer window on the client displays the server and its file structure. If a drive is now operated on the client, it is connected to the server via Ethernet and is available as a local server drive. This provides a simple and easy way of exchanging machine parameters.

John Roberts, Distribution Sales Manager, B&R USA, Roswell, Ga.


Do We Still Need Gear Motors?

We think we have the right idea using gear-head servo motors--the most important advantage being increased torque as the trade-off for less speed. However, it appears that the more conventional servo motors and controls are getting stronger all the time, providing considerably more torque than they were capable of when we specified gear motors seven years ago. Can we now get the torque we need without way over-specifying the motor size?

Send us your comments, suggestions, or solutions for these problems. We&rsquoll include them in the March 2005 issue of CONTROL DESIGN magazine. Send visuals, too — a sketch is fine. E-mail us at or mail to The Answer to Your Problems, CONTROL DESIGN, 555 W. Pierce Rd., Suite 301, Itasca, IL 60143. You can also fax to 630/467-1124. Please include your company, location and title in the response. Have a problem you&rsquod like to pose to the readers? Send it along, too.