Micro-Nuggets !!! ~~~~ Post 'em if you got 'em

[GuenterMueller]

---

@altenbach wrote:
[...]

Well, You can go about 3x faster than your fast solution by autoindexing the numeric and then format and concatenate later (Bottom image).

(With the disadvantage that you can't really control any useful delimiters, but in this case you would use array to spreadsheet string instead anyway, which is also faster than your solution. Now shown).

Even the slow concatenate solution you presented is a bit convoluted. Format into string has concatenation built_in! So a cleaner solution is possible (top in image). Not super fast, but good enough for small arrays.

[...]

---

Right you are, Christian. Thanks for pointing this out here.

By intention I did not focus on this but solely the position of the concatenate function on the BD. Everything else (also the string generation) is by intention as identical as possible in order to get "strong" profile results.

[GuenterMueller]

---

@nathand wrote:

This makes complete sense.  When you concatenate inside the loop, you may have to copy the entire contents of the existing string on each loop iteration.  When you concatenate at the end, you only need to copy once - LabVIEW can determine and allocate the full string length, then copy each element into the appropriate position.

---

Thanks for your feedback. I agree that the result makes sense.

I was interested in the profile results because I exepcted that even using the for loop to set up the array might have it's memory issues when dealing with strings (= creating an array of strings). I am satisfied with the profile result because it shows exactly what we all notice in LabVIEW: Try to use a for loop when setting up an array - because it is so hard to beat with regard to performance.

[SteveChandler]

Sometimes you have to use a VI that was developed by someone that you did something really bad to in a previous life. The VI is used by existing code and you are rightfully terrified of modifying it in any way. I inherited a collection of such VIs that were developed by someone who did not know about clusters and used the maximum number of terminals - all wired. This micronugget is contained in the following series of images.

[PhillipBrooks]

---

@Steve Chandler wrote:

Sometimes you have to use a VI that was developed by someone that you did something really bad to in a previous life. The VI is used by existing code and you are rightfully terrified of modifying it in any way. I inherited a collection of such VIs that were developed by someone who did not know about clusters and used the maximum number of terminals - all wired. This micronugget is contained in the following series of images.

---

Very nice example of a secondary prophylaxis!

http://en.wikipedia.org/wiki/Preventive_medicine#Prophylaxis

"secondary prophylaxis - whereby the disease has already developed and the patient is protected against worsening of this process"

[Norbert_B]

Steve and all,

referring to Steve's good nugget about the global stop, i feel i have to add some very important information, since it can create headaches and wrong functionality in certain cases.

Don't take me wrong, it is a very good solution for the global stop issue.... on Windows!

But it is nothing you can directly "convert" to real time by default!

Why is that?

Let's talk about the purpose of a real time system: One 'process' within your software is "the one". If the systems runs into performance issues, this 'one process' is the very last process which ought to be effected. So we call it the "time critical process".

Using LV RT for implementing such a system, each of the processes is placed in seperate, parallel running loops (inherent multithreading!). But we got to tell the system which loop is the time critical one; which of the loops contain the algorithm, which must fail as the last process on the whole system if anything goes wrong. For this, we have timed loops with priorities. The "priority range" of timed loops lies between the VI priority levels "high" and "time critical". Hence, no VI has to be defined as time critical priority in most cases!

Now the problem starts off: We use the global stop in all of our loops, so we are talking about a shared resource. Since the VI must be non-reentrant (otherwise, no functionality!), processes with different priorities are calling a blocking resource (non-reentrant VIs block other callers if its already executing). So it is possible, that our time critical loop has to wait for a normal loop to execute the FGV/AE. In fact, even if the execution of the FGV/AE is very fast, it still could block for up to ms-range (note: the actual value depends on several items, e.g. LV version. It can also change in the future) because the time critical loop tries to preempt the blocking loop which in fact prolongs the execution of the FGV/AE.

What is the solution for RT?

The shared VI, in Steve's case the Global Stop core.vi, has to be configured to be priority level "subroutine". This must only be configured for VIs which are executed fast!!

We do so in order to configure the SubVI call in the time critical loop to be "Skip if busy". This ensures that the time critical loop can keep it's timing (maybe faster than ms => >1kHz). But you have to keep in mind that the loop skips the execution of the FGV/AE, so it is no lossless communication layer anymore.

OK, for the stop command, it does not matter if its lossy or not, but for other features, it might be an issue.

What is the solution for lossless communcation on RT?

Simple: RT-FIFO.

What does "subroutine" priority level mean?

From the LV help:

When a VI runs at the Subroutine priority level, it effectively takes control of the thread in which it is running, and it runs in the same thread as its caller. No other VI can run in that thread until the subroutine VI finishes running, even if the other VI is at the Subroutine priority level. In single-threaded applications, no other VI runs. In execution systems, the thread running the subroutine does not handle other VIs, but the second thread of the execution system, along with other execution systems, can continue to run VIs.

In addition to not sharing time with other VIs, subroutine VI execution is streamlined so that front panel controls and indicators are not updated when the subroutine is called. A subroutine VI front panel reveals nothing about its execution.

hope this helps,

Norbert

[SteveChandler]

Here is a little trick that I sometimes use for wordy comments on the block diagram. I put the comments in a string constant and set it to show the scrollbar. I put the high level stuff in the visible portion of the string and to see the details you have to scroll. I create and edit the comments in notepad then copy and paste into the constant.

If you like the idea of a scrollbar but feel strange about abusing constants you might consider voting for this idea.

[JÞB]

Look ma NO Code!   And I mean it

Here.vi contains empty FP, BD and Con pane and its icon is an attention glyph.  Absolutely worthless right?  here is one use case.

When starting a project we all start from our VITs right? New... (Hey now that the new.. from browser opens fast its not so painful) And create our shell code with documentation.  Drop Here.vi and give youself a reminder about what you are going to do later....

Because its in vi.lib Here vi can be filtered on or off in the heirarchy view! and finding all instances is a snap- Not found- you are done with the code and ready for peer review-----BUT Wait! There's more. Like a infomercial salesman I'm going to DOULBE the offer.

Here.vi is also the best code review tool in existance! Why drop the review notes on paper- where you can forget them?

Address the review comments right on the vi at the location and drop Here.vi.  The developer responsible has instant access to the comments and locations of every hit and can use the comments to write the review report deleting Here .vi as we go along. 

Clean-up is a SNAP Here.vi is even dishwasher safe

[johnsold]

Nice.

Any reason for not using the 4-2-2-4 conpane?

Lynn

[SteveChandler]

Hey, maybe a reuse VI that contains the Here.vi and the comment with a scrollbar below it. Set that VI to place contents.

[JÞB]

---

@johnsold wrote:

Nice.

Any reason for not using the 4-2-2-4 conpane?

Lynn

---

Per group style guide, my ini contains the "defaultConPane=4833" token - It does make sense for how the group uses LabVIEW

So there was no reason to change it and it would have been a peer review hit  Here.vi is not set up for re-enterant execution so I avoided the deviation from policy