Hard Inline VI

[SteveChandler]

When you inline a subVI it is not the same thing as placing the contents of the VI on the callers block diagram. Almost but not quite.

The difference is that all outputs of a VI (inlined or not) become available at the same time when the VI completes execution.

Set the VI above to inlined and use it in another VI

The idea is an additional inline setting as follows.

Now the VI will truely be inlined as if it were not a sub VI at all.

The name "hard inline" is just a suggestion and could be called something else.

[InfiniteNothing]

http://digital.ni.com/public.nsf/allkb/E5B7CD2CA4F7643686256FF7005B4E64

The sequence structure is removed from the execution and the code within the loop will behave as though the sequence structure did not exist.

But also in general to optimize the latency if you had a sub VI that had two independant logic chains (like it calculated input1+2 and input2 *2) the compiler would not wait for logic chain 2 to finish before processing whatever input1+2 was connected to.

[AristosQueue (NI)]

InfiniteNothing: thanks for following up on this.

I checked with FPGA team... that is a known issue to be fixed in a future version. It was not an intentional break in dataflow, just something that got missed, and fixing it has been problematic (I didn't ask for details) but they hope to set it right in the not too distant future. The page you cite is the knowledge base entry to explain the problem.

A subVI with two independent logic chains is really uncommon and generally bad programming practice -- violates the "S" in S.O.L.I.D. In general, though, I'm pretty sure most users would not only expect but actually desire having both inputs update at the same time -- in desktop and RT programming, that makes displays update in sync. In FPGA, it keeps paired pins paired.

[InfiniteNothing]

Thank you for hearing me out.

In a SCTL, the maximum clock rate is determined by the longest logic chain. The desired (and I believe the implemented behavior) is to have the outputs calculated asynchronously. That way if you have fastOpChain wired into slowOpChain, you can clock your loop at 1/(fastOpChain+slowOpChain) instead of clocking at 1/ (2*slowOp).

You can't see the front panel of the subVIs anyway so the display is not relevant. My understanding is that on FPGA, the pins are only guaranteed to be paired up by the end of the cycle.

[InfiniteNothing]

Here's another reference to the control timing being removed:

https://decibel.ni.com/content/docs/DOC-36834

5. Different Execution Paradigm
The execution paradigm of the SCTL differs from standard execution in LabVIEW because all the enclosed code executes in one clock cycle. To meet the iteration latency requirement, LabVIEW FPGA compilation removes flow-control circuitry used to execute structured data flow.

Removal of the flow-control circuitry not only lowers FPGA resource use but, most importantly, allows the diagram to behave like a concurrent circuit, where data is represented by electrical signals flowing, unrestricted, throughout the SCTL.

[AristosQueue (NI)]

And it might well be true that in SCL this is desirable behavior -- I'm not an expert in SCL programming -- but that doesn't change the RT and desktop arguments. If the sequence structure is ignored in SCL, then it doesn't matter whether it is there or not. And it matters a great deal for the other cases.