PCI-6527 initialization issue (C++)

[sead_suskic]

Hello Vladimir,
 
In order to get a more complete understanding of the encountered issue, what are the exact symptoms? Namely, your first posting states that "threads can't open their initialization files" when you use any DAQmx function, while your second posting mentions a "crash". It would help to get as specific as possible.
 
Also, can you share any more details about the application to specifically add more context on how your code executes? It would be best if you could provide some source code. Namely, when you say "when I use any DAQmx function", do you mean immediately after or before the code that attempts to open the initialization file? Is this code executing in the context of a dllMain by any chance?
 
Answers to these question might help us to get to the bottom of your issue.
 
 
Regards,

[David L.]

Vladimir,




I would like to ask that you please post
simple code which I can run and reproduce this problem. This will help us
further the issue greatly.

[David L.]

Vladimir,




Any specific reason for your curiosity
of what priority level DAQmx runs at? This information is not readily
available, and I am just interested as to why this may be relevant
in helping us resolve the issue. Is there a ?bigger picture? issue I should be
knowing about?

[sead_suskic]

Vladimir,

The CFile exception and the current working directory issue allowed us to
completely narrow down the debugging avenues, and it appears that one of the
infrastructure components is causing the anomaly. Of course this is not really
news to you, because that's what you have been saying all this time, but we
actually got down to the module, the source file, and the offending function.
We will file a bug report to the responsible infrastructure group, and at this
moment I really cannot tell you when a fix might be available. One good news might
be that the fix does not necessarily have to wait for the new version of
NI-DAQmx because this particular infrastructure component is distributed by
other National Instruments applications and drivers.

For now, the sleep seems to be one way to work around the issue, but as you
might guess this might work for some systems and not others. You could also add
code that will ensure that all of your threads successfully read the
configuration data in the INI files, and then call any DAQmx functions. I regret that this bug caused this much pain, but at least now we know the scope of the issue.
By the way, now that you have at least one bug resolved, will pivovarna.exe be any closer to hitting production, and might this result in some brew exports over to this side of the pond? :smileyhappy:
I am not sure if you knew this, but National Instruments products have had some brewing experience in the past (see <a href="http://sine.ni.com/csol/cds/item/vw/p/id/413/nid/124400" target="_blank">http://sine.ni.com/csol/cds/item/vw/p/id/413/nid/124400</a>).