PCI-6527 initialization issue (C++)

[jcarbonell]

Hey Vladimir:

I launched a C example in the debugger, it doesn't look like there are any relevant threads (When a DAQmx task is created, it looks like some rpc threads are launched.) that could cause a problem.  Anyway, looking over this thread, you've never described what exception happens when you try to open the file after DAQmx has done something.   What is the exception that the CFile has thrown, and what is the contents of the exception data?

Jeff

---

@kovalenkov wrote:
Hi David,

I would not normally ask this as I know this is well protected information.
However, If you look at OS thread dispatcher and how it works it is quite apparent that thread priority could be an issue. For example: There are threads A, B and C. If of same priority, OS thread dispatcher would normally run each thread 33% of it's processing time. Now, let's say that thread B has higher priority than A and C. In this case, thread dispatcher would spend more time on thread B (depending on priority level) and less on A and C. As far as I know, if thread priority is set to highest (god forbids) and this is a sole thread with this priority level, it would mean that the thread is run 90% of dispatcher processing time. Real life application with highest thread priority is Windows Task Manager.
Now imagine that thread B, despite it's higher level of processing, contains a critical section, semaphore or mutex. It could quite likely happen that thread A and C would suffer from starvation. The funny thing about it is that even if thread priority would be low, and critical section, semaphore or mutex are wrongly implemented, starvation of other threads could occur. However, I believe that the later is not the case. Thus, thread priority is higher than normal.
Thread starvation would also explain, why the application works with Traditional DAQ, and why it fails to read INIT file in other threads with DAQmx. It also explain why a simple command Sleep (10) would solve this issue. In our example it would mean that thread B would be thrown out of processing queue of thread dispatcher and put into waiting queue. Meanwhile A and C could process normally. My application uses timeouts for every action any thread has to do. Thus, starvation would cause timeouts to occur.

All I am asking you is to check if this could be an issue. I do not expect an exact answer to my question, but I do need some answer, as this issue in the application should be addressed ASAP and I am far behind schedule as is. The only thing that saves me is that application runs superbly with Traditional DAQ. However, upgrade to DAQmx is inevitable.

Best regards,
Vladimir

Message Edited by kovalenkov on 03-17-2007 02:01 PM

---

[kovalenkov]

Hi Jeff,

Apparently I was way off. The exception returns CFileException::badPath. In my application, I use relative file addressing, meaning that I set file paths to '.\INIT\something.dat', rahter than 'c:\Program Files\My Application\INIT\something.dat'. Thus, no matter where the application is installed, all files will always be found.
However, I did put a code that outputs a path in the threads where INIT files don't open and I found the catch. A default working directory is set to: "c:\program files\national instruments\MAX"!!! This comes as a surprise to me, specially because in my application, I do not set working directory at all. The weird thing is that current working directory is properly set to working dir of my application in the thread that uses DAQmx, while in other threads it is set to the above.

However, knowing this doesn't change my problem. I don't want to set default working directory every time I am going to try and open a file using CFile object as this would be highly unpractical and easy to forget when impelmenting add-ons in the future.

Best regards,
Vladimir Kocjancic

Message Edited by kovalenkov on 03-20-2007 06:00 PM

[sead_suskic]

Hello Vladimir,

Given this latest information about the default working directory, can you please confirm that your application does not raise the CFileException::badPath if you put a delay before your first DAQmx call? By the way, this is really weird!!!!

What does your current workding directory print-out report from all threads when you add the delay?

[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?

I am not sure if you knew this, but National Instruments products have had some brewing experience in the past (see http://sine.ni.com/csol/cds/item/vw/p/id/413/nid/124400).

[kovalenkov]

Hi Sead!

I am glad to hear that this is a bug and that it will be fixed in the near future.

Now, regarding brewery :). It is already in production, but with Traditional drivers.
If you ever travel to Slovenia, you can taste what a fine home made brew made almost automatically by a PC (with NI-DAQ PCI-6527 DIO board) tastes like at a home brewery at Krvavi potok (that is near Italian border). Brewery is called 'Pivnica Flora'.

If you know of any brewery on the other side of the pond that would desire the technology used, please, feel free to contact me via e-mail.

Best regards,
Vladimir

Message Edited by kovalenkov on 03-21-2007 08:22 AM

[kovalenkov]

Hi Sead,

I can confirm that. And I can also explain why this happens. It is likely that at the same time as one thread calls one of DAQmx functions, other threads arrive to the point where CFile is used. Because DAQmx function is executing, the path is set to wrong value. Thus, the exception occurs. If you put Sleep infront of first call of DAQmx function, other threads already process the part with CFile and then DAQmx function is called. That is why it works with Sleep.

BR,
Vladimir

---

@sead_suskic wrote:
Hello Vladimir,

Given this latest information about the default working directory, can you please confirm that your application does not raise the CFileException::badPath if you put a delay before your first DAQmx call? By the way, this is really weird!!!!

What does your current workding directory print-out report from all threads when you add the delay?

---

[kovalenkov]

Hi everyone!

I just installed DAQmx 8.5 and it appears that this issue was not addressed. Any suggestions as to when it will be?

Best regards,
Vladimir Kocjancic

[Matthew_W]

Hi Vladmir,

 I'm sorry the issue was not addressed with the DAQmx 8.5 release. We cannot say when a particular feature will be added to future releases of NI products until they have shipped.

Best regards,

MatthewW
Applications Engineer
National Instruments