LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

How to initialize typedef array without loosing the typedef

Solved!
Go to solution

@LukasW wrote:

In (B) will the shift register be preallocated because of the autoindexed for loop? If yes this could be my workaround for now.


If you autoindex at the output tunnel of a FOR loop as in my case, the output array gets preallocated automatically at the correct size, no need to initialize, shift registers, and such.

0 Kudos
Message 11 of 21
(2,350 Views)
Solution
Accepted by topic author LukasW

I just found a solution: With reshape array I can change the dimension of the typedefed array and keep the typedef.

It looks like this:

td_array_prealloc_td.PNG

 

Autoindexing instead of using the shift register would be a lot nicer but looses the typedef. If I manage to get rid of the array in the typedef I will use the autoindexed tunnel as you suggested.

 

I also tested a few versions regarding loop times. The test generates 1000 entries for the typedefed array, for a typedef without array and doubles. Those are then passed to the different VIs, which execute 100 times to get some sort of a mean loop time. The VIs output the total time taken to execute the for loop in µs.

td_speetest.PNG

I tested the following approaches:

- Typedef without array, autoindexed loop

- Typedef without array, shift register with preallocated array

- Typedef with array, shift register with preallocated array (respahe array function)

- Typedef with array, shift register with no preallocation (empty array)

- Typedef with array, autoindexed loop, no typedefed output

 

Those are the times for processing 1000 entries per array:

td_array_looptimes.PNG

 

As the shiftregister without an initialized array is the only version that is noticeably slower I think that even though the for loop has a fixed number of iterations the shift register does not get preallocated in the right size.

I just did this out of couriosity because the reshape array method allows to initialize the shift register while keeping the typedef anyway. I though I might share this, maybe it is interesting.

 

Thanks for your help,

Lukas

0 Kudos
Message 12 of 21
(2,329 Views)

I don't see the timing code. What's in the subVI? Can you attach your benchmarking code?

0 Kudos
Message 13 of 21
(2,310 Views)

Sorry I forgot to attach the project.

 

The subVIs contain the different approaches as discussed here, the timing code is also inside the subVI (only measuring the for loop).

0 Kudos
Message 14 of 21
(2,299 Views)

Just to muddy the waters a little... make a "Strings and Values" property node (for something that has strings and values, of course).  What is it?  A typedef'd array, of course.

 

I'm still against it, though.  😉

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 15 of 21
(2,279 Views)

Not bad, but not enough.  In LabVIEW, you can have your Cake and Eat It, Too.  I made the following minor change to your code, which mimics a technique I use, myself.

 

You have two base Cluster TypeDefs, Config and Output.  If you look at my version of these clusters (you can see an example in the Snippet), you'll notice that I made an Icon for it.  Turns out there's a poorly-known feature that NI introduced around LabVIEW 2012 (maybe 2011?) that lets you right-click on a Cluster constant having a TypeDef and replace the Cluster (which can be huge, by the way -- I've got one with 160 elements) with its Icon.  Pretty self-documenting, I'd say.

 

Now look at your Array TypeDefs.  I remade them as follows -- I dropped down an Array container, then into it I put one of the Cluster TypeDefs.  So Config Array is an Array of Config (TypeDef).  This is where you Have Your Cake, as you have now consistent TypeDefs.

 

I modified only two of your tests (one shown here).  The changes were simple -- where your Front Panel control was your "old-style" array, I just right-clicked it, chose "Replace", "Choose a Control", and substituted my new TypeDef.  If you are a fan of QuickDrop, it's even easier -- click-select, Ctrl-space, start typing the new Typedef name until it appears, P (replace).

Neuer und Besser.png

Bob Schor 

0 Kudos
Message 16 of 21
(2,270 Views)

@Bob_Schor wrote:

Not bad, but not enough.  In LabVIEW, you can have your Cake and Eat It, Too.

 


But your VI has a coercion dot at the output array, which the OP was trying to avoid (thus this entire discussion). Of course we need to remind us that this is probably a painless coercion, which does not involve any significant effort for the compiler.

 

(You only have typedef'd array elements while he has a typedef'd array of the same structure)

0 Kudos
Message 17 of 21
(2,260 Views)

Yep, there is a coercion dot.  If you look at the type of the Wire, it is 1D Array of Output (TypeDef Output.ctl), while the Indicator is of type Output Array (TypeDef Output Array.ctl), which is a 1D Array of Output (TypeDef Output.ctl).

 

While TypeDefs are definitely a Good Thing, one needs to recognize that sometimes wiring a value that is the very definition of the TypeDef into an indicator that explicitly is the TypeDef will cause such a coercion dot, which as you note, has no real meaning (as the only thing being "coerced" is what you call the collection, no data-changing takes place, and it would be interesting if any significant code (= CPU cycles) is generated.

 

I was going to conclude that if this really bothers you, you can always do a TypeCast, but that doesn't seem to work for compound types.  I've "loosened" my "No Coercion Dots!" stance a bit in favor of "Use TypeDefs to Organize and Document Data!", and accept the occasional exceptions (which tend to be easy to spot).  After all, if the coder knows that the Output Array indicator is of type "Output Array", and sees that it is being created from an array built of type Output, he (or she) should be able to shrug and say "OK, LabVIEW has given me a "technical" Coercion Dot, I'll live with it ...".

 

Bob Schor

0 Kudos
Message 18 of 21
(2,248 Views)

I was thought to avoid coercion dots but I'll keep in mind that in this case it probably doesn't really do anything.

A bit off the original topic but interesting now: If I need to calculate something out of say a Double and an Int32 is there any benefit in using the conversion functions to avoid the coercion dot or will it do just the same?

 

The cluster icon is definitely a really useful feature I'm using a lot.

 

Is there any benefit in having e.g. a Control typedef plus an Array of Control typedef? I see the point of going from the Array typedef to just the cluster and then put in into an array if needed.

 

Lukas

0 Kudos
Message 19 of 21
(2,219 Views)

@LukasW wrote:

I was thought to avoid coercion dots but I'll keep in mind that in this case it probably doesn't really do anything.

A bit off the original topic but interesting now: If I need to calculate something out of say a Double and an Int32 is there any benefit in using the conversion functions to avoid the coercion dot or will it do just the same?

 


Here is some easy reading from a few years ago

 


@LukasW wrote:

 

Is there any benefit in having e.g. a Control typedef plus an Array of Control typedef? I see the point of going from the Array typedef to just the cluster and then put in into an array if needed.

 


 

I would just typedef the element. Especially if it is a cluster (as in your case) it defines the unique and important data structure. Going to an array just repeats that same structure N time and you are not really adding any useful information.

 

 

Message 20 of 21
(2,208 Views)