Serial port dropping bytes

[FredFred]

Hello To All,

I am having a problem with the following.

In my VI i have a I opened a serial port (com1) and am using the property node to read the number of bytes present at the port. I feed this value into the read serial port vi and the return count does not match what was present at the port does any one now why? What must I be doing wrong?

I am using the basic read write example.

Thanks in advance.

FD

[smercurio_fc]

The VISA Read may be automatically ending the read when it sees the linefeed character. Do you have termination character enabled or disabled?

[Edjsch]

In my application they are equal (as you suspect they should be). Do you have "Enable Termination Char" (in VISA Configure Serial Port vi) set to TRUE or unwired (the default is TRUE)? If so, it may be that it is seeing the termination character (default is LF) which terminates the read, but the number of bytes at the port are more than what is read. Just a possibility. (Sorry, I didn't see the reply while I was composing my reply).

Message Edited by Edjsch on 05-20-2008 01:13 PM

[FredFred]

Thanks Alot that was the fix. I should have noticed this at first when the port was configured.

[Edjsch]

Glad you found your error. Today I was doing some more testing/development of my application and noticed something interesting (unexpected):

I have the termination character enabled and set to \n (LF). I am sending my vi a string of 20 bytes with a \n in the middle.

I have a Bytes at Port property node wired to the Byte Count (required input) of the VISA Read. That seems to override the termination character. In other words, I receive (the VISA Read read buffer is) the entire 20 byte string (including the \n), while I was expecting to receive only up to (and including) the \n (after which I am doing another VISA Read to get the remaining part of the string).

It appears that the Byte Count and the Termination Character can conflict. In this case, it appears that the Byte Count takes priority. When the Termination Character comes before the Byte Count, as in my case, it seems to be ignored. Can anyone confirm this?

If this is true, what happens if there is a slight delay (much less than the timeout) between the \n and the remainder of the string? In other words, my string is continuous at 9600 baud. How long a gap must there be for the VISA read to terminate the read upon seeing the \n and letting the block diagram continue? (Possibly the length of a Break = 250 mS default, or greater than say 2 stop bits time, for example?) I searched the Help and have not found the answer yet.

Thanks! -Ed

Message Edited by Edjsch on 06-03-2008 01:44 PM

[Edjsch]

I found this (http://zone.ni.com/devzone/cda/tut/p/id/4256). It says this regarding Serial End Modes for Reads (ASRL End In), "If the byte count (specified by VISA Read) or timeout (VISA property) is reached, the read terminates regardless of what value this property is set to."

That is the case where the Byte Count is reached first, but I have not found (yet) what happens if the Termination Character is reached first. As I said, when there is no gap between the \n and the next character (only 1 stop bit time), the Termination Character seems to be ignored. Hope someone can confirm. Thanks again.

Ed

Message Edited by Edjsch on 06-03-2008 02:00 PM

[Dennis_Knutson]

If the term character is detected first, the read stops. If the byte count is read before seeing the term character, the read stops. When you do a read, are you sure the \n is really the control code and not the characters '\' and 'n'? Is your indicator set to Normal or '\' Codes Display when you look at the read result?

[Edjsch]

What you say is what I expected, too, that the \n should terminate the read.

The string, created in Notepad, when pasted into a text box with "\ Codes Display" enabled is "\s05.167\sLB\n2.432\sin\n".

With "\ Codes Display" disabled it is:

" 05.167 LB
2.432 in
"

as it appears in Notepad. Strange thing: When I look at the saved Notepad txt file in a Hex editor, I see that there is a \r\n (0x0d, 0x0a) as is the standard DOS/Windows line termination. I don't know why LabView doesn't see the \r. Any ideas?

Anyway, it appears that the Termination Character is being ignored, and the full 20 "bytes at the port" are returned. A bug?

[Edjsch]

I found the problem. I forgot to check the Hyperterminal setting "Send line ends (\r) with line feeds (\n)"! So I wasn't sending the \n as I thought I was.

I was thrown off track when I saw that when I copy and paste the string from Notepad into a string indicator ("text box"), either displaying "\" codes or Hex Display, only the LF (\n) is pasted (shown), as I said previously. The \r was not shown. It looks like Labview eliminates the \r when the \r\n pair is pasted from the Windows clipboard.

When I pasted that string into a Hyperterminal window, it only transmitted the \r. The \n wasn't sent! That's why the 20 bytes were returned!

This link http://digital.ni.com/public.nsf/allkb/6E2C88C43C76A77386256975006DB10A confirms that "VISA Read will return from reading after it receives a termination character, even if it has not received the number of bytes specified." which is what you (Dennis) said. It also said, "the VISA Read does NOT return the termination character."

So the number of bytes OR the termination character will terminate the VISA Read, as we expect. Thanks for your help.

Ed

[Edjsch]

I want to correct something I said in my previous post: In testing this morning (with Hyperterminal set to send both the CR and the LF) I see that the \n is indeed returned. Previously I said it was not. Here is the first part of my string (copied and pasted from the string indicator):

"\s05.167\sLB\r\n"

(it terminates with the \n). Note that both the \r and the \n are present. I misread that link in saying that the termination character is not returned. (Actually, I haven't found where it specifically says it is returned, but it doesn't say it is not either.)