Calling DLL function as an asynchronous task with callbacks?
Ray
Some more background: I am working on acquiring data for modal testing with a National Instruments cDAQ-9182 and NI-9233 and 9234 cards. Unfortunately, while the latest MATLAB DAQ toolbox does introduce cDAQ support, it does not support the 2 cards I use. Also, NI-DAQmx does not provide the capability to trigger off of a signal and acquire a fixed number of points before the trigger condition (a pre-trigger) natively with this card (it doesn't support any triggering off of this card). Therefore, I have used NI LabWindows CVI (a C API with built in support for DAQmx interaction) to write my own data acquisition function that meets my requirements. I then implemented it as a DLL, and am able to call it via MATLAB. The problem is that I cannot do anything else while it is waiting for a trigger, which makes writing a DAQ GUI challenging because I would have to have users stop acquisition
in order to do anything else while the program is waiting for the trigger condition.
Thanks for any advice you can offer,
Ray
Rob Purser
Are you using this device to read accelerometers? If so, try Data Acquisition Toolbox in the r2011a prerelease. We'd be extremely interested in your feedback.
However, that won't solve your pretriggering problem. To do that, or if you want to use these devices to read microphones or arbitrary voltages with IEPE excitation, there is a workaround. The Data Acquisition Toolbox provides a mechanism for advanced users to access the hardware directly from within MATLAB. I used it to write this interim NI USBTC-01 support on MATLAB central.
http://www.mathworks.com/matlabcentral/fileexchange/29707
You can use that as a reference to write the low level code you need to do what you want. In the NI documentation, the type of trigger you want to do this is called a "reference trigger"
All the best,
-Rob Purser
Mike
Thanks for posting the info on how to directly access NI DAQmx hardware through MATLAB. I was able to perform several tasks that were not previously supported by the Data Acquisition Toolbox. For example,
(1) I was successfull at controlling the IEPE excitiation source of a NI-9234 module in a USB-9162 carrier.
(2) I was successfull at interfacing with multiple NI-9233 and NI-9234 modules in a NI cDAQ-9162 chassis.
(3) And I was sucessfull at interfacing with NI PXIe-4496 boards in a NI PXIe-1082 chassis. Specifically I was able to have one task span multiple boards instead of using multiple analog input objects as is necessary with the Data Acquistion Toolbox commands.
I have had one problem though. When trying to create DAQmx event callbacks I cannot figure out how to specify the callback function in the correct format. For example, the DAQmxRegisterEveryNSampleEvents requires the 5th input to be a pointer to the callback function. I have tried to specify this using a function handle but that has not worked. It seems that a C pointer is required and I am unsure how to do this. Can you provide any guidance? Also, is their any documentation available on directly accesing DAQmx hardware within MATLAB?
One final question. The release notes for the Data Acquisition Toolbox Versions 2.18 (2011a) state the following,
"You can now directly access IEPE accelerometer measurements on a National Instruments CompactDAQ device."
Do you know what is meant by this? It appears that NI-9233 and 9234 devices are still not supported as listed under the CompactDAQ section of the support hardware list.
Thanks in advance for any help you can provide.
Mike Francisco
Ray
Thanks for your feedback. I didn't have time to look into your advice when you first posted it (I was working with a tight deadline, and had to resort to a much less elegant solution that I had done before). The advice of how to interact with DAQmx functions within MATLAB is very handy, and looks much easier to use than the ways that we've done before (using loadlibrary() with daqmx .dll files, and calling functions with calllib() ). Unfortunately, DAQmx drivers do not support reference triggering with 9234, 9233 cards to my knowledge, so this method won't completely solve my problem, but it is definitely a useful tool.
I am using the cDAQ-9182 with 9233 or 9234 cards to read accelerometers, and I am very interested in the additional capabilities introduced in the DAQ toolbox 2.18 with r2011a. The documentation of the changes is pretty vague though, as Mike pointed out. Does it now support IEPE acceleration measurements with 9233,9234 cards in cDAQ 8 slot chassis's? I know that with 9233 cards and previous versions of the data acquisition toolbox, we could already make these measurements with a single card USB carrier, and the 9234 required a simple workaround to set the coupling to AC and IEPE current on, but other than that it worked fine. What exactly are the new capabilities that this version introduces?
I haven't gotten around to installing 2011a, but it's on the to-do list. I'll post an update if I have any success.
-Ray Bond
"Rob Purser" <rob.p...@mathworks.com> wrote in message <ih9boc$3jh$1...@fred.mathworks.com>...
Ray
The capability to trigger off of the signal level using a pre-trigger is critical to my applications (such as modal impact testing), so if that isn't possible, then I'll have to stick to other ways of acquiring data. If I wanted to run a test with a modal shaker or something, this would work just fine, but that isn't the case. The session based interface seems like a good start, but doesn't look like it has all of the capabilities of the legacy data acquisition toolbox interface yet.
-Ray
Details:
I hooked up a cDAQ-9178 with 2 NI-9234 cards in place
(disregard my mentioning the cDAQ-9182, evidently I remembered the number wrong)
To that, I connected a single axis IEPE powered accelerometer to chan0 of the first card, and a tri-axis IEPE accelerometer to the second card. After initializing the session, adding channels and setting the sensitivities to 1, I placed the tri-axial accelerometer on a handheld calibration shaker, turned it on and acquired data. The data was as expected, and comparing the calculated RMS value of the acceleration of the channel in the direction of the calibration excitation to the previously known calibration, it matched.
"Ray" wrote in message <it0hv4$fe0$1...@newscl01ah.mathworks.com>...
Mike
It appears that we are trying to do the same thing, that is acquire data from IEPE enabled data acquisition hardware using a reference trigger (for impact testing) or immediate trigger (continuous acquisition) for vibration measurements. Until Rob posted the info on directly accessing NI DAQmx hardware I was always stuck with the limitations of the Data Acquisition Toolbox not supporting multiple cDAQ cards in a chassis, not supporting analog input objects that span multiple PXI boards, and not allowing control of the IEPE exciation sources. So what Rob has posted has helped me greatly!
I have also read over the documentation for the session-based interface but haven't got a chance to try it out. I also noticed that it did not mention how to create reference triggers, and as with you, if this is not supported I am unable to use it.
I am glad to hear that you were able to get NI-9234 module to work with the session-based interface. I am supprised since they are not listed as cDAQ supported hardware.
I was also wondering about what you said about the DAQmx drivers not supporting reference trigginer,
"Unfortunately, DAQmx drivers do not support reference triggering with 9234, 9233 cards to my knowledge"
Isn't it possible to create a trigger using the following command? I would have expected this to work with all deivices that used DAQmx drivers.
daq.ni.NIDAQmx.DAQmxCfgAnlgEdgeStartTrig(taskHandle,triggerSource,triggerSlope,triggerLevel)
In addition to the triggering problem, I also need to be able to have a callback execute during continuous acqusition such as when a certain number of samples are acquired. This would allow averaging of data and updating of the display with current data. I was able to do this using the legagy commands, and will most likely able to it using the session-based interface, but I haven't been able to do it using the commands for direct access to the hardware as I discussed in my first post. Do you have any suggestions?
Thanks,
Mike
Ray
It's good to hear that it's more than just me that needs this sort of thing; I haven't been able to find information anywhere from people with these problems but my lab has had the issue that we have tons of NI daq hardware now, but no good way of acquiring modal impact data with it, so we're stuck using older, clunky 16-bit VXI's with E1432 cards for the most part. It sounds like we're wanting to do the exact same thing. I need the callbacks for the same reason; I need to be able to look through FRF's, Force Spectrums, and Coherence plots as I acquire more averages.
You would certainly think that you could just run the trigger configuration line that you said, but you'd be wrong unfortunately. Even though the example DAQmx code in their C documentation uses that line for an acceleration acquisition example, the example code doesn't actually run without an error. Apparently, all of those trigger functions are implementing hardware triggers on-board, which the 9233/9234 do not allow. I'm 99% sure that the software triggers built in to DAQmx do not work either for these cards. I spoke with NI support engineers about the triggering issue, and they couldn't answer it and said that they would get back to me. When they did, their answer was that the example code would work as long as I remove the triggering off of the signal and instead started acquisition when I pressed a button. Thanks a lot, NI! (see text of the support message below).
I'm currently working on writing acquisition code in C with NI's labWindows CVI program, and I have my own data acquisition function with pre-trigger written and working well. I haven't gotten to implementing callbacks yet, though, although it seems straightforward. The problem is, it would be 100x easier to do the DSP that I need in MATLAB, so I'd really like if MATLAB would work for this.
-Ray
Text of NI response to question of why DAQmxCfgAnlgEdgeStartTrig in their example throws an error, and how to implement triggering with DAQmx functions:
[Quote]
I hope you are doing well today! I just wanted to follow up on our
conversation about the DAQmx software triggering in the Cont Acq Accel
Samples-Int Clk-Analog Start example. It turns out that the code is mostly
already written! The start button on the UI can function as your
"trigger", you just simply need to remove the coding aspects that has to do
with triggering. If you remove the triggering portion from your UI and its
associated code you should be able to automatically collect data when you
press the start button. You will also have to remove the lines:
DAQmxErrChk (DAQmxCfgAnlgEdgeStartTrig
(taskHandle,"Dev1/ai0",DAQmx_Val_Rising,30.0));
DAQmxErrChk (DAQmxSetAnlgEdgeStartTrigHyst(taskHandle, 10.0));
These lines set up your triggering and are unnecessary if you simply want
to start collecting data from the start. The DAQmxReadAnalogF64 is already
in your code and the way it's set up right now will read back 1000 samples
with each call.
[End Quote]
"Mike" wrote in message <itd8t0$mjj$1...@newscl01ah.mathworks.com>...
Mike
I have been down the same path as you. We also have a lot of VXI hardware which we had some sucess with using with the DAQ toolbox but it is becoming outdated and MATLAB no longer provides support for VXI devices. One thing that was nice about VXI was that one analog input object could be used to span multiple boards. And we have a lot of NI hardware that we would perfer to use with MATLAB instead of LabView.
That's too bad about the DAQmxCfgAnlgEdgeStartTrig trigger issue. It sounds like it a NI issue not MATLAB. And yeah, the help NI provided you wasn't very helpful. Hopeful it will be resolve someday.
Every year it seems that MATLAB gets very close to providing the funtionally that I need but always comes up a little short. Since we do all of our data processing and analysis in MATLAB I have would have a tough time switching to writing data acquisition code in anything else. Here's a summary of the problems I run into.
Legacy DAQ code:
- doesn't support cDAQ chassis
- doesn't support analog input objects that span multiple PXI boards
- doesn't support control of IEPE excitation source
Session-Based DAQ Interface:
- doesn't support PXI
- doesn't (appear) to support reference triggering
Direct NI Hardware DAQ Interface:
- reference triggering doesn't seem to work
- don't know how to create event callbacks
Hopefully it will all come together someday.
Mike