Software error occurred in MIG software.

[Stuart_G]

Guenter

Can you elaborate a little?  You one post says "Querying the devices in the system solves the problem" but then you say "DAQmx 8.7.1 doesn't solve the issue".  Perhaps my posts were unclear.  I reread them and can see where maybe there is misunderstanding.  In all cases and all versions of DAQ you have to call one of the system or device property nodes in order to not get the error.  What I meant when I said "we fixed this is 8.7" is that pre 8.7 only doing a device reset would work.  In 8.7 and greater calling the device or system nodes will work (they didn't before).  Again we didn't fix anything in 8.7 where if you do nothing the problem doesn't exist (you must call one of the nodes).  Sorry to everyone if this was confusing.  I just saw where we filed a bug request internally to address this.  It might be difficult to fix, so I hope the workaround is acceptable.  If the workaround isn't behaving correctly in 8.7.1 let me know.

Stuart

[GuenterMueller]

Thanks for your answer, Stuart.
Sorry for any confusion. I am affected by that "Init DAQmx in a LabVIEW application that is started when the computer starts up" issue. When the computer/application starts up, one of the very first VIs that execute initialise two DAQmx tasks for Dev1 (which is a PCI-6514). It usually results in ErrorCode -229665 as mentioned in this thread several times.

I have attached a VI that initialises the DAQmx tasks as I have been doing in LV 7.0, 7.1.1 and 8.0.1 under Win2000 and WinXP (see OldStyle.zip). As I now take from your post, this just worked by accident: This code doesn't use a DAQmx System Property at startup. (Nevertheless it is running successfully on many systems ...)
Now I have moved to LV 8.5 and VistaX64 and notice that this way of initialising the DAQmx tasks is no longer working. As a workaround I use a while loop to initialise DAQmx and stay in the loop as long as an error is reported. (When starting up the PC it usually takes 45 seconds for the initilisation to complete successfully. See NewStyle.zip that contains the VI with the init loop and two screenshots how it behaves at computer startup.)


One of your answers to this thread mentioned "If you call one of the system or device properties first thing in your application we block on those waiting for the devices, channels, etc to be initialized.  We fixed this in 8.7.".
I updated to 8.7 and still got the -229665 error code on computer startup.
Then I inserted a DAQmx System Property Node and my DAQmx-Init-Loop took about 2 seconds to complete successfully.
This observation was the reason for my post on April, 10th. (I still cannot initialise DAQmx as I have been doing for years...)

For some reason the situation now has changed and the DAQmx-Init-Loop runs several times when the computer starts up. So reading a DAQmx System Property Node will not block the application until Dev1 is available. (Reason for my post on April, 30th.)  I do not have any idea why the DAQmx-Init-Loop now iterates for about 45 seconds again ...

I apologize for my threads which in fact do not point out clearly the situation I face.
To change this, I have attached the zip files.

I hope, this makes it clear. Please let me know if I missed anything. I am willing to get this "ugly" DAQmx-Init-Loop disappear from my code (or to leave it as it is if we cannot find a solution in a reasonable time frame).

Regards, Guenter

[tnek]

Hi Guenter,

I took a quick look at the code that you posted and was wondering what your end goal is for this VI. From what I can see, digital tasks are created for the first device installed in the system and then cleared. When the task is cleared, all of the configurations that were made are no longer there and all of the resources allocated for the task are released. Please let me know what you are trying to accomplish and I'll try my best to help you out.

Regards,
Kent
Applications Engineer

[GuenterMueller]

Thank you for having a look at my code, Kent.

The VI tries to initialise the PCI-6514 (which is Dev1) in my system. If I place a shortcut to the according application into the Startup folder, I can see that it takes about 45 seconds for this VI to successfully initialise DAQmx when the operating system starts up. (To illustrate how it behaves on my computer I added the screenshots from which you can take the timing that it takes to init DAQmx.)

Another VI (executed later in my application) will initialise these DAQmx tasks again. (This is the reason for the VI closing any DAQmx task was initialised succcessfully.)
So, the only purpose of the VI (with the DAQmx-Init in the loop) is to wait until Error -229665 is not(!) reported.

As already mentioned in this thread, I only need the loop when the computer starts up.
I could also wait for 60 seconds before trying to initialise DAQmx. Then no Error -229665 will appear.

Regards, Guenter

[phonoX]

Hello,

this corresponds with my experiences.

I added a 60 seconds pause after the system startup. Then it works. Restarting the program when the system is already running is no problem.

Karsten

[GuenterMueller]

Thanks for the confirmation, Karsten.  (For a while I believed that I am the only one who is affected...)
You are right: Adding a 60 seconds delay seems to reliably solve the issue.
Guenter

[Stuart_G]

Guenter

Sorry...just catching back up on this..  I have taken a look at your code now.  I want to only talk about the "new style" as I believe the old style was working for you because of chance.  I also want to ignore all the startup times and why some are taking longer than others etc.  My question is simple now that I look at your code.  When you run this loop does the DAQmx system "Dev Names" property block or not block?  Also, is there a difference if you take the device reset out of your application?   You shouldn't need to do that.  I am assuming the error you get is from the system property node.  Is that correct?  Can you verify where the actual error is happening?

Thanks

StuartG

[GuenterMueller]

Thanks for your support, Stuart.

The DAQmx system "Dev Names" property does not block. (You can take it also from the screenshot with the loop. The loop is required.)

"Also, is there a difference if you take the device reset out of your application?" -> There is no difference. The device reset came very late to the code. Sorry for me leaving it in.

"I am assuming the error you get is from the system property node.  Is that correct?  Can you verify where the actual error is happening?" -> I do not remember exactly the code's behaviour with regard to the first error (although I guess you are right). I will check this tomorrow (thoroughly) and post once again here.
Guenter

[Stuart_G]

Guenter

Thanks for persevering.  I had one of our crack experts look at this.  It does appear that we missed this particular property node.  That is what caused my confusion.  I thought all of these properties where we returned "device information" had been addressed, but it looks like we missed one (yes it does happen from time to time).  We have filed an internal bug fix for this and will try and address it soon.  Again thanks for bringing it to our attention.

StuartG

[GuenterMueller]

Thanks, Stuart. Thanks to the "crack expert", too.

So I will keep the Init-Loop in my code.

By the way:

Today, I changed the "Init Loop" to show the error code of each iteration.
Surprising: Error -2147220712 is reported.
(Bad luck: My Init-Loop did not check exactly for error code -229665 which I intended to prevent. So the loop now has been waiting for the error -2147220712 to disappear.)

I have attached a part of the desktop's screenshot (incl. a screenshot from the current DAQmx init loop that now appends the error code to an array at each iteration  and  task manager) a couple of seconds before the VI sucessfully finishes execution.
I can take from the list of running processes that a couple of "NI processes" are missing when the application attempts to initialise DAQmx.
Once these processes appear, DAQmx initialises.

Some copy and paste from LabVIEW:
Error -2147220712 occurred at an unidentified location
Possible reason(s):
(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.

I am unsure if this issue falls into the same category. Nevertheless, this thread seems to be a good place for it.

Guenter