05-03-2023 03:53 PM
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.
Solved! Go to Solution.
05-04-2023 01:31 AM
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.
05-04-2023 07:49 AM - edited 05-04-2023 07:54 AM
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.
05-07-2023 10:06 AM
Hi!
I see two issues with your code:
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.
05-07-2023 12:24 PM
I am going to try some of that. It will probably help alot.
05-10-2023 08:07 AM - edited 05-10-2023 08:18 AM
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.
05-10-2023 09:25 AM
My port configuration settings
05-10-2023 09:46 AM
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.
05-10-2023 09:52 AM
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.
05-10-2023 11:14 AM
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.