The update just went live. Check out VIPM for the latest version of the toolkit and remember....Update Your Firmware!
Here's a feature request. Add a watchdog timer for PWM outputs to have them stop in a 'neutral' motor state after some length of time. It would not fun trying to chase after a robot running on LIFA and a bluetooth module after the connection fails... not that it would ever happen or anything...
Two big issues I have with my Mega 2560:
1) USB Serial does not initailize properly. Disabling the Initialize Serial block in the Initialize function fixes this.
2) I2C Multiple Byte Read gets mixed up.
#1 is well known, so I won't go much into that.
#2 I have not seen mentioned elsewhere. I've tried to read the 6 Degrees of Freedom board from Sparkfun.com and the HMC6352 Honeywell Compass from Sparkfun.com. Both the Gyro on the 6DOF Board and the Compass have a burst read mode, where you ask it to send data, and it replies back with 2 bytes of data. In LabVIEW, I request to read back 2 bytes, but often, the bytes are swapped, or just plain missing, giving me bad data. If I read back 4 bytes, the data can be rotated, shifted, and other combinations. I'm pretty sure it's not supposed to do that.
On the 6DOF board, I have the luxury of reading back the LSB or the MSB independantly, so that's my work around for it. The compass does not have that luxury without digging deep into the EEPROM.
If I set the # of read bytes to 3 or 4, you can see what happens to the other byte.
You can see in the 2nd Front Panel Window, that the data that should be first, is in element 3, and then the data that should be 2nd is in element 0, and element 1. This device does have the characteristic of spitting out the second (LSB) byte of data repeatidly until asked to read again. But why isn't it working in the right order?
Kind of an update...
I've noticed this issue only crops up once a 0x10 gets sent... then all heck breaks loose.
0x10, for those who don't remember, is the new line character... I believe LabVIEW is getting this confused with this.
I've run into this issue before when using LabVIEW and a PIC24 when using a writeString function of some sort.
Maybe something to look into.
What do you mean by 'once a 0x10 gets sent... then all heck breaks loose.'? Is it when 0x10 is sent via I2C from the sensor to the duino or when 0x10 is sent from the duinon to lv, lv to duino? What do you see when this happens?
From your previsou post it sounds like when you try to read bytes via I2C the bytes are returned in random order or not at all. Is there any pattern to this? Do you know what the expected delay is between requesting a value from the sensor and actually recieving it? The LIFA firmware was written to return as soon as possible but will wait up to 100 ms for a response from the sensor.
I tried responding to the email, but it never showed up.
A bit of a correction. Once Decimal 0d10 is sent, it messes up, which is New Line... not Hex 0x10. Sorry for the confusion there.
I'm not sure if it's the problem is on the Arduino side, or the LabVIEW side. I don't have any of the hardware in front of me... I was just bored in my digital system design class, and figured I would post an update of the stuff I noticed on Thursday. 🙂
I looked through the source code on the LabVIEW and Arduino side, and I didn't notice anything out of the ordinary. I am a little confused why the serial stuff isn't event driven.
I don't have any real Arduino experience, but I do know that the Arduino community is pretty mature, so the likelihood that it's a bug with the low-level I2C seems pretty low, but then again, the fact that it's such a simple write/read function, and then the Arduino firmware is as simple as read-from-i2c, write-to-serial, I'm not sure where the problem lies.
From my code, you can see, I read back 2 bytes of data. They're concatenated using the "join numbers" in LabVIEW, then divided by 10, which gives me degrees from the HMC6352 Digital Compass in 0.1 degree increments, although the HMC6352 is said to have a resolution of 0.5 degrees.
Whenever I receive back what should be 0d10, 0x##, the data gets skewed. The bytes are not read back in the right order, and often, some 0x00s are inserted from somewhere. Once a 0d10 is sent, the data is forever messed up until I Stop-Start the LabVIEW program. This kind of leads me to think that the issue is on the LabVIEW Serial read side.
If I have a chance tonight, I'll try to dig a little deeper, and maybe try to write my own Arduino communication module.
Thanks for the concern, and if anything else is needed, let me know.
The only thing that comes to mind is the following:
Inside the Init VI VISA Configure Serial Port VI is used to disable the termination Character. If ther Termination Character is enabled (and sen to 0x0F) a VISA read will read until it gets the desired number of bytes or the termination character. Since we are just passing bytes and not ascii characters we need to make sure the termination character is disabled so that we do not stop reading prematurely.
If I recall correctly you removed the Config Serial VI from Init to get past the sync error right? Is this the same board and is the Config serial still disabled?
Sounds good. Let us know what you find because this might help track one of the causes of error 5002.