LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why does the LabVIEW 'TCP Read' add a carriage return to embedded line feeds?

I'm sending ASCII strings from a device into LabVIEW using TCP.  I'm using the CRLF as a termination (end-of-input) character and trying to use LFCR as a newline (but not end-of-input) but the TCP read vi is adding a CR before the LF which ends the read early.  How do I stop that?

0 Kudos
Message 1 of 10
(2,887 Views)

The detailed help for TCP read describes different modes.  Try a different mode and see how it works.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 2 of 10
(2,885 Views)

the four different read modes include the CRLF terminator, but I haven't seen a way to stop the vi from adding characters.  if I go to another mode i probably need to write a new vi to emulate the CRLF mode.  possible, but not ideal

 

0 Kudos
Message 3 of 10
(2,881 Views)

Make sure you're not sending extra characters.

 

Edit:

Sorry, I don't mean "you" personally; rather something that you're not aware of is doing this.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 4 of 10
(2,865 Views)

i've messed with it for a while and convinced myself that i'm not actually sending the characters.  when i use a simple terminal program like TeraTerm i don't see the extra characters.

0 Kudos
Message 5 of 10
(2,861 Views)

Can you show us some simplified code that demonstrates the problem?

0 Kudos
Message 6 of 10
(2,856 Views)

it is pretty simple:

  • TCP open
  • TCP write to send the data request
  • TCP read to get the data

this leaves a lot of data in the buffers.  I've added a TCP read using the "standard" termination mode and is get the rest of the data (after the read times out).

the actual code is on a lab computer and is a hassle to get to

0 Kudos
Message 7 of 10
(2,852 Views)

@ChiliLover wrote:

it is pretty simple:


If we need to write our own test code, most likely nobody will even bother.

 

TCP is regularly used to transmit binary data where not a single byte pattern is "reserved", so obviously something is wrong in your case if the bytes are edited in some way during transmission. We probably really need to see your code.

0 Kudos
Message 8 of 10
(2,838 Views)

@ChiliLover wrote:

it is pretty simple:

  • TCP open
  • TCP write to send the data request
  • TCP read to get the data

this leaves a lot of data in the buffers.  I've added a TCP read using the "standard" termination mode and is get the rest of the data (after the read times out).

the actual code is on a lab computer and is a hassle to get to


TCP read DOES NOT add characters to the data. You are either sending more than you think you are or you are not reading the data correctly. Use Wireshark to see exactly what data is being sent by the device.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 9 of 10
(2,826 Views)

I saw an idea in a related post and I tried it successfully.  I set up a single character TCP read (standard mode) with a long timeout followed by a while loop containing a single character TCP read (standard mode) with a much shorter timeout.  I'm getting complete reads now.

I'm pushing characters to a ethernet chip on my device.  it could be that the device is "helping" me out by adding the CRs.  the documentation is poor but there is no indication that the calls would be doing that.

anyway, i've got a solution now so thanks.

0 Kudos
Message 10 of 10
(2,818 Views)