LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
Jeff.F

Create vertical sequence like structure where all frames run independently and in parallel to clean up BD.

To compress the BD add a vertical sequence like structure where all frames run independently and in parallel.  As soon as inputs being used for a given frame are present, that frame executes.  I foresee some input tunnel properties where a tunnel could be assigned to one or multiple frames. Tunnel props could authorize a frame to start execution even though all data hasn't arrived at the structure.  This structure is just for visual compression in the BD.

7 Comments
RavensFan
Knight of NI

Why do you need such a structure?

 

How do the sequence structures you show now run when you have an infinite while loop in frame zero of the stacked sequence?

 

Considering how we should be trying to get away from using any stacked sequences, and only use flat sequences when necessary, I don't see how your idea helps anything other than to lead to more abuse of sequence structures, and in a way that makes it very confusing as to how it is supposed to execute.

Jeff.F
Member

It's not a sequence structure functionally.  It just looks like one (as in the attached png file in my first post.) The frames page vertically to view each parallel frame.  I would call it a Parallel structure where each frame can run or not depending on whether it's inputs are satisfied.  The objective of the structure is to compress the block diagram by placing parallel loops into a single structure.  The structure pages vertically to indicate the parallel nature of the frames.  Individual frames would start and terminate separately but the overall structure could not be exited until all frames were finished.  I am also indicating that the input tunnels could be assigned to one, multiple or all parallel frames.  This represents some function that the structure designers will need to figure out.  The tunnel assignment property would allow certain parallel frames to start execution if it's inputs were satisfied (data present) while other parallel frames were still awaiting their tunnel data to arrive.  If a given parallel frame had no tunnels assigned then it could start immediately just as any lone loop with no wires attached could.

 

I can see I missed some detail.  Thanks for the great questions.

 

JÞB
Knight of NI

"To compress the BD add a vertical sequence like structure where all frames run independently and in parallel."

 

Ummmmm.. I do not want to sound negative but...  All LabVIEW BD objects may run when all data is present.  Basic data-flow paradigm.  Are you suggesting a new structure to synchronize start?  That is a subvi with parallel loops. 

 

How would a new structure (that exposes the default multi-threading behavior NATIVE to a dataflow language) help you? 

 

How would this reduce the BDspace required for an example application?

 

OTOH: would such a construct (albiet impractical) reduce race conditions?  would it help novice LabVIEW developers transition to a dataflow paradigm?  Would this be ultimately beneficial?  Interesting discussions could be waged on each of these points.....   I do encourage the OP to bring this to the LaabVIEW forum for a chat or two.... PM me to get my attention to the thread


"Should be" isn't "Is" -Jay
tst
Knight of NI Knight of NI
Knight of NI
G-Money
NI Employee (retired)
Jeff.F
Member

@tst, Yes, the two references are pretty much exactly what I was trying to convey.  Note to self, search the subject before posting.

 

The first reference by gvholland covers the basic idea with the only difference being that the frames are vertically arranged (versus horizontially like a stacked sequence.)

 

The second reference by Mr. Marlow goes into depth about how data would be passed to specific frames and the use of InPlaceness.  I added only a method to associate a single element tunnel with one or more parallel frames.  I believe that smmarlow's array elements being passed to frames by index is superior.

 

I think at this point we can merge the two or three discussions.  Thanks for all your questions.

Jeff.F
Member