Digital I/O

cancel
Showing results for 
Search instead for 
Did you mean: 

.NET Errors

I am experiencing two problems with .NET:

 

1. Error calling method Automation.BDaq.BDaqDevice.GetModule, (System.ArgumentNullException: Key cannot ne null, Parameter name: key).

2. "Constructor Node in SFC" error when calling "OptumSFCInterface".

 

Getting those errors once in every few weeks or months when trying to operate the Advantech Digital I/O (using .NET dll), or an interface for an QSL database (assembled under .NET Framework 3.0).

I am using LV2012, on Win7 and .NET Framework 4. The Applications runs under Win7 and  .NET Framework 4.

The .NET assemblies in memory, when compiling, are shown in the attached file.

 

The errors pop up without any reason that I can see.

0 Kudos
Message 1 of 7
(6,698 Views)

It sounds like you are trying to get or set a null value. I would run a some sort of function that checks to see if the value is null before sending it to the funciton that is giving you the error.

TimC
National Instruments
Applications Engineer
0 Kudos
Message 2 of 7
(6,676 Views)

It is the same reference that is used inside the application. The application runs 24/7 and it work fine. Only that once in a month or more It goes with that error.

Is there any possibility that the relevant .NET module is omitted by the Operating System?

 

My second question was about another .NET dll problem.

If I exit the application and start it again, the problem dissapears (until the next time).

 

Could it be the same answer for the two problems? Somthing to do with th OS and LV?

0 Kudos
Message 3 of 7
(6,667 Views)

Sense it runs constantly for such a long period of time without failure, I would say it’s safe to say that everything is behaving as expectedly, just that there is a small chance of this particular DLL call sometime returning a null value that messes up your program. It could have to do with the interaction between the DLL and rare corner cases of the OS, such as while scanning for a virus. Because of the rarity of the occurrence, it would be incredibly difficult to test and figure out.

TimC
National Instruments
Applications Engineer
0 Kudos
Message 4 of 7
(6,649 Views)

If it was the case, then the next call to the dll would have succeeded, but it wouldn't. The following calls fail too. Only after restarting the application the call succeed.

Since there are two .NET dlls that are loaded by the application, and the calling issue arises randomly between them, I guess it is about the OS unload the modules during the application run. If this is the case then it has something to do with the connections between LV and the OS.

0 Kudos
Message 5 of 7
(6,635 Views)

So you are saying you get this error regardless of what .NET dll you are calling?

 

Again this is a really difficult issue to troubleshoot because it takes weeks to months to run one test to see if it is giving you the same behavior.

 

I would try calling the dll from another program the same number of times at the same speed to see if you got the error, and test it on multiple machines, but that would take months.

 

Also, it would be fairly difficult for someone else to reproduce.

 

Is there a way for you to tell what is throwing the error?

TimC
National Instruments
Applications Engineer
0 Kudos
Message 6 of 7
(6,616 Views)

Let me preface this by saying that my .net expertise is limited but growing.  It sounds like your reference might be closing unexpectedly.  Can you catch the error and create a new reference with the constructor node when it happens?

 

As TimC says, it's going to be a pretty tough problem to troubleshoot because of the rarity.  Maybe you could setup another vi to close the references and try to generate the error manually.  Alternately, maybe you could set up the Visual Studio debugger to attach to LabVIEW and wait for the error.

 

Good luck!

 

James

0 Kudos
Message 7 of 7
(6,581 Views)