LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Question about USB CDC with LabVIEW

Solved!
Go to solution

I have a question about using a USB CDC device with LabVIEW.

I currently connect with the USB device using the VISA Serial VI's. I have a short header followed by a payload packet. The header is a fixed size and includes the message size of the payload. The payload can be up to 70000 bytes if the packet is full.

 

I am not sure I am using the right protocols with the VISA Serial VI's. Is there a better palette set that is recommended for USB CDC devices? I looked in the package manager and didn't see anything.

 

This might be a double post... I tried to post it earlier and it did not appear. If it is, apologies in advance.

0 Kudos
Message 1 of 11
(2,094 Views)
Solution
Accepted by topic author DBISI

Do you have a specific problem or is this simply a “just in case I was missing something” inquiry?

 

A USB CDC device is (should be) logically just as a RS-232 device, there are no special functions to use for your USB CDC device.

 

Your communication problem is easily solved by two VISA reads. The first reads the fixed size header, decode and verify it and use the length for the second read.

Rolf Kalbermatter
My Blog
Message 2 of 11
(2,044 Views)

Thanks for the reply.

 

I have two issues that I am dealing with, the first being speed and the second corruption.

Using the VISA, it currently take upwards of 10 seconds to transfer the full data packet.

And I keep having issues with the data not making sense when I do get it.

 

Finally, I have been fighting some sort of overrun condition that causes the USB device to actually reset (to the point you hear Windows chime as if a device was just plugged in). Whenever that happens, I have to restart LabVIEW.

 

Here is a screenshot of my current setup for the RS232. It is a lot more stable now but I still have issues with data not making sense. I open in one VI (and close at the end of it) and do all the COM in a sub VI.

 

There might be some dev issues on the other end I am fighting, I don't know yet. But I figured I would ask to see if there was anything I could do better/improve on my end.

 

Note: looking at it now I do see I am missing a valid check on my header, which I will add.

Download All
0 Kudos
Message 3 of 11
(2,026 Views)

Hi!
I see two issues with your code:

  1. The VISA read VI reads nor more than the number of bytes specified as 'byte count'. But it can return less if there's less in the buffer, for example. If you don't get the full 29 bytes of the header in a single read, it will be split, and neither the first nor the second read will contain the entire header.
  2. So you read the payload byte by byte? That will be pretty slow, and might make your buffer overrun.

As a first attempt, I'd try to read the entire data more or less at once without any processing, and check it for consistency, after.

 

Ah, and you can increase the buffer size in windows in the device manager.

Message 4 of 11
(1,974 Views)

I am going to try some of that. It will probably help alot.

0 Kudos
Message 5 of 11
(1,966 Views)

I looked in the Device manager for something I can adjust to increase the buffer size, but didn't see it. All I got was a FIFO setting that looked like it was already at it's maximum.

Not that it is a good solution as I don't want to have to do this on the final product.

 

I reworked my VISA Read (see attached), and while I am not getting the device dropout anymore, I am having two issues:

First is I am not able to read the data right away. It seems to want to wait until all the data comes in before it reads even the header, which I find odd.

2nd is I am loosing data. I have corruption. It is almost repeatable as I see the same failure in the same place, but sometimes I see other failures. I turned off Special Characters. I am not sure if there is some other setting I should probably look at.

 

Note the error loop is for a breakpoint. If it fails here, it usually fails with no reads. And the data error is on a 2nd attempt from the beginning. If I am understanding the execution correctly.

Example 3 is the VI COM Read. Example 4 is the entire write, read header, read payload process.

I don't have any errors reading the header. I only have failures reading the payload, and usually when it's really large. If it's a smaller payload it's fine.

 

BTW, I appreciate all the assistance. Thanks.

Download All
0 Kudos
Message 6 of 11
(1,928 Views)

My port configuration settings

 

0 Kudos
Message 7 of 11
(1,918 Views)

A few comments:

 

Are you sure your device uses 9800 baud? That's a very weird baudrate. Standard baudrates are 2400, 4800, 9600, 19200.

 

Your delay when trying to read the header might have to do with the so called latency setting. FTDI chip drivers all use by default a latency of 16 ms. https://www.ftdichip.com/Support/Knowledgebase/index.html?settingacustomdefaultlaten.htm

 

That can slow down your communication if you have multiple small transfers.

Rolf Kalbermatter
My Blog
Message 8 of 11
(1,912 Views)

Ah, I manually typed in 9800 out of mistake. But I have played with the Baud rate and it doesn't matter what setting it is. Even at 115200 it runs the same speed. Since it's a USB CDC device, the Baud Rate seems to be ignored. It's not an FTDI device but an ESP32-S2 device.

0 Kudos
Message 9 of 11
(1,909 Views)

Thanks for the feedback.

I think I finally figured it out. I thought I had the terminating characters disabled, but there was a second setting for ASRL End In I was unaware of that I corrected (see attached) and now I am getting a full data set with what looks like no corruption.

 

Thank you everyone for the assistance.

0 Kudos
Message 10 of 11
(1,900 Views)