Trouble with receiving data from a Zebra Miniscanner in LabVIEW.

[LLindenbauer · Accepted solution]

---

@samuelm91 wrote:

I was never able to get it to return any data and the timeouts were before I added to loop to force it to constantly check for data at the port. I'm finding a Prolific USB to Serial Comm Port. I've tried installing the latest driver from Prolific's website, but it didn't help. As you said it might be that an incompatibility with VISA. Do you know a work around within LabVIEW? 

---

If you are on a Windows computer, you can use .NET with System.IO.Ports.SerialPort - You can check your design before wiring it up in LabVIEW by opening it in a PowerShell console like

$port = new-Object System.IO.Ports.SerialPort
$port.Name = "COM4"
$port.Open()
$port.Write("*IDN?")
Start-Sleep -Milliseconds 500
$port.ReadExisting()

Good to have handy when no serial tool is installed. There is a good chance that this is how your other serial terminals establish their connections, as well. Take note: "ReadExisting" does the "BytesAtPort" thing, so don't use that in the actual production code. If you already have a VISA-system wired up, you can replace your VISA VIs with the .NET method nodes and it should be a pretty much a drop-in replacement - you can even leave the VISA resource wire as it gets updated to the .NET reference.

[BertMcMahan]

---

@LLindenbauer wrote:

---

@samuelm91 wrote:

I was never able to get it to return any data and the timeouts were before I added to loop to force it to constantly check for data at the port. I'm finding a Prolific USB to Serial Comm Port. I've tried installing the latest driver from Prolific's website, but it didn't help. As you said it might be that an incompatibility with VISA. Do you know a work around within LabVIEW? 

---

If you are on a Windows computer, you can use .NET with System.IO.Ports.SerialPort - You can check your design before wiring it up in LabVIEW by opening it in a PowerShell console like

$port = new-Object System.IO.Ports.SerialPort
$port.Name = "COM4"
$port.Open()
$port.Write("*IDN?")
Start-Sleep -Milliseconds 500
$port.ReadExisting()

Good to have handy when no serial tool is installed. There is a good chance that this is how your other serial terminals establish their connections, as well. Take note: "ReadExisting" does the "BytesAtPort" thing, so don't use that in the actual production code. If you already have a VISA-system wired up, you can replace your VISA VIs with the .NET method nodes and it should be a pretty much a drop-in replacement - you can even leave the VISA resource wire as it gets updated to the .NET reference.

---

Very good tip, kudos!

(Though FYI to the OP, your system very likely doesn't use the *IDN? protocol. Maybe it does, but that's usually scientific instruments, not barcode scanners.)

[samuelm91]

Looks like Powershell was the answer to finally get this working natively. I still need to figure out how to force it to the background so the user isn't dealing with a popup every scan, but this solves the biggest problem I have had for some time.

Thank you both for your help.

[BertMcMahan]

So Powershell is just calling a DLL. You don't have to actually use Powershell. See this article:

https://www.ni.com/documentation/en/labview-comms/5.0/language-integration/call-net-lv-app/

(Fourth edit, kept linking the wrong article!)

Also try this one:

https://forums.ni.com/t5/Example-Code/NET-Serial-Port-Write-and-Read-Using-LabVIEW/ta-p/3514121

[samuelm91]

Unfortunately the VI provided isn't working for me, I honestly have no clue why direct methods with LabVIEW aren't working, when off platform is working fine. Hopefully my client won't have a problem with a native Windows program.

[samuelm91]

Nevermind on figuring out how to run the PowerShell script in the background. LabVIEW can do it natively from the CMD command. I really should have checked that first.

[Frozen]

This was just too strange of a problem, so I downloaded the manual for the scanner in question. I believe you missed one of the required settings for the COM port.

Page 14 of  the Simple Serial Interface document states:

The next section of the document states that RTS and CTS are used for communication since it is half-duplex.

I think if you add the flow control parameter, it should start working for you. 🤞

The scanner also uses ACK/NACK protocol.

Looking a bit farther I found this...
"Once the number of characters indicated by the host is received (plus the two bytes required for a checksum), further
characters are ignored."

Spoiler

All communications between the host and the decoder are exchanged in the form of packets. A packet is a collection
of bytes framed by the proper SSI protocol formatting bytes. The maximum length of a packet is 257 bytes,
consisting of a checksum (two bytes), a header (four bytes), and up to 251 characters of data. Note that the length
field in the header does NOT include the length of the checksum, but DOES include the length of the header itself.

Good luck and hope this helps.