Serial communication formatting issue

[vt92]

I am communicating with a host machine that spits out data over the serial port.  I am using fairly standard parameters (9600, 8, N, 1) and I am getting data.

The problem is the data formatting.  Obviously, the data is supposed to be fixed width, but the fields get shifted after each CR/LF.

Here is some sample data:

     0   |    0.925 |    0.833 |   110.444  |   549.278  |    23.812  |
                                                                       |  2   |
    0   |    0.921 |    0.832 |   106.971  |   480.604  |    24.464  |
                                                                      |  3   |
   0   |    0.926 |    0.831 |   114.320  |   555.821  |    23.785  |
                                                                     |  4   |
  0   |    0.920 |    0.830 |   108.434  |   587.374  |    23.411  |
                                                                    |  5   |
 0   |    0.925 |    0.836 |   106.459  |   554.808  |    23.717  |
                                                                   |  6   |
0   |    0.923 |    0.830 |   112.048  |   507.875  |    24.242  |
                                                                  |  7   |     0
   |    0.924 |    0.837 |   103.943  |   605.860  |    23.181  |
                                                                 |  8   |     0
  |    0.921 |    0.831 |   108.303  |   582.447  |    23.459  |
                                                                |  9   |     0
 |    0.925 |    0.827 |   118.501  |   426.680  |    25.118  |
                                                               | 10   |     0
|    0.922 |    0.826 |   116.223  |   483.567  |    24.527  |
                                                              | 11   |     0   |

Any ideas what may be causing this?  Are there any serial parameters that could be altering the data format?  I get the same results using LabVIEW and hyperterminal.

I have no control over the host machine (long story).

Thanks for your help.

[JÞB · Accepted solution]

Set your VISA properties to "enable term char on reads" = TRUE and "term char" = 0x0A (Linefeed) .  Configure your reads to read MORE characters than you expect and each read will end when a 0x0A is seen. (you can suppress the VISA warning  if you so desire.

-What happened to the Cursor- this lack of cursor makes posting quite a bit harder! Laura_F- is this known? 

[vt92]

Hi Jeff,

Thanks for the response.

One question: do you think LabVIEW is adding the CR/LF?  The reason that I ask is that the CR/LF is really there, it is not just an issue of the program truncating the lines early.

Here is a picture of the data shown with the special characters:

[vt92]

Here is the data in hex:

[JÞB]

---

One question: do you think LabVIEW is adding the CR/LF?

NO!  the VISA API adds the termination character on writes IF and ONLY IF instructed to do so.  Reflectively, the VISA API returns when it reads a termination character (if so instructed) and automagically deletes the term character from the string read.  Also- it gives a warning that the read stopped because a term character was read.

<Sea-Story time>

Long ago and far away I was debugging a "test" that used a HP-3458A DMM.  The DMM was in a direct digitizing mode and stored what would now be called "Waveforms" (the exact distinctions need not be addressed here) in its internal memory.   Because of the range of stimulus the device failed to trigger on boundary conditions (predictable by specification) yet SOMETHING else seamed to go wrong too and data was missing - sometimes a LOT of data, sometimes a little bit of pre-trigger data.  3 DAYS later I observed that the LAST byte was 0x0A every time or 10 - the exact value that we were trying to trigger on! so the semantic equivilant became Trigger on terminate then return all values stored after you stopped starting.

the VISA warning is there for a reason

[Wayne.C]

The fact that hyperterminal is giving the same results points the finger at the host machine.  It looks like the host is trying to transmit a reading # and then 6 values?

One thing I noticed is that the host does not transmit a consistant # of 0x02 between the sets of readings.  71 and then 70 and then 69 etc.  I really think there is mistake in the host program. 

Can you post a text file containing the hex data?  I'd like to try something.

[vt92]

Thanks, Jeff.

"Configure your reads to read MORE characters than you expect..."  

That was the problem, I wasn't reading enough characters.

[JÞB]

Don't forget to mark the correct solution!

Whoops- I did not read through the entire thread as it was "pretty fimly" in my mind.   Thanks

[imig]

Hi,

I am getting different sentences serially. each sentence is of variable length(no of bytes).

Now i have fixed the read buffer size to 100. Now what happens is that every time any one of

the sentences is broken. i have connected the broken sentence to shift register in while loop and on the next chunk

this is concatinated to the rest of its bytes. But its not working with this strategy. What should i do?