LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

In Place Element Structure style/usage guide

Solved!
Go to solution

Attached is a two part diagram.  The top half has the In Place Element Structure surrounding the entire loop.  The bottom half has the In Place Element Structure surrounding only the part of the structure portion of an array element that is modified.  The smaller In Place Element Structure is the only place that the array elements are modified.  Since I am new to the usage of In Place Element Structures, I would like to know the pros and cons to both methods of encapsulating the data modification.

 

0 Kudos
Message 1 of 9
(5,645 Views)

I do not know about pros/cons, but a few things I consider.

 

1)  Most times the IPE is not really necessary, and certain operations will not be "in place" just because the IPE is used.  That said, sometimes the better look is enough reason to use.

 

2) There is certainly a small overhead each time the IPE is invoked to acquire the resource and lock other instances.  This argues against repeated usage inside a loop or sprinkling too many of them around the BD.

 

3) The lock is applied as long as the code inside the IPE is running, this argues against enclosing more code than necessary inside the IPE if the resource is shared.  (Apparently not the case here, but with DVRs certainly possible).

 

I use your lower construction much more often, I prefer to see the IPE at a glance.

Message 2 of 9
(5,636 Views)

Don't forget that LabVIEW has good inplaceness algorithms so the structure might not be needed at all. It is difficult to tell how the rest of the code looks like. Is this a subVI? How is it called within the main VI? For example, if that cluster array is kept in a shift register in the main VI, you could inline the subVI (newest LabVIEW version only).

 

You could also look into data value references to truly operate only on a single copy. 

Show buffer allocations to get a better feeling what the compiler is actually doing. Can you attach your actual VI?

 

 

There are other potential performance issues, for example, the "orientation array" should be before the FOR loop (disable autoindexing).

Message 3 of 9
(5,630 Views)

The calling VI replaces the "In" array with the "out" array in a shift register.

0 Kudos
Message 4 of 9
(5,612 Views)
Solution
Accepted by topic author Les__Bartel

There's no benefit to using the In-Place Element Structure in either of those diagrams.  Try using "Show Buffer Allocations" tool - you should see that LabVIEW is not making a copy of the cluster even without the IPE, so the operations are already in-place.

 

However, you might get some performance benefit from moving the "Orientation Array" outside the for loop, unless you are actually modifying it while the for loop runs.

Message 5 of 9
(5,582 Views)

nathand wrote:

However, you might get some performance benefit from moving the "Orientation Array" outside the for loop, unless you are actually modifying it while the for loop runs.


I agree.  Whenever creating a sub VI, I make it a rule to put all controls and indicators on the root level of the diagram, meaning they should be outside of any structures.  This improves readability because all the inputs are on the left side of the diagram, and all the outputs are on the right side.  It can also improve performance because it will prevent LabVIEW from reading a control over and over each loop iteration, and extra buffers won't be created for indicators that are in case structures.

 

Chris M

0 Kudos
Message 6 of 9
(5,574 Views)

@nathand wrote:

There's no benefit to using the In-Place Element Structure in either of those diagrams.  Try using "Show Buffer Allocations" tool - you should see that LabVIEW is not making a copy of the cluster even without the IPE, so the operations are already in-place.

 

However, you might get some performance benefit from moving the "Orientation Array" outside the for loop, unless you are actually modifying it while the for loop runs.



Sure enough, you're right.  How is it that LabVIEW doesn't need the hint to do In Place modification, but it might (your wording) benefit from moving the Orientation Array outside the loop?  The only place the array is referenced is on the visible portion of the block diagram.

0 Kudos
Message 7 of 9
(5,548 Views)

@Les Bartel wrote:
but it might (your wording) benefit from moving the Orientation Array outside the loop?  The only place the array is referenced is on the visible portion of the block diagram.

Note that I said the same thing even earlier above.


As Darren explains here, terminals should be on the toplevel diagram, and not be buried inside structures.

 

In the case of FOR loops, there is the additional performance hit that the control needs to be read with every iteration of the loop. (the terminal value could have been modified from within a parallel process!). If it is before the loop, it can be folded into a constant for the duration of the loop for much more efficient code.

Message 8 of 9
(5,505 Views)

@altenbach wrote:
As Darren explains here, terminals should be on the toplevel diagram, and not be buried inside structures..


Actually, the real explanation is further down by Greg McKaskle, but you probably found that by now. 😄

0 Kudos
Message 9 of 9
(5,473 Views)