From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Low-Level Snap VI Datflow enforcing by using Sequence Structure

@Bob: I repeat IMAQ dispose is not placed immediately after IMAQdx Get Image which you tried to explain. In the given example it is placed after three more fucntions:

IMAQdx Stop Acquisition, IMAQdx Unconfigure Acquistion, IMAQdx Close camera.

-If IMAQ dispose is right after IMAQdx Get Image, Yes there is race condition which is not the case in example.

@ richjoh Are you refering to my first post or the one which PalanivelT posted?

-If later is what you are refering i agree. But i am talking about my first post and i checked by highlight execution.

Thanks
uday
0 Kudos
Message 21 of 25
(1,052 Views)

Uday,

 

     First, I was commenting on Dr. Powell's subsequent note, which didn't use cameras.  Second, even in the original example, the Principle of Data Flow says that technically (which is the way I was arguing), I'm still right.  You could put a dozen functions in the sequence between the wire going to the Image Indicator and the Dispose sitting on the Error line, there would still not be any data dependence on the two functions.

 

     From a "practical" standpoint, this shouldn't be a problem because the additional functions will probably cause a "time delay" before the Dispose fires, allowing the Image to be drawn, but there is nothing in the Block Diagram (without the Sequence) to ensure this.  You brought this up as a "bad example", and took NI to task for not "fixing" it -- it may be "incomplete" and could probably be "improved" -- I encourage you to come up with a better (and technically correct) example, contact NI Software Support, and offer it to them.

 

Bob Schor

0 Kudos
Message 22 of 25
(1,041 Views)
Talking about your first post. Explain what the steps are to the result, is the image not displayed in the indicator? Remove the sequence structure, is the highlight result the same?

I've notice NI examples use sequence structure for the purpose of simplify the topic explanation.
0 Kudos
Message 23 of 25
(1,025 Views)

udka wrote:-If you still want to display image in your indicator you can use snapshot mode in indicator which will make copy of image.

Edit:The error wire has to pass from left to right through sequence structure.Same for Image wire.


Thanks for Info on snapshot mode,

Hope lot of disussion went on sequence strutcure,

 just wanted to share my understanding,sequence structure doesnt play any difference betwen its presence and absence.

----------------------------------------------------------------------------------------------------------------
Palanivel Thiruvenkadam | பழனிவேல் திருவெங்கடம்
LabVIEW™ Champion |Certified LabVIEW™ Architect |Certified TestStand Developer

Kidlin's Law -If you can write the problem down clearly then the matter is half solved.
-----------------------------------------------------------------------------------------------------------------
0 Kudos
Message 24 of 25
(1,019 Views)

@udka wrote:

 


A race condition is where two operation need to execute in a defined order, but that order is not enforced.  In many cases, timing delays will lead to the desired order, but this is a poor substitute for actually enforcing the order, for two reasons:

 

1) it is easy for someone at a later date to modify the code in such a way that time delays are no longer sufficient.  For example, someone might not shutdown the camera because they want to continue using it, or they might place a subVI to modify the image before displaying it.  If the image stops displaying, they will have difficulty identifying the source of the problem (race conditions are some of the worst bugs to diagnose).  It's hard to appreciate in a simple example such as this, but this issue becomes more serious in real-world complex code.

 

2) Even if you "don't see a chance" there is always a chance, at least on non-RT operating systems like Windows (where threads can be delayed for many milliseconds), and especially when one of the "racing" operations is in the UI thread (like the displaying of image in this example).  The single UI thread is shared, and long UI operations in one part of the code can cause long delays elsewhere.

 

As a result, it is always better for it to be "clearly impossible" for something to execute out of order, rather than for one to "not see a chance" of it happening.

Message 25 of 25
(1,010 Views)