01-28-2012 02:12 PM
I'm not entirely sure I understand what you mean. The bits of code I've been posting are first complied and then put on a microprocessor, so I thought the return commands were doing what they should. I figure a picture says a thousand words, so I've attached a screenshot of the VI running with the abcd12.00\r\n lines feeding in. As can be seen in the 'Read String' indicator, all of the lines complete except for the line that was reading when I took the screenshot. If I omit the \r\n from the input string, the whole 'Read String' becomes a block of text with no formatting or returns.
Jeff
01-28-2012 03:28 PM
That all looks okay. Apparently whatever you programmed into the microprocessor is sending a carriage return and linefeed.
Your screenshot looks right. If you open your com port in the middle of a piece of data being sent, you probably will miss some of the first piece of data.
What you need to do is just discard the first string you read after opening the com port.
01-28-2012 06:28 PM
The problem is solved. I actually found two ways to do this (and I'm sure there are many more). One way manipulates where the string is read from using tokens, and the other simply uses the 'pick line' from multiline string command. Both outputs agree, though I thing the pick line command is a lot more straight-forward. I've attached the VI with both methods in it. Thanks for the help and guidance!
Jeff
01-28-2012 08:27 PM
You still need to get the set buffer function out of the the loop. There is no need to set the buffer size on every iteration of the while loop.
01-28-2012 10:21 PM
Good call. I put it inside the loop because originally I was having an overrun error and that seemed to fix the problem, but it's fine being outside the loop now!