LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Darren's Occasional Nugget 01/05/2018

One of the most popular posts on the LabVIEW Idea Exchange is Wait (ms) with error pass-through, which accumulated 826 kudos before NI declined the idea. But did you know that this functionality is available in LabVIEW 2017 and later with the Stall Data Flow VI? Check it out:

stall.png

 

All three of the snippets above function identically. Stall Data Flow is a Malleable VI, which means it automatically adapts to whatever data type is wired in...note that it can be used to stall data flow on either the numeric or the error wire in the screenshot. 

 

Fun fact: Stall Data Flow.vim was written and added to LabVIEW by JeffK, the father of LabVIEW!

 

About the only disadvantage I can think of with Stall Data Flow.vim in its current implementation is that, if you wire an error cluster, the wait will still happen even if there is an incoming error. I haven't yet been able to convince JeffK that we should make this change, but I'm not giving up!

 

There are several other useful Malleable VIs available in Quick Drop and the palettes in LabVIEW 2017 and later. The easiest way to browse them is to launch Quick Drop and type 'vim'.

Message 1 of 24
(7,532 Views)

@Darren wrote:

 

About the only disadvantage I can think of with Stall Data Flow.vim in its current implementation is that, if you wire an error cluster, the wait will still happen even if there is an incoming error. I haven't yet been able to convince JeffK that we should make this change, but I'm not giving up!

 


The wait with error in/out has been around for a while, it is the Wait Express VI. It has bitten me in the past, I thought it would not wait if there was an error in, it turns out it does! 

Where do we start the campaign and signature gathering to convince Jeff K that we should make it not wait if there is an error in? 

 

Fab

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
0 Kudos
Message 2 of 24
(7,456 Views)

@FabiolaDelaCueva wrote:

@Darren wrote:

 

About the only disadvantage I can think of with Stall Data Flow.vim in its current implementation is that, if you wire an error cluster, the wait will still happen even if there is an incoming error. I haven't yet been able to convince JeffK that we should make this change, but I'm not giving up!

 


The wait with error in/out has been around for a while, it is the Wait Express VI. It has bitten me in the past, I thought it would not wait if there was an error in, it turns out it does! 

Where do we start the campaign and signature gathering to convince Jeff K that we should make it not wait if there is an error in? 

 

Fab


I can't even find the Wait Express VI - and probably not many of us can, because everywhere I've gone, someone has made up some version of "wait with error terminals.vi"

 

Hey maybe JeffK would accept a compromise - that is, a Boolean to control that behavior?

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 3 of 24
(7,438 Views)

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!

Message 4 of 24
(7,425 Views)

On the other hand, there is Wait function with error terminals from OpenG, which allows optionally skip wait in case of error...

Message 5 of 24
(7,328 Views)

@billko wrote:

@FabiolaDelaCueva wrote:

@Darren wrote:

 

About the only disadvantage I can think of with Stall Data Flow.vim in its current implementation is that, if you wire an error cluster, the wait will still happen even if there is an incoming error. I haven't yet been able to convince JeffK that we should make this change, but I'm not giving up!

 


The wait with error in/out has been around for a while, it is the Wait Express VI. It has bitten me in the past, I thought it would not wait if there was an error in, it turns out it does! 

Where do we start the campaign and signature gathering to convince Jeff K that we should make it not wait if there is an error in? 

 

Fab


I can't even find the Wait Express VI - and probably not many of us can, because everywhere I've gone, someone has made up some version of "wait with error terminals.vi"

 

Hey maybe JeffK would accept a compromise - that is, a Boolean to control that behavior?


It's actually called Time Delay and is in the Timing palette. The detailed help on it doesn't really describe the expected behavior on the incoming error.  (looking in LV 2017).

Message 6 of 24
(7,275 Views)

@RavensFan wrote:
It's actually called Time Delay and is in the Timing palette. The detailed help on it doesn't really describe the expected behavior on the incoming error.  (looking in LV 2017).

If you convert the express VI to open the front panel you see that the error is just wired through, same as in the new stall dataflow tool. Yes, the help on "time delay" should mention the error handling. It does say that it operates similarly to the "wait" or "wait next", which are also unconditional.

 

I do like the ticker output of "stall dataflow", it often eliminates placing a tick count elsewhere on the diagram. The only thing I would change is removing the sequence frame inside it. Seems only cosmetic. 😄

Message 7 of 24
(7,263 Views)

@altenbach wrote:

I do like the ticker output of "stall dataflow", it often eliminates placing a tick count elsewhere on the diagram. The only thing I would change is removing the sequence frame inside it. Seems only cosmetic. 😄

True.  But looking inside, it looks like the subVI contains the way you'd be programming it within the regular VI before the this VIM existed.  Like someone did a "Create SubVI" of the code that existed in the higher VI where the sequence was necessary, then did the needed conversions for a variant and creating the .vim structure, and didn't bother to removed the sequence which is now an unnecessary structure since the subVI wraps the wait with the dataflow path.

0 Kudos
Message 8 of 24
(7,259 Views)

Hmm -- shortly after I read Peter Blume's "LabVIEW Style" book for the first time (maybe a decade ago), I created a "Delay (ms)" and Delay (sec) sub-VI modeled after something I saw there, a half-height (Icon-size) VI that sits on the Error Line and has a single I32 input.  I still use it, works fine, mnemonic (the Icon says "Delay (ms)"), and can be tailored skip "Wait on Error" (though I've not thought to do that ...).  Why re-invent the wheel?

 

Bob Schor

Message 9 of 24
(7,253 Views)

I don't consider this new VI reinventing the wheel, but improving it by putting some tread in the rubber.

 

Everyone created their own version of the wheel, unless they used the Express VI.  And if you created one that was based on the error wire, probably the most common use case, it would only work on the error wire.

 

The new implementation allows you to go off road on various surfaces allowing you place it on any kind of wire you might want.

Message 10 of 24
(7,243 Views)