LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Diagram Disable Structure and Asynchronous SubVI Bug?

Solved!
Go to solution

@rolfk wrote:

I don't think I agree with you here. The flat sequence structure would behave exactly the same, no matter if it is internally implemented as a node or not. This is how LabVIEW dataflow has worked since the inception of LabVIEW and I see no reason why it should change.

 



If what you say is true, then the result of the following code would be 50 if the FSS were implemented as a Node since it would by definition wait for all of its inputs.  It is a sequence of individual nodes instead, so the result is 100 because the first frame (a node) gets to run immediately without waiting. 

 

FlatSequence.png

 

The FSS is not a node and its behavior would certainly not be "exactly the same" if it were. 

Message 11 of 16
(787 Views)

Interesting, learned something new, which I'm not sure I find intuitive. It's however clear that it's intentional since you can't just move a tunnel between frames.

 

However each frame in the FSS still is a node in itself and acts the way I would expect it to work. And it seems only logical to me to treat a DSS frame the same as any other frame in LabVIEW. It's not like some C preprocessor directive that removes anything from the original source code. Doing so would have created some counter intuitive situations IMHO.

 

Someone really went out of his or her way and certainly did not apply lazy design to the FSS. Otherwise the most straightforward way would have to be the creation of an FSS that would simply behave like the SSS with no distinction of input dependencies on individual frames.

Rolf Kalbermatter
My Blog
Message 12 of 16
(780 Views)

I think the behavior shown in Darin's image changed in LV6, 7, 8 ??? Prior to that the FSS behaved as a single node.  I do not have any of the old versions to test, but I seem to recall that the change was noticed because it broke legacy code.  Or maybe my memory is broken, I forget.

 

Lynn

0 Kudos
Message 13 of 16
(773 Views)

@johnsold wrote:

I think the behavior shown in Darin's image changed in LV6, 7, 8 ??? Prior to that the FSS behaved as a single node.  I do not have any of the old versions to test, but I seem to recall that the change was noticed because it broke legacy code.  Or maybe my memory is broken, I forget.

 

Lynn


Can't verify that. The erliest version that seems to have the FSS is LabVIEW 7.0 and it behaves the ame as in Darins picture. Before there was only the stacked sequence and that of course did behave as a single frame in this respect.

Rolf Kalbermatter
My Blog
0 Kudos
Message 14 of 16
(762 Views)

Rolf,

 

Perhaps it was the difference in behavior between the flat and stacked sequence structures that I recalled and because it was different   concluded that it was a change.

 

Thanks.

 

Lynn

0 Kudos
Message 15 of 16
(760 Views)

Glad I was not the only old-timer who was a little discombobulated the first time I noticed the unique behavior of the FSS.  I was tipped off to it when I was trying to use scripting to split an existing frame and noticed it was not in the node class hierarchy. 

 

So yes, clearly there was deliberate effort made to not implement the FSS as a node.  It gives up the ability to rearrange the cases, easily convert SSS, and some code readability.  In return?  Some convenience when there literally is no data flowing between frames I suppose.  In general, I use the FSS when I need to insert something into the flow, but not use the data in the flow.  In those cases the implicity linking of the frames in the FSS gets me nothing that I wouldn't already have by linking single-frame structures using the same wire.

0 Kudos
Message 16 of 16
(748 Views)