LabVIEW Minutiae (that may bite you someday)

[JÞB]

---

Were you actually looking for an explanation of this?

---

Yes,  Thanks!

[GregFreeman]

Don't be fooled, reading from a DMA FIFO will SLAM your RT processor, not yield it to other processes!  This has burned me twice now when wiring -1 up to the FIFO read expecting it to act as the "wait" in my loop (despite answering threads in the past where I pointed out to other people why they were having this problem!). It just slipped my mind again and bit me the other day.

Noted here by NI, but I figured worth mentioning. Unless you are monitoring your CPU usage on your RT system, it can be tough to figure out why other processes aren't executing.

My question is, why not use interrupts? Is that KB just an excuse for a poor design decision, or is it the right design decision?

[altenbach]

A "build path" primitive with two diagram constants as inputs (a path constant and a string constant for a file name) apparently does NOT get folded by the compiler, but costs ~15 microseconds every time (debugging disabled). I had that deep in an inner loop and gained a 50% increase in speed by avoiding it.

Good to know. I wonder why that is! 😉

[Yamaeda]

---

@altenbach wrote:

A "build path" primitive with two diagram constants as inputs (a path constant and a string constant for a file name) apparently does NOT get folded by the compiler, but costs ~15 microseconds every time (debugging disabled). I had that deep in an inner loop and gained a 50% increase in speed by avoiding it.

Good to know. I wonder why that is! 😉

---

Actually it seems the same/smilar with arithmetic nodes, i did a test with a formula node vs labview primitives (1 add, 1 mult, 1 div) and the primitives were slower! If i changed the mult and div (which used constants) to 1 precalculated mult it was as fast, so i guess the formula node does that while the primivites calculates all steps. (or could this be an effect of debugging enabled, i dind't check that)

/Y

[Intaris]

---

@for(imstuck) wrote:

Don't be fooled, reading from a DMA FIFO will SLAM your RT processor, not yield it to other processes!  This has burned me twice now when wiring -1 up to the FIFO read expecting it to act as the "wait" in my loop (despite answering threads in the past where I pointed out to other people why they were having this problem!). It just slipped my mind again and bit me the other day.

Noted here by NI, but I figured worth mentioning. Unless you are monitoring your CPU usage on your RT system, it can be tough to figure out why other processes aren't executing.

My question is, why not use interrupts? Is that KB just an excuse for a poor design decision, or is it the right design decision?

---

I think the reason for not using interrupts is jitter and latency.  It's simply faster slamming the CPU.  I personally would like SOME element of control over this though.  Like choosing a user-configured poll rate in cases where you simply need better than X response but still want to do other tasks while waiting.  The poll rate seems to be 1ms outside of timed loops which is WAY too slow for our application because we seem random loop times of 1ms for a process which should be running at 20kHz (50us).  Using within a Timed loop slams the processor as you say.

[altenbach]

---

 (or could this be an effect of debugging enabled, i dind't check that)

---

(If l remember right, sorry posting by phone: )

In recent LabVIEW versions, most (all?) folding requires debugging to be disabled. You can configure LabVIEW to show folding of wires and structures (search for "fuzzy wires").

[JÞB]

---

@altenbach wrote:

---

 (or could this be an effect of debugging enabled, i dind't check that)

---

(If l remember right, sorry posting by phone: )

In recent LabVIEW versions, most (all?) folding requires debugging to be disabled. You can configure LabVIEW to show folding of wires and structures (search for "fuzzy wires").

---

You may need to actually RUN (and MUST save ) a vi before loop invarient structures will show as folded. 

Or, From the help:

Constant Folding

LabVIEW uses constant folding to optimize the performance of VIs. With constant folding, LabVIEW computes constant values on first run of the VI, instead of calculating them during each run. LabVIEW does not constant fold structures if you enable debugging.

You can display constant folding hash marks on the block diagram by selecting Tools»Options, selecting Block Diagram from the Category list, and placing checkmarks in the Show constant folding of wires and Show constant folding of structures checkboxes. When you place a checkmark in the Show constant folding of wires checkbox, hash marks appear on the wires attached to constants that are constant folded. When you place a checkmark in the Show constant folding of structures checkbox, gray hash marks appear inside structures that are wired to constants. The hash marks might not appear until after you run or save the VI. The hash marks also do not appear when you make an edit to the VI

[Darin.K]

---

@altenbach wrote:

A "build path" primitive with two diagram constants as inputs (a path constant and a string constant for a file name) apparently does NOT get folded by the compiler, but costs ~15 microseconds every time (debugging disabled). I had that deep in an inner loop and gained a 50% increase in speed by avoiding it.

Good to know. I wonder why that is! 😉

---

LV9 seems to imply via the fuzzy wires that it is folded and a quick test suggests that it is.

And the help is a bit misleading here.  You need neither to run the VI nor save the VI, you only need to compile the VI (ctrl-run) to update the folding.  LV will show the folding regardless of the debugging setting, but you need to disable it to actually do the folding.

[altenbach]

---

Darin.K wrote: LV9 seems to imply via the fuzzy wires that it is folded and a quick test suggests that it is.

---

Intersting. Unless I am looking at it wrong, it is definitely not folded in newer versions... I wonder what changed.

(In my original code leading to this investigation, I actually had a Temporary Directory function on the top input, which arguably cannot be folded, because the windows settings might change externally. Out of curiosity, I then tried a path diagram constant and it still did not get folded and gave the about same speed as with the tempdir primitive.)

[crossrulz]

I'm seeing the constant folding in 2012 SP1.  Haven't gotten 2013 installed yet.

(you have to look closely, but the fuzzy wires are there)