LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Having trouble reordering elements in class data cluster

Solved!
Go to solution

HI Code,

 

Now I need the narative.

 

What do you want me to edit where and where are you looking to verify what you think should happen.

 

Screen shots would help also.

 

Thank you,

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 11 of 18
(1,556 Views)

Ok, so when I open the Notes Generator.lvclass file and then open the Notes Generator.ctl control, I can check using context help that the control recognizes the first element (and 2nd and 3rd) of the private data cluster as a typedef. (see screenshot1.jpg)

 

When I open New Notes Generator.vi, I can see from the conversion dots that the data types on the input cluster and the class constant don't match.  Context help shows that the input cluster has the first three elements as typedefs, but the class constant does not.  (see screenshot2.jpg)  So the class data doesn't seem to have updated to match the class control.

 

 

Download All
0 Kudos
Message 12 of 18
(1,553 Views)

Yes I definately need a narative to proceed. Under LV 8.6 everything I tried works as I expect.

 

So please provide a step by step proceedure along with screen shots.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 13 of 18
(1,552 Views)
Solution
Accepted by topic author Quantum_Code_Monkey

Quantum Code Monkey wrote:

Ok, so when I open the Notes Generator.lvclass file and then open the Notes Generator.ctl control, I can check using context help that the control recognizes the first element (and 2nd and 3rd) of the private data cluster as a typedef. (see screenshot1.jpg)

 

When I open New Notes Generator.vi, I can see from the conversion dots that the data types on the input cluster and the class constant don't match.  Context help shows that the input cluster has the first three elements as typedefs, but the class constant does not.  (see screenshot2.jpg)  So the class data doesn't seem to have updated to match the class control.

 

 


 

This may have been fixed in LV 8.6 since I do not see any coercion dots.

 

Please try a simple experiment:

 

Copy your code to some place safe and experiment on a copy.

 

Close the project and all of LabVIEW and then just open the type-def by itself. Edit the type def and save the changes. Close everything (again) and then go back to your project. Does editing the type def with the private data closed help?

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 14 of 18
(1,544 Views)

Ok, here's the full narrative:

 

I saw that the data order on the third element (MOT Powers) of the private data control wasn't what I wanted, so I reordered the elements of the cluster and then verified with context help that the order had changed.  I saved the control (and later saved the class itself from the project window for good measure).  I also updated the order of the clusters in the inputs of the New Notes Generator member VI (by copying and pasting from the private data control).  I verified with context help that the input clusters in this member VI have the right order now.  Then I go back to the New Notes Generator member VI and notice that the order of the clusters within the MOT Powers element in the class wire (from the class constant) hasn't updated.

 

I used the suggestion to convert the clusters (the first three in the private data control) to strict type definitions (something that will be useful for me regardless of how the rest of this works out), and made sure that the private data control and the New Notes Generator member VI both have updated to show that they contain type defs.  (Again, using context help).  But the data coming out of the class constant hasn't updated.  I tried deleting the class constant and manually adding another to the block panel, but that didn't help.  The real problem is that the data order of the MOT Powers cluster/typedef is still unchanged in the class constant.

 

Screenshot3 is context help from the class constant wire (note MOT z2 power reading immediately follows MOT z1 power reading, not the order I want)

Screenshot4 is context help from the private data control (note Hyperfine z1 power reading immediately follows MOT z1 power reading as it should)

Download All
0 Kudos
Message 15 of 18
(1,543 Views)

Ok, I tried your experiment (slightly modified) and it seems to have worked.

 

I couldn't just resave the type def by itself, since the type def was already just the way I wanted it, so I changed one of the data types from a double to a single and then saved it.  The changes seemed to have propogated through.  So then I repeated the whole process and changed the data type back to a double and the changes propogated through again.

 

Strange but true.  Thanks for your help, Ben!!

0 Kudos
Message 16 of 18
(1,535 Views)

You are welcome Quantum.

 

You may be seeing a different manifestation of a bug I reported and was fixed for LV 8.6 that affected type defs in Private data. In my case i was re-naming (or was it deleting) elements from the type-def and LV was crashing or using the wrong value when trying to update the diagrams (there was more than one bug!). R&D claimed they could not re-create the bugs and after going back and forth we finally figured out they (R&D) close everything up before edititng type defs so when they re-opened the project, they never saw the bug. So that experiment was to test if you were seeing what R&D could not.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 17 of 18
(1,531 Views)

 

I know this an old post, but I had the same trouble - I created a cluster without the type definition. 

 

Once I made the cluster strict type definition, I still had elements that were coming up in the wrong labels.

 

I found out that if I right clicked on every instance in the sub vi's, if the option to show the typ defintion did not exist, it was not connected, and the element would get 'lost' from the label.  I deleted the cluster, and copied it from another that was connected to the type definition.  Now everything works.




metzler CLAD
0 Kudos
Message 18 of 18
(1,333 Views)