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: 

Both disable structures should have less effect on diagram synchronization

Status: Declined

Declined for reasons listed by AristosQueue in the comments thread. The specific comment is pasted here for convenience:

 

"So... I originally proposed this idea in 2009. In the time since then, I've been lobbied and debated by both sides. I think I have to concede the idea. It appears that structure nodes on the block diagram mentally serve as synchronization boundaries for a majority of users -- even if the job of the structure node is to comment out code. I have not done a scientific survey of this, but I definitely find more people who think it should sync than who don't. And that appears to be the same opinion heard by my peers on LV R&D.

 

The LabVIEW NXG development did discuss this question and decided to maintain the existing behavior.

 

I think it is time to close this idea as "Rejected." It's been discussed many times. I don't see it changing ever at this point."

Both the diagram disable structure and the conditional disable structure are intended to allow easy enabling or disabling of blocks of code. These nodes ought to have no effect on a diagram except to remove or add sections of diagram. But they currently have the side effect of formalizing the blocks of code they surround, as if they were a sequence structure. There are two cases where this is undesirable.

 

1. Without the disable structure, these two loops would run in parallel. 

 conddis_unwantedsync.png

2. This VI arguably ought to terminate because that wire dependency from the loop to the Stop primitive is only created because whatever is in the disabled frame needs the result of the loop, but the code in the enabled frame does not. But because the disable structure acts as part of the code, this loop runs forever.

 conddis_shouldterminate.png

26 Comments
Active Participant
I think that strictly speaking you are correct (so I will kudo this), but I can see how this will take a while to get use to (expecially in case 2).


  


vipm.io | jki.net

Proven Zealot
PJM: Regarding case #2, if we stopped drawing the tunnels and perhaps grayed out the single segment of wire that went into the structure, I think that would go a long way to indicate "That data flow connection is disabled."
Knight of NI

Another solution for the first case would be to allow linking of disable structures.

 

This way we would could place two (one around each code fragment), and the dataflow is no longer forced. Switching any of the linked disable structures would switch all others of the group.

 

I must say that I tend not to use such "diagram spanning" disable structures, and I probably would not dare to do so. 😄 In a typical case they surround just a single compact code fragment. 😄

 

Not sure what to say about the second case.....


LabVIEW Champion. It all comes together in GCentral GCentral
What does "Engineering Redefined" mean??
Knight of NI
This is an interesting setup.  So does this mean that Diagram Disable structures act a lot like Case Structures with a constant wired to it?  Are they implemented that way?  Right now, it seems that Diagram Disable structures can be a hack around using Sequence Structures.

GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Proven Zealot

> So does this mean that Diagram Disable structures act a lot like Case Structures with a constant wired to it?

 

There are differences between the two, mostly in type propagation at output tunnels, inclusion of required subVIs and whether broken wires are allowed or not without breaking the VI. 

Active Participant

Aristos Queue wrote:
PJM: Regarding case #2, if we stopped drawing the tunnels and perhaps grayed out the single segment of wire that went into the structure, I think that would go a long way to indicate "That data flow connection is disabled."

I am not sure about not drawing the tunnel, but graying out the wire seem like a good idea. Maybe the tunnel could be grayed out too.



  


vipm.io | jki.net

Proven Zealot

I don't think this feature is valuable enough to warrant the data flow confusion that it will inevitably cause.  Even with grayed-out wires idea, users will have to look at disable structures differently than everything else on the diagram when it comes to data flow.  Right now, there's no question that, when you wire to any structure border, whether or not you actually use the data, you're forcing an execution order.  That assumption is thrown out the window with this idea.

 

Don't get me wrong, I love the disable structure.  But in the case of the screenshot above, I would much rather create two disable structures, than add some weird new anti-data flow mechanism that allows me to just use one.  Let's not add any more data flow "exceptions".

 

-D

DNatt, NI
Proven Zealot
I don't see it as a dataflow exception. I see it as an editor operation akin to "select a rectangle of code and hit delete" The code in disabled frames *does not exist*. IMHO, it should behave like a free label comment or a pasted .png graphic, not like a part of your diagram.
Knight of NI Knight of NI
Knight of NI

Personally, I tend to agree with Darren. I think that a "rectangle of code" is not a concept we want to have, as it implies that the placement of code has meaning, when in fact we know it doesn't.

 

The disable structure has the label you can change in the project, so that you can modify all structures at the same time. I haven't used this myself, so I can't tell how convenient it is, but it should at least work.

Message Edited by tst on 19.06.2009 12:48 PM

___________________
Try to take over the world!
Trusted Enthusiast

I agree with Darren: it would cause more confusion. And like altenbach, I have never even dared to diagram disable two parallel processes with the same diagram disable structure!

 

The likelihood even being able to use such a feature is unlikely! Have you ever so conveniently laid out your code such that the two operations in parallel ops could be disabled by the same rectangle? Look at the above code in the example: I would have put the two loops that are running in parallel vertical from each other. This way, it's more evident that they're running in || in the first place. With that more logical arrangement, you couldn't disable the two increments with the same diagram disable.

 

Fundamentally, I agree with Aristos' proposal - "Commented out code" should never create a dataflow dependency!! But the ramifications of such implementation would 1. Cause confusion, and 2. not be a handy-enough feature for your avg user.

Message Edited by mechelecengr on 06-19-2009 08:01 AM
Wirebird Labs: Expert Toolkits for LabVIEWDeploy, by Wirebird Labs: Expert Toolkits for LabVIEW