.|
Reference |
Unidirectional Drivers |
|
|
Continuing the examination of protocol design, and how text and binary data is output to the device.
There are also multimedia walk-throughs of some of these techniques
in the online Technical
Resources.
Because serial data is transmitted one byte at a time, the receiving device (or computer) needs to be able to tell where one command ends and another begins. It is therefore necessary to know how long the packet is, whether there are any special characters or values that are used to indicate the start or end of a packet, and how information in the packet is assembled for transmission or interpreted up when received.
For text encoding, there are fairly well established and commonly used approaches for transmitting blocks of text, and these have been usefully exploited in many command protocols. Serially-transmitted ASCII has been around for more than 40 years, and originally required electromechanical typewriters and printers to convey input and output data: long before mice, keyboards, CRTs and LCDs.
These paper-based machines needed to roll the paper up at the end of each line of text, so that the following blank line was ready for the next text packet. This required a command called the Line Feed, and is encoded in ASCII by the number 10 (0x0A). To move the print head back to the left edge of the paper required a Carriage Return command, also encoded in ASCII as 13 (0x0D). There are several other ASCII "control characters" that originate from the era of paper-based and electromechanical computer interfaces, and dumb-terminal devices.
The combination of Carriage Return and/or Line Feed (also known as CR, LF or CRLF) is still in use in serial communication today. To indicate that a "line" of text finishes, it is common to transmit a CR, LF or CRLF as the last byte in the packet. This indicates to the receiving system the end of the text packet: it can now process that packet and be ready to receive the next one.
If ASCII encoding is used to control a device, its protocol will specify the "end of line" character or characters it uses.
For binary encoding, there may be a chosen value or combination of values to indicate the start, length and end of a packet.
All protocols should describe what byte values start a packet, how many bytes to send in the command: this could be a fixed length packet (and may require padding bytes), or a variable-length packet which may include its length as a value within the packet itself.
Finally, the packet may be terminated with a specific stop byte value.
Start and stop bytes ensure that successive commands can be detected correctly and are clearly demarcated from each other.
The Byte Array to ArrayList pattern illustrates how to convert a byte array to an ArrayList object that can be more flexibly manipulated. You could use an ArrayList to successively build up the start bytes, data bytes, padding bytes, checksums and stop bytes of each packet.
Sending data to your device from within a driver is relatively trivial, but does depend on the type of data you wish to send, and the Port type, or base class of your Port Script.
Drivers with serial or TCP ports use Port Scripts inherited from the SerialInPortInstance and TcpInPortInstance base classes, respectively. These base classes include the Write and WriteLine methods that make outputting text strings in your driver very simple.
The Write String to Port pattern illustrates how to output text strings to a serial or TCP port, with or without end of line terminators.
Note
Sending successive strings, one after the other, is not the same as sending a single combined string: the receiving device will probably interpret each string as a different command, and will most certainly do if the WriteLine method is used. Ensure you send all of the text packet at once, using a single string.
As mentioned above, it may be necessary to combine different fragments of strings to create your final command. These fragments might be string constants, strings formatted on-the-fly, or converted from other data types.
The Building and Formatting Strings pattern illustrates how to combine and convert strings from different component parts.
As with text strings, the SerialInPortInstance and TcpInPortInstance base classes include an overload of the Write method that can output byte arrays to a serial or TCP port, respectively.
The Write Byte Array to Port pattern illustrates how to outputs a byte array to a serial or TCP port.
Commands that convey parameters and settings may require more than a single byte to encode the parameter's value. A byte can store values between 0-255, however for some high-resolution parameters this may be too small a numerical range. Multibyte values are simply values larger than one byte.
Special consideration must be given to encoding and receiving multibyte values, to ensure that the correct order of bytes used in the conversion process is maintained. Refer to the Building Packets topic for more information and examples.