09-13-2012 12:07 PM
I am puzzled by a slight inconsistency I noticed when struggling with using serial.write() to transmit an unsigned int back to LabView. I wasn't getting what I expected to see when merely trying to display the number read from the PING sensor after receiving into LabView using the send receive vi. I'll write another topic on that one, but to this point... here is what I noticed.
In the low level analog commands, the Read Analog Pin, which uses analogRead() function, serial writes the high order byte first, then the low order. However, the sampleContinuously() and finiteAcquisition() functions both use analogRead() function for their purpose, but they "serial write" the low order byte first, and then the high order byte second.
It would seem that one or the other order is out of whack? Or do people just casually deal with the returns on the other side at LabView end?
Thank you....
Tim (anotherAlias)
#
Low Level - Analog Commands - Read Analog Pin (analogRead)
Serial.write( (retVal >> 8));
Serial.write( (retVal & 0xFF));
sampleContinously() w/analogRead...
Serial.write( (retVal & 0xFF) );
Serial.write( (retVal >> 8));
delay(delayTime*1000);
finiteAcquisition() w/analogRead...
Serial.write( (retVal & 0xFF) );
Serial.write( (retVal >> 8));
#
Solved! Go to Solution.
09-13-2012 06:56 PM
It entirely depends on how you interpret the bytes in LabVIEW.
Analog Read Pin:
Continuous Acquisition Sample (note how it handles the bytes differently from above):
Get Finite Analog Sample (I don't understand how this one works)
09-14-2012 12:00 PM
Thank you Nathan for taking the time to explain the lower levels... I hadn't gotten to the point of looking into the actual VIs at that point to get the real answer. I guess I needed a kick in the butt... I appreciated having all those samples around to finally get a clue of how things might be working underneath. Now I understand one has to work BOTH sides of the equation and go to the source for the answers.
Thanks again...
Tim