There are two methods for getting data into a Thin Client system – through the Server, or through the Clients.
Getting data through the Server
For small installations, where input/output devices are not very far from the Server, and there are not many devices to read, this can be a very good solution. It is certainly the most traditional, with I/O devices being connected to serial ports or special hardware installed in the Server. As all Thin Client software runs on the Server anyway, there is no problem with each client identifying its input or output devices with physical addresses on the Server. This is also very efficient, as data doesn’t have to travel through the Client, to the Server, and back to the Client. However, it is very limited – a Server can only handle so much I/O, and if devices are far removed there will be difficulties in moving data (especially serial data) over the distance.
Getting data through the Clients
Each industrial Thin Client made by Automation Control Products comes standard with two serial ports and one parallel port. Most devices in an automated factory can communicate via a standard serial port. This makes a Thin Client an ideal solution for reading the data and sending it back to the Server. In this case, the program attached to the Client identifies a port on the Client (rather than one on the Server) as its source for data. The data is then converted by the Client and put on the network, where it can travel throughout the entire plant. In fact, one of the ports on the Client can be configured to read RS-422 data, eliminating the need for extra 422 cards or converters.
If these serial ports are not being used for I/O, either one of them can instead be used to read a TouchScreen connected to the Client. The Thin Clients come with a keyboard and mouse port, but TouchScreens plug into a serial port to read the user’s input. ACP Thin Clients include drivers that cover most of the TouchScreens in use today.
However, not all data used in manufacturing comes in a serial form. Increasingly, more and more of it is in one of the more common fieldbus forms. That is why ACP’s industrial Thin Client also can read and write Profibus data, and will soon (4th quarter, 1999) be able to read and write DeviceNet as well.
For Profibus data transfers, a daughter board must be plugged into the Thin Client. This card is a standard PC-104 based board, which fits within the regular Thin Client case. Although adding the card causes the loss of one of the serial ports, using the Profibus network allows the Thin Client to read and write data among Profibus devices. The data is then transferred (via the standard Ethernet cable) back to the Server, where it can be used by the Server, the program attached to the Client with the Profibus card, or any other Client on the network. When released, the DeviceNet feature will function in the same way.
Where should you read your I/O devices? Each installation varies, but here are some of the things that you should consider:
I/O on the Server
Pros:
- If I/O device requires a special card, these cards can be installed in the Server (it is a standard PC).
- If the I/O is very heavy, reading/writing from the Server can keep that data traffic off of the network.
Cons:
- Devices may not be local to the Server, and there may be difficulty running data signals.
- A server can only take so many I/O devices.
- Installation and debugging is not as straightforward.
I/O on the Clients:
Pros:
- Clients are usually right next to the I/O devices, meaning that there are no data transmission problems.
- I/O connections are easy and logical.
- ACP’s industrial Thin Clients can handle serial and some fieldbus devices.
- ACP’s industrial Thin Clients can be configured to handle the RS-422 protocol.
Cons:
- The Thin Client network may need to be separate to keep network traffic down.
- Special data I/O cards cannot be accommodated by Thin Client computers.
- If Clients are moved, the I/O must be moved with them.
As you can see, there is no right answer. Each installation will need to be evaluated based on the location of the I/O devices, the type of I/O and the other factors discussed here.
