asynchronous multipoint acquisition with niDMM & niSwitch

[Mark_S1]

Debora,
    niDMM_ReadStatus has been in NI-DMM for several years, since at least version 2.0.  In the NI-DMM help file, under Programming with NI-DMM, you can go to either NI-DMM LabVIEW Reference or NI-DMM C/CVI/VB reference and it's under Functions/VIs -> Acquisition -> Low-Level Acquisition -> niDMM_ReadStatus.  It located in a similar hierarchy on the LabVIEW palette and the CVI Function Panel.
    NI-DMM uses NI-DAQ under the hood to control the 4060, but you'll be using NI-DMM to program the 4060 and NI-Switch to control the SCXI-1127, which will also use NI-DAQ under the hood to control the 1127. Therefore, there would be no problem to use NI-DAQmx to control the SCXI-1600 and the SCXI-1102.
    Now, whether the SCXI-1600 and SCXI-1102 will be able to do the same job as the 4060/1127 combo, I'm not sure.  What I can say, is that if they can, then there won't be a problem using NI-DMM, NI-Switch and NI-DAQmx in the same application.

Good luck,
Mark
DMM SW

[Jeff_T.]

Hi Debora,

Mark is totally right, niDMM_Read_Multipoint is a blocking function in that once it is called, the function will not return control to your program until it finishes executing.  This is appropriate for many applications but in your case (as you have already seen) your program is "blocked" for 120 seconds until all  your points are available.  

So the niDMM_Read_Multipoint function initiates acquisition, waits until all data is acquired, returns the data to your program, and then returns control to your program.  The niDMM_Initiate and niDMM_FetchMultiPoint functions give you some more flexibility with program control.  You can "initiate" or start your data acquisition and then as your hardware is taking data your processor can perform other tasks.

Now the niDMM_Fetch_Multipoint is also a blocking function so it would not be advisable to call that function unless you knew that your data was ready (otherwise program control would be "blocked" until all your data was available and you might as well have called the niDMM_Read_Multipoint function).  That is why Mark recommended that you also use niDMM_ReadStatus to check how many points you have available and tell the Fetch function to just read that many points.  There is a great CVI example called "Cont Acq & Chart Multiple Samples.prj" that uses the same structure that Mark used in his second segment of code.  This is a shipping example that should be stored in the following directory:

C:\Program Files\National Instruments\CVI80\samples\niDMM\Multi Point\Cont Acq & Chart

Now as far as using two SCXI chassis in the same system, there should be absolutely no problem doing that.  The SCXI-1600 has less accuracy than the 4060 and the SCXI-1102 offers signal conditioning benefits that the SCXI-1127 does not, but there will be no conflicts in using them in the same system.  Please feel free to ask us any further questions that you might have as you develop this application.

Best Regards,

Jeff Tipps
Applications Engineer
National Instruments

[digi]

Really thanks all of you!

As I already told you, I have an old application with NI4060+SCXI1127
(You can read something about this application in
http://digital.ni.com/worldwide/italy.nsf/webcustsol/C6D45F948EC4C9CF802570290044D0EB?OpenDocument&node=
sorry, only in italian,
or in our site (in english, but less detailed)
http://www.fielddata.it/HomeEN/esperienze/testing.asp?initlayer=2 )

I have to double this application using SCXI1600+SCXI1102, and the two "units" have to acquire "in parallel"...
so I was thinking to implement a CVI dual thread application:

• one thread for 120 channels acquisition on NI4060+SCXI1127
• one thread for 120 channels acquisition on SCXI1600+SCXI1102

Do you think that, using the program structure suggested by Mark, the slow NI4060+SCXI1127 thread will not block or slow the SCXI1600+SCXI1102 thread?

Thank you very much
Debora

[Mark_S1]

---

@digi wrote:
Do you think that, using the program structure suggested by Mark, the slow NI4060+SCXI1127 thread will not block or slow the SCXI1600+SCXI1102 thread?

---

Debora,
    Yes, that should work, but like Jeff said, niDMM_FetchMultiPoint will block just like niDMM_ReadMultiPoing if you ask for more points than are there.  So, if you use niDMM_ReadStatus to either wait until the entire acquisition is complete and fetch all points, or use niDMM_ReadStatus to see how many points are currently available and only fetch that many, then the DMM thread will play nice with other threads.  You'll want to do something similar in the NI-DAQmx thread so the call into NI-DAQmx doesn't block, but I'm not as familiar with the NI-DAQmx API to be able to tell you the actual function calls.

Good luck,
Mark
DMM SW

[Jeff_T.]

The DAQmx portion can have the same code structure as the DMM portion that Mark gave us.  We will just replace the initiate, readstatus, and fetch functions with their DAQmx equivalents.

niDMM_Initiate:                    DAQmxStartTask               
niDMM_ReadStatus:            DAQmxGetReadAvailSampPerChan
niDMM_FetchMultipoint:       DAQmxReadAnalogF64

Best Regards,

Jeff Tipps
Applications Engineer
National Instruments

[digi]

Really thank you: very precious information.

Only one doubt...
with niDMM_Fetch_Multipoint is it possible to use niSwitch_ConfigureScanList in the same way I used it together with niDMM_ReadMultiPoint?


Or, in other words: I saw that niDMM_Fetch_Multipoint is a lower level function than niDMM_ReadMultiPoint.  Is it possible to define the scanlist?

Bye
Debora

[Mark_S1]

---

@digi wrote:
Really thank you: very precious information.

Only one doubt...
with niDMM_Fetch_Multipoint is it possible to use niSwitch_ConfigureScanList in the same way I used it together with niDMM_ReadMultiPoint?


Or, in other words: I saw that niDMM_Fetch_Multipoint is a lower level function than niDMM_ReadMultiPoint.  Is it possible to define the scanlist?

Bye
Debora

---

Debora,
    There would be no problem scanning with a switch while using niDMM_FetchMultiPoint.  The trigger(s) and Volt Meter Complete will be configured exactly the same as when using niDMM_ReadMultiPoint.

Good luck,
Mark
DMM SW