Serial Port Communication

Comm Port Buffering

The OCS firmware maintains a Transmit Buffer and a Receive Buffer for each available Comm Port. When a Send or Receive element is activated, data is transferred between the appropriate buffer and the ladder program's registers (presumably, %R). The programmer determines which registers are used during configuration of the element.

For a Comm Port Transmit element, the TX Count word contains the number of characters moved from the program registers to the transmit buffer, so long as power is applied to the element. This number can be less than the requested number if the comm port buffer is full. When power is removed from the element, the TX Count Word contains -1 (negative one).

For a Comm Port Receive element, the RX Count Word contains the number of characters moved from the receive buffer in the program area. This number can be less than the requested number if the comm port buffer contains fewer characters than requested.

Return to the Top: Serial Port Communication

Serial Ports and Cscape

The serial port physically present on the OCS unit is primarily intended for use as a Cscape interface port. This is referred to as COMM1 on the OCS . By default, this port uses the CsCAN Horner APG's proprietary network protocol that runs on the Bosch CAN network specifications. Prior to the advent of the OCS. protocol, which is the protocol used by Cscape to communicate to the OCS controllers.

If OCS COMM1 is opened using ladder elements, the CsCAN functions are disabled, and the port can not communicate with Cscape through this port. When the port is closed by ladder functions, CsCAN and Cscape communications returns. The port can not be used as a user-defined port and as a CsCAN port simultaneously.

If the port is opened using ladder elements, and the OCS is manually placed into the IDLE mode, the CsCAN functionality and Cscape communications return. When the unit is subsequently placed into the RUN mode, however, it is necessary to reopen the port under ladder program control.

If it is necessary to use the COMM1 port under ladder program control and communicate with Cscape at the same time (i.e., for purposes of debugging) the OCS can be connected to a second OCS unit using CsCAN network and the Pass Through A feature of Horner APG’s OCS products is to connect Cscape “local”, aka directly, to an OCS, then do pass-through programming and monitoring to other “target” OCS controllers connected via CsCAN. Connection features. This method also allows debugging of serial port related features.

Return to the Top: Serial Port Communication

Timing and Synchronization

It is possible that the Serial Transmit and Serial Receive elements do not complete within one program scan time. The elements do not pass power until all data bytes have been transferred. This is not usually a problem for transmissions but can be significant for receptions. For example if the ladder program requests 3 bytes of data, but the remote unit only sends two. Or worse, the remote unit has failed and doesn't transmit at all.

It is the programmer's responsibility to write ladder programming code to check the status of the transmit and receive elements and to provide a suitable timeout, if necessary.

Return to the Top: Serial Port Communication

Handshaking

Handshaking is a method whereby the destination end of a transmission can control how much and when data is sent to it.

Note: For purposes of this discussion, source end is defined as the unit which is transmitting data. Destination end is defined as the unit which actually receives the data. Any physical unit may transmit, receive, or both, and may therefore be the source end at one instant and the destination end at the next.

Handshaking is configured with the Comm Port Open element. There are five (5) possible types of handshaking:

NONE - There is no handshaking. The source unit sends as many data bytes as it can as fast as possible for a given the baud rate. No consideration is given to the capabilities of the destination end.

XON/XOFF - (Also called software handshaking) The destination end keeps track of how many characters it has received and the size of its internal buffers. If the buffer gets full or the unit is otherwise unable to receive further characters, it must transmit the XOFF (transmit off) character. The source end must then stop transmitting data until a subsequent XON character is sent by the destination end. Because there is some heavy software overhead involved, the timing of transmissions is variable. The destination must first determine that it is full and then transmit the XOFF signal. The source end must read the XOFF signal and react to it. In the mean time, several additional data bytes can be sent. It is up to the destination end to ensure that it sends the XOFF signal soon enough that the buffer is not overrun. The XON and XOFF characters are predefined by the ASCII ASCII - American Standard Code for Information Interchange - ASCII-coded characters are single-byte values in the range of 0 (zero) to 127. Codes in the range 128 to 255 are not defined by the ASCII standard, but rather by the equipment manufacturer. character set. XON is 11 hex A base-16 numbering system which uses the symbols 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F for numeral. or 17 decimal. XOFF is 13 hex or 19 decimal. The XON/XOFF handshaking is most often used where only ASCII values are being sent. XON/XOFF can not be easily used where binary data is involved, because the XON/XOFF codes are also valid binary codes.

