LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

NI-DAQmx - Multiple Channels Data Aquisition

Hi guys, this is my first post and it's a little bit long so i would really appreciate any help in any part of it.

I am currently working on a datalogging project for my thesis with a company, but i've had some issues that i can't seem to find their solutions on the forum or anywhere else tbh.

 

I am using: DAQ NI-6361 Drivers & CB-68LP Terminal Block & Labview 2020 & Differential Mode Configuration. The code is attached below.

NOTE: The software is full of additive stuff, just ignore them and don't let them distract you from the point.

 

What i am trying to do is to be able to record voltage data from 8 Channels (Precisely: 100 Samples Per Second Per Channel).

 

The problems i am facing:

 

1. Ghosting: When i try to read data from 1 Channel, the readings are perfectly fine and accurate. But when i start reading from multiple channels, i always face a "Ghosting" issue, and extra voltage is always reflected on the channel that follows the connected one.

(Say i physically connect voltage to the channels in order as follows:

Ch.1 : 10 V

Ch.2 : 0 V

Ch.3 : 0 V

Ch.4 : 10 V

Ch.5 : 10 V

Ch.6 : 0 V

Ch.7 : 0 V

Ch.8 : 0 V

,but the software reads:

Ch.1 : 9.93 V

Ch.2 : 61 mV

Ch.3 : 1 mV

Ch.4 : 9.93 V

Ch.5 : 10.06 V

Ch.6 : 61 mV

Ch.7 : 1 mV

Ch.8 : 0 mV)

 

How can i eliminate these reflected values of 60mV? (NOTE: They are not always 60mV, it depends on the supplied voltage of the channel before)

I double checked the devices/wires/drivers/chassis, and replaced each one of them with new ones individually, but didn't affect a thing.

I read about using Virtual Dummies from the NI-MAX, and it reduced the settling time of the MUX and the ghosting values got lowered from 60mV to 42mV ,but still, didn't eliminate the issue.

Any note, comment is appreciated.

 

2. Sampling Error: So i mentioned that we need to sample 100 Samples per Second per Channel. And in the software i have a DAQmxTiming.vi and the DAQmxRead.vi, I am having a really hard time trying to match between the Clock Rate, Clock Samples/Channel, and Read Samples/Channel.

Apparently if i set both the Samples/Channel of the Clock and the Read to -let's say- 10, and the Clock Rate to 100, i get 10 Samples per Second per Channel.

In other words, the Samples/Sec/Chan value = Clock Rate / SamplesPerSec. 

But whenever i try to manipulate those values to achieve 100 Samples/Sec/Chan, the software always gives this error after a some time of aquiring data: 

Error -200279: Unable to Keep Up with Acquisition in DAQmx.

Anyone has an idea how i can achieve this? 100Samples per Sec per Channel.

 

Your help is highly appreciated guys! Thanks all.

 

0 Kudos
Message 1 of 13
(826 Views)

1. Ghosting

What are the sources of these signals?  If they have a high output impedance, you will want to add some buffer circuits.  Op-amps in voltage follower configuration work very well for this application (output of the op-amp is a low impedance, allowing the DAQ hold circuit to discharge easier, helping with the ghosting effect).

 

2. Sample Rate

You want to continuously acquire data at a 100Hz rate.  So set the sample rate to 100.  Because you are acquiring continuously, DO NOT wire up the "Samples Per Channel" on the DAQmx Timing VI.  You are just limiting the DAQmx buffer and any slow down will cause you to get a buffer overrun error.

 

You could also be running into a loop rate issue due to all kinds of analysis, formatting, and building an array.  You should consider using a Producer/Consumer setup to allow a parallel loop to do the work and avoid falling behind for the DAQ.

 

You should also avoid building up a large array for logging your data.  Try logging saving the data as you acquire it.  I recommend opening/creating the file before the loop, write directly to the file inside the loop (use the Write Text File, you will have to format the data yourself), and close the file after the loop.

 

I recommend you don't worry about the Samples Per Second Per Channel.  It is 100 at this point, as set by the sample rate input on the DAQmx Timing VI.


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
Message 2 of 13
(803 Views)

Regarding your second question: Have a look at the documentation for DAQmx Timing: in continuous sampling mode the samples per channel input determines the buffer size. You want to read 100 samples per channel but your buffer can only hold 10 per channel which leads to the error message.

No idea about your first question though, sorry 😉

Message 3 of 13
(795 Views)

For problem 1. It looks like you are only driving the inputs to 10v when you say you go to 0v, are you driving it to 0v or are you just removing the 10v? 

 

For problem 2 try setting samples per channel to -1 on the read VI and the wait time in the loop to 200ms  then see if that works.

______________________________________________________________
Have a pleasant day and be sure to learn Python for success and prosperity.
Message 4 of 13
(772 Views)

Also the way you have the samples per channel linked to the sample clock vi and the read vi will not work the way you expect. because the sampel clock is outside the loop it never gets updated, so there is that. It would be good to stop the acquisition if you want to modify the sample clock then star the acquisition over. There are few good reasons not to change your sample clock timing during a test. 

______________________________________________________________
Have a pleasant day and be sure to learn Python for success and prosperity.
0 Kudos
Message 5 of 13
(765 Views)

Thank you for the conclusive reply crossrulz!

I checked the impedance of the source and it's as low as 150mOhm. So it should be within the normal range, no?

 

Regarding the sampling rate, i tried disconnecting the wires from the Timing as you suggested, and it was the best behaviour so far.

It didn't reach 100 Samples/Sec/Chan but at least it got up to 74 Samples/Sec/Chan (Which is weird because why 74? haha)

 

Either ways i will have to check the Producer/Consumer technique, but thanks alot again for your help!

0 Kudos
Message 6 of 13
(735 Views)

Hi cordm and thanks for your reply.

 

Yes i understand that i am limiting the buffer with that move but i couldn't achieve 100 Samples/Sec in any other way.

It seems like they are always divided at the end and so if i want the buffer to be able to hold 100 Samples too, the Samples/Sec readings become 1 Sample/Sec/Chan.

 

 

0 Kudos
Message 7 of 13
(733 Views)

Hi Jay14159265, and thanks for your reply.

For problem 1, yes you are right, i am only doing that to test the maximum allowed voltage for our system, if it works for 10V it should work for anything smaller i suppose.

 

And when i say 0V i mean disconnecting it, not setting it to 0V, so it's technically an open circuit.

 

For problem 2, i tried that, only difference is that the wait time made it produce 5 Samples per second instead.

0 Kudos
Message 8 of 13
(729 Views)

Yes you are right. I noticed that too, but luckily i don't have to change the timing during aquisition, so i guess it's okay(?)

0 Kudos
Message 9 of 13
(728 Views)

By the way i ran the software for 5 minutes (300Sec) setting only the sampling rate to 100, and i expected 30,000 Samples in total, but for some reason it produced only 11,000, which is about 36 Samples/Sec.

 

It seems like increasing the duration somehow lowered the number of samples and it started skipping some points(?)

Any idea why this is happening?

0 Kudos
Message 10 of 13
(723 Views)