Why Do LV7 VIs Stop Executing When I Click on the Window Title Bar?

[TimTower]

I am trying to run a deterministic VI (LV 7.0) which reads data from a DSP and displays it in a graph. The VI has to read the data within a certain time or the DSP overwrites the buffer. I find that the graph stops reading (for about .25 sec) when I click on its title bar (or that of any other VI), and I lose data. The graph is running in the Data Acquisition thread, under Time Critical Priority (the only VI in this thread and with this priority). I have tried a dual 2400 CPU (AMD) under WinXP Pro, and also a PIII-1000 single CPU under Win2000. Same result. I have also tried a bus mouse (USB and PS2) and a serial mouse (COM1) - same result. Under LabVIEWs Tools/Options, I have "Run With Multiple Threads"
checked. How can I ensure that the mouse (or keyboard, for that matter) does not stop my graph VI?

[SW]

Hide titlebar.


TimTower wrote:
> I am trying to run a deterministic VI (LV 7.0) which reads data from a
> DSP and displays it in a graph. The VI has to read the data within a
> certain time or the DSP overwrites the buffer. I find that the graph
> stops reading (for about .25 sec) when I click on its title bar (or
> that of any other VI), and I lose data. The graph is running in the
> Data Acquisition thread, under Time Critical Priority (the only VI in
> this thread and with this priority). I have tried a dual 2400 CPU
> (AMD) under WinXP Pro, and also a PIII-1000 single CPU under Win2000.
> Same result. I have also tried a bus mouse (USB and PS2) and a serial
> mouse (COM1) - same result. Under LabVIEWs Tools/Options, I have "Run
> With Multiple Threads" checked. How
can I ensure that the mouse (or
> keyboard, for that matter) does not stop my graph VI?

[BenZimmer]

Try this: separate the acquisition and display into 2 VIs, and share the data with a LV2-style global.

Use VI server to launch the acquisition VI, hiding the front panel.

Then display the data in your display VI by polling the contents of the LV2-style global.

Just curious: what hardware and software are you using to talk to the DSP?

Regards,
Ben Zimmer

[TimTower]

Hi Ben. thanks for the feedback. I will try this when i get a chance. I am talking to a Motorola 56300 Dsp in a Delta Tau Pmac Motion Controller card, (PC and ISA versions) over DPRam. I am using a DLL supplied by Delta Tau. I wrote a LV driver to poll the Pmac card and retrieve the data.

The larger issue here is, why does Win2000/XP allow the mouse to pre-emt all other operations, for a full 250 msec? Surely there is enough CPU time available to deal with a mouse click in, say, 1 msec, and then return control to the time-critical threads? Why should this happen even on a powerful dual-CPU PC? On most Plcs and Dsps on the market, it is standard practice to have deterministic loops. It is rather disappointing that Microsoft cannot implement this, given th
eir billions.

[Joe_H]

I have ran into this during other time critical data acquisitions within a loop using win2K and found that if I put a wait function in a loop with 0mS it works just fine if I move the mouse.

Sorry cannot help more

[TimTower]

Hi jhoskins. Thnaks for the feedback. I tried this, but it made no difference. My VI loops every 37 msec, and takes about 12-13 msec to read the data (2048 x i32 array). I am already using "Wait until next ms multiple" , with a value of 37 msec, to get the required loop time (which I calculatem based on the sixe of the Dsp's rotary buffer). So, when the VI has done its 12 msec read, plus about 2-3 msec data processing, it should hand control back to the OS and be idle until the 37 msec is timed out. Adding a wait (ms) with 0 as the time value would merely hand control back to the OS, which my VI is doing anyway, so I dont see how this can help. Anyway, the OS stops everything for about 250 msec when the mouse is left clicked on a titlebar
and held down - this seems to be much too long. I am still at a loss.

[dambored]

Hi

First question, is your dll call reentrant or running in the UI thread? It needs to be reentrant.

Splitting it into to seperate VI's should help. What I would try is to have one VI with one loop running in the User Interface thread waiting for a queue. Once it receives the queue update the graph.

The second VI will contain your time critical loop, running at a high priority, getting the data and putting on the queue. I would make the dll call in a VI wrapper set with a reentrant priority. I would not use wait for next multiple, instead time how long the dll call takes and subtract it from what you want you loop to run at and wait the difference. I have used this in the past for fairly time critcal operations.


Dean

[TimTower]

Hi Dean. Thanks for the ideas. The VI was not re-entrant (since it is called in only one place, and has only one data set), but I tried making it plus its subvis re-entrant, as you suggested. No difference.

FYI, I have observed that the problem only occurs within the VIs memory space - e.g. if I am running this VI uncompiled under LV, clicking on the title bar of any uncompiled VI currently open (whether running or not) causes every running VI to stop for about 250 msec. However, if I have another App running - e.g. a compiled LV App (which Windows would assign to a separate memory space), it does not stop. Similarly, if I click on this compiled VI (exe), it stops for 250 msec, but has no effect on the uncompiled VIs.


I will try splitting the VIs when I get some time, and will report back.

[dambored]

Try making the Call Library Function Node reentrant as well.

Attached is an example. Not a beautiful, but illustrated an experiment I did. With this experiment I have a delay in a loop putting the time the loop took on a queue. The other VI is graphing that time. When I click on the title bar of the graphing VI, it stops responding for a period of time, but the other loop keeps running uniterupted. I have no idea what a dll call would do.

Good luck...

[Andrey_Dmitriev]

Hi, Tim

This problem normally occured when your VI constantly switch back and forth to the user interface thread. Probably you have some VIs, functions or operations, which running in the UI thread:
- Property Nodes
- Menu Control VIs
- VI Server
- Thread Unsafe CINs or DLLs.
Be sure, that all of elements above not used in your deterministic VI, and all DLLs calls are reenterant.
Hope it help.