06-15-2018 08:17 AM
I would like the save into a file (ini or txt) the configuration of the front panel. The front panel include several clusters. In these "main" clusters, there are other clusters. The second part is to update the front panel according to data previously saved into the ini or txt file.
I tried several things without success. I should mention that I am a beginner in LabView. 😞
Please see the typical front panel in the attached file with the implemented solution/try.
The best for me will be to use the standard LabView librairie. But if it is not possible or too complicated, I am ok tu use openG for instance or MGI but I do not know how to use it.
Thank you in advance for your help.
Solved! Go to Solution.
06-15-2018 09:56 AM
I don't have the Open-G libraries, to try out what you have, but in general you just need to save all your control values to a file. It can be a simple text file using the "Write Delimited Spreadsheet.vi" and "Read Delimited Spreadsheet.vi"
Here is an example, granted it has a lot less controls than yours but you should get the idea.
06-15-2018 09:58 AM
Another nice solution that I found was to use XML conponents. The "save" proceed is well done in the .txt file.
However, the load proccess is not working. "texte IN" and "texte OUT" are exactly the same but the "value" indicator remains empty. Then, I do not know if the For loop is working to update the font panel.
06-15-2018 10:08 AM
Thank you for your answer.
It could be a solution but since I have a lot of controls, it is critical. Also, I have other panels, close to this one but with additional controls so I would like something that I could reuse whatever the font panel.
If there is no "automatic" solution, I will try yours.
06-15-2018 10:23 AM
The OpenG read and write panel VIs are the quickest and easiest way to start using config files. I usually only have a couple of parameters I need to remember for the next application load, so I tend to use the cluster VIs instead. If you write the panel, it will save everything including graph data, which will become very slow for large amounts of data.
06-15-2018 01:04 PM
I had not previously noticed the OpenG routines for handling Cluster Data in a Configuration File. I tried it, and it seems to work! What I did was make a VI with a copy of your Input Settings Cluster, write a little test routine (shown in the "disabled" part of this Snippet) that did an Open Config Data, Write INI Cluster (OpenG), then Close Config Data. To read it, I did as shown below.
Worked like a charm. However, the output Indicator (INI Data) was not "pretty" like the Input. Suggestion -- when creating Clusters, always right-click them, choose Create TypeDef, and create a TypeDef of the Cluster. Now if you want to put a Control or Indicator "matching" your Cluster, just plop down the TypeDef you just created! A little-known "trick" with Cluster TypeDefs is that if you have the Cluster on your Block Diagram (which if it has many components, can take up a lot of Screen Space), if you double-click the edge of the Cluster, it will collapse into its Icon under which it was saved. This will probably be an "unhelpful" Generic LabVIEW Icon, but if you create your own Icon for your TypeDefs, it will show the Icon you created. Talk about self-documenting ...
06-15-2018 01:46 PM
What do you mean not "pretty"?
06-15-2018 02:55 PM
I'm saving 1000 words (well, about 950 ...)
The Control on the Left was the Input (from the User), done as a Silver (= pretty) Control, while the Right shows what LabVIEW makes, by default. Note I did say that the OP should make a TypeDef out of the Cluster, then could use that as the Indicator and it, too, would be "pretty". Also, there is "hidden" data in the last Cluster element that shows up on the right, but is not visible (not sure why) in the Control on the left.
06-15-2018 03:01 PM
Ah I see. I think the "default control style" is set for each VI, so maybe you have it set to "modern"?
Strict type def will enforce that all instances of a control look identical, so sometimes I will set the typedef to strict type def to make everything look nice. Then set it back to type def so that it can still be edited on the front panel.
06-15-2018 03:07 PM
Yes, but it is more than just the Style. The OP also had "Decorations" in the Cluster to handle some of the 2D arrays (two columns, multiple rows, the Decorations "name" the Columns) which need a TypeDef to work.
I have to confess I don't (quite) understand what you were saying about Strict (versus Permissive?) TypeDefs. I create TypeDefs for Clusters (and Enums, and sometimes Arrays) all the time, and I don't think I've ever given much thought to Strict, Yes or No, but have been happy with the Default. What am I missing?
Bob "Still Learning" Schor