|Top Previous Next|
Girder 6 like Girder 5 has a wire independent script based driver infrastructure built in. Driver independent means that no matter if the hardware is connected through RS232, RS485 or Ethernet if the hardware API is the same you'll only need to develop the driver once. Moving to a different wire is only a matter of changing the initialization parameters.
Since the transport library is script based it allows for driver development without the need for a C++ compiler by using the built-in Lua scripting. The implementation is slightly different from the Girder 5 transport API. This was done so that drivers can run on both Girder's and PEAC's scripting engine. For most applications these drivers can be very simple. More complex hardware APIs will take a bit more effort.
The transport system consist of out 4 different parts. These are, the parser, the connection, the transaction queue, transactions and the callbacks into your code.
The connection object abstracts the actual wire protocol (RS232, RS485, ethernet) away from your code. You get 3 events. "Connected" and "Disconnected" and "Failed". The connection automatically tries to re-establish a broken connection.
Protocols will all have some way of delimiting different messages form each other. Often this is based on a special marker like and end-line ("\n") or based on number of characters. The parser takes this worry from your hands and snips in the incoming data into packets.
This object holds the transaction that get queued up for processing. Some transaction do not need to wait for a response before the next transaction is processed while others list sit and listen to the packets coming by. By far the most common is the transaction that sends some data and waits for a response.
Communications with hardware is usually request-response based. We call a pair of these a transaction. Typical transaction send a command to the hardware and wait a certain amount of time for the response from the hardware. If the response does not arrive on time it is sent again if so desired. Other transaction simply sit around listening for incoming data, these are called persistent transactions. While others again and fire and forget sending a command but not expecting any response. Transactions have 3 different events they generate for your scripts. "OnData", "OnSent" and "OnTimeout". The first is called when a response arrives, the second when the data for this transaction has been sent and the last if no response is received before the timeout. Note that multiple transaction can be queued up and sit in the queue until the connection is established.
At any one time there can only be one 'current' transaction. That is a transaction that blocks sending of other transactions until it has either timed-out or received a response. There can be any number of transactions in the "persistent" queue. What happens after a timeout or data received events depends completely on the script and the return value it sends back to it's transaction.
There are 4 different transport types
The serial transport uses a RS232 or RS485 connection using a COM port on your computer. Since comports are rare on computers these days this most likely will be a USB to RS232 dongle.
The TCP connection is a reliable connections in the sense that any loss of data should be corrected by the underlying system. Data should always arrive and if it does not the system should generate a disconnected event.
The SSL connection has most of the same characteristics of the TCP connection with the added benefit that it encrypts the data traveling over the wire. Note that currently we do not have a way of verifying the remote certificate and this could in theory lead to man in the middle attacks.
See the TCP connection for parameter details.