03-31-2014 12:42 PM
James,
Thank you for the update. Did you upgrade anything else on the system (.NET,service packs etc) that may have helped?
My issue may be totally unrelated since my environment and board are different (VS C++ 2008 calling NiDaq and NI 6363)
BUT the system runs for a random number of hours and then punts with:
0 NI Platform Services: An unknown or unexpected communication fault occurred while attempting to read data from or write data to a device.
Task Name: AIN
Status Code: -50401
0 MAX: (Hex 0x80040311) The client process has been disconnected from the configuration server. If this problem persists, please note the steps you performed that led to this error and contact technical support at http://ni.com/support.
Task Name: AIN
04-02-2014 08:52 AM
No .NET changes that I am aware of...I've always built against 4. Aside from standard Windows updates and NI DaqMX update (currently running 9.8) nothing has changed on that front.
I did restructure my code a bit but its hard to tell if that had any effect on theDAQMx related items.
My recommendation--for what its worth--would be to isolate the NI related code and try to execute it in a thread (or backgroundworker maybe--if possible in your application/design) so that nothing can disturb it from other aspects of your program.
I have a sneaky suspicious that something in my program was somehow, in some way, interrupting calls to the DaqMX library somehow. Just a hunch... The large majority of the program I'm workign was written years before I was hired.
07-15-2014 08:22 AM - edited 07-15-2014 08:37 AM
Hello All, I'm back on this problem and no closer to a solution.
I dug up the oldest version of our test software and have been running it in a loop. I found that it too exhibits the same proble as my latest software.
This tells me that none of the changes that I've made in the years since this programs creation have caused this error to occur.
I am going to complete another cycle of testing with this software and verifiy that I can duplicate the exception. Once that occurrs I plan on stripping it down as much as possible to just the NI related code and letting that run on loop.
Is there any logging or diagnostics that I can look at on the configuration server end? Maybe something I can look at on that end might give me some clues.
This bug appears to be popping up on an nearly an hourly basis in our one high volume production cell.
This status code is also returned:
Task Name: Dev2AnalogInputTask Status Code: -2147220719
07-16-2014 02:13 PM
Hi JamesDean59,
Since there has been some time between posts, would it be possible for us know what versions of DAQmx and the .NET Framework are installed on the Windows 7 machine you are seeing this behavior?
Also, have you reset the MAX configuration database? By following these instructions you will be able to restore MAX to a known state. Before completing the reset, please save all custom scales, DAQmx tasks, or any device configurations you have within MAX.
Regards,
Jordan G.
07-16-2014 03:33 PM
Absolutely.
The production machine is:
(Version 15 of our software)
Windows 7
DAQMx 9.8.45.42
.NET 4.0
I had my development machine pull up a very old version of the software and perform cycle testing..which also encountered the same problem.
In that instance:
(Version 1 of our software)
Windows 7
DAQMx 8.7.20.11
.NET 2.0
The developement machine also ran Version 15 which ended with the same exception in the previous posts.
I've not tried resetting the MAX configuration database. When should this be done? Why should this be done?
In either version of the software, a restart of the software resolves the problem for a short while.
My next step is to strip the older version of the software down to the bare minimum--data acqusition, measurement and a basic UI.
I am open to any thing you would like me to try. This exception gets thrown 4-6+ times per day.
Thanks!
-Kris
07-17-2014 02:14 PM
Hi Kris,
It is possible the MAX configuration database has become corrupted and by resetting the MAX configuration base this file will be removed. I would recommend resetting the MAX configuration database before simplfying your code.
Regards,
Jordan G.
07-17-2014 02:41 PM - edited 07-17-2014 02:43 PM
I'll reset the MAX configuration next time I do cycle testing. Should be tomorrow or early next week.
If the configuration is corrupted would that not result in more immediate frequenct failure? I.E everytime a call was made it would error out as the configuration was bad?
07-18-2014 05:21 PM
Hi Kris,
It could be a corruption of the database file or the file could be a strange state. By resetting the MAX configuration database we are further isolating the issue and allowing the database to possibly return to a normal state.
Regards,
Jordan G.
08-15-2014 03:00 PM
Good Afternoon all,
I thought It would mention that I've resolved this issue. I re-designed the program and forced all of the national instruments code into a sepeate execuatable. On that new executable I set up a Service Hose with named pipes bindings. In my production test application I set up ChanelFactories to connect to the service hosts and execute their calls across the named pipe. This resulted in 0 occurrances of the bug at the start of this thread.
Over the past few days I've been able to run cycle testing on my Windows 7 machine without issue. One test takes between 2 and 3 minutes depending on options selected. I would let the machine run over night and when I came in each morning it was still there running its tests.