Callback Priority

[Q?]

Is there a way to raise the priority of a callback function to "Time Critical"? I'm doing data ack with two M-Series PXI 6225 cards and need to close the processing loop to 1 msec.

[Jeffrey_P]

Thank you for contacting National Instruments!

The callback function itself doesn't really have a priority, it will inherit the priority of the application that it is running in.  I would increase the priority of the software application (CVI?, C++?, C?)

-Jeff P.

[Q?]

This is being developed in CVI. I have other less critical UI functions also. So it sounds like the applications should be set to a time critical priority with the data ack function as it's only "task". Fire another thread of lesser priority to perform the UI and other functions.

[Jeffrey_P]

That is the way that I would go!

[Q?]

In order to make some accurate timing measurements on how long it takes me to read the 160 AI channels over the two cards, I've toggle a Digital O/P high prior to the read and toggle low after the read. The Digital O/P is connected to the input of a Timer/Counter input setup to measure the pulse width.

My data ack application is setup as a DLL that starts a thread of Time Critical priority. The thread creates and configures the AI tasks. The two AI tasks are synchronized triggered on the same input signal. There is a task callback function to indicate when the AI sample has been completed. I assume the callback will run at the same time critical priority. The sample rate is 200 Hx for now.

Another application access and starts the data ack DLL with a small display panel to update the maximum pulse width recorded for the AI reads. I'm getting consistent read rates of around 400 to 500 usec while running the application in the IDE. However, when I run the .EXE directly (independent of the IDE), I get results of 6 to 15 msec, depending on whether or not I move the mouse.

Why is it running better from within the IDE?

[Jeffrey_P]

The EXE that you mentioned, is that the EXE created simply by depressing the run button, is that a true build created from within the CVI environment.  One thing that might cause the EXE to run slower than the program itself, is if the EXE was created as a debuggable EXE. This adds extra information into the program and some extra overhead to handle errors and debugging and such. 

Is this the case here?

-Jeff P.

[Jeffrey_P]

One other thing that I would try.  This issue sounds like it might be related to the build options available within CVI.  You may want to repost this question in the CVI forum, and maybe link back to this post.  The CVI users would be more savvy when it comes to the relationship between the actual program and the exe.

Just a thought! 

[Q?]

Actually solved my problem....

Had to go into the Windows SDK function calls for thread configuration and control. Just setting the thread priority to Time Critical is not good enough. The Priority Class has to be raised to. I set this to High Priority, one level down from Real Time.

Once doing that, I now get consistent read processing times of 130 usec for all 160 channels at a sampling rate of 1 kHz.

The issue of execution time in my prior post was that when I started the EXE outside of CVI, the CVI IDE was still open and was slicing time with my app. The performance issues got better once I closed CVI, but the timings were still inconsistent because I had yet to implement the solution above.