how to check for board type with daqmx

[josswern]

I've just noticed new M-series boards are obviously no longer supported by traditional daq driver,
only daqmx.
as I have several programs which should be able to use e-series boards as well as the new m-series,
it seems I'll have to switch to daqmx.
as I need to check for a specific range of boards (not all are suitable), I'll have to find a
daqmx equivalent for
'Init_DA_Brds(Board, BoardType);'
which returns a board code I can check if ok for the task or not.
(it seems to me that daqmx operates from a higher abstraction level as traditional ni-daq,
hiding details of currently used hardware. but what if I need to know ?).

[bilalD]

Check out the DAQmxGetDeviceAttribute() and DAQmxGetSystemInfoAttribute() functions for information about the installed devices and other system attributes.

Hope this helps

[josswern]

ok,
thanks, that works - first check for available devices via DAQmxGetSystemInfoAttribute(),
then determine devictype with DAQmxGetDeviceAttribute() .
seems I'll have to completely rework my whole existing code, though 😞

[josswern]

just an additional note on daqmx vs. traditional ni-daq in general:

up to now I couldn't find a useful approach for dealing with pc's equipped with different hardware.
with trad. ni-daq, I used to scan the system's devices until a suitable one (detected from the board-id)
found and used this variable (boardnumber) in subsequent calls to config/measure functions.
thus, it would not affect if, e.g., the desired card was device #2 on one and device #4 on another pc.
with daqmx (daq assistant), however, the devices get 'hardcoded' into the generated tasks
(e.g. dev4 on the development-pc), and this is not 'portable' between different targe machines
(dev4 on the devel-pc might be dev1 on a target-pc).
on the other hand, I could use string variables to hold the device name and pass this to
the function generated by daq-assistant, but this breaks of course subsequent use of the assistant.
any ideas on this ?

[josswern]

update - this:

> on the other hand, I could use string variables to hold the device name and pass this to
> the function generated by daq-assistant, but this breaks of course subsequent use of the assistant.

will not work.
even worse as expected, daq-assistant stores device-names in the .mxb file which describes a task.
so the only possible workaround now seems to be to 'hack' this file (did so with a hex editor, and it worked 🙂
- even programatically, to reflect an evtl. changed device before actually activating a task.
I know, this is ugly and will probably fail at some point in the future, as it relies on undocumented
features/assumptions.
However, I can't see another way right now, to keep my programs running on any target-pc out there,
where I just can't guarantee for a specific board having a certain device-name/number.
all in all, I consider this daqmx 'feature' a major design flaw.

[bilalD]

The CVI DAQ Assistant can generate code for you and this helps to get a good idea of how to use the API and allows for quick prototyping. But you are not bound to using the Assistant only. The Assistant regenerates the configuration code anytime you change it. So your best bet might be to copy the assistant generated C code into another C file so it wont be overwritten everytime. This way, you can customize your code for your application's needs.