PCI-6527 initialization issue (C++)

[kovalenkov]

Hi Jeff,

There is only one issue with this. When running an application in debugger, no error occurs.

[jcarbonell]

Hi Vladimir,

It's ok that the debugger obscures the error, I just want more information about your application.

Jeff

---

@kovalenkov wrote:
Hi Jeff,

There is only one issue with this. When running an application in debugger, no error occurs.

---

[kovalenkov]

Hi Jeff!

As instructed, I set a breakpoint to a first DAQmx funciton I call. This is stack trace:
'>    Pivovarna.exe!CDioKartica::Init()  Line 2257    C++
     Pivovarna.exe!CDioNit::InitInstance()  Line 241 + 0x11    C++
     Pivovarna.exe!_AfxThreadEntry(void * pParam=0x0012f7b0)  Line 118 + 0xd    C++
     Pivovarna.exe!_threadstartex(void * ptd=0x00f3aba8)  Line 241 + 0xd    C
     kernel32.dll!7c80b50b()    
     kernel32.dll!7c8399f3()'


Hope it helps.

[David L.]

Vladimir,

In a previous post, you said that 'Thread that is the only one which uses DAQmx is started first.', but then later state 'Other threads are used either for data acquisition or data handling'. These seem contrary to each other. Is there any way you may be able to post code which i can run to reproduce the problem?

[kovalenkov]

David,

To calm your fears, other threads do not use DAQmx or NI related hardware for data aquistion. The hardware typically used by other threads are temperature sensors and water leve sensors. Data handling part only uses information, obtained from hardware, that is already stored in some variable.
Thus, I can assure you, that no other thread invokes any DAQmx calls.

As far as your question go, I know how it can be reproduced on my applicaiton. I don't know wheather this error is driven by use of MFC classes and objects or weather it is invoked using CFile object. The easiest way is to create something simillar to what I have written in previous posts in a simplier form that is. The way I see it, you need unmanaged and document based MFC application with static linking to start with. Then, you need to create two to four (depends on how exact do you want to get) classes that will be used as a thread. Then, set Initinstance method of all threads, so they will read INIT file using CFile object as described in code pasted. To one thread (to the one that you will start first) add code (after reading INIT file) that will do DAQmxResetDevice or something equally trivial. Then, in the main program start all threads suspended and resume them one by one. First thread resumed must be a thread that will use DAQmx.
That should do it.

Best regards,
Vladimir Kocjancic

Message Edited by kovalenkov on 03-12-2007 01:50 AM

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

[kovalenkov]

David,

it will take some time for me to develop a simple application that will do basically what this application does in the background. Due to lack of time, I do not have high hopes for it to be completed before next monday (March 19th).

Best regards,
Vladimir

[kovalenkov]

David,

While I develop test application that would replicate an error, could you please answer one question?
When DAQmx starts its own threads, what priority level is assigned to them?

BR, Vladimir

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

[kovalenkov]

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