From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

[LabVIEW] Send CRLF as Termination Character in Serial Port

Solved!
Go to solution

Hello All,

Good day.

 

I am now facing the termination character problem when using serial port to send commands to instrument.

When I study the example(Example>Hardware Input and Output>Serial>Continuous Serial Write and Read), there is only one byte termination character(CR or LF) can be sent in every time. However, I need to send CRLF (\r\n) to make sure instrument can receive the command correctly, but it seems that LabVIEW doesn't support it. 

Could somebody give me some suggestions where I can find more information about this?

I had searched a lot of pages in community about CRLF, but I still can't find out the solution. Thank you!

0 Kudos
Message 1 of 8
(9,867 Views)

wrote:

Hello All,

Good day.

 

I am now facing the termination character problem when using serial port to send commands to instrument.

When I study the example(Example>Hardware Input and Output>Serial>Continuous Serial Write and Read), there is only one byte termination character(CR or LF) can be sent in every time. However, I need to send CRLF (\r\n) to make sure instrument can receive the command correctly, but it seems that LabVIEW doesn't support it. 

Could somebody give me some suggestions where I can find more information about this?

I had searched a lot of pages in community about CRLF, but I still can't find out the solution. Thank you!


http://www.ni.com/tutorial/4256/en/#toc7

 

A hardware using multiple termination characters seems a bad design to me, can you check, maybe it is configurable at the hardware?

0 Kudos
Message 2 of 8
(9,845 Views)

Hello Blokk,

 

Thank you for your reply. This instrument is really old, so it is not configurable on termination character.

I had tried to follow the setup from your link, and it seems that \r\n doesn't work.

The packet shown on sniffer is still incorrect. (this command should be sent as 64 31 30 30 0D 0A).

command1.PNG

serial3.PNG

Besides, there seems a transfer on the wire in to "TermChar" which is not shown in http://www.ni.com/tutorial/4256/en/#toc7 .

command2.PNG

 

 

 

After trying to combine \r\n to string, the bytes of CRLF can be sent by LabVIEW correctly, but I am not very sure is it a right way to send CRLF. 

command5.PNGcommand6.PNG

0 Kudos
Message 3 of 8
(9,836 Views)

Hi Peter,

 

when you need to attach two chars to your string the easiest is to use some ConcatString functions - so yes, this way is correct…

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 4 of 8
(9,829 Views)
Solution
Accepted by PeterjwWu

Yes this is correct. If you have any doubt, you can always show the string as hex.

The term char is an ASCII char, so 1 byte long.

However I don't see a real problem: writing, you simply add 0D 0A to the command string; reading, you can set 0A as the termination character. I guess that 0A would not appear in the answer body; if it could, then after the read check that 0D is just before 0A and eventually do another read.

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
Message 5 of 8
(9,826 Views)

What I would do is make a subVI just for writing the command.  In it, you use Concatenate String to add the CRLF to the end of the command.  This way you do not have to check it at every single message you send.  As for the Termination Character, leave it as the LF and enable the stop on read.  As long as the messages are all ASCII, you will have no issues.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 6 of 8
(9,810 Views)

Actually when I write drivers for instruments I NEVER use the automatic appending of a termination character on outgoing data but rather append that termination character (sequence) explicitly to every command I send out. I only use the termination character on incoming data to make receiving commands much easier.

 

Trying to do your own "terminate Read on termination character" is a mess to implement, has generally a bad performance and creates a problem when you want to instantiate such a driver multiple times as you somehow have to have an internal buffer for each device connection (LVOOP could help with that but since it already is built into VISA then using that is MUCH easier).

But appending the right termination character(s) to all commands you send out is a very trivial exercise and costs no extra time during driver development.

 

You will notice that VISA allows to set the termination mode for End Out and End In seperately so leaving End Out to "None" and setting End In to "Termination Character" is generally the way to go.

 

And if you want you can always create a low level subVI Write Command.vi or something and let it append the right termination characters for you if you want. For drivers which also need appending of a checksum or similar I usually do it that way. The Write Command.vi calculates the checksum, appends it to the command and terminates the command in whatever way the device requires.

Rolf Kalbermatter
My Blog
Message 7 of 8
(9,784 Views)

wrote:

You will notice that VISA allows to set the termination mode for End Out and End In seperately so leaving End Out to "None" and setting End In to "Termination Character" is generally the way to go.


We should note that the End On Write will only work with the termination character if you are using a serial port.  It is ignored for GPIB and Ethernet.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 8 of 8
(9,770 Views)