Serial read byte order changing

[DPac]

Hi,

I'm new to Labview and I'm trying to read speed and torque from a Datum torque transducer via RS232. I need to read data as a 6 byte frame. I have followed the protocol provided by the manufacturer (first 3 bytes concatenated + some calculations give torque and 4 and 5th byte concatenated gives speed and the last byte provides the supply voltage at the torque transducer).

When I re-run my code, the order of the bytes keep changing. In two screenshots, I have attached a correct order (with 128 in the first byte). But sometimes when I run the code the order changes, so instead of going 0 1 2 3 4 5, it reads 3 4 5 0 1 2 (or something else), which ruins my calculations.

I have tried switching ON and OFF the Termination character and changing the flow control settings, but it either makes it worse or does no good. Forgive me for my lack of knowledge in Labview or basic serial communication.

I would appreciate any information on it. Thank you!

Regards,

DPac

Attachments:

1. Correct (expected) byte order

2. Wrong byte order

3. My vi

[Wayne.C]

DPac,

First order of business is to determine if Term Char should be enabled or not.  Can you post a link to the communications manual for this transducer?

[DPac]

Hi Wayne,

I didn't see that specified in the documentation. I have attached the same.

When I have the termination character set to False, the change in byte order occurs only once every 3-4 times of running the vi. But when I set it to True, the order changes every 1-2 times I run the code

Regards,

DPac

[Wayne.C]

DPac,

Term Char should definitely be disabled.  I'm running an older version of LV so I can't look at your vi.  Can you save your vi for LV2010 and post it? 

[DPac]

Hi Wayne,

Please find the attached vi for LV2010

Regards,

DPac

[crossrulz]

Were there any times that you didn't get enough data?  That would throw it off.

Use a shift register for the error so you don't lose the error between iterations.

[Wayne.C · Accepted solution]

Your transducer is streaming data.  That means that it continues to transmit continuously without your vi having to request any data.  When you read data from the stream you need to know where the first byte of the frame is.   You need to be synced with the frame of data.  Do you know how often it transmits a frame of data?

Document that you posted says the Bit 7 (MSB) of each byte is used to sychronize the frame.  First Byte has Bit7=1 and the rest of the bytes have bit7=0.  That means that the first byte will always have a value equal to or greater than 128.  The other bytes will always be 127 or less.

[DPac]

Hi crossrulz,

I always get some data. It's just in the wrong order at times (wrong byte order I mean) when I re-run the code.

I used NI measurement & automation explorer to dig into the serial configuration and tried reading from the serial port.

Attachment 1 shows the correct data read - 80 00 22 00 00 55 (which is hex, so in decimal it's 128 00 34 00 00 85.

Attachment 2 shows what happens when I clear the device, you can see the order change

[GerdW]

Hi DPac,

- did you notice the warning in the upper right corner of your MAX window?

- did you notice the other message telling you about continouous transmission of that transducer?

Think about those two facts...

[DPac]

Hi,

I did notice the warning messages. But I get the same warning when I read 1024 bytes in MAX, but you can see (in attachment) the data repeats itself every 6 bytes, which is in accordance with the manufacturer's data sheet.

I am convinced by Wayne's observation of data being continuous and providing data without Labview requesting it. When I use the software provided by the manufacturer to log data at the device's maximum capacity, it logs at 80-100Hz

Is there a sensible way of syncing the first byte (128) with Labview? I was thinking of having another VISA read outside my loop to check if the first byte is 128, if not keep clearing the VISA device till it becomes 128 and then start running the loop. But then the loop should have another VISA read inside it to read the actual data continuously.