serial data in hex

[jilla]

Hello,

I am trying to read RS-232 data from a LabVIEW VI. When I use a serial reader program called "Docklight" and set the output type to "Hex", I get 72 hex words, separated by spaces per each query of the port. When I use my LabVIEW VI, I get a bunch of garbage characters, which I suspect are some sort of ASCII format that just needs to be converted to hex. How can I get the visa read command to output hex values?

Also if I use a serial write command to query the port, and then immediately do a serial read of 144 bytes, will I lose any data? Thanks.

[RavensFan]

Try setting your string indicator to Hex display, by right clicking on it and selecting that option from the popup menu.  The data comes in, and if the hex value relates to a non-printable character by way of the ASCII table, then it will look like garbage.

Then the question is how do you want to work with the values that came in?  Do you want to work with the characters?  do you want to convert the string characters to their equivalent as a string that displays their hex values?  Most likely you want to work with the actual numerics.  Use the string to byte array function to convert the string characters to a U8 numeric array.  It is under the string then the conversion pallette.

If you do serial write and do a serial read of 144 bytes,  you should not lose any data as long as you have a long enough timeout setting for the other device to be able to send the 144 bytes.  You may want to put a slight wait statement between the two statements to allow enough time for the other device to send the 144 bytes and have them loaded into the serial buffer.  Then,

[jilla]

Thanks Ravens Fan,

That did the trick, but now the data seems to somehow be scrambled:

When I use Docklight, I get this (which is correct):

81 01 03 0E 02 02 08 EB 08 00 00 00 00 00 00 FF 65 00 00 12 2A 00 00 0A 00 13 13 3B 09 39 48 00 00 00 00 00 00 00 00 03 84 94 5C 08 48 0F 02 AB FF 09 A2 0F FF 09 94 02 5E 09 A2 09 A2 0F FF 09 93 0B 5E 09 B4 00 00 7B

The "81" is a sync word that is always found at the beginning of the 72 byte sequence. When I use my VI, I get this:

0013 133B 0939 4800 0000 0000 0000 0003 8494 5C08 480F 02AB FF09 A10F FF09 9402 5C09 A209 A20F FF09 940B 5E09 B400 0067 8101 0221 0802 08EB 0800 0000 0000 00FF 6500 0012 2A00 000A

Note that some of the values may have changed btwn the 2 runs that created the data streams above, but note that the "8101" comes as the 25th word in the sequence using the LabVIEW VI.

Any ideas?

Thanks again.

[RavensFan]

Without seeing your VI, I would guess that your serial reads are getting out of synch with the data being sent.  Are you just telling it to read 72 bytes at a time?  Is the device sending data continuously or do you give it a command and wait for a response?

It almost seems like you have data left in the serial buffer from a previous data stream.  This could happen with a device that sends data continuously and the port is opened in mid-stream of a previous response.  So you get the last 20 bytes (for example) of one message, then you get the first 52 bytes of the new message.  The last 20 bytes of the new message are left in the buffer until the next read.  Check to see if that is a possibility.  If so, you may need to create a software buffer that stores all collected bytes and searches through the string for that "synch" character of hex81 and parses the data accordingly.

[jilla]

I agree that it looks like the data is being sent continuously and Im catching it midstream but (at least in Docklight) when I issure the command "0xC5 0x01 0x3A" I only receive the 72 bytes that I pasted into my previous post - always starting with "81". Also, when I use my LabVIEW VI, I always receive "8101" as the 25th word - you would think that its position in the data stream would vary if I was just picking it up midstream.

I have attached my VI (ECS serial read3) - would you mind taking a look. Don't worry about the stuff after the read - Im still messing around with that. Thanks.

[RavensFan]

A couple of quick tips before I look at the code deeper.

Be sure to wire up the error clusters between all of the VISA functions.  It helps for enforcing dataflow and will allow you to see any errors that are generated a little more easily.

Try to avoid stacked sequence structures.  Only use flat sequence structures if necessary.  As far as I can see, most of the sequence structures aren't necessary since data flow (meaning one part of code can't run until all wires going into it have input values on the wires) is present.  Right click on all of the stacked sequences and select Replace with Flat sequence structure.  From there you can merge most if not all the frames.  No need to branch the VISA reference, just wire it through.  For that matter the three write statements with a byte a piece could be merged into one write statement.

It looks like you are waiting to read 144 bytes but only working with the first 72, (I'm thinking this may be the source of the problem.)

You have the termination character enabled by default on your initial VISA config function.  If you get that character, hex 0A or line feed during your string, the VISA read will return early.  And give you all that you have up to that point.  Do you ever expect to get hex value 0A in your data stream?  If so, the rest of the bytes after that termination character will remain in the buffer.  They will become the beginning of the next read string.  (Actually, I think this may really be the source of the problem!)  Wire a false to the enable termination character to the VISA config and see what happens.  Also, wire a 72 to the VISA read and not a 144.

Good luck!

[jilla]

Sweet! Thanks for the advice, Ravens Fan. I do not think that I would have ever caught the termination character enabled error! I have incorporated all the changes that you suggested into my VI but will not be able to test it for a few hrs. Ill keep you posted. Thanks again.

[RavensFan]

Here I simplified the VI code, but it is still functionally the same.

And it does look like you have the character 0A in your string, so I thing that is the source of the problem.

[jilla]

I believe that disabling the termination char did the trick (I also incorporated your other suggestions to improve my code). Thanks a lot for all the help!

[rohitmalve]

Hi,

may be i am going on different track.But I am ryt now working with docklight only.I am facing an issue as follows:

From docklight i am sending an string  02 0B 10 1A 00 38 FF B1 10 67 03 But i am receiving it with some garbage data on my serial device as follows: 02 0B 10 1A 00 38 FF FF FF FF FF FF FF B1 10 67 03

So i am getting the extra FF in my received string which is unwanted.

02 0B 10 1A 00 38 FF "FF FF FF FF FF FF" B1 10 67 03

Please guide on this.