Measurement Studio for .NET Languages

cancel
Showing results for 
Search instead for 
Did you mean: 

System/Application startup causes error -2147220712 (and others)

I have a developed a .NET logging application (in C#) using DAQmx and an NI USB-6210 board all running under XP Pro. All works fine when the application is launched after the host PC system has been running for some time.
 
I have now put a shortcut to the application in the Startup folder so that it is launched as part of the system boot (The system is set to run the account containing the Startup folder immediately on boot). I now get the following error message.
 
NationalInstruments.DAQmx.DaqException: (Hex 0x80040318) Internal error: The client has failed to connect to the configuration server, possibly because the server is too busy or has run into a communication error. Please note the steps you performed that led to this error and contact technical support.
Status Code: -2147220712
   at nNIMSSAIL100.StatusObserverT<nNIMSSAIL100::ApiTraits<nNIMSSAIL100::DotNetApi> >.CheckWithName(StatusObserverT<nNIMSSAIL100::ApiTraits<nNIMSSAIL100::DotNetApi> >* , tCaseInsensitiveBasicString<unsigned short\,_STL::char_traits<unsigned short>\,_STL::allocator<unsigned short>\,nNIDMXS100::tLocaleConsideringWideStringComparitor\,nNIDMXS100::tLocaleConsideringWideStringCaseForcer>* pName)
   at NationalInstruments.DAQmx.DaqSystem.get_Devices()
 
i.e. it fails at the first DAQ call in the application at the statement
 
                 string[] devices = Daqsystem.Local.Devices;
 
that I'm using to determine if the hardware device I want to use exists on the system.
 
My guess is what is happening is that my application is starting before the NI configuration server and the other underpinnings of the DAQmx interface have completed their startup activity.
 
I also have to insert waits of several seconds  AFTER this call succeeds , i.e after the device I want appears in the return string from the call before I can execute calls like
 
                myTask.AddGlobalChannel(cD.globalChannelName);
 
to prevent 'resource not available' type errors from this call. Even after the device name is returned there are clearly other startup activites going on.
 
I suppose I could catch each DAQmx call exception, wait and retry until I get success all the way though this configuration stage of my application, or put a big 'worst case' delay in at the start to allow the NI code to do what it has to do, but that's a kludge at best.
 
Is there any other coding mechanism or call that I can use from my application that indicates that DAQmx and all its underpinning NI code is up and running and ready for use? 
 
Regards,
 
 
Malcolm Sharp
  
0 Kudos
Message 1 of 9
(5,521 Views)

Hi Malcolm,

It does indeed appear to be the case that you are running your application before all the NI software has booted correctly, I can't think of any particular calls that will check that all the software is up and running before starting your program. One way around this (although not so elegant) may be to install the windows server 2003 resource pack onto XP and use a batch file to start your program - forcing it to first way for a set period of time before executing?

I'm not hugely familiar with C#, however I will look into the API for DaqMX under VStudio to determine if there are any useful function calls you could use in your program to have it check/preempt issues before it starts running.

All the best,

Applications Engineer
0 Kudos
Message 2 of 9
(5,514 Views)

Rob,

Thanks for confirming what I thought, i.e. all the NI software hadn't completed initialising before I started my application. I've added a try-catch loop calling

    string [] devices = DAQsystem.Local.Devices

repeatedly with a 1 second wait until the call doesn't throw an exception. I then toop around the same call again until the device I want appears in the list and then I go into another try-catch loop until the call

    myTask.AddGlobalChannel(...);

doesn't throw an exception. From that point onwards (so far!) all the subsequent calls to the DAQmx execute without error. Elegant solution? Not!

There must be many applications of NI instruments used for unattended logging where the supporting PC system is supposed to be just switched on and the logging application starts. I find it hard to believe that I'm the first to drop a DAQmx .NET based app in the startup folder so surely this problem has cropped up before? Or is it just a problem with the newer USB devices that maybe take longer to set up than their PCI/PXI cousins?

In any event it would be good for us developers out here to know either that (a) there is a specific routine that we can call in a try-catch loop that will eventually return success when all the NI software is up and running or (b) the name of the LAST routine in the list of NI routines that gets called so we can loop on that call, checking for a success return. Maybe this can get added to the wish-list for a future release?

Thanks and regards,

Malcolm Sharp

0 Kudos
Message 3 of 9
(5,511 Views)

Hi Malcolm,

It certainly isn't the most elegant of solutions! I agree others must use programs like this to log on start up, even if not with .NET the API is the same under LabVIEW. USB devices shouldn't take much longer to find and setup, the drivers are already installed and after boot up the resource and IRQ etc will be setup under windows device manager - It may take a little longer than PCI due to the device being setup on a specific bus and resources mapped in BIOS, but not a significant amount!

I am looking through our systems now to find out if a specific routine exists for knowing when all devices are ready - I've not personally heard of one! (But that doesn't mean one doesn't exist). As soon as I find anything I will let you know, if one doesn't exist I will certainly suggest it to someone at R&D for future inclusion.

Sorry I don't have a more conclusive answer for you at this point, I will have soon hopefully!

All the best,

 

Applications Engineer
0 Kudos
Message 4 of 9
(5,508 Views)

Hi Malcolm,

I've been chatting to one of our system engineers and this appears to be the best solution for you, to continue to check if that status of the cards are ready and staying in a loop until they are ready - and then move onto the bulk of your code to work with your hardware. It appears to be the safest way to ensure everythings setup and ready to go - another option is to check the services have started and wait for a set amount of time before starting your program (you will however still want the error checking to ensure that the cards are ready to go before starting your program so this would most likely just add to your code and provide nothing useful)

Thanks,

Applications Engineer
0 Kudos
Message 5 of 9
(5,507 Views)

Rob,

Many thanks for the responses. I'm not a great believer in sticking in arbitrary delays for other threads to (hopefully) complete, so I'll continue with the 'polling for no exceptions' method for now. The problem is that to be absolutely sure I'll have to put the code for handling this exception around nearly every call to DAQmx! Ideally I'd like to have a simple single call or loop around a call that will tell me ALL the NI code is up and running on ANY NI system configuration so my application code doesn't need to worry about this and ends up being as generic as possible. I'm not convinced that simply inserting delays are the correct way to acheive this!

Anyhow I have got a work-around for the problem for now. However, if you do come across the solution (or a better solution!), or build it into a later release, please let me know.

Thanks and regards,

 

Malcolm Sharp

0 Kudos
Message 6 of 9
(5,503 Views)

Hi Malcolm,

I agree it's not the most elegant of solutions, if I find another way or should one appear in upcoming releases I will let you know!

All the best,

Applications Engineer
0 Kudos
Message 7 of 9
(5,497 Views)

Rob,

Thanks!

Malcolm

0 Kudos
Message 8 of 9
(5,495 Views)

I am having a similar issue, however, waiting for 15 mintues before starting the program with a try/catch loop does not solve the problem. I am using four computers to test the issue with windows 7: a laptop running x64, laptop running x86, desktop running x64, desktop running x86. All computers are executing the exact same build of the application, and all have the most current version of Daqmx installed. Both of the desktops don't have the issue, but both of the laptops cannot find connected devices (I am only using a USB-6008), and the following exceptions are being thrown:

 

------------------------------------------------------------------------------Exception 1

 

Exception Message:     Internal Software Error occurred in MIG software. Please contact National Instruments Support.

Task Name: _unnamedTask<0>
Status Code: -229771


Exception Source:      NationalInstruments.DAQmx


Exception Stack Trace:    at nNIMSSAIL100.StatusObserverT<nNIMSSAIL100::ApiTraits<nNIMSSAIL100::DotNetApi> >.CheckWithName(StatusObserverT<nNIMSSAIL100::ApiTraits<nNIMSSAIL100::DotNetApi> >* , tCaseInsensitiveBasicString<unsigned short\,_STL::char_traits<unsigned short>\,_STL::allocator<unsigned short>\,nNIDMXS100::tLocaleConsideringWideStringComparitor\,nNIDMXS100::tLocaleConsideringWideStringCaseForcer>* pName)
   at NationalInstruments.DAQmx.Task..ctor()


Exception Target Site: Void nNIMSSAIL100.StatusObserverT<nNIMSSAIL100::ApiTraits<nNIMSSAIL100::DotNetApi> >.CheckWithName(nNIMSSAIL100.StatusObserverT<nNIMSSAIL100::ApiTraits<nNIMSSAIL100::DotNetApi> >*, nNIDMXS100.tCaseInsensitiveBasicString<unsigned short\,_STL::char_traits<unsigned short>\,_STL::allocator<unsigned short>\,nNIDMXS100::tLocaleConsideringWideStringComparitor\,nNIDMXS100::tLocaleConsideringWideStringCaseForcer>*)

 

------------------------------------------------------------------------------Exception 2

 

Exception Message:     MAX:  (Hex 0x80040318) Internal error: The client has failed to connect to the configuration server, possibly because the server is too busy or has run into a communication error. Please note the steps you performed that led to this error and contact technical support.
Status Code: -2147220712


Exception Source:      NationalInstruments.DAQmx


Exception Stack Trace:    at nNIMSSAIL100.StatusObserverT<nNIMSSAIL100::ApiTraits<nNIMSSAIL100::DotNetApi> >.CheckWithName(StatusObserverT<nNIMSSAIL100::ApiTraits<nNIMSSAIL100::DotNetApi> >* , tCaseInsensitiveBasicString<unsigned short\,_STL::char_traits<unsigned short>\,_STL::allocator<unsigned short>\,nNIDMXS100::tLocaleConsideringWideStringComparitor\,nNIDMXS100::tLocaleConsideringWideStringCaseForcer>* pName)

Exception Target Site: Void nNIMSSAIL100.StatusObserverT<nNIMSSAIL100::ApiTraits<nNIMSSAIL100::DotNetApi> >.CheckWithName(nNIMSSAIL100.StatusObserverT<nNIMSSAIL100::ApiTraits<nNIMSSAIL100::DotNetApi> >*, nNIDMXS100.tCaseInsensitiveBasicString<unsigned short\,_STL::char_traits<unsigned short>\,_STL::allocator<unsigned short>\,nNIDMXS100::tLocaleConsideringWideStringComparitor\,nNIDMXS100::tLocaleConsideringWideStringCaseForcer>*)

 

------------------------------------------------------------------------------

 

 Also, I have noticed that both National Instruments software, as well as the application I am building require internet access permission by my firewall in order to find the devices. I have tried both enabling access for all National Instruments software and my application, as well as disabling the firewall altogether, both to no avail. On top of the present exception issue, is there any way to prevent the daqmx driver from requiring internet access by a firewall in case a user disables access and cannot figure out the cause of the problem?

 

Thank you,

Matt

0 Kudos
Message 9 of 9
(3,884 Views)