LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Need help converting python code to Labview

Solved!
Go to solution

I have a device that is requiring a string command send to it in bytes through a serial port.  I am not familiar with this and could use some help.  I have included the python code for writing and reading the port.  How to I create the "Bytes() and Bytes.decode() commands in Labview?

 

# encode the command to get the device SN in bytes, and write it to the device
command = "255:R:OCODE:1\r\n"
command_in_bytes = bytes(command, 'utf-8')
port.write(command_in_bytes)
# read the first 500 characters (or less if it times out), convert it to a string, and print it
response = port.read(size=500)
response_as_str = bytes.decode(response, 'utf-8')
print(response_as_str)

 Thanks

Terry

0 Kudos
Message 1 of 5
(253 Views)

 Short answer LabVIEW uses NI-VISA to communicate with instruments on a serial port.

 

serlCapture.PNG

 

Now watch this video: VIWeek 2020/Proper way to communicate over serial

========================
=== Engineer Ambiguously ===
========================
Message 2 of 5
(216 Views)
Solution
Accepted by Terry_S

LabVIEW uses 8 bit ASCII characters for strings and as such is already properly encoding for your device. Python uses Unicode strings and the device does not understand Unicode (most devices don’t) so you need to encode the string into 8 bit characters. As device commands almost never use  characters beyond the basic 7-bit ASCII character set, the LabVIEW 8 bit ASCII encoding is equivalent to UTF-8 encoding for such strings.

 

Just enter the string as you see it in your Python code into a LabVIEW string control or constant and send it off with Visa Write.

But watch out about the Display mode of a LabVIEW string control or constant. In order to properly encode the \r\n in that string into the according control characters, the LabVIEW object needs to be set into ‘\’ Display Mode. Right click on the control and select that menu option. Right click again and select Visible->Display Style to enable a glyph that visualizes the currently selected Display Mode.

And spend one hour of your precious time to watch the valuable presentation movie that LVTS has pointed out in his message. That hour already pays itself off manifold in your first LabVIEW application to communicate with a serial device.

Rolf Kalbermatter
My Blog
Message 3 of 5
(213 Views)

Thanks you for answering what I had asked for and the great explanation.

0 Kudos
Message 4 of 5
(177 Views)

@RTSLVU wrote:

 Short answer LabVIEW uses NI-VISA to communicate with instruments on a serial port.

 

serlCapture.PNG

 

Now watch this video: VIWeek 2020/Proper way to communicate over serial


One potential gotcha with this program. The explicit adding of the EOL constant to the command string avoids the (very) common problem of having to deal with the display mode of the string constant. BUT it will only append a <CR><LF> on Windows computers. On old Macs it will only append a <CR> character and on Unix (Linux) and MacOS X it will append only a <LF>. So if your device expects an explicit <CR><LF>, you make your VI work on Windows only. If however your device will work with either and ignore two consecutive EOL marks, it will work regardless, and yes some smarter devices do exactly that, if their programmer did spend a few minutes to think about making the communication protocol a little easier to use and more tolerant to different computer systems communicating with it.

Just a shout out to be aware of this. The EOL constant may look like a good solution to avoid having to explain about the string display mode in LabVIEW to properly envision backslash escape codes, and it will usually work for typical development work, which is in over 95% of the cases done under Windows. But try to reuse such a driver for your cRIO project, which is running under Linux on the target, and suddenly your device may act badly or not at all anymore.

Rolf Kalbermatter
My Blog
0 Kudos
Message 5 of 5
(132 Views)