Best way to pass an array of waveforms inbetween VIs

[CoastalMaineBird]

Occurrences have been around since LabVIEW 3, I think. Notifiers have not.

I don't know who recommended Notifiers over occurrences IN GENERAL.

All you're interested in is the fact that an update OCCURRED. When that happens, you will call the Data Source VI and ask for some channel's new data.

A notifier has a data type and carries data when it's triggered. In this case, what would you carry via the Notifier?
I suppose you could carry the whole new data array, but that's making copies of the big array again. Yuck.

I suppose you could tell the Data Source that Notifier X is now assigned to channel Y, so when updated, it could poke channel Y's data into the Notifier
. That's not too bad. You have to call the Data Source with a Notifier ID, and a channel ID, and a function of "Set Channel". Whenever the channel selector changed, you would do that again. Whenever the notifier fired, the data would be right there. I suppose that's workable.

My idea was that each window generated an occurrence upon opening. It called the Data Source with a function of NOTIFY ME, passing its occurrence.
The Data Source appends that occurrence to an internal array.
When Updated, the Data Source went thru the array and triggered every occurrence (there might be 1 window or 9 windows open).

When a window closed, it called the Data Source with a function of "STOP NOTIFYING ME", and the occurrence. The Data Source would find that occurrence and remove it from its list.

In the Window code, there would be a WAIT ON OCCURRENCE - this would wait for 500 mSec or something. If Timed out, it just checks for the DONE button or something.
If NOT timed out, it was t
riggered. So call the Data Source with the current channel number and replot the data you get back.

[AllanS]

When I aquire the data from the DAQ card will I be forced to 16 waveform data types. I have tried to simulate this by using the ExpressVI signal generator and creating 16 of them and packing them in an array slows my computer down amazingly. Is there less overhead when it is a DAQ assistant VI or should I look into converting out of the waveform data type?

[CoastalMaineBird]

I have never used Waveform type. It does nothing for me. You are not forced to use that type - the EXPRESS VIs are for speed of CODING, not speed of execution.

In the manuals for the RT (real-time) module (a project I am currently working on), it says something to the effect that you should never use any EXPRESS vis on the real-time card - they have too much overhead.

Still - I find it hard to believe that 16 signal generators would bog your computer down, unless you're running on an old Apple II.

By what are you judging that your computer has slowed down? What do you mean?

You should be (and as a newcomer perhaps you are not) aware that it
is necessary to add timing delays to loops in some situations. I have seen newbie code where someone will have a while loop waiting on a button push. That's fine, except it might eat your CPU time. Putting an indicator on the [i] variable showed that it was polling the button over 10 million times per second!! The problem with that is that the CPU is busy polling the one button, and doing nothing else. Putting a wait of 100 mSec in the loop lets somebody else use the CPU (the task that does the wait goes to sleep for 100 mSec - the CPU is available for something else), while still being reasonably responsive (100 mSec is not noticable) to the user. Perhaps you have such a situation?

In short, while I know that the waveform data type adds overhead, I would look somewhere else FIRST , for ways to solve your "slow down" problem.

Tell me how you measure the speed.

[CoastalMaineBird]

FYI:
I just measured the SIMULATE SIGNAL express VI at 628 uSec to generate the default signal (100 samples, 1000 Hz)

I just measured the SINE PATTERN vi (old standby for me) at 18 uSec (100 samples)

That's 35x speed improvement.

Maybe express IS your problem...

[AllanS]

I am about to stop working for tonite about maybe the weekend (I am burning out) but even when I dont do any signal generation just having the 8 graphs open at a time bogs my computer down.I will make sure I have at least 100ms delay in each loop. Most of my loops are event driven loops, occurence loops, or wait for front panel activity. I have noticed that when I run some of my VIs my task manager says 100% of my processor is being used. That means I must be missing something in the execution.

Never the less Ill try the things you said and get back to you by monday. I really cant thank you enough for all this. When I get good at this I will def. do the
same for other people.

[CoastalMaineBird]

My guess is you have missed something.

If the graph windows are waiting on occurrences, they should be waiting most of the time, I would think.
If you have no signal generation, then I presume you have no updates, which means the graph windows never do anything except whatever your timeout function does.

I have noticed that when I run some of my VIs my task manager says 100% of my processor is being used.
This is where you need to focus: A user-interface VI, where you're mostly waiting to see if he pushed this button or that button, should use very little of the CPU. If you're polling the buttons, do so no faster than every 100
mSec. If you're using EVENT structure, it's done for you.
If you have two or more parallel WHILE loops, remember that if one of them is blocked (waiting for button push), the other will still run. If it doesn't have a WAIT function in it, it will eat the CPU.

The basic rule is: A while loop in a CALCULATION of some sort doesn't need a delay - LabVIEW will interrupt it when necessary. A while loop in a USER INTERFACE function (waiting on user interface actions) needs to wait about 100 mSec or so to share the CPU. The EVENT structure will help you do this - it waits until one of the events happens. You don't need to poll that button 10,000,000 times in a second.

If you want to post your latest code, I'll take a look at it.

[AllanS]

Okay, I have fixxed the bogging my computer down problem. As it turnout I didnt have delays in my 8 plot VIs, I knew I had to have a delay i just threw those togeather real fast not thinking. One thing left that I have noticed that spikes my CPU usage to 100% is moving any of the front panels around by draging the title bar. This really isnt a problem but it is very very weird. I am in the process now of building what I call my data distributing VI as you described above and once I get it working will most likely add occurances as you have suggested. Thank you for all your help.

[CoastalMaineBird]

OK, the WAIT ON OCCURRENCE will solve that for you.
They have a TIMEOUT input.
Set it to 500 mSec or something, and that thread will not occupy the CPU until A) triggered, or B) timed out. You can tell the difference from the output and respond accordingly.

[AllanS]

This happens when I drag my event loop VIs and occurence loop VIs around in the same way. On my occurence loops they are all set to 500 ms for timeout times.

Its weird the faster I move these forms around the screen the more of my processor they use.

[Jeremy Braden]

If you think Coastal Marine Bird rules, be sure to give him 4 stars. The rating shows up on his profile.