resizing window affects data acquisition

[LVJoe]

Hi Guys, got a really annoying problem that I've been trying to solve for about 2 weeks now, I'm hoping someone will be able to help me.

We communicate through a dll to our data aquisition box (custom). Our custom data aquisition box has an array which we read in a timed loop every 20ms (although the array is present for around 50ms), once read we send a command saying that we have read the data.

Once we've read the data we put it into a queue. The logger then reads from this queue, all works fine on a normal run. However if we resize any window (not just a labview one) this seems to knock out our Timed loop. i.e. we miss 1-2 arrays worth of data (50-100ms). This is strange as we have it in a Highest priority VI running in the "Data aquisition" thread. We also do lots of other things i.e. read from a TDMS file and read/write to global variables and display data on a graph, this doesn't seems to have much of an affect on the timed loops, its just when we resize a window. Obviously we do not want to risk losing critical data, so we need a way of stopping this from happening?

Its almost as though the VI is running in the User interface thread and is a lower priority than the resize window method.

Does anyone have any ideas on how we can solve this issue?

Thanks in advance

Joe

We are collecting data at 1Khz and our Dll is thread safe and is set to "run in any thread".

Using Labview 2009f3

[Andy.G]

Hi Joe,

What sort of LabVIEW architecture are you using for this application? Producer Consumer seems it would be best for this application. Also if the data is being passed from you DAQ device via dll, windows could be prioritising other events before passing the assigned data through your dll. Have you not considered feeding the acquired data directly into LabVIEW?

[LVJoe]

Hi Andy,

Thanks for your reply.

We have to use the dll as our whole product is built around this, we used to read write via the dll when required, however, now we have now implemented streaming where data is streamed to the PC and we just take the local copy from the PC memory for efficiency. If two sections of our product needed the same data, it used to make two calls via the dll for the same data(slow), now the data is available in PC memory, which makes it a lot quicker for reading/writing due to no overheads. We give each variable in our DAQ device a decimation i.e. var1 update every 3 cycles, var2 update every 5000 cycles.

As mentioned before the DAQ device holds the data until the PC has told it that it has been read, it is a producer/consumer architecture with notification.

Is there any way of prioritizing our events over the windows ones??

Regards

Joe

[josborne]

A challenging problem, indeed!

I think your problem could be caused by a number of things.  But my first guess is the DLL.  If I recall correctly, DLLs are sometimes forced to run in the user interface thread as mentioned here: http://zone.ni.com/devzone/cda/tut/p/id/3009

Quote:

• If the node is not configured as a threadsafe call, the call is assumed to be non-threadsafe, and is run in the User Interface thread.

[tinnitus]

hello,

May be you can post part of code where acquisition is  realised  to see how loop are synchronized

and  screen shot you think code could be not optimized,

Also I ever seen graphics or property node acces completly slower down a  simple code

so resizing windows could be the exessing  drop ( not sure of translation !!!)

Regards

Tinnitus

[tinnitus]

again

You said that you use producer/consumer with notifier , in this case if you don't want to lose data

you have to be sure that producer send message to consumer slower than producer can execute

otherwise use a queue so message will stored waiting for being processed

Hope this could help

Regards

Tinnitus

[DFGray]

Are you running in Windows?  Normally, Windows prioritizes the foreground process at the expense of all background processes.  For normal use, that is desired.  For LabVIEW however, this is bad, since it prioritizes a single thread.  However, if you tell Windows to optimize for background processes, LabVIEW works much better.

1. To change this on Windows 7, right click the Computer selection in the start menu and select Properties.
2. Under Computer Name, Domain, and Workgroup Settings, click Change Settings. This will bring up the System Properties dialog.
3. Navigate to the Advanced tab and, under Performance, click the Settings button.  This brings up the Performance Options dialog.
4. Navigate to the Advanced tab and click the Background services radio button.
5. Click OK on all the dialogs to finalize.

Instructions are similar on XP and Vista.  You can start from the My Computer icon on the desktop, right click it, and select Properties, then go to step 2 above.

[LVJoe]

Hi Guys,

Thanks for all your replies. Sorry for late reply, I was out the office yesterday.

Unfortunately i can not post my source code however i have made a small mock up of how the system generally works, to give you an idea.

josbone: Our dll is classed as thread safe and we have it running as such - i thought this could be the case to start with. I presume because it is classed as "any thread" it could still be running in the UI thread though?

Tinnitus: I have attached a mock up that shows the main points in the system. I think I got a little confused on my previous reply. The DAQ holds the data there for 50ms and that is our only chance to read the data(more data comes through and our buffer can only hold 50ms worth). Which if the Timed Loop executes at 20ms should be fine.

DFGray: I got really excited reading your reply - it sounded like it was a great fix, however, unfortunately it did not work 😞

Hope the mock code helps

Regards,

Joe

[josborne]

>>I presume because it is classed as "any thread" it could still be running in the UI thread though?

Not sure if I can be of much more help regarding the threading.  But I am still suspicious that the DLL might be the cause.

Here is a technique that might help:  Begin to remove stuff from your code, and see if the problem goes away.  This will help identify the root of the problem.  For example, instead of actually calling the DLL, call a little subVI that simulates it (or just use a case/disable struct to avoid running the DLL).  It help to narrow down your search.

[DFGray]

With a 50ms window to get your data, you will always be fighting the operating system on Windows.  Have you considered doing this on RT?  Can you increase your buffer size to 200ms?  If not, there are a couple of other things you may be able to do (assuming you are running Windows).

• Get a better video card.  Hardware acceleration may solve some of the processor intensive parts of redrawing the window.  Be careful, however, since, especially in Windows Vista, the change in the driver model resulting in a lot of high-end cards not accelerating 2D drawing.  ATI cards were particularly bad at one point, although this has since been sort of fixed.  Better, in this case, means better 2D acceleration.
• Change to classic look for your Window scheme.  Turn off any aero glass or even the XP 3D look.
• Get a better processor, especially a multi-core one.  This should help reduce the processing hit to a manageable level, especially if your current processor is single core.

I noticed your code had a lot of array and variant manipulations.  You may be able to reduce this and help your data throughput, as well.  Try using LabVIEW objects instead of variants and preallocate your data instead of using build array primitives.  This may take some inventive coding, but it usually helps more than you might think.