Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Seemingly Random Error with DAQMx, C#, NI-6251 PCIe

Hello everyone,

 

I've got a C# application that collects data from a NI-6251. The application is actually 3-4 years old now and have been running fine for the most part (there are problems but none related to the National Instruments/DAQMx)

 

We've recently upgraded a few of our machines to Windows 7 and I've been running into a problem on only these machines. Our XP machines that run the same exact software on the same exact hardware never encounter this problem.

 

I've seen the following errors. Restarting the software and/or computer will resolve the issue.

 

Originally I saw Error #2, then upgraded the drivers to version 9.5.  I've not seen Error 2 anynmore, only Error #1.  

 

Error 1:

MAX (Hex: 0x80040311). The client process has been disconnected from the configuration server. If the problem persists, note the steps [...] Status Code -21472207

Driver 9.5

 

Error 2:

NI Platform Services: An unknown or unexpected communcations fault occurred while attempting to rear data from or write data to a device. Task Name: Dev2AnalogInputTask. Status Code: -50401.

Driver 8.7

 

If anyone has any thoughts or questions please let me know! 

 

Thanks! 

0 Kudos
Message 1 of 39
(5,160 Views)

I would like to get some additional information to help troubleshoot the issue. What version of LabVIEW are you using and would it be possible to install DAQmx 9.6 or 9.7?

 

Jeff L
National Instruments
0 Kudos
Message 2 of 39
(5,134 Views)

Hello Jeff,

 

In this application, we're not using LabView. We're using a C# based program with the DAQMx.dll. 

 

I installed DAQMx 9.7 late yesterday and am re-running my cycle testing to see if this change had any effect. 

 

NI MAX reports the driver as 9.7.0f0. The lastest file in the .NET global assembly cache shows as 9.6.45.292. Our application reports that it is currently using the 9.6.45.292 driver. 

 

Yesterday I was able to run our test sequence for nearly 5 hours continuously without issue. However near the end of the day yesterday, it finally threw the HEX error.  

 

As I meantioned, I'm now running the 9.6.45 driver and am currently repeating the test to see where it gets me. 

 

Its interesting because I've got the same software running on all the machines, which are a mix of 7 and XP. Initially everyone had the same 8.7 driver. The 7 machines started throwing errors periodically (only when involving that analog DAQ card) so I started going through the driver update process..

 

 

 

 

 

 

0 Kudos
Message 3 of 39
(5,130 Views)

Hey JamesDean59,

 

When you repeated the test, how did it go?  Also, what .NET framework is the program using?

Jesse S.
Applications Engineer
National Instruments
0 Kudos
Message 4 of 39
(5,105 Views)

Good Morning.

 

The software is written using .NET 4.0.  

 

I was able to go much longer before hitting the error.

 

The initial test on the version 9.5 driver yielded about 305 test cycles, which was around 4.5-5 hours of runtime. 

The second test on the version 9.7 driver yielded about 600 test cycles, which was nearly 8.5 hours of run time. 

 

Now during my cycle testing I see far less errors than when the software is being using during production. They saw an average of two errors per hour or so and they maybe run 15-20 cycles in that time frame. 

 

I am not sure why that is, there is very little different that takes places between the two instances. There are maybe two or three additional calls made to the analog DAQ card when in production use.

 

I am beginning to think that perhaps I am making one to many calls to it or making them too quickly?

 

Or perhaps thats not the case, the Windows XP machines have not had any problems like this. 

 

 

0 Kudos
Message 5 of 39
(5,101 Views)

JamesDean59,

 

Is it possible that the Windows 7 machines are going to sleep and causing the error?  This could be why it appears random.  Also, is this an executable that is being shared amongst the machines or are you compiling the code on each individual machine?

Jesse S.
Applications Engineer
National Instruments
0 Kudos
Message 6 of 39
(5,085 Views)

Jesse,

 

No the machines don't sleep during the day. The do kick up a screen saver but thats about it. During my cycle tests they were up and running. 

 

The executable is compiled on my machine and then copy/pasted to the others. 

 

I'm not sure if the 9.7 drivers helped or it just was coincidence that it lasted 2x as long with the 9.5 drivers. 

 

The one Windows 7 machines, we'll call it Machine A, hasnt seen an error in a week or so however, its not been very active at all, maybe performing 3-4 tests per day as opposted to Machine B which, when in use, runs 100+ per day. 

 

I'll let Machine B run with the 9.7 drivers in production mode and see if there is improvement. 

 

 

Thanks!

-Kris

0 Kudos
Message 7 of 39
(5,079 Views)

JamesDean59,

 

Are you compiling it on an XP or Windows 7 machine?  That could be a possibility as well as to the error.  I'm sorry if it appears all I'm doing is asking questions with this.  Just trying to probe and figure out possible solutions to this.  It's definitely not a common issue.  Also, we are thinking maybe something is happening behind the scenes in Windows 7 that may be shutting down the port temporarily on one of the machines which makes it so you don't have access to that device.  This is just a guess though.

 

Another thought is maybe since you upgraded to Windows 7, you are seeing a performance increase on the inside, and with the machines that are doing 100+ tests a day, there may be some point in the program where it attempts to redo a test while a prior test is still finishing up.

Jesse S.
Applications Engineer
National Instruments
0 Kudos
Message 8 of 39
(5,068 Views)

Jesse,

 

Perfectly understandable. All the code is compiled on a Windows 7 machine and then copied off to the other Windows XP and Windows 7 machines. 

 

I was running a cycle test again today to try to duplicate the error. This time it hit on 30 cycles of testing.

 

1.PNG

 

 

Our testeing is sequential, none of it runs concurrently. Basically what one cycle of testing consists is:

 

1) powering up the device under test (analog card to a progammable power supply) and then checking voltage and current levels.

2) running the device under test and acquiring its digital output signals via the digital daq card. 

 

Step 2 has a number of smaller steps in it based on the specific device, etc so there may be multiple acqusitions that are made by the digital card. No problems with that. Working perfectly fine. 

 

In between steps 1 and all of the sub-step 2 steps are calls to turn on and off the device under tests. This involves the analog card, which, peridically, attempting to set an output voltage will result in the attached error. 

 

I've tried a number of different work-arounds.

 

My first attempt was a re-try loop within the using section of the code below. Its not pictured but I just had a simple for loop that would run 5 times, if an exception were to occur. This yielded no joy. 

Code.PNG

 

My second attempt was to encapsulate that entire SetOutput method in a try/catch with a for loop that would try to call the SetOutput method again if an excpetion occured. My logic behind this was perhaps re-instantiationg that Task would make a difference since the last one got 'disconnected from its server." I figured well maybe making a new one would get it though. 

 

That did not work either. It still disconnected and the 5 retries all failed to have any positive effect. 

 

I know that restarting the testing program will fix the problem and allow for testing to continue until the exception is hit again. So that tells me re-instantiating/resetting something resolves the issue. The question is what. 

 

 

 

0 Kudos
Message 9 of 39
(5,000 Views)

Do you have shared variables in the program?  If you do, we are thinking it might be something internal in Windows with how it handles shared variables.

 

You said that restarting the program corrects the issue?  For a possible workaround, can you code it to terminate the program and recall the program if this error occurs?  Also, by compiled code, do you mean an executable?  If it is an executable you are running, can you try just running the code from the development environment to see if this still occurs.  And are you using 32 bit or 64 bit Windows?

Jesse S.
Applications Engineer
National Instruments
0 Kudos
Message 10 of 39
(4,981 Views)