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

[JamesDean59]

see post below! 

[JamesDean59]

I had a reply typed up and I thought I posted it.. eviently not anyways...somehow I missed the fact that a second page was created...ha, anyway...

I might be wrong on this but in C# I don't believe there is a keyword called shared. I think the equivalent might be static.  If that's the case then yes there are a number of static variables, static methods and static classes in the program. I didn't write the software initially I was brought in a number of years after the fact. 

Essentially its built like this:

public class AutomatedTesting

{

static digital_IO = new DigitalDAQ;

static analog_IO = new AnalogDAQ;

public TestExec()

{

  //do testing stuff here

  setPSVoltage(5);

}

public static void setPSVoltage(double voltage)

{

 analog_IO.SetOutput(AOChannel.PSVoltage, voltage);  // i posted a screen shot of this method in a previous post.

}

}

Of course theres significantly more variables and items in the program but the this should give you a better idea of the basic structure.  TestExec is run in its own thread so as to not lock up the UI thread. As I mentioned earlier, the testing tasks are executed sequentially so there is no items running that would make concurrent calls to the analog daq card.

The source code for this is written/built (targeting x86 platforms with dotnet 4.0) on either my laptop (Windows 7, 64 bit) or a development machine (Windows 7, 32-bit). The new build is then copy/pasted to our production machines. 

I have run the code from the dev environment (Vs2012) and also ran into the error there. 

Hopefully this gives you a better view of whats the basic setup. 

Is there any additional information you can give me on the error that I am receiving? Any kind of background information? 

[JasoNI]

Hi JamesDean59

Which version of MAX do you have? A very similar error occurred in version 4.8, but was fixed in 5.0.

Regards,

Jason D

Applications Engineer

National Instruments

[JamesDean59]

Jason,

MAX 5.3.1f0 is on most of the machines.

Some of them have MAX 5.4.0f0. As I've been installing the 9.7 driver set on them. 

[JasoNI]

JamesDean,

Do example programs work? Does MAX have the same configuration in the Windows 7 machines as the XP? I have included a KnowledgeBase article below that details how to import and export the configuration of MAX so that you can verify the same configuration exists.

Export/Import MAX configuration: http://digital.ni.com/public.nsf/allkb/0E0D3D7C4AA8903886256B29000C9D5A

Regards,

Jason D

Applications Engineer

National Instruments

[JamesDean59]

You bring up an excellent point. I am not sure if MAX has the same configuration on the XP machines as the 7's. I'll look into that. I know that my two DAQ cards are in there..thats about all I know.

I did some additional debugging today and discovered a few things:

I found this object called "DaqSystem" which I gather provides overall control and information about the current local DAQ system.

During Normal Operations it looks something like this:

After the process has been disconnected from the server. I take that as meaning, my program has lost its connection to MAX, it looks like this:

Now when I retry my "set power supply voltage" method I am greeted by another exception, reporting that there are no analog output channels and this makes sense because we've lost connection to MAX...

So I thought I would try re-instantiating classes on various levels. Thinking, well, maybe that would re-connect us..

So far reinstantiating:

1) The task, no effect.

2) The class that contains the methods that use the NI method calls, no effect.

3) I tried issuing a reset to the card, however now that I realize I've no connection to MAX this is rather moot. 

So we've lost our connection to MAX and the only way to re-establish it is to restart the program, thus unloading the reference/assembly.. 

As far as I can tell this disconnection is random and making 100 calls or 10 calls makes no difference. On one instance, I was able to perform almost 600 test cycles (which would have at least 10 or more calls to MAX). The test cycle that the above screen shots came from only had 17 cycles. 

Since this is only occuring on Windows 7 machines. I do not think the problem is in our testing software. It must be in something "above" that. Perhaps you are onto somthing with the configurations Jason.. I'll look into that and get back to you. 

I did not bring up the XP machines myself, they were done years ago and when I installed the 7 machines I made no special changes in MAX other than installing it. Perhaps there is something that needs to be changed. 

Let me knwo if you think of anything or have any comments.

Thanks

[Deagle]

JamesDean,

I'll look into this and let you know when I find more information. I agree it looks like it may be something involving Windows specifically. Please let me know if importing the MAX Configuration proves to be useful.

[JamesDean59]

I'm working on a temporary workaround that involves re-loading the NationalInstruments.DAQmx.dll. Do you know of any way that I could force a disconnection between it and NI MAX? I'd like to (ideally) force the exception and test my workaround code. 

Thanks! 

[Deagle]

JamesDean59,

You may want to try starting/stopping the NI Configuration Manager Service. This can be done by navigating to: Start » Control Panel » Administrative Tools » Services.

[JamesDean59]

So my workaround does not quite work and I am at a loss to explain why it does not work.

Here is what I know.

1) Restarting the program resolves the disconnect error.

2) No amount of calls to the DAQMx or other National Instruments assmblies result in any positive results once the exception has been thrown. In fact, most, if not all call will throw the disconnected exception as there is nothing for the assembly to talk to.

So we need to restart the program without actually restarting the program. That is to say we need to re-load/re-initalize the National Instruments assemblies. 

Now natively C# does not support dynamic loading/unloading of assemblies. So the only way to do this is in a secondary AppDomain. Application domains provide an isolation boundary for security, reliability, and versioning, and for unloading assemblies.

I've got this part up and running. I have successfully created the new AppDomain, communicated across it and everything. I even have it being unloaded and reloaded as necessary. 

However when the disconnect exception (above) occurs. I have the testing software try 5 times to reload the secondary AppDomain and resume testing. However each time the the same exception is thrown and the software fails to conitune. A restart of the software resolves the problem. So unloading and reloading this secondary AppDomain does not re-initalize the connection to the NI Configuration service...why I do not know. 

If you can shed some light on the connection routine/scheme that would be helpful. I could try restarting the NI service, refreshing the device list in MAX (somehow) and trying to reload the secondary AppDomain...however that seems like a dirty solution to this problem.