LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Showing results for 
Search instead for 
Did you mean: 

Concatenating tunnel mode that allow string type

Status: New

I finally found the time to download a trial version of LV2012. I find that the new 2012 features are really useful and interesting. Good job NI! Smiley Very Happy

One of the greatest for me is definitely the new "concatenating tunnel mode".

I've noticed that it cannot be activated with a variable of scalar type, and this obviously makes sense for almost every type of variables. However, strings are only formally scalar variable. I have lots of VI where the concatenate string vi has exactly the same use (on strings) that Build array has on numerics type of data, particularly when the concatenation had to be conditional. Obviously it is possible to convert the string into a U8 array before to connect the wire to the tunnel, and reconvert it into a string out of the loop, but this convertion probably can be internally managed without too much effort.

The attached snipped can show you what I mean. So, in my opinion, if tunnels could accept strings also when in Concatenating (conditional or not) mode would be great.



Sorry, in my message I've attached the snippet instead of making it visible in the post, but I don't know how to do the trick...



Active Participant



One alternative to the current implementation that you have illustrated is to use auto-indexing on the outgoing string, and then wire the resulting string array into a concatinate function that you shrink to have just a single input. The concatinate node will then flatten the array into one string.


This way you can skip the case inside the loop and use the conditional indexing feature of LV2012 (or better; use the OpenG alternative which is drastically more efficient, at least until they fix the way the in-built conditional tunnel works) to generate the array to flatten with the concatinate function.


Thanks Mads! Your suggestion makes the implementation even simpler than mine.

However, in my opinion, the focus of my idea remains the same. Perhaps this is so only for me, but all the three options of tunnels seem to me so natural for strings, that it seems to me a pity to have to apply some kind of convertion on the result. Smiley Wink


In the mean time I understood how to show a snippet on the post, so I put there a new one, with your suggestion added.


Concatenate strings in tunnel.png


Thanks a lot.



Knight of NI

Hate to do this to you, but I've added another way to do this.  It would be interesting to see which way is truely the most efficient.  I just don't have time to do a benchmark right now.

Concatinate String.png

There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5

You are welcome, crossrulz!


One of the benefit of idea exchange (and discussion forum) is the opportunity of learning a lot from other's way to do the same thing. Smiley Happy


I took the time of a benchmark (only for speed) of the different proposed methods... and the winner is...


1. the use of shift register (not so surprising) Smiley Very Happy

2. the use of two conversions String->U8 array->String and the tunnel conditional concatenation

3. (with a time close to the second method) the use of a TRUE FALSE vi, and the external convertion using the concatenate

4. the conditional tunnel for building array, and the external convertion using the concatenate


I included the snipped of the vi I used, if you want to check results on your PC.


Ok, good to know. However, I must say that I am not always looking for the maximum speed. Often execution time is not the primary performance to look at. From the point of view of software maintenance, the clarity of the diagram may be very important. Don't you think that it would be great if it were possible to write our example as follow? Neat, isn't it? Smiley Wink







I forgot the snipped...



Concatenate string methods benchmark.png


Your test involves short strings.  Do longer strings with variable length affect your results?  Please post times if possible.  Thanks


Although the tests proposed are very interesting, I think we're going a bit off topic.

The point in the proposed idea is:

since (unlike other variables) it is absolutely legal to concatenate strings together, why LV does not allow us to do that operation, using the new tunnel's features?

If NI has implemented these new features efficiently or not, is another (interesting) topic. Of course, knowing the performance of different methods, you can choose the one that best suits your situation. For those who can not open the attached snippet, I write with pleasure the results of four different methods:


1. the use of shift register (not so surprising)  = 156ms

2. the use of two conversions String->U8 array->String and the tunnel conditional concatenation = 185ms

3. (with a time close to the second method) the use of a TRUE FALSE vi, and the external convertion using the concatenate = 207ms

4. the conditional tunnel for building array, and the external convertion using the concatenate = 425ms


wevanarsdale:   Obviously these results can vary a lot, case by case. In the example VI, for each iteration, the lenght of the added string is "small" (1 to 6 chars) but the resulting string grows a lot, because of the 1000000 iterations, up to about 3M chars. For each iteration the concatenating tunnel has to manage such a big string. I tryed to increase the lenght of the added string (up to 50 chars), but the the podium positions didnt change. The method that more suffers of the increased added string len is (obviously) the one with str-> U8 convertion. As far this test is significant, the new tunnel concatenating mode seems to work efficiently enough for my purposes.



Proven Zealot

The conditional tunnel for building an array will (standard caveats about promising future functionality) be more efficient in 2013. We followed the standard pattern of "make it work, then make it work efficiently" which tends to be the least bug-prone path to high speed code.


I'm still looking forward for this feature in LabVIEW 2015.  I don't have idea if it's implemented in LabVIEW 2016.