LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 

Add Frame After and Split Frame in Sequence Structure

Status: New

Currently if code is already written, it is difficult to put it into a sequence structure, splitting the code into multiple frames, without breaking wires. It would be great if when I right clicked on the edge of a sequence structure and chose "add frame after" it allowed me to draw the next frame before placing it.

 

Add-frame-after-sequence.png

 

I would also like to be able to selectively split an existing frame up

 

Split-frame-in-flat-sequence.png

 

Wouldn't this be easy and intuitive?

 

I tried to look for other ideas like this on the exchange and all I found was this but he was a little confusing in explaining his idea and how would it work. 

 

---------------------------------
[will work for kudos]
11 Comments
Knight of NI
Sorry, but personally, I would be opposed to anything that would encourage anyone to use the sequence structure. There is certainly nothing in the above example that would require it's use. I would, however, kudo a suggestion to remove it.
Trusted Enthusiast

@Dennis: Needing a single sequence frame to group code execution is inevitable - we can't get rid of the structure altogether (you may gain a minority argument on eliminating the multi-frame FSS). Other than that, I share the same sentiment.

 

It's a good Idea, and I nearly Kudoe'd it, but I maaay be able to use the feature once a month... about how often I'll drop the unavoidable FSS. And for every one time I am able to use the feature, how many of the illustration below would be created around the world? (Hey Dennis, have you ever run across this programming paradigm on the LabVIEW board? Smiley Wink )

 

FundamentalMisunderstanding.png

Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Active Participant

Of course I concede that there is no reason to use the sequence structure in the above code example. It was just the code I was working on when I thought of posting the idea I had had for a while on the idea exchange. People should undoubtedly try to avoid sequence structures (especially in labview coding example VIs).

 

That doesn't mean that making them work better is a bad thing though. I doubt preventing broken wires when adding or splitting frames would encourage anyone to use the structure when they wouldn't have otherwise.

---------------------------------
[will work for kudos]
Active Participant

Agree 100% with JackDunaway. The idea is not to encourage using sequences, is to make its edit process easier. Sometimes we have to use it, then shoud be as easier as possible. It's nonse making something hard to work with just to avoid it's use instead of teaching good programming practices.

 

The kind of comments made by Dennis Knutson make people afraid of speaking out. Eve though, like JackDunaway, I was not kudoing the idea, but I did just to support rex1030 I kudoed it!
André Manzolli

Mechanical Engineer
Certified LabVIEW Developer - CLD
LabVIEW Champion
Curitiba - PR - Brazil
Member
If there was no need for the sequencer, I would agree.  I do not like having to use it.  However, in times there are no other better alternatives to force a specific sequence,  having this feature would make it much easier to use.  Kudos!
Active Participant

Kudos here. Just an hour ago I was trying to find a bottleneck in some code and dropping tick counts all over the show. As it was pure LV code (with no error cluster) I was timing there was no easy way to add in dataflow timing. So it had to be done using sequences.

 

This was purely for debugging/understanding, and being able to do as the idea suggests would have saved me some time.

 

_________________________
All your base are belong to us.
Proven Zealot
I agree and felt the need though rarely. Definetly a helpful feature considering the ways we will follow to bring the required part into the new frame.
Trusted Enthusiast

More generic Idea that applies to all structures.

Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW
Trusted Enthusiast

I'm a few months late but Kudos! My first thought was to just move on. But after following Jack's link I kudoed the more generic idea and came back to kudo this one. If the generic idea were to be implemented it should definately include the structure that so many detest but like a a roll of duct tape can be handy at times. Especially in those situations that nrp mentions.

=====================
LabVIEW 2012


Member

Years later...

 

I think this thread should kept alive, because it is a really strong feature. This is also true for the idea Jack linked. How Manzolli noticed, there are some cases where the flat sequence is necessary and important. Otherwise the code becomes undeterministic because of race conditions. Connecting the error clusters into a line doesn't work in every situation, how you can see in the example below.

Flat_sequence_example.png

In this example the error coming out of the VI's needs to be bypassed, because the VI in the third frame must not be affected by an error. On the other hand, for synchronization issues, it has to wait until the VI's of the secon frame have finised executing.

 

 

By the way: Now it would be possible to merge the first and the second frame. Last times I applied accidently the merge to the wrong frame and saved, but going the way back was not that easy...