Serial Read with random output.

[Rocket_Man_Jeff]

Hi all.

I've seen similar threads posted but haven't found anything that seems to troubleshoot my exact problem.  I'm attempting to read a serial output from a microcontroller using Labview.  The microcontroller part works fine as proven using Hyperterminal, and I'm getting data in Labview.  The problem is that the serial string is starting and ending at random points when being read.  The code on the microprocessor is as follows:

// write test message to serial port
    
        while (1) {     
           printf_P(PSTR("12.00\r\n"));
           printf_P(PSTR("9.58\r\n"));
           printf_P(PSTR("2.12\r\n"));
        }

The Labview display (Numeric) will look something like:

2.00

9

58

2.1

2

1

and so on.  All the lines eventually add up to be what they should as seen in the Read String part of the attached VI.  The issue is that I need to read those strings in their entirety to control the frontpanel meter.  I figured it's a formatting issue and I've played with this for quite some time with no luck.  Any help would be greatly appreciated!

Thanks,

Jeff

[RobCole]

One of the things that I can see in your code is that you set up the serial port, find how many bytes are there and immediately read them. Are you sure that all of the bytes have been received? check how many bytes are at the serial port. You have turned the termination character ON. This is good. Tell the read function to read, say, 1024 characters. With termination on, it will stop when it sees the termination character and return the string. Then you can read again for the next line.

The online help reads: "This function might return less than the number of bytes requested if the function reaches the end of the buffer, reaches a termination character, or if a timeout occurs."

Give it a try.

     Rob

[Rocket_Man_Jeff]

Thanks for the reply.  Unfortunately it didn't solve the problem, but I got some more potentially useful information.  According to Labview, there are usually 69 bytes at the port to be read, and the length of the string varies from 2 to 7 characters.  No matter what I set 'bits to be read' to, the results are still the same.  I see that when a string of 7 characters makes it though we have a complete string, so I wrote a 'do while' loop to only output data when a string of 7 characters is accepted.  The problem with this is that these 'complete' strings come at seemingly random intervals, as in I might get three strings in two seconds and then not another for ten seconds.  I hope it's a start in the right direction!  I've attached my latest version of this, so any input would be great!

Thanks,

Jeff

[RavensFan]

Don't configure your port in the while loop and don't close it in the while loop.  You are reconfiguring the port on every iteration.  It is very likely you'll lose data if it comes in during the period of time the port is closed.

Also, put a wait statement in your loop so it doesn't run so fast that it eats all the available CPU cycles as a greedy loop.

[Rocket_Man_Jeff]

Thanks for your reply.  I've made those two corrections but the same issue is still occurring.  The primary error is Error 85 saying that the scan string is not in the expected format.  I've been using the syntax table for the format string, so I'm pretty sure that part is correct.  I set up a fixed string input just to check the formatting and all is well with that (seen in my latest attachment).  Using a 'wait' command like you suggested I can physically see the read string is not coming in correctly (which is probably what triggers the Error 85).  Also, I put an abcd in front of the number in the serial string to be read to hopefully act as an indicator that the number immediately follows, but again no luck.  Since each line eventually comes together before the \r\n, is there a way to read the 'previous' line and scan from that?

Thanks!

Jeff

[JÞB]

Use the \n to end your reads and seperate yor messages

Fulshing the buffer tosses all the data out (mayes it hard to read after its gone)  We wont discuss infiate loops How did you expect the VISA close to ever run? 

Try this

[Rocket_Man_Jeff]

Are you suggesting that the \n should go into the Labview VI or into my serial input?  Right now the code that generates the serial string is:

// write test message to serial port
    
        while (1) {     
           printf_P(PSTR("abcd12.00\r\n"));
           printf_P(PSTR("abcd9.58\r\n"));
           printf_P(PSTR("abcd2.12\r\n"));
        }

I also tried:

// write test message to serial port
    
        while (1) {     
           printf_P(PSTR("abcd12.00\n"));
           printf_P(PSTR("abcd9.58\n"));
           printf_P(PSTR("abcd2.12\n"));
        }

which had no effect.  I know my VISA close will never run at the moment - my VI started from a textbook example which had it in there and I just haven't deleted it or gone about implementing it.  I figured closing the VISA is the least of my worries!  I have the set buffer size block in there because without it I get an overrun error.  I was just experimenting with trial and error and using a set buffer size block fixed that error.  Thanks for the modified VI, however I'm only running Labview 2010 and get an error when trying to open it.

Jeff

[RavensFan]

If that is literally what you are sending in C code, then  you have a problem.  It looks like you are sending the characters backslash-r-backslash-n.  None of those are a new line character.

In LabVIEW when a string is set up to show \codes, a new line character (ASCII decimal 10) will show up as \n.  But you are literally sending 2 characters of a slash and an n which are two completely different bytes then the new line character.

In C (or at least in BASIC) you would need to concatenate a chr$(10) to the end of the string.

[JÞB]

Nice catch Bill - I totally read through that

[RavensFan]

I didn't see it the first time I read the message either since when I read \r\n my mind automatically thinks CRLF without realizing it wasn't being used in a LabVIEW context.