Memory considerations while using the Queue and Functional Global techniques

[nathand]

---

amaglio wrote:

I have an U8 variable that I made a type definition out of. I am making this variable a type definition because the size of it may need to be incresed to say U16 in the future. Is there a best way to convert LV integers to my type definition U8 variable. For example, I have a for loop that is iterating through an array, and if I know that the array size is not going to be greater than 256, what is the best way to convert the I32 iteration count to my type definition U8 variable? I tried using the type cast function but it does'nt work because it takes the higher bits of the I32 integer not the lower bits. Any help is greatly appreciated.

---

The conversion functions in the numeric palette will get you from an I32 to a U8.  If you then need to convert to your type definition you can use typecast, but that may not be necessary since LabVIEW will handle most of the conversions for you automatically.  For example if you're bundling your value into a cluster that's already defined to use your U8 type definition, I wouldn't bother to typecast the U8 value.  Sometimes it's simpler to make your type definition an I32 from the start, unless you really need those extra 3 bytes.

---

Also, on another note..... I am looking to buy a  comprehensive and useful LabVIEW book that covers the majority of advandved LabVIEW programming techniques such as Action Engines, Optimizing Performance of VIs, Memory Management, etc.... Is there a "Best Book" out there, or maybe a list of some of the best?

---

I don't have any recommendations on a book; I haven't spent much time looking for one.  The resources available in the NI Forums, on the Info-LabVIEW mailing list, and in the LAVA forums are very helpful and are constantly being updated by people answering questions like yours.  Read through enough postings and you'll pick up all sorts of useful tricks and information - people share some amazing bits of code.  If you're really curious about the details of memory management and optimization, take some computer science classes in lower-level languages that require you to manage all those details yourself.  You'll get an understanding of what the computer is doing when it executes your code, and an appreciation of how nice LabVIEW is for taking care of all those issues.

[amaglio]

Thanks for your help nathand. I ended up using the Variant to Data function for this task, this way if the type of my type definition changes no changes in the code will be necessary... Which is actually my initial reason for using the type definition variable. Right now the possible variations of a variables value does not exceed 256, but in the future they may.... Since the data size of this U8 type def becomes very large, every byte counts. 

[amaglio]

I've got a few questions about storing data with clusters. I am currently reading data from files, and there are many different categories of data within the files and some of the data uses different data types. I am currently storing all of the data in a cluster. I am going to migrate all of this data to an AE. As far as keeping my memory to a minimum, would it be better to have an AE with many different shift registers for each category of data that comes out of these data files as opposed to continue to use the one cluster that stores all of the data?

[DFGray]

That really depends on how you implement it.  Putting each element in a separate shift register will allow you to minimize data copy issues.  However, so will proper programming technique (think In Place Element).  In any case, it is much easier to scale the single-element queue object.  With the queue, you can always add another element to the cluster and always write another get/set function pair.  With an action engine, you will run out of connector pane for data types sooner or later.  You could run through a variant, but then you have to convert it back and you might as well have used the queue, which will be faster because of no data transform.  But lest we get lost in the trees and ignore the forest - do you really want to add that many things to a single action engine?  Would it make sense to divide it up?