no connection "required" for VI outputs?

[tst]

My point in linking to the LAVA thread was to show that it was technically possible (albeit difficult to achieve) and that quite a few people want it. Personally, I'm not sure that I would use it, but I don't think it would be a bad feature to have. I thought the idea exchange already had an idea for this, but a quick search didn't turn up anything. You're welcome to perform a more thorough search and post a new idea if you can't find one.

[X.]

"You should never have to change priority but if you choose to change what you should not then you can go to this screen where you should not go and change this setting that you should never change." The original was better.

That one is already quite good!

[smercurio_fc]

Hmmm... I wonder if changing that hex value as I had done to make the output required still works for LV 2011.... Though even if it does it clearly wasn't the best way to do it.

[X.]

Just to add some oil on the fire, here are a few older threads which show that I am not the only one to feel the need for this:

Making an Output Required

How can I make an output terminal "Required"?

[smercurio_fc]

Clearly, other people have asked about this, and have wanted the feature, as this has been asked about off and on for several years. That's nothing new. As noted, if you want it to get consideration, post an idea.

Or, I could do it for you and bask in the oodles of Kudos that I'll get.

[Ben]

Recently I have discovered (in LV 2011) that there is a type of "Output Required" implemented in LVOOP for Dynamic Dispatch terminals. Since I discovered it in an odd use-case I had devised I'm a little fuzzy on the reasoning since aparently it was implemented thinking we would never write code like that.

So it is there now.

Ben

[X.]

@smercurio_fc: I have already in a sense, by referring to this thread in a different suggestion I recently posted. But be my guest and you will get my kudo. Just link to this thread for context.

[X.]

@Ben: care to expand? I am not using LVOOP so I can't really figure out what you are talking about.

[Ben]

In LVOOP there is a "contract" between the methods and the data in the cass wire that the action performed on the data in the wire actually gets acted on.

Dynamic dispatch works with pointers so the methods act on the data where ever the pointer is pointing. Most of the time when working with classes the data "Lives somewhere" often a shift register. So the contract says a method will act on the data in the SR. The normal contruct in LVOOP is to wire the class data from method to method so they can act on the data where-ver it is. If they are all in a loop with the class data in SRs then all is normal no suprises.

The issue enters when a dynamic dispath wire branches. A branch will force a data copy. One of the branches will work on the data in the SR. THe other branch will operate on the data in the copied buffer. If all of the methods are "read-only" operations then no big deal. But if one of the methods modifies the data, the result is not going show up in the SR, the updated data will be in the copied buffer. This pattern break the contract since the method was passed a wire that came from the SR, but due to the copy, the SR never sees the data change.

SO in LVOOP Dynamic dispatch wires must start and end at terminals that are in themselves dynamic dispatch.

I do not claim to be a expert LVOOPer. I only know enough to use it to achieve by end. I suspect I got part of that screwed up.

The only thing I can say for certain is "if you have a runnable LVOOP app in LV 2010 that opens bad in LV 2011, and drilling down shows you a broken VI with not broken wires but there is a forked class wire, you ran into the same problem as me and you have to mod your code to eliminate the branch."

I am hesitatn to even post the above but it the best i can do to explain it.

Ben

[X.]

Interesting... Is this just your interpretation of the broken wire or is it actually a message from the Error List? Anyhow, even if all the LV Knights would tell me mandatory outputs are a bad thing, I have encountered a few cases where it would have saved me a lot of debugging time. I would even go as far as to argue that Error clusters should be mandatory by default (that, for one, would force me to be a bit more systematic :-).