Note: XON/XOFF handshaking usually implies a full duplex Full-Duplex devices are able to Send and Receive data simultaneously, often referring to RS232 or 4-Wire RS485. (both ends may transmit simultaneously) communications channel as the destination end needs to transmit the XOFF characters at any time (including in the middle of a transmission from the source end). The advantage to XON/XOFF handshaking is that it can be implemented using an easy and cheap three-wire (TX/RX/Common) cable.

HARDWARE - [Also called RTS/CTS handshaking.] Hardware handshaking requires extra signals be sent between the two units, thus this is more expensive to implement due to the increased numbers of wires in the interconnecting cables. In operation, the destination end determines that it is empty, and activates its CTS (Clear To Send) signal. In response, the source end sends data so long as the CTS signal remains active. Many devices have the RTS/CTS signals wired directly into the hardware. Thus, an inactive CTS signals from the destination end can instantly shut down the source end. These hardware operations can be very fast because no software control is necessary in this case. Also, this manner of handshaking can be used regardless of the nature of the data being transmitted, ASCII coded or binary.

Multi-Drop Full Duplex Full-Duplex devices are able to Send and Receive data simultaneously, often referring to RS232 or 4-Wire RS485. - In a full-duplex multi-drop situation, all available units are wired in parallel. For receiver circuitry this is no problem so long as the load on the network is not excessive. All units have their receivers enabled at all times. Each message sent through the system is somehow identified by giving it a drop address. All units will receive all messages. All units check the drop address against their own address, and only the unit with the matching address responds. All units maintain their transmitters disabled at all times, except when they need to transmit. When a unit determines that it has something to transmit it turns on its transmitter, sends the necessary data packet, and then disables its transmitter. Full Duplex Full-Duplex devices are able to Send and Receive data simultaneously, often referring to RS232 or 4-Wire RS485. Multi-drop is usually found in multi-master or peer to peer systems, where all units have a more or less equal chance of needing to transmit a message. Often, the units needs to verify that the message they sent are sent correctly so the receiver is left on at all times. The advantage to this system is that many units can be connected to a simple three-wire (RX/RX/Common) cable. The drawback to this system is increased firmware and software complexity.

Multi-Drop Half Duplex Half-duplex devices are able to Send and Receive data, but only one direction at a time, often referring to 2-wire RS485 devices. - Multi-Drop Half-Duplex operation is identical to Full-Duplex except that the transmitting unit's receiver is disabled when the unit is transmitting. All units maintain their transmitters disabled and receivers enabled at all times except when they need to transmit. Usually, protocols dictate that only the unit matching the drop address can transmit. This unit turns on its transmitter, turns off its receiver, sends the necessary data packet, and then disables its transmitter and enables its receiver. Half Duplex Multi-drop is usually found in Master/Slave systems where one unit is designated a Master and all other units are Slaves. The Master transmits a message to one Slave, and then disable it's transmitter. All Slaves hear the message, but only the Slave with the matching "drop address" will turn on its transmitter and respond.

Modem Control

The OCS now has the capabilities to control an external modem. Using the Modem Control element, the OCS can initialize, dial, and hang up the modem. The Auto-Answer mode of the modem, if available, can also be turned ON or OFF.

RS-485 with the OCS

Some OCS units do not provide RS-485 An EIA standard that specifies electrical characteristics of drivers and receivers for use in serial communications. Electrical signaling is balanced and multipoint systems are supported. compatible signals. It is necessary to purchase and install a third-party RS-232 to RS-485 converter. In this mode, transmitter control is OCS Signal CTS, available on the DB-9 connector, Pin 8. When the OCS asserts this signal, the converter enables its transmitting section.

Return to the Top: Serial Port Communication