How do I solve the error -200074 problem with DAQmx and MAX?

[KarolS]

Hi Jarrod,

I was attempting to do self-calibration on the replacement board (not any of the channels) when I had the chassis off.  The self-calibration help menu said to disconnect all inputs to the board prior to self-calibration.  I never had a chance to calibrate any of the channels. 

I have been fighting ground loops for years, so I am well aware of the problems they can cause.  I left the relative humidity sensor ungrounded when I first wired it up.  However, plugging and unplugging the sensor changed the readings on the other channels.  I was using a 25 ms gap between reading each channels to ensure sufficient settling time.  I am not an electronics person, but our electricians have generally advised me to try ungrounded first and then ground the device if the ungrounded condition causes problems.  So, for better or for worse, I grounded it to the chassis and the initial problem went away.  I've had problems trying to incorporate this sensor for years, so I'm ready to toss the relative humidity sensor and get a stand-alone data logger for it.

I will check the board with the DAQ Diagnostic Utility.  I saw that it had a link for the legacy E-series devices.  I will let you know what it turns up. 

Karol

[KarolS]

I ran the DAQ Diagnostic Utility and the board checked out ok. 

I then checked the individual channels and they functioned just fine, as did the program.  No 'resource allocation error' came up. 

As you suggested, I agree that there must be a ground loop with the relative humidity sensor.  I removed the relative humidity sensor completely from the data acquisition system and re-installed the original board with which the system had been calibrated.  The original board checked out ok.  I've got the program running and collecting data right now without errors. 

I'm confident that a ground loop with the sensor was the issue, but I'll let you know if the problem crops up again. 

Thanks for the help.

Karol

[Jarrod_B.]

Hello Karol,

I'm glad to hear that the DAQ Diagnostic Utility helped and that your boards are still in great shape.  Good luck with your application!

Best regards,

[KarolS]

Jarrod,

The -200074 error cropped up again. 

I am trying to independently collect data from 6 different machines and need the ability to start and stop data collection on each machine independently, plus I need to be able to change the data collection rate between 5 seconds and 30 minutes independently between programs.  Ken wrote a server program that collects data from all channels every second and each machine has a subservient program that collects only the data pertinent to a given machine at a user-selected rate from the data maintained by the server program.

After I removed the relative humidity sensor, the server program and sub-programs worked fine for a while.  I then purchased and installed a stand-alone data logger with an RS-232 serial port; half-duplex; 19,600 baud.  After running the installation, one of the channels monitored by the server program again had the -200074 error.  However, shutting down and restarting the computer solved the problem.  As I understand it, the data logger has an onboard memory and only dumps data when requested by the user.  I dumped data periodically and had no other problems once I rebooted the computer.

However, about a week later, the server program again had the -200074 and resource allocation errors.  Unfortunately, rebooting the computer, a complete power-down of the system, and various other attempts (including recalibration of the board) were unable to solve the problem.  The problem is usually associated with three specific channels, which I believe are the last three channels to get called in the server program).  If I try to run the server program immediately after I finish clicking through the error messages that cancel the program, I can force the same error on the other channels.  In Measurement and Automation Explorer, I get the same message the first time I test the problem tasks, but if I click test a second time, I get an accurate reading. 

I have since removed the standalone data logger and the associated software, but this has not solved my problem.  The computer is running in a stand-alone mode since Symantec Anti-Virus and Windows Updates had previously been linked with some problems. 

I hope you can help me solve this because my tests run from days to months.  These mysterious data acquisition failures have the unfortunate problem of costing time to solve and a lot of time to re-run the tests. 

Thanks,

Karol

[KarolS]

Jarrod,

I forgot to add that one of the tasks that is a problem in the server program is the previous relative humidity channel.  The server program still points to the task, even though the sensor had been removed.  It didn't seem to be a problem, although it read 99%+ humidity, which I interpreted to mean that the channel was somehow picking up a signal.  The program worked fine even with the 99%+ reading for several weeks.  The first thing I did when I couldn't get the program to work was to wire the + to - of that channel on the terminal block and the negative to the chassis ground.  The reading in MAX is now 0.0035% for that task, although it didn't solve the problem with the server program. 

Karol

[KarolS]

I tried one additional hardware switch today.  I had switched SCXI-1125 modules before and had the problem stay in slot 1.  I tried switching the terminal blocks today.  When I moved the SCXI-1313 terminal block from slot 1 to slot 2 (leaving the 1125 modules alone) and put the SCXI-1328 terminal block in slot 1 without changing the configuration to recognize the change in terminal blocks, the error initially stayed with slot one.  When I changed the configuration on slot 2 to correctly recognize the SCXI-1313 terminal block, a similar error to the one that I usually got on slot 1 with the 1313 terminal block showed up on slot 2.  The message was: 

Error -200324 occurred at Test Panel

Possible Reason(s):

Device not available in NI-DAQmx. It is possible that the device is being used by Traditional NI-DAQ or that the device is being reset.

After using a device in Traditional NI-DAQ, you must reset the device before using it in NI-DAQmx. For SCXI devices, you must reset the communicator DAQ device. Call the Traditional NI-DAQ Device Reset VI or the Init_DA_Brds function. To reset all devices in Traditional NI-DAQ, right-click the Traditional NI-DAQ Devices folder in MAX and select Reset Driver for Traditional NI-DAQ. If you are resetting the device, wait for the reset to complete.

Device: SC1Mod2

I could not find a Traditional NI-DAQ Devices folder in MAX, although we had used traditional NI-DAQ device drivers previously.  Could it be possible that I've got remnants of Traditional NI-DAQ still on the computer and that this is causing my trouble?  If so, how do I clean this up?

Karol

[Jarrod_B.]

Hello Karol,

Try going to Add or Remove Programs in the Windows Control Panel.  Select National Instruments Software and click on Change.  A dialog will come up that lists all NI software installed on your computer.  Please check to see if Traditional NI-DAQ shows up in this list.  If it does, you might want to go back to MAX and double check that this category does not show up (it should be on the same level as NI-DAQmx Devices).  If it does not show up, that is rather strange that you got that error.  Are you using Traditional NI-DAQ VIs anywhere in your application?

Best regards,

[KarolS]

It appears that the problem is with the SCXI-1313 terminal block.  With all the inputs removed, most of the channels read an increasing voltage which change as the input scaling is changed.  The guy helping me suggested that my terminal block was bad.  Before I go order one, I'd like to know if there is a way to check and see if this is correct.  I've also read some other threads on the Discussion Forum that make me wonder if maybe the SCXI-1000 chassis is bad.  I'd like to get an order in today, but I want to make sure that whatever I order solves my problem.

Karol

[Jarrod_B.]

Hello Karol,

If you disconnect your signals from the SCXI-1313 terminal block, there is no guarantee what the SCXI-1125 will read.  An increasing voltage is not an indication that the terminal block is bad.  Unfortunately at this time, we really haven't narrowed this down to the point where we know which component is causing the problem, so I couldn't recommend that you order any new devices. 

I have found a few other cases where customers have seen the error -200074 when using an SCXI-1125 with an SCXI-1313 terminal block.  While there were no solid resolutions to the issue, this was reported to R&D (CAR 3FBAUPNY) for further investigation.  Previously, though, the error seemed to be limited to configurations using an M Series DAQ board.  If you run a test panel on the SCXI-1125, when does the error occur?  Does it happen all the time, only the first time, only when you using certain settings, etc.?  Any additional information you could provide would be helpful to R&D in their investigations. 

For now, there is not much more that I can suggest.  R&D is investigating the issue, but I cannot give any timeframe on when a resolution will be reached.  If a solution or workaround is found, we will post back to this forum.  Thanks for the feedback, and I apologize for the inconvenience.

Best regards,

[KarolS]

Jarrod,

Thank you for your reply.  I was not convinced that the terminal block was faulty, so I decided not to order a replacement.

When I run a test panel in MAX on the SCXI-1125 with the SCXI-1313 module, I get an error the first time only.  If I click start again without exiting, the channel will read the correct value and remain correct until I exit. 

I found the message "SCXI-1001 Giving Erroneously Scaled Data" and several of the posts described the same problem as I've been having (so did the message "MAX configuration bug/corruption?")  In response to the first message, Logan K stated that there was a software/hardware issue with the SCXI-1313 terminal block and that it had been resolved in NI-DAQmx 8.0.  We've been running NI-DAQmx 8.3 with an E-series board, so either it wasn't exactly the same problem or the fix only worked for M-series boards.

Ken is currently cleaning up the hard drive - removing all traces of National Instruments software - and reinstalling.  I have also tried the best practice recommended by Tim Jones and colleagues in the "SCXI-1001 Giving Erroneously Scaled Data" post.  In addition, I made sure all unused channels were terminated (recommended by several other posts for getting better performance from the SCXI-1125 modules.)  Ken isn't finished with the computer yet, so I haven't been able to determine if their solution worked.  However, I suspect that it will because the positive results Ken produced in early February came after he essentially wiped out/restored the channels in MAX. 

Karol