Data display slow because I have too many DAQs displaying or poor coding?

[JÞB]

---

@labview12110 wrote:

Does split 1d array allow me to choose which array elements go to which graph? or how does it split them? Say i want to change somehting on the fly later, or add an option on the front panel to move inputs from one graph to another for comparison, will it allow me to do that or it splits them sequentially?

---

In that case wire the entire array to both graphs.  Then show plot legend and visible plot checkboxes! The plot names will even adapt to the Task Channel names (so you could name them as to what they really are with assigned names back in create channel .vi  (I'm slick like that)

The stacked plots are going to redraw much slower than graphs with only 1 draw area.  with that many plots updating I'd stick a defer FP updates around the write to the terminals.  And yes Dynamic data type is a real problem here replace with "Build array" if you don't follow my other advice.

[labview12110]

I really need the graphs split to easily see and group the data hence the stacked plots. Would separate plots be my only alternative to this and better my draw time?

[JÞB]

Stacked plots have to render each draw area and update them one at a time so they are slower.  HOWEVER,  the bigger issues should be addressed first to see if some performance improvement can help you.

#1 make sure none of your controlls or indicators overlap (that forces both objects to be redrawn when either is updated)  And, there are tricks about "Total bounds" that you need to respect  even a invisible lable or catpion way over there is part of the total bounds. draw a square aroud everything in the control or indicator- the cannot go through another square (there is a VI Analizer test for this if you have VIA

Next get rid of the DDTs the make the write to the terminal have to figure out what the data type really is before processing it to be drawn.  a 1D array of waveforms will process faster.

Last put a single flat sequence frame around the terminals and one error wire.  Drop invoke nodes on the error before and after the sequence frame select method FP Defer updates.  set it true before the suequence and false after.  What this does: when you write to a waveform graph terminal you start a whole series of things that eventually redraw the graph on the FP  some of those things require the UI thread and can only happen one at a time (but usully fast) its all the thread swapping going on when a buch of graphs are being updated that takes time.  that modification said go ahead and get everything ready but don't actually apply the change yet and then after all the stuff got ready we commited everything to the FP in one fell swoop.

Here is VIAs results:

Arrray and Array2 overlap (BAD! so do "Collect Data? and Data File"  the top ones (note the hits for duplicated labels)

And yup- Those DDT graphs and charts get their own VIA slapdowns as "Scalar chart updates"

[labview12110]

Last put a single flat sequence frame around the terminals and one error wire.  Drop invoke nodes on the error before and after the sequence frame select method FP Defer updates.  set it true before the suequence and false after.

Could you please explain this. I am not understaing what it is I am supposed to do. do you mean around the stuff before my while loop?

Also I have attached an updated version with everything spaced out and no repeat labels or evil dynamic data. also changed the graphs to be overlayed but it is running at the same slow speed.

[Taki1999]

How much data are you plotting on each iteration of the while loop? Is it more than makes sense for your monitor resolution?

You may get some benefit from decimating the data before plotting. Downside of that is that you can't zoom in and see all of the data.

Also, add a label for your Log Event button and consider taking that part out into a different while loop.

[JÞB]

These Mods:

But do them a bit neater than I did  [EDIT] one of those boolean constants should be a FALSE- <Face Palm>

will stop all the fighting for the UI thread that all those semi-synced writes to terminals are all clammoring to the OS for and allow the UI to update all the redraws at one time.

There is a good section in the help file that gives more detail See "Screen Display" Here  It also provides some other tips to speed up graph redrawing.

[labview12110]

that makes more sense thanks! hopefully eveyrthing speeds up now, i'll let you know in a bit.

I have access to a second laptop, would all my problems be solved if i broke up the program and put one daq as a standalone with an executable? I jsut hate doing that becasue I cannot change the program as easily that way.

[JÞB]

---

@labview12110 wrote:

that makes more sense thanks! hopefully eveyrthing speeds up now, i'll let you know in a bit.

I have access to a second laptop, would all my problems be solved if i broke up the program and put one daq as a standalone with an executable? I jsut hate doing that becasue I cannot change the program as easily that way.

---

NO!

Go re-read that help file link!  Especially the section on I/O!  Theres a few pointers in there on DAQmx.  If that doesn't give you some ideas on how to run that DAQ loop better post back.  One question to ask yourself is how often do you really need to update the FP?  Users only see about 20Hz eyeballs are very slow.

[labview12110]

---

@JÞB wrote:

---

@labview12110 wrote:

that makes more sense thanks! hopefully eveyrthing speeds up now, i'll let you know in a bit.

I have access to a second laptop, would all my problems be solved if i broke up the program and put one daq as a standalone with an executable? I jsut hate doing that becasue I cannot change the program as easily that way.

---

NO!

Go re-read that help file link!  Especially the section on I/O!  Theres a few pointers in there on DAQmx.  If that doesn't give you some ideas on how to run that DAQ loop better post back.  One question to ask yourself is how often do you really need to update the FP?  Users only see about 20Hz eyeballs are very slow.

---

I had not thought about that. I definitely need the data at a rate of at least 50Hz , but can I reduce display without interfering with the logging? It logs before going to the while loop anyway correct?

[JÞB]

You are logging waveform data anyway!  log it at 50 Hz or 5Hz or once an hour it doesn't affect the acquisition timing.  Those DAQ device buffers can store lots of samples Though probably not an hours worth and the user would get frustrated waiting for an updates beyond 200mSec or so  a 5Hz acq loop would be just fine! (Nice of me to send you back there right?)