Write/ Read Keys problem

[ian_fung]

hi all,
I am looking for your advise for the attached vi for writing/ reading keys.

Facing problem:
Since the input/ output is of cluster of mixed control types, I am having problem to write & read all settings correctly. I am sure that I must have missed out something IMPORTANT 😛

I have tried indexing "TypeDesc" to Variant's "Type" input as well as Fixed it DBL/ I32. However, both methods do not seem working well. I am still having problems with "Use Dirty Transmitter"(Boolean) and "arrays" types.

Any suggestion would be very much appreciated.

Best regards
ian.f

[Ben]

Hi Ian.f,

I always welcome the chance to help a fellow enthusiast. Unfortunetly I think I will be of limited use.

First let me say that the best resource to answer this question is probably Jeane-Piere Drolet becuase I think he has cracked this nut in some of his code from "OpenG".

That being said, let me do what I can for now. There are a number of issues that are hitting you. First is the arrays. You are currently reading them as a variant and attempting to convert (this is where Jeane-Piere may be able to help). The data is coming to you as a variant because the array of refnums for the cluster are generic types that handle all data types. If you use a "to more specific" node you can convert these nodes to the actual class of data used. The complication them becomes "which tpye do I convert which ref to?" Agian I think Jeane-Piere has got this figured.

I have accomplished what you appear to be attempting in a more specific fashion. I will try to outline my approach below.

1) Make the cluster a strict type def. My appraoch usese the same cluster in more than one place and this will simplify support.

2) Instead of using refnums to the individual cluster elements, use a refnum for the entire cluster.

3) When trying to update the cluster, update the ENTIRE cluster. I have not figured out how to update just a part of a cluster using control refs.

4) When trying to save use a "unbundle" by name to break-out your parts and save them as required for each type.

5) For the arrays I will create a new section for each array. In that section I will have at minimum a field called "number_of elements" or similar. This filed will get the array length. If there are elements in the array, I will start writing them as "element1",..
This gives me enough data to put things back together at restore time.

I am curious how you end up solving this challenge. I have successfully written code that will automatically locate all of the controls and indicators on the front panel of a VI of my choosing and save/restore them from file BUT, it does not support the complex data types like clusters and arrays. I still have to do these explicitely.

I will watch this question to see if I can help or learn more.

Ben

[JeanPierre]

Who summoned me? ;¬)

indeed we have written VIs to read/write variant data from/to config files. See http://sourceforge.net/projects/opengtoolkit and download the three packages error, lvdata and variantconfig.

Write Key (Variant).vi parses variant data and writes it to config file. Arrays and clusters are parsed recursively to any level of embedding. Key names are generated automatically from data names strored in the type descriptor of the data.

Read Key (Variant).vi accepts a variant input and populates it with data read in the ini file. Also recursive to any level of cluster/array embedding.

[Ben]

Thanks Jean-Pierre!

I am going to have to pressure my legal types to decide once and for all if I can use the OpenG source.

Its sort of frustrating knowing there is a solution out there but I am just not allowed to use it.

Ben

[ian_fung]

hi Ben,

Yes, you are right that Jean-Pierre Drolet did a great job on this matter. In fact, I found one of his solutions at

http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=5065000000080000001F250000&UCATEGORY_0=_49_%24_6_&UCATEGORY_S=0&USEARCHCONTEXT_QUESTION_0=Type+descriptor&USEARCHCONTEXT_QUESTION_S=0

Here's my solution (with helps from Jean-Pierre Drolet's solution)

Comments welcome.
Thank you, Ben.

Best regards
ian.f

[ian_fung]

hi Jean-Pierre Drolet

I am in total agree with Ben.
You are of great help, indeed.

Give you ***** stars!

Warmest regards
ian.f k

[Ben]

Hi Jean-Pierre,

I finally got the legal type to look into things, but already I am confused.

Your link makes it look like this is part of OpenG.

Is this part of and covered by the OpenG license?

Ben

[JeanPierre]

Yes it is part of the OpenG Toolkit for LabVIEW.
The main purpose of the license is to make sure that the code remains open source and nobody else can license it as his property.

Otherwise you can use the code at will for your internal use. If you distribute an application that use OpenG VIs, then you must allow the end user to eventually relink to upgraded version of the toolkit e.g. the OpenG VIs are released in a separate LLB with their source code (or offer to make this available for up to three years)