NI cDAQ unsupported module (NI-9238)

[rmp]

Hi folks,

Just received a cDAQ-9174 chassis and a NI-9238 low voltage module. I'm getting the "NI cDAQ Unsupported Module" status in Measurement & Automation Explorer for that module. It recognizes the 9174 chassis, but not the 9238 module (in slot 4). More details:

 - Labview 2010 SP1 on Dell laptop, Win10

 - Labview Run-Time 2012 SP1 15 (various earlier Run-Time versions... this 2012 is just the latest)

 - Upgraded to NI-DAQmx 9.9 because I saw a post saying this was the last version supported in LV 2010 (device driver, ADE support and Configuration upgraded), and rebooted after install, but that did not solve the problem

 - Measurement & Automation Explorer 5.6 came along with the NI-DAQmx 9.9

 - I tried moving the module to slot 1... now M&A E reports unsupported modules in both slot 1 & 4

Any ideas on how to progress?

[santo_13]

Please verify the driver version compatibility of all hardware involved, it sounds like you may need a more recent version of driver.

[rmp]

For those in the same predicament, here is what I've found so far:

 - Labview 2010 vs DAQmx versions:

    - DAQmx versions 9.1.5 - 9.9 are compatible (https://www.ni.com/content/ni/langs/en/support/documentation/compatibility/16/ni-daqmx-and-labview-c... )

 - DAQmx versions for NI-9238:

   - link to NI-9238 has lots of associated compatibility links

   - can't find info that has NI-9238 vs DAQmx versions

 - DAQmx version 9.9 (download site):

   - README file doesn't seem to have info on which hardware are supported 

[ZYOng · Accepted solution]

The first supported version in Windows 10 is LabVIEW 2015 SP1 and NI-DAQmx 15.5

According to NI-DAQmx 15.5 Readme, NI-9238 is supported.

[rmp]

Thanks so much ZYOng, I think I got lost in all of the different docs... I didn't see that.

[rolfk]

This page: https://www.ni.com/en/support/documentation/compatibility/09/software-support-for-compactrio--compac... clearly lists LabVIEW 2014 as minimum for FPGA support of the 9238 and LabVIEW 2011 for DAQmx support through NI-DAQmx 14.1.

This is because NI-DAQmx 14.1 is the first to support this module and it only can be installed in LabVIEW 2011 to LabVIEW 2014.

So your puzzle is as follows:

- 9238 requires at least NI-DAQmx 14.1 to be operable.

- NI-DAQmx 14.1 only supports to be installed into LabVIEW 2011 to 2014.

- While LabVIEW 2014 most likely would work on Windows 10 it is not officially supported.

- To use an officially supported version for Windows 10 you would need at least LabVIEW 2015 SP1.

- LabVIEW 2015 SP1 can work with NI-DAQmx 15.5 to NI-DAQmx 18.6

- If you plan to go Windows 11, more or less mandatory in a few month for anyone with an IT department managing their computers, the earliest officially supported LabVIEW version would be  LV 2022 Q3, but I have run 2020 on it although not for production code. Even a 7.1.1 installation succeeded here but nobody in his right mind would use that anymore, as great a version as it was back then.

[rmp]

Thanks Rolf,

It turns out that our LV license does allow upgrade. So, I tried installing a few different versions of LV... all with install issues until I got to LV 2020. Now, I'm finding that DAQmx 20 has installed but not the ADE and Config DAQmx support files (it kept the 9.9 versions that came with LV 2010). When I try to "Remove" the v 9.9 modules, NI Package wants to also remove some other legacy apps that we developed (just data processing apps, so not sure why they have a DAQmx ADE/Config dependency). (I suspect these app dependencies is why ADE and Config did not automatically get installed/upgraded with DAQmx module).

So, this is getting to be a rabbit hole. And, yes, Win11 is right on the horizon. It's wonderful that NI has all of these options and features, but it does significantly complicate the software management.

[rmp]

Wow, turns out that LV 2010 does seem to work with 9238 module if you have:

 - Meas & Auto Exp (MAX) v20

 - DAQmx driver v20

 - DAQmx ADE v 9.9

 - DAQmx Max Config 9.9

I'm sure it's not supported or advised, but for a simple timed voltage read app it seems to work.

[rolfk]

---

@rmp wrote:

Wow, turns out that LV 2010 does seem to work with 9238 module if you have:

 - Meas & Auto Exp (MAX) v20

 - DAQmx driver v20

 - DAQmx ADE v 9.9

 - DAQmx Max Config 9.9

I'm sure it's not supported or advised, but for a simple timed voltage read app it seems to work.

---

That's only by accident. 😁

Generally when you install a new version of DAQmx it will actively go and remove any DAQmx support from any LabVIEW installation it can find and then update the supported versions (current and previous 3 LabVIEW versions) with the new support libraries.

What has happened here most likely are two things:

1) Your DAQmx 9.9 support libraries in LabVIEW 2010 are probably so old that the DAQmx 2020 installer could not find them anymore.

2) The relevant DAQmx function APIs used, seem to not have had any incompatible changes. This is important as the DAQmx 9.9 LabVIEW support libraries now factually call into DAQmx 20.0 system driver libraries and that was of course never tested to work.

On one hand it is not very surprising as the DAQmx API is relatively stable and NI normally only extends it with new functions for new hardware but doesn't unnecessarily break backwards compatibility. However there is no guarantee and NI does not test it and there have been occasional changes in DAQmx APIs that would fatally break if called from an older version of LabVIEW VIs. So if it works it works but if you start to get weird crashes at some point, this might be the reason.

[rmp]

Thanks, I suspect you're right about your analysis. However, since attempting to manually remove the older 9.9 DAQmx component (through NI Package manager) it found and reported a dependency (another very large app that we developed many years ago... not sure rebuilding it in LV2020 would be successful, and would take much time to test), and wanted to remove that also, I wonder if the install process of 2020 DAQmx would have also reported that dependency and given me the choice to remove it... or, might it have just gone ahead and deleted the dependency... which would have been quite a "yikes" moment of discovery.

And, yes, I would not advise anyone else to accept the nonconforming, but seemingly working approach either. However, in my case it allows me to work two problems in parallel:

 - I can get a working app in the hands of a user so they can start testing efficacy of the app

 - In parallel I can work on solving the nonconformance (and Win11) issues

Thanks again for your insights.