From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
05-24-2016 06:52 PM
Hello there,
@Bob_Schor - is it possible that your second snippet will eventually not work? The Get Cluster Information vi does not return the elements of the clusters but only an array containing the data types of the elements (according to the description).
I have been tackling a similar problem for some time and managed to find a solution in this (old) post: https://decibel.ni.com/content/docs/DOC-10524 which enabled me even to manage arrays within my (unknown) input cluster (I am still working on LV 2014 where the variant VIs are indeed hidden gems).
But then I bumped into a problem: what if the cluster contains another cluster?
With respect to the data type I can easily account for that by using a "cluster" case and extract the necessary information about my sub-cluster elements with the get type info vi.
But how do I get down to the values of the cluster within the cluster? The above method won't work - unless the 2015 version of the get info vi works differently (which I doubt).
To be honest: I am rather curious about the issue than aching for a solution. I should be able to solve my specific problem with the XML-strategy mentioned above.
But I still have the feeling, I'm missing out on a rather simple answer.
05-25-2016 08:35 AM
@Sheepyhollow wrote:Hello there,
@Bob_Schor - is it possible that your second snippet will eventually not work? The Get Cluster Information vi does not return the elements of the clusters but only an array containing the data types of the elements (according to the description).
Oops! You are absolutely correct. There is a solution (which I've successfully used, but assumed the afore-mentioned "native LabVIEW function" replaced -- shame on me for not testing thoroughly. In the NI Tools Network, the OpenG set of Tools, particularly OpenG LabVIEW Data Library, contains several functions that you can use for this purpose, including Get Cluster Element by Name and Cluster to Array of VData, which is what I thought the LabVIEW function was more-or-less doing.
I have been tackling a similar problem for some time and managed to find a solution in this (old) post: https://decibel.ni.com/content/docs/DOC-10524 which enabled me even to manage arrays within my (unknown) input cluster (I am still working on LV 2014 where the variant VIs are indeed hidden gems).
But then I bumped into a problem: what if the cluster contains another cluster?
Ah, recursion, always a lot of fun. Basically, if you have a function called "Take Apart Cluster" that "does the right thing" by taking apart the elements of a Cluster and returning, say, a flat Array of text that describes the Cluster, what do you do when an element is a Cluster? Why, you pass that (sub-) Cluster to "Take Apart Cluster", i.e. you make the function call itself. To implement this in LabVIEW, you need to make the function Reentrant. If you haven't worked with Reentrant functions or recursion before, it can be a little mind-bending, but it does work and can solve problems such as this.
To be honest: I am rather curious about the issue than aching for a solution. I should be able to solve my specific problem with the XML-strategy mentioned above.
Indeed, an XML parser needs to be recursive ...
Bob Schor
05-25-2016 12:32 PM
@Bob_Schor wrote:In the NI Tools Network, the OpenG set of Tools, particularly OpenG LabVIEW Data Library
Bob Schor
Yes, that's where most suggestions lead to - I wonder if there is a "native" solution, though.
Concerning the recursion issue - it won't work with native functions for the same reason as above.
I have build a simple (and limited) example and will post this I I have a bit more time.
05-25-2016 12:56 PM
Well, the OpenG functions (which have been around for at least a decade) all use "native" LabVIEW (though some of the functions might be "hidden" in VI.Lib). I took a look at how Cluster to Array of Variant worked -- they basically flatten the Variant to a String (which contains an internal description of the data) and Type Descriptors (which has the "type" information in some internal LabVIEW format too complex for most of us), then use these to, element by element, convert the particular Element (parsed from the String) to a Variant (using information from the Type Descriptors), resulting in an Array of Variants. A tad messy, and I'm glad I didn't have to dream this up ...
Bob Schor
05-26-2016 07:27 AM
While risking sounding like a broken record...
THe Nugget I linked above dealt with clusters of arrays of clusters of arrays... used recursion... And only resorted to variants in one situation when I had to figure how large an array was before going back to native LV data types. While I only implemented a lmited number of data types ( the ones I needed) it does expalin how and it ofers a full set of VIs to show how it was done.... back in the day.
Ben
05-26-2016 09:32 AM
@Sheepyhollow wrote:Hello there,
@Bob_Schor - is it possible that your second snippet will eventually not work? The Get Cluster Information vi does not return the elements of the clusters but only an array containing the data types of the elements (according to the description).
If you use a Variant to Data with Array of Variants as conversion, instead of the current one, data should be retained.
/Y
05-26-2016 09:43 AM
/Y
05-26-2016 09:53 AM
@Ben wrote:While risking sounding like a broken record...
As long as you don't do these scratchy noises...
You are right to point on this Nugget again - I must admit that I started reading and lost track after a while because I was a bit overwhelmed by too many unfamiliar things, there is still a lot of stuff I have not yet played around with..
But I'll give it another try since the initial problem/task you describe is exactly the same that I am dealing with now and it's furthermore adressing several other issues and question that I already came across (and, partly, solved in my way).
However, I started out on control references in the first place because it is the only way I found to transfer a 'flexible' cluster to another save-data-VI (I don't have fully "arbitrary" clusters because I still can control their content, but I different VIs with different needs).
Thanks for the reminder!
05-28-2016 11:47 AM - edited 05-28-2016 11:55 AM
Wow, Yamaeda-san -- using Variant to Data to transform a Cluster to an Array of Variants seems much simpler than what the equivalent OpenG function does! I'll have to try this to convince myself that it works, but just because you can do something using complex, tricky-to-understand code doesn't mean that "straight-forward and simple" won't work!
Bob "Always Learning" Schor
P.S. -- It really does work!
05-28-2016 11:56 AM
Funny... I was quite close to that one but I failed to see the potential. I once wired a blank variant to the conversion VI and found that some of the no-go-errors disappeared.
But I didn't get the point.
Thanks, all!