LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

NI VISA serial data communication

Solved!
Go to solution

Hello, I am a student researcher working on creating a VI for data acquisition that uses an NI USB 6218 and a PC. We then transmit that data using an NI VISA serial driver, to a USB-attached serial interface, running at 230.4 kbps.  In the file attached to this post, the program returns an error indicating the application is not able to keep up with the hardware acquisition (Error -200279). Right now, the data is being collected continuously at a sample rate of 8 KHz, but we get the error at our desired sample rate of 12 KHz. In addition, after this VI runs for some time the obtain queue function returns an error saying that the application has run out of memory (error 2).

 

What component of the VI would be contributing to these errors? What is the maximum rate that data can be transferred using this configuration?  Is there another method we can use besides queues that will make it so that nothing overflows?  What instrumentation of our system can I use to determine why it is meeting our performance expectations?

0 Kudos
Message 1 of 9
(1,840 Views)

First, get rid of the express VI and use the DAQMx calls directly. As you have it written, you are aquiring an analog wave form and then getting a single value out of it and passing that via your queue. This will result in a software timed data aquisition. Why not read multiple samples and pass that to your other code for processing? Also, don't create the queue in every loop iteration. Obtain the queue reference outside of the loop. Why are you posting to the queue and then immediately dequeueing the value. That makes absolutely no sense. In fact, the entire use of the queue makes no sense.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
0 Kudos
Message 2 of 9
(1,827 Views)

You are likely hardware limited.

 

Physics demands that those electrons can't move faster than c. How long is your phy layer?


"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 9
(1,762 Views)

Hello Mark,

Thank you for your help, replacing the express VI with the DAQmx functions stopped all the errors from occurring. Moving the obtain queue function outside the loop also helped. However, the problem still remains that even if the frequency of data collection is set to 12kHz or higher, the serial data is still being transferred at about 8kHz. 

 

Is it possible that we could just be hardware limited, or is there another problem that we could be running into leading to us not collecting data as quickly as we need? Attached is the new VI we've been working on. Is there another way to transfer this data besides through the use of a queue?

 

Thank you for your assistance, I am new to labVIEW so any explanation helps!

0 Kudos
Message 4 of 9
(1,709 Views)

@leongz1 wrote:

Moving the obtain queue function outside the loop also helped.


Based on your example, you shouldn't even have the queue since you are just enqueuing and dequeuing immediately afterward in the same loop.

 

Your conversion to bytes also won't do what you want.  You should not be using the DAQmx Read to get a waveform.  Instead, get a 1D Array of Double.  Then use Flatten To String to convert to a string to write through the VISA Write.  There is an input on the Flatten To String to include the array size.  Make sure this is set to FALSE.

 

I would use a constant to set the number of samples to read from the DAQmx Read.  This will help with memory allocations since the allocation will only need to happen once (can reuse the same memory buffer since they are the same size).


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 5 of 9
(1,690 Views)

Why serial?  At ~230 kbaud, you're looking at a maximum serial transmission rate of about 20 kilo-BYTES/sec.  That isn't going to be enough to transmit 8-byte data acq measurements at 12 kHz.  Maybe you should be transmitting via ethernet instead of serial?

 

Further, I'd recommend you convert to a human readable ASCII format for transmission, especially when you're fairly new to this stuff.  That'll make troubleshooting much more straightforward.  For example scientific notation with 5 significant digits and delimiters between values would put you at about 12 bytes per sample.

 

With these things in place, you'd probably be limited to somewhere in the order of 1 kilo-sample/sec transmission over serial, but could go very much faster over ethernet.

 

 

-Kevin P

 

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 6 of 9
(1,676 Views)

Hello crossrulz,

You're diagram was extremely helpful, we were able to get the serial data to come in properly. However, we're still getting strange behavior for frequency of collection, everything is set to 12khz, but as you can see with the attached waveform, the data we see that the spacing between serial data is at approximately 5 kHz now or 200 microseconds. In addition, when we change the analog input, there is a 2 to 3 second delay for any changes in the output waveform shown. What could be effecting this discrepancy?

 

I appreciate the assistance.

Download All
0 Kudos
Message 7 of 9
(1,665 Views)

Hello Kevin,

Thanks for your help, for some context, we are comfortable operating with binary data over serial, and our application can work with 8 bit per sample ADC resolution. So we think that 230.4 kbps should work with a sample rate of 12 kHz. Is that a wrong assumption?

0 Kudos
Message 8 of 9
(1,664 Views)
Solution
Accepted by topic author leongz1

8 bits per sample at 12 kHz and 230.4 kbps makes sense to me.  I can't say for sure where the breaking point will be, but 50-60% of theoretical transmission rate seems reasonable to shoot for.  

 

However, your conversion from 8-byte double to 1-byte u8 should be done differently.   You need something more like:

u8 = floor( 255*(sample - min) / (max - min))

where max and min represent the configured voltage range for your A/D converter.

 

Attached are some minimal changes to your posted code to:

- do the conversion to u8 as described above

- read more samples per loop iteration to reduce overhead.  This is the likely cause of your 5 kHz speed.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 9 of 9
(1,647 Views)