Test Your Substrate Quality with a Segmented Tension Roll

Quik-Cal: Push button calibration cuts setup time

TI17C amplifier output vs competition

Both the SteadyWeb^TM MicroProcessor controller and the SteadyView indicators have serial ports available for communication with other devices. Using the SteadyWeb MicroProcessor as an example, let's take a look at how these may be applied.

The SteadyWeb MicroProcessor controller is typically used for local control of process tension, physically close to the machine section of interest. Frequently however, machinery incorporates some sort of computer, either a PLC or a PC, and a remote console which is used to either control the machine or provide operating status from a single location. In this situation the operator may need to have tension information displayed at the console, and possibly even to enter setpoint or control information from the console.

Our flexible implementation of serial communications is specifically designed to allow this in a few different ways. The simplest way to get serial tension information out of the SteadyWeb MicroProcessor is to configure it to send periodically the desired information to a remote device. Configure as follows:

Function	Function name	Setting
f22	Communications mode	Statistics
f75	Communication baudrate	9600 (typically)
f76	Communication format	8,N,1 (typically)
f77	Statistics data	Tensn
f78	Statistics Timebase	1 sec (typically)

If the SteadyWeb contains the RS232 option, you have an appropriate cable to connect it to your PC, and the PC communication program (e. g. Win3.1's "Terminal"; or Win95's "Hyperterminal") is set up with the same communications parameters as above, you will then see process tension on your PC screen, with a new reading appearing every second. This could be useful for diagnosing machine problems, since you can easily capture the information over a desired period of time into a disk file for later review. Another alternative would be to use a serial (not parallel) printer instead, in which case you would get an instant hard-copy of the data.

Setpoint and output information can easily be added by changing the setting of f77, and the desired information can be sent more or less frequently by changing the setting of f78. Note also that there is no real "programming" involved, and the controller sends the data out whether or not there is a device "listening" to it.

If a machine's PC/PLC has more than one device sending data to it, a separate RS232 port would be required for each device. On very small systems this may be practical, but on even moderate-sized ones, RS232 becomes an inappropriate interface to use because of the cost involved in providing multiple communication ports on the PC/PLC, the cost of running separate cables from the PC/PLC to each device, and because of distance limitations with the RS232 standard itself (around 15 feet, depending on the RS232 implementation). RS232, although popular, was originally designed for office and data-processing environments. Therefore the most popular interface type for industrial communications is RS485.

The RS485 standard has a number of advantages over RS232: it allows for much faster (up to 500 times) communications speed; it allows up to 64 devices to communicate over the same two pair (or even one pair) of wires ("daisy chaining"); and although the maximum length depends on how the system is designed, a total length of around 1000 feet is easily achievable in most cases.

But in order to realize all these benefits, you have to make a few concessions. First, if all the devices are using the same pair(s) of wires on which to "speak" and/or "listen", the host PC/PLC obviously needs some way to tell the devices apart from each other. This is done by assigning each device its own unique "Network Address". In the Dover line of products, this address can range from A through Z or 0 through 9. This allows for identification of up to 35 (26 + 9) individual devices (as a testing and troubleshooting feature, Dover products will respond to Network Address "0" even if its address is set to something else).

Second, while it is possible to devise a means to prevent each device on the network from talking while another device is doing so, it is impractical for devices from different manufacturers to use the same method since there are no standards for arbitration between requesting devices for these interfaces*. Therefore the way bus contention is eliminated is by implementing a simple Master/Slave arrangement by which the Master (the host PC/PLC) requests data from (or sends data to) each Slave device as needed, by sending each device an appropriate command containing that device's address. Slave devices receiving a command addressed to another slave simply ignore that command. It then becomes the responsibility of the host to request data from the appropriate devices at the appropriate intervals. All this does require some "programming", but fortunately this type of programming is well understood, and for any given machine, will likely need to be done only once.

So, in order to set up the SteadyWeb MicroProcessor on an RS485 network, do the following:

Function	Function name	Setting
f22	Communications mode	Remote Control
f75	Communication baudrate	9600 (typically)
f76	Communication format	8,N,1 (typically)
f80	Network Address	1 (typically)

Of course the controller will need to have the RS485 option, which consists of a different interface IC, and then you will need to find out whether the network is "4-wire" - the host talks to all the slave devices on one pair of wires, and the slaves all talk back to the host on a separate pair; or "2-wire" - where all the communications occurs on a single pair of wires. The controller will then need to be set up accordingly. Programming the host for a 2-wire system may be slightly trickier, because all devices including the host need to wait until any other device is finished talking before communicating again.

When Remote Control mode is used in a SteadyWeb Microprocessor, the controller always reponds to a command sent to its address, either with the requested information, or just an "Acknowledge" (ACK) message. Commands sent to it which it doesn't understand are responded to with a "Negative Acknowledge" (NAK) message. NAKs can be used by the host to initiate retransmission if desired.

Note that unless you have an RS232-RS485 converter, you won't be able to use RS485 with your PC or laptop. You can still use Remote Control mode with RS232, but again, you will need one communications port per device.

Using Remote Control mode gives the host access to many features, such as setpoint entry and mode selection. See Section 9 of the SteadyWeb Microprocessor manual for configuration information and a complete list of available commands.

All of the above information applies to the SteadyView also, but of course the user interface is different. See Section 6 of the SteadyView manual for how to configure these products and a list of available commands.

I hope the information I have provided is useful to you. For those who are interested, you may download from this site (or I can send you a disk) containing "setup files" for Win3.1 Terminal, which configures Terminal for the default communications parameters of the SteadyWeb MicroProcessor, and the SteadyView indicator.

This program also places buttons at the bottom of the screen, each of which sends a command to the controller. This makes it easy to test communications and verify that the device is configured properly. I can also recommend an RS232 - RS485 converter which will allow you to use your PC (with an RS232 interface) to talk to RS485 devices.

* This is the purpose of protocols such as Ethernet or CAN (Controller Area Network).

-Alan Wysocki (9/97)