Startup VIs - Any pitfalls to accessing hardware at system startup?

[rowdyr]

Hi All,

We are developing a standalone machine with LabVIEW and a Windows 10 based PC. The built application VI has been moved to the startup folder so that it starts on system boot. Occasionally we have been seeing the following error messages when the application starts:

• -2147220691 The operation timed out while waiting on the configuration database to start. Visit http://ni.com/info and enter the Info Code MAXServiceNotStartingError if the problem persists.

• -2147220694 Unable to access the configuration database because an incompatible data dictionary has been detected. This error may have been caused by a recently installed component. Note the steps you performed that led to this error and contact technical support at http://ni.com/support.

Would these errors be related to accessing the hardware too soon - before the relevant NI service has started or while the service starting? We have been able to fix the problem but running NI MAX and selecting Tools->Reset Configuration Data. But then the problem will resurface days or months later.

The hardware that seems to be causing the issue is a USB-6001 and DAQmx is used as the software interface. How do you go about finding any NI services that might be required for this and can you check programatically if this service is up and running?

A while back I had a similar problem on another machine - again, an executable VI in Startup. I don't remember the error codes in that case but I was able to solve the problem but adding a 30 second delay as the very first thing in the application. That wasn't the nicest solution, so I was wanting to try something better this time.

Thanks

[rowdyr]

I had a reply from NI Support and this is what they said:

There are a lot of unknowns on this scenario.

Most likely the delay is causing the system to allow for proper rebooting of the system including the necessary registers and services. If NI services are not established then it would not be able to connect to its database which MAX Back-end database service (mnimxs.exe) takes care of.

That being said there is no fix to this as the services must run first before anything can start on the LabVIEW front.

There is no LabVIEW API to do what you wanted-check the services- but you can tap on to the .NET framework and call these from LabVIEW.

You can also reset MAX each time you run the VI and then use the library from the SystemConfig API to programmatically add/remove devices in MAX.

I'm yet to try any of these things yet but will follow up in this thread if I make progress. It's a bit of a tricky one because the error doesn't happen often. I also read somewhere that corruption of the configuration database can happen if the computer is not shut down properly. I will also check the system logs to see if this was the case.

[DerrickB]

You could also try implementing a VI to check service status via sys exec call which will likely be a bit easier than dipping into .Net: https://serverfault.com/questions/754766/show-status-of-a-windows-service-from-the-command-prompt

Though it may still be possible that devices take time after the service is available to become initialized and fully ready for use. Often our "best" answer is to add a delay to software to get past the initialization time due to inability to definitively determine when all prerequisites are ready. If you can isolate conditions for causing the corruption and it isn't just an unclean shutdown then please provide that info so it can be investigated further.

[Bob_Schor]

There is a model for something a little bit similar -- LabVIEW Real-Time systems usually have a "Real-Time" operating system (PharLap or NI Real-Time Linux) running on a PXI system (which might even be running Windows!) or a cRIO.  You develop the routine that's supposed to run "at startup" on the RT Target -- when the system restarts, the Real-Time OS starts up, does "whatever it needs to do to initialize itself and possibly its hardware", then starts your compiled code, deployed to "Run at Startup", running.

Pretend that we want to do something similar on Windows.  You build an Executable.  You want Windows to boot, do whatever it needs to do to get itself running.  Look up how to set up this Executable to "Run at Startup".  [It's pretty simple].

Some things to consider:  Windows runs a lot of things at Startup, including Virus checkers and other utilities.  You should try to figure out what your Windows system runs without telling you, and stop those that might interfere with your LabVIEW routine.  

As for ensuring it is "safe" for your Startup LabVIEW routine to run, you can start the routine off by simply putting in an additional Time Delay to make sure that the LabVIEW routine starts last.  You could also put code into your Executable to ensure that you don't lose CPU Cycles because Windows is running "something else" that you don't anticipate (keep track of both "time since our code started running" and "time we expect to have elapse since our code started running" (assuming you can accurately estimate the latter).

Bob Schor