LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

cDAQ-9178 Sync Digital and Analog Modules

Hi, everyone:

First time poster here.  I’m new to LabVIEW and was wondering if someone could tell me if the code I wrote is doing what it's supposed to do.

What I’m trying to do:  I have a cDAQ-9178 chassis with 5 NI modules installed in the following slots:

  1. NI 9216 (using 8 channels: RTD sensors)
  2. NI 9237 (4 channels: strain gauge)
  3. NI 9421 (8 channels digital input: relay activation and process step reading)
  4. NI 9472 (4 channels digital output: relay group select)
  5. NI 9205 (Voltage input from external instrument: DEA 288)

The NI 9472 outputs a voltage that selects one of four relay groups.  The other four modules record data.  The relays are part of a multiplexer that selects a subset of sensors.  I was asked to provide an effective sampling frequency of 10 Hz for each of the four channels.  Therefore the system runs at 40 Hz.  Ideally, I would have all 5 modules in sync, with the NI 9472 (Voltage out) leading the measurements by ~4 ms (the time it takes the relays to change states and stabilize). However, I was unable to do this.  If I put the measurement components in the relay-control loop, everything slows down to about 1 Hz.  Also, my understanding is that without the FGPA module, perfect timing of the NI 9472 is impossible (at least for what I need it to do).  Therefore, I settled on a slightly less ideal approach:

  1. Run the NI 9472 (Voltage out to relays) using the LabVIEW software at a nominal 40 Hz.
  2. Run all measurements in sync with each other (but out of sync with the 9472).  I'm currently running all four measurement modules at 2kHz and down sampling to 40 Hz using the last data point.  It seems like a waste, but I was unable to get them to all run at 40 Hz.
  3. Measure the relay voltage (using the NI 9421) so I know what relay group was actually activated in post-process.
  4. Throw away bad data points in post-processing (points that were measured while all relay groups were open, or multiple relays were closed).  So far, what I'm seeing is that about 0.5% of the time there will be two relays open at the same time.  I will throw away those data points or potentially replace them with interpolated data.

I think the attached VI achieves this goal.  However, it's hard to know if everything is doing what I think it’s doing.  So my concerns are the following:

  1. Are all four measurement modules starting at the same time?
  2. Do all four measurement modules use the same clock?
  3. Are there any other misses or bad practices in this code?
  4. Is there a way to sync the NI 9472 with the measurement modules?
  5. In general, is there a better way to approach this problem?

Thanks in advance

njspeer

0 Kudos
Message 1 of 10
(4,613 Views)

Hello njspee,

 

attached an idea, not fully tested.

  • Use for loops to make the configuration of the tasks.
  • The DO can also be controlled by the AI sample clock
  • If you are working on a windows system you do not need a timed loop.
  • The 9216 has a slow rate so the array will be filled up with the sam values.
  • The 9237 is a DSA modul and has a filter delay
best regards
Alexander
0 Kudos
Message 2 of 10
(4,489 Views)

Thanks, Duffy2007.

 

I am unable to open your VI with my copy of LabVIEW 2015.  Is there anyway to save it as an older version?

 

Thanks,

njspeer

0 Kudos
Message 3 of 10
(4,474 Views)

Hello njspeer 

best regards
Alexander
0 Kudos
Message 4 of 10
(4,469 Views)

Thank you very much, Alexander.

 

I'm still trying to make sense of your VI.  

 

I was unaware of the 9237 input delay.  Thanks for bringing that to my attention.  I have a few (maybe nieve) questions.  My first question is regarding the synchronization: My understanding is that in your VI the 9205, 9216, 9472 and 9216 are all using the ai sample clock, but the 9237 is using its internal clock.  If that is correct, is there any way to get the 9237 on the same clock?  This application needs to be able to run for a long time without any drift.

 

Thanks,

Nathan

 

0 Kudos
Message 5 of 10
(4,442 Views)

Hello njspeer ,

 

i have added a property so the 9237 clock should be used from the other moduls. I think this i correct, but i never tested it over a long time.

best regards
Alexander
0 Kudos
Message 6 of 10
(4,435 Views)

Thanks for the help, Alexander.

 

Your example made me aware of several things I had missed.  I’ve implemented most of the differences from your code.  I still have a couple questions:

  1. In your code you explicitly make the 9205 and 9216 use the 9237’s sample clock using property nodes. However, the DI and DO appear to be using the 9188's AI sample Clock.  In my code, I used a property node to force the DI to also use the 9237’s clock, the same way you did it for the 9205 and 9216.  Is there any reason I shouldn’t do it this way?  I need all measurements to be synchronized.
  2. I cannot get the DO NI9472 to run on the same loop as the input modules. Everything I try, the output frequency drops to about 1 Hz.  I tried using the DAQmx Write/RegenMode/Do Not Allow Regeneration, but that does not seem to help.
  3. Also, in your code, for the NI 9472, you have a sample clock in your task. In my code, I do not use one.  Since the timing is controlled by LabVIEW, what does defining a sample clock actually do?
  4. Also, I'm confused by the 'Faktor S/Srate' term that is used to determine the number of samples per channel.  Could you please explain this term?

Thanks again,

Nathan

0 Kudos
Message 7 of 10
(4,415 Views)

Hello njspeer ,

 

1. Yes your modification is ok. The importand thing is that the 9237 has an internal clock, because it is an DSA modul with a delta sigma ADC and thats the reason, why i used this clock.

2. 3. I used the sample clock so the DO is also synchronized to the inputs.In your code the DO run asynchron to the inputs. You must set 50KHz and 1250 samples for strain and 2Khz and 50 samples for AI and DI then the loop should run with 25ms.

4. This was because the DAQmx driver makes the timing of the loop and with this i can influence the timing behaviour. Normally i use factor 1/10 example 1Khz 100 samples, then the loop runs with 100 ms and you get in every loop an array with 100 elements. You can delete this.

 

best regards
Alexander
0 Kudos
Message 8 of 10
(4,412 Views)

Thanks so much for your help, Duffy2007.

 

I was able to implement everything except getting the 9472 on the same clock.  When I try, I get buffer errors.  However, I don't think putting the 9472 on the same clock will be beneficial; since the 9472 signal still has to be generated by LabVIEW, the actual 40 Hz Boolean signal will not stay in synch— even if it were possible to sync it to an underlying 2kHz clock from the NI 9237 that the other analog modules are using, the relay group select functionality would not stay in synch.  I think the ultimate solution would have to be through the FGPA LabVIEW module, which I currently do not have.

 

Since I am measuring the relay-group voltage on the NI 9421, I can split everything up post-measurement.  The 9472 running out of sync will cause a few missing data points here and there, but should not be a huge deal.  I will either replace them with NaN or an interpolated value.

 

Attached is a copy of my final version in case anyone else wants to use it as an example.

 

Attached is my current version. 

 

Thanks,

Nathan

0 Kudos
Message 9 of 10
(4,388 Views)

Hello njspeer ,

 

please remove the wait function inside of the while loop, because the DAQmx driver makes the timing of the loop. 

Use a queue to separate the produce (DAQmx) from the consumer (File I/O, Charts, ...), if writing the file takes longer, because the file gets bigger, then the aquisition can run into an error, while the samples could not be read from the buffer.

You are using the iteration count from the while loop, this count has no overflow so it will stop at the maximum of the i32.

best regards
Alexander
0 Kudos
Message 10 of 10
(4,379 Views)