labview arduino uno bad transfer of data

[marques51]

Hello

I am a newbie , and in my project ( a temperature datalog wireless using arduino and xbee- I don't use lifa interface, just get the packet via Labview standard serial VI).

A weird thing happens when the some numbers from arduino/xbee arrive in labview, the Vi doesn't show some numbers : 

the number 125 and 126 , for instance ( and many others)..isn't not random...is always the same numbers...

this is the way that i send the packet

int32_t l;

int16_t j;

payload[1] = ( ((l >> 24) & 0x000000FF));
payload[2] = ( ((l >> 16) & 0x000000FF));
payload[3] = ( ((l >> 😎 & 0x000000FF));
payload[4] = ( ((l >> 0) & 0x000000FF));
payload[5] = (j >> 😎 & 0x00FF;
payload[6] = j >> 0 & 0x00FF;

where l = temperatur from thermocouple ( *100)

and j is the ambient temperature(*100)

in Labview I use join the numbers and convert (cast) to sgl  and j to int16.( /100 to get the decimals)

I believe is some wrong way that I'm putting the bits in the packet...or the conversion in labview.

I really search a lot in internet, and saw some guys with this problem with the magicals 125 and 126 numbers!!!!!

If somebody could get me a idea what is it???...I really appreciate... I've researched a lot in Google....I've tried strings...litle endian...etc..etc...in each way some numbers missing.... ...I've tried add a random number like 6000 in the value...I just move the problem, 125 and 126 show...but ( for instance  208 and 209 don't).....It is weird ( for me , at leat....)

( excuse my bad English..I'm from Brazil)

thanks

[RavensFan]

---

@marques51 wrote:

I believe is some wrong way that I'm putting the bits in the packet...or the conversion in labview.

---

Don't know what "ibts in the packet" means.  But there are 8 bits in a byte.  The one possibility is if you set your serial port up for 7 data bits then anything 128 or larger won't come through.  That is very close to your "magical" 125 126 numbers.  What if you were sending 127?  128?  129?

Can you post your VI with the string data that comes in from the VISA read saved as default data in a string indicator.?

Tell us what the i and j values are in your arduino so we can try to match them up with the  6 bytes that LabVIEW receives.

[marques51]

Hello Ravens Fan

thanks for the reply

right now I'm trying usind union, and change both numbers to double with four bytes

this way

union {
double f;
byte b[4];
} stuff;
union {
double j;
byte b[4];
} stuff1;

payload[1] = stuff.b[0];
payload[2] = stuff.b[1];
payload[3] = stuff.b[2];
payload[4] = stuff.b[3];
payload[5] = stuff1.b[0];
payload[6] = stuff1.b[1];
payload[7] = stuff1.b[2];
payload[8] = stuff1.b[3];

and in labview i use the jpg atached...join the string ..reverse...and cast to sgl 

still without receving some numbers.

about the 125 and 126...is that...if the temp. increase jump from 124 to 127 ( waiting for some time.... while 125 ans 126 is passing.....) if the temperature decrease...127...to 124 .. the labview doesn't understand the number 125 and 127..or some others..

Because my changes the numbers are other than 125 and 126...but still missing some numbers ( mainly with this format xx.81)....

Excuse my bad english

I still believing is some way the send the bytes...some factor to multiply...or some thing like that.

By the way ...the chip Max 31856 multiplies the temp for 128 and use a factor to change ito to Celsius ( 0.0078125 to sensor and 0.015625.

I've tryed to send the raw data to lavbiew and there use the factor...still the same...the problem is in the raw data ( x* 128 or  10  * 128 *0,0078125 = 10), because I've made a simulator....and the problem still there..

thanks

marques

[RavensFan]

I'm quite sure whatever the problem is is on the Arduino side either with your device or your programming.  LabVIEW certainly "understands" the numbers 125 and 126.

Unfortunately, I can't help you solve your problem because you didn't attach what I asked for.  A small screenshot of LabVIEW code with broken wires is meaningless.  I can't tell what types of integers are the blue wires, or what types of floats are the orange wires.  And none of it tells me what the actual data is on the wires.

I'll give you the specific steps for what you need to do.

1.  Attach a string indicator to your the output of your VISA Read.

2.  Run your VI until you get some data in that indicator.

3.  Stop your VI

4.  Go to Edit then pick Make Current Values Default.

5.  Save your VI.

6.  Attach your VI to a message.

7.  Tell us what numbers you expect to see in the VI

[marques51]

thanks again

see attached a vi labview and a simulator arduino.

this is a sub vi of the whole project, is the vi responsable for get the data.

using my system ( with xbee) in this case the number 10 ( show up sometimes) and 17 and  19 never show up...

i tryed to use a uno without xbee to simulate...but is too much for a newbie....I believe will be easy for you..

obs: I'm using int32  just to check...because I need double numbers...but the error happens in both( in other numbers...but..it happens....)

[RavensFan]

Your forgot to do steps 2, 3, 4, and 5.  There is no data shown in that VI so I can see what you actually received from the Arduino.

I do see one potential problem.  You have the termination character enabled on the Serial Configure which defaults to linefeed x0A or decimal 10.  Since you are sending binary data, a byte of value 10 is just as likely to be a valid byte of data as any other.  But because you enabled the termination character, the VISA read will terminate there and your message will be short.  Any remaining bytes will show up in the next VISA read and none of your data will be aligned.

Since you know your packet of data is a defined size of 22 bytes, just use that and disable the termination character.

There is one other problem.  Since your device sends data continuously, when your VI starts and does the first VISA read, you don't know if you are starting at the beginning of a packet, or have already missed some bytes and are reading the middle of a packet.  There is no mechanism to realign the data.  A good communication scheme as your VI send a "command" to the arduino, and it only responds back with data once it sees that command.

[RavensFan]

Something you can do that could clean up your LabVIEW code.  I like how you created a cluster to do the conversion from string to meaningful data names.

There is one input on that Unflatten from string you should look more closely at.  There is an input called "Data Includes Array or String Size" that defaults to True if unwired.  You MAY need to wire a False to that input.

Back to the helpful part.  A few places you take 4 bytes, build an array, reverse it, then typecast to an I32.  Instead of having your cluster have 4 U8's called Payload(1,2,3,4)Temp Sensor, make a single I32 called Temp Sensor.  Now those 4 bytes will be directly typecast to an I32.  You might have an issue with byte order (most significan byte or least significant byte first.  You can either fix that in your Arduino code, or wire up the constant of the Unflatten from String called "byte order' with the appropriate value that works.

Check your other datatypes.  Sometime you take an I32 and use a coercion bullet to make it a single to wire into a single precision indicator.  Since the data is still effectively an integer value, you might as well make the indicator an I32 integer as well along iwth the typedef of the output cluster.

Where you check temperature against >=45 and <=-5 and OR that together.  Just use In Range and Coerce.  Put a NOT on the InRange output. It will eliminate a few nodes and wires.

[marques51]

Hi

I've tryed everthing...with termination terminal in True and False.....still the same..

This is a project that the device is in to a huge oven ( 5 m of diameter) , rotating,  more 300 C...and the syncronism is perfect...is rare I loose a signal..I have afrraid about this "conversation" between the xbee ...( is simple :one send...other receive ..no corrdenator..just end device...works pretty well)..

I'll do the other steps , but if you have an arduino in your hand, the simulator would be ussefull to test it..and I will learn the righ code to do that ( I almost there...I dont know how I send the payload trough serial straight to my vi. without a xbee..I fell the problem isn't in xbee , but in the convertion of the string......but I'm really tired to find in the Google..)

thanks

[RavensFan]

I don't have an Arduino, so I can't try it.

I'm quite sure the problem is not in LabVIEW.

Nothing is jumping out at me as a problem in your Arduino code,

The two things I'd be most suspicious of is the use of SPI and the Xbee, neither of which I'm familiar with.  Could any of your missing bytes be a meaningful control code to either of those?  If the Arduino is sending out using XBee,  what are you using to get that into your PC?  Do you have some Xbee receiver that acts as a serial port?

Can you replace the Xbee with a hardwired RS-232 serial connection and see how that works just for the sake of testing?

A better simulator would be if you replaced your Arduino code with something that sends the values from 0 to 255 in a for loop.  Have your LabVIEW code read 256 bytes.  See if that is missing bytes, perhaps you even missing more than the ones you already know about.

What if you used Hyperterminal or Procomm plus or whatever terminal program you can get your hands on and use that instead of LabVIEW?  Does that show missing bytes?

I still think you will need  to improve the communication mechanism.  You say it works pretty well as it is (ignoring the problem that began this thread).  But you might just be lucky that you haven't read any data in the middle of a packet being sent.  For 22 bytes at 9600 baud, that means the length of the data is roughly 22 msec.  Your Arduino code has a 1 second wait in it.  So ~98% of the time you'll start the VISA read while no data is being sent and get the full packet.  About 2% of the time you'll start the read in the middle of packet.  This problem will happen on the first run of the VI.  If it hasn't happened at the beginning, it likely won't happen while the code is continually running.  If the port is first opened while the middle of the packet is coming in, things will be out of synch and persist.  Have you stopped and restarted your code a few hundred times to see if that 2% chance of a problem showed up?

[marques51]

hi

here you are the vi with data saved

I dint know how I change a 4 U8 in one I32 ...this is in the VI..dont in arduino code..right?? 

thanks

 obs : I've changed the Input in flatem to F..and...nothing...still the same..

The behavior of the my end device is the leds rx and tx blinks when receive the signal..but fot the number 17 and 18 they don.t blink..is like the arduino doesn't send the sinal ( but the led in the xbee transmitter blinks)