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: 
croohcifer

Stall Data Flow should be a no-op in the event of an error

Status: New

I'm a huge fan of the Stall Data Flow malleable VI except in the case that I have it wired on an error wire (my most common use case) and there's an error on the wire.  I generally trust and expect that VIs (especially those on the palettes) will no-op (with rare exceptions like close ref methods) and fail fast in the event of an error on the error in terminal.  I understand that this is kind of a unique case since the VI in question is malleable and doesn't have an actual error in terminal, but my guess is that most users:

 

1.  Wire this specific VIM on error wires most often

2.  Likely don't want the VI to stall in the event of an error

3.  Would prefer to see that error propagated as quickly as possible like most other VIs do

 

Thoughts?

12 Comments
wiebe@CARYA
Proven Zealot

I definitely feel the same way about not stalling on errors. But we can make our own .vims. This one would be fairly easy to make. 

croohcifer
Member

Sure, and normally I would write my own workaround and not even post it here, but this case almost feels like a bug to me.  I'm mainly curious to get NI's perspective on a niche case like this.

crossrulz
Knight of NI

See the discussion here: Darren's Occasional Nugget 01/05/2018 (introduction to Stall Data Flow)

 

Oh, and I am in favor of no waiting on an error.  I have an alteration of that VIM in that thread that would cover the requirement.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
AristosQueue
Proven Zealot

How in the world could that node *not* wait on error? All nodes in LV execute only when all their inputs arrive at the node. You're asking for a node that would abandon that??? I don't see that happening.

croohcifer
Member

I think you may have misunderstood what I wrote.  The wording is perhaps ambiguous.

 

I'm *not* saying that the VI should abandon data flow - i.e., if there is an error wire wired to the input, don't wait for that error on the wire to propagate to Stall Data Flow and instead just call the VI immediately.  I agree that would be nonsensical.

 

What I'm saying is that *if* you wire an error wire into the input node and *if* at runtime there is an error on the wire when Stall Data Flow is called, I want Stall Data Flow NOT to call Wait (ms).  Instead, I want it to no-op.  This would make its behavior consistent with basically all other VIs that have error terminals, including timing functions like the High Resolution Polling Wait.

 

Hopefully that's a clear explanation 🙂

croohcifer
Member

JeffK's argument on the thread crossrulz linked to above is "Everyone can create malleable VIs so just create a variation of Stall that does exactly what you want.  I implemented the simplest version that works with a single pass-thru wire and has the simplest semantics.  I'm expecting people to design variations of Stall as well as lots of other useful vims I've never even thought of!"

 

With the greatest respect for JeffK, I disagree.  There are many NI-written VIs on the palettes that are open-source, and I don't see those VIs violating the principle of no-oping in the case of an error on the input terminal.  To take the most obvious example, the High Resolution Polling Wait is open-source and performs a near-identical function to Stall Data Flow, but it no-ops if there is an error on the input.  Why should Stall Data Flow be any different?  Just because it's a VIM?  I don't think that's a good reason to violate a best practice for passing errors expediently along the error chain.

 

Of course we can create our own code, and we do.  I just think something as ubiquitous as a wait with terminals to enforce data flow *shouldn't* be something every NI user has to recreate, maintain, and internally distribute.  It should be on the shipping palettes and operate in a manner consistent with other VIs. 

AristosQueue
Proven Zealot

croohcifer: I see your counterargument and raise you the 800-lb gorrilla of rejection notices. 🙂

See specifically the discussion about variations on Wait MS. The Stall Data Flow has the same behavior as Wait MS.

 

Related query: Why are you stalling "no error" anyway? That seems really odd.

croohcifer
Member

AristosQueue:

 

I'm certainly not out to rehash the gorilla :).  I think my argument is distinct.

 

On the thread you linked to, you said: "When a node takes a refnum as input, it generally can generate at least one error: "refnum is invalid". It also generally needs serialization up against other nodes that use refnums (programs that use refnums rarely use just one). Neither of those necessarily applies to the Wait Ms node. It is frequently used along side pure dataflow code to control the rate of execution. It cannot generate errors of its own. In our opinion, that makes it a node that should not needlessly encourage serialization. Requring the sequence structure around the Wait primitive discourages its serialization to a degree that seems, in our observation, to be appropriate."

 

Essentially, you said that NI wouldn't want to put dataflow-enforcing terminals on a Wait function because it would encourage unnecessary serialization, but I think that's a false choice fallacy.  You can have both functions (one with and one without error wires), and since 2014 when you wrote that, NI has added the High Resolution Polling Wait AND the Stall Data Flow VIs, both of which do what you said you wouldn't do in 2014.  I'm really glad that your opinion changed because now I don't have to write those VIs myself and tell everyone in my company to use the ones I write and internally distribute!  Yay!  All I'm saying is that one of these NI-provided VIs (Polling) returns immediately if there's an error on error in.  The other (Stall) does not.  This is an inconsistency, and I don't understand the reason for not wanting to make the behavior the same between these and nearly ALL other LabVIEW VIs on the palettes:  fail fast and no-op in the event of having an error (i.e., the Status boolean in the error cluster is TRUE) at runtime.

 

I'm not understanding your question: "Why are you stalling "no error" anyway? That seems really odd."  Could you elaborate?  I'll be really clear about what I'm asking for.  This code should take ~ 1000 ms to execute:

 

Capture.PNG

 

This code should take as close as possible to 0 ms to execute:

 

Capture2.PNG

 

Instead, the second screenshot takes ~1000 ms to execute.  If you replace Stall Data Flow with the High Resolution Polling Wait, it behaves exactly as I want and exactly like most other VIs on the palettes if there is an incoming error:  it propagates the error as quickly as possible and does not execute its core functionality.

 

I'm struggling to understand why some of NI R&D wants Stall Data Flow to break this paradigm.  (I say "some" because Darren agrees with me and has urged others to kudo this idea :P).  I'm completely willing to be convinced that it should stay as is, but so far I don't see a good argument.

AristosQueue
Proven Zealot

> High Resolution Polling Wait

 

This node *can* produce errors. Therefore it has error terminals. My opinion has not changed.

croohcifer
Member
This node *can* produce errors. Therefore it has error terminals.

When you wire an error wire into Stall Data Flow.vim, the specific compiled instance also has error terminals (even though it can't produce an error).  Thus, in this scenario, I believe it should behave consistently with other regular VIs that have error terminals.

 

Let me ask a more targeted question:  I was always taught that code should bubble up an error as fast as possible, so I code with the mindset that if a VI has error terminals, it should propagate any incoming errors (i.e., status boolean = TRUE) as fast as possible regardless of whether the VI itself can contribute an error to the error chain.  I'm interpreting what you're saying as fundamentally disagreeing with this when it comes to Stall Data Flow, but I don't understand why.  Why would you not want your code to fail faster?  Is that not a best practice?