LabVIEW
Parallel Stacked Structure
Lets start with the functionality:
- put code in a structure
- have some inputs, and some outputs to the structure
- there can be several of these structures running in parallel
- you may not want to see the code within all of the structures
Wait a minute, that sounds remarkably like a subVI 
Hi Ken,
in addition to Cory's comments:
Did you notice that LabView runs code in parallel by default? It's called dataflow 
Hi Ken,
this wasn't meant to be sarcastic. Your question just leads to that conclusion...
Anyway, there's a product suggestion page at NI.com. And there's the new Idea page to post your idea.
My personal comment:
I wouldn't use such a structure as it hides code (similar to stacked sequences). And it could break dataflow.
And there would be synchronization problems: what happens if one "frame" is finished faster than others? Will it wait until the whole structure has finished execution (changes execution order compared to have all in parallel) or should it's output get propagated earlier (breaks dataflow)?
I still opt for subvis as suggested before...
Hi Ken,
"What's wrong with hiding code..? SubVIs in a lot of cases simply hide code"
I like to see what's happening in a vi. With a stacked sequence this isn't possible. Using subvis I still see what the main vi does as I create descriptive icons and useful documentation texts.
"they're not always broken into modular statements as in other languages."
I don't get this...
xkenneth wrote:All,
Wouldn't it be nice if I had a structure that was visually arranged like the stack sequence structure but allowed every sub-diagram to execute in parallel? Perhaps my wish for this is because I'm coding incorrectly! Who knows? Let me know your thoughts.
- Ken
Without seeing your code it is hard to answer that question.
You could literally put the code from each seq fram in a unique, single frame flat seq structure. Do that for all of your frames and then literally stack them on top of each other.
The two amin draw backs I see from doing that is
1) You will only be able to see the one on the top of the pile unless you move around.
2) You will not be able to click on something to switch which frame you want to look at.
But it will do what you are asking.
So let say we don't stack them on top of each other but side by side. These will still execute in parallel but that will take up a lot of realestate. No problem, just size down the frames (shut auro-grow off) so they all fit on the screen.
This will still work but it will be a pain in the arse to edit and find code. So the first instinct would be to size them back up but there is another way of handling this. instead of using a seq frame use a sub-VI with an icon that represnts what is going on the sub-VI. Using this approach, you have everything side by side executing in parallel on the main diagram and when you want to edit something the sub-VI diagram is big enough to let you see everything.
But what if I want to use an event structure to handle the events from the GUI?
Use dynamic event registration in the sub-VI to register for the events.
What if I want to manipulate a property or update the GUI from teh sub-VI?
Use control references.
Here is a screen shot of the app I am working on today.
It has about 400 sub-VIs so far and will probably reach 600-800 before I am done. Yes I use many more techniques than I listed above.
The following is just my opinion:
A "Top Level" VI should be like a "top Level" report. It should imply the over-all concept but not get tangled up in low level details.
If you want more help from us, we do much better when we have concreate images rather than a lot of words. Post up your code and the other volunteers here ly post some tips.
Just trying to help,
Ben
