App running slower than it should be

[Capuchin]

I have an app doing continuous data acquisition, The clock rate is 5000S/s and it's taking readings every 1250 samples, so it should run at 4 fps, and does so occasionally, recently it has started to run at less than 2 fps. I can hold the mousebutton down on a control (I have tried on the intensity chart's Z axis color thingy) and it will happily run at about 10fps until it has cleared the buffer, and then 4fps once it's runnning on new data. As soon as the mousebutton is released it runs slow again. No idea why, there is no code attatched to the z-axis thing.

Any light anyone can shed on this would be appreciated, thanks.

Capuchin.

[AdamB]

Hi Capuchin,

There could be a number of reasons for the problem you are seeing, and I think the best way to get the right information to you quickly is for you to send in your VI and I'll have a look and see if there is anything specific I can see.

Thanx

AdamB

[Capuchin]

Hi Adam, thanks for the reply. It seems to be running okay currently, maybe something to do with the system running out of allocated RAM when I tried it, although I still have no idea what would cause the issue with it running fast when I hold the mouse button.

Attatched below is the VI, this is my first project so apologies for poor code. I'm still developing it so may be a few iffy bits here and there 🙂

There are a few subVIs that will be missing, but i don't think those are the problem. Theyre very simple.

[Capuchin]

It's definately something to do with the data acquisition, it runs okay when i pause that bit.

[AdamB]

Hi Capuchin,

Well looking at the code it does seem like you are doing a lot of work with the data once it has been aquired.  It may be something to do with that instead.

Assuming that you have a frame rate of 4 then you are sampling 1250 samples each time.  and then you are completing over 1250 for loops, as well as a number of loops after this, and then the file writes etc.

I'm not sure what you mean bu pause the aquisition but I'm assuming youi take out the analog reads as well as the code that this relies on?

Try just taking out the code that this relioes on.  You may find it's all the processing that is slowing you down.  I there any way of doing the analysis offline?

AdamB

[Capuchin]

Hi Adam, thanks for all your help, I think you are right that the processing was slowing it down. Sadly it is unavoidable with the data acquisition card we have, we were hoping to have a retriggerable solution, but we have the 6008 with only one PFI input. So we are having to read in the trigger line and data in analog and compare the 2 to extract the data we want. Hardly an efficient system but I can't think  of a better way to do it with the equipment. Future iterations of the project will probably use a triggerable system.

I have recently got hold of a slightly better laptop and it seems to be doing the processing 3 or 4 times faster - which seems to solve the problem for the goals of the project - although I am slightly worried if the PC will cope under heavy load (just hoping it wont be put under heavy load).

I guess it sped up when I held the mouse over a control as this forced windows to focus and allocate more processor time to LabVIEW? Sounds like typical windows to me 😉

Thanks for your time looking at this and sifting through my godawful code 🙂

Cap

[AdamB]

No problem,

It might be an idea from this point onwards to think about the Producer Consumer archetecture?

This allows you to keep the code running at the desired rate whilst queueing the data that needs to be analyed.

If you visit these links there is a bit more information about the archetecture.  It might help.

http://zone.ni.com/devzone/cda/tut/p/id/3023

http://digital.ni.com/public.nsf/websearch/DD7DBD9B10E3E537862565BC006CC2E4?OpenDocument

Regards

AdamB

[Capuchin]

Thanks for the links Adam, they are certainly interesting. However the system is a real time acquire and display of data, rather than a subsequent analysis of results. The difference being that processing needs to be performed on current data rather than on *the next set of data in the queue*.

The DAQ card (or the USB card in the PC) seems to have quite a mighty buffer built in. I think for my application, the synchronisation between data capture and external components is going to be the hardest thing. Hopefully flushing the buffer before each cycle and ensuring the system is in synch through digital triggers will be sufficient for the task.

Cap