A person has already come to me asking how to interface an Axon Microcontroller to LabView. Instead of a bland answer to the effect of “It’s nothing special”, I decided to write a quick write-up about communications between computer systems; and I will use the communication between my SAGAR robot and LabView operator panel as an example.
First, you need to connect the two systems at the physical level, IE you need to wire the two devices together. For my project, I used an XBEE radio link. This emulates a serial cable between the Axon and my laptop. I used an Axon’s uart port, and a USB port on my laptop for the USB to Uart chip. LabView has VISA libraries to read from a serial port. This is the easy part of any communication system.
The tricky part is how to convey information between the two. I need to go back to a basic level to fully explain this. For us 10 fingered humans, we express numbers in base 10. The number ‘6’ means this many ( * * * * * *) things. We say ‘6’ to express that many items to another human, and the base 10 number systems is commonly accepted by the human race as THE way to express the number of things. Computers are different. They can only express things in binary, base 2. So ‘6’ to a computer is 110. The problem is that there are many ways to express ‘6’ in a computer. It could be 0110 or 1010 or 01111010. We tell the computer how to represent a number when we declare it as an int, double, etc. So if we were to send data at a binary level, we would have to keep track of how either system is representing it’s numbers. If they don’t match, they won’t understand each other.
There’s also this little thing called big/little endian. This describes the order of how a number is stored in a computer. One way is the way we would consider normal, IE 231 is stored as 2 – 3 – 1. The other way stores numbers backwards, 1 – 3 – 2 . If the two systems as mismatched, again you get communications errors.
These two variables of computer systems are hard to keep track of, and make communications challenging. A way around this is to convert all communications to the ‘human’ standard, something we organic life forms can understand. I use printf() statements to output a sentence of data in a comma delimited form otherwise known as a NMEA sentence. For example,
$SAGAN,20,2,30.193392,-85.797508,55,193*75
Conveys information about the waypoint mission SAGAR is running. The first field, the ‘header’, tells LabView what sentence this is, ie what it conveys. The next fields give the number of waypoints, the current waypoint, the coordinates of the waypoint, the range and bearing to that waypoint. The sentence ends with a * and a checksum to check integrity of the sentence.
Because we are converting all binary data to ascii representations of base 10 numbers, there is no way to confuse the data, no need to worry about how it’s declared in either system nor how it’s stored in memory.
When LabView receives the sentence through a serial port, it checks the sentence against the checksum to confirm its integrity, scans the header to determine its contents, and then breaks it apart into ‘tokens’. These tokens are sub-strings of the numbers between the commas. Then they can be converted into computer numbers using the LabView equivalent of atof(). (Ascii to float).
And there we have it. We successfully conveyed a number from an Axon Microcontroller to a laptop running LabView, without messing with how numbers are declared or stored. The tradeoff, however, is it takes more bandwidth to send ascii sentences then it does to send binary data, but the ease in which to integrate the two systems is worth it, at least in my opinion.
