LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LVOOP Class Mutation

Solved!
Go to solution

Hi, I am just starting out with LVOOP.  I've read the main knowledge-base articles, had a small amount of training (on the Advanced Architectures course) and have had a play with my own classes.

 

I now want to use OOP for a test system, so I created a class with lots of standard data types, DBLs, arrays of DBLs, Int32s, etc.  I created a load of accessor VIs and some manipulation VIs and that was fine.

 

Then I decided to change the name of a member in the private data control (.ctl) from "Voltage Range" to "Voltage Spread" as this is more descriptive for me.  Having used clusters many times before I expected that the bundle names would simply update automatically.  This is not the case.  Having done some searching it would appear that this is all about class mutation.  I can see why LabVIEW would want to monitor changes to the private data control but I want all my VIs to refer to the latest version of the .ctl file.

 

I have had a search online about this but now I am more confused than when I started as there appears to be no simple "right-click and select Update" type command.

 

Any help much appreciated.   By the way, I am using LabVIEW 8.5.

Certified LabVIEW Architect and LabVIEW Champion specialising in Noise, Vibration and Harshness
0 Kudos
Message 1 of 9
(3,846 Views)

If memory serves, renaming an element in the class cluster should correctly modify all the the VIs using that element. You then need to save them for them to remember the new name.

 

If you're talking about the names of the controls in accessor VIs, you are correct that they don't change, but this is not because of mutation. They changed because they are defined as part of the API of the class and that's not something that LV would change automatically. In principle, it's quite possible that the API of the class would have different names and data types than how the data is represented inside the class.


___________________
Try to take over the world!
0 Kudos
Message 2 of 9
(3,828 Views)

Firstly,  thanks for the response.

 

Your first paragraph is the problem I have.  You say that renaming a cluster element label should 'ripple through' and then you need to save all VIs.  This is what I would have expected too.

 

However, I had a cluster item called Voltage Range and I wrote a couple of accessor VIs which read/wrote to it.  I then decided to rename it Voltage Spread which was more descriptive and the accessor VIs did not update, they still had Voltage Range in the bundle / unbundle diagram items.

 

If it had been a cluster it would have blacked out and I'd have a broken wire.  This did not happen.  I exited LabVIEW, saved all, re-opened LabVIEW and now everything is broken and unifxable by normal methods.  I can only guess it is due to mutation but have no idea how to fix it.

Certified LabVIEW Architect and LabVIEW Champion specialising in Noise, Vibration and Harshness
0 Kudos
Message 3 of 9
(3,824 Views)

I've also noticed that the object wires in the VIs that no longer work have become fatter for no apparent reason and the terminals are dynamic even though I did not set them to be.

 

Any help much appreciated!

 

Malcolm

Certified LabVIEW Architect and LabVIEW Champion specialising in Noise, Vibration and Harshness
0 Kudos
Message 4 of 9
(3,817 Views)

Maybe this is something which is specific to your class. I just verified in LV 2009 and renaming an element modifies all the bundles/unbundles correctly. I'm pretty sure that it worked the same way in all older and newer versions.

 

I would suggest you build a simple class and see if it happens there too. If it does, you could try uploading and sending it to NI.


___________________
Try to take over the world!
Message 5 of 9
(3,804 Views)

I had a very small audio class project that works.  I copied it, changed a member lable and it did not ripple through.  I am also seeing black lines around my object wires for no apparent reason.

 

Normal Wire copy.gifBlack Wire copy.gif

 

From what I can read this is something to do with default values, but I cannot find out how to fix it or what the implications are.

 

I doubt NI would be interested in my call as I'm using 8.5 and I'm not on any form of Software Support Programme.  Maybe when I have some money to my name!

 

Thanks for your help

 

Malcolm

Certified LabVIEW Architect and LabVIEW Champion specialising in Noise, Vibration and Harshness
0 Kudos
Message 6 of 9
(3,775 Views)

NI should be interested in fixing bugs for future versions even if you're not on active support. That said, since you're using 8.5 it's quite possible that what you're seeing isn't present in later versions, but there's no way to know without a simple project with reproduction steps.

 

The only valid reason for a wire to change its appearance that I can think of is if the type of the wire changed to another class (or if you changed the wire appearance yourself). The black-for-non-default-value concept should only apply to controls, indicators and constants, but not to wires.


___________________
Try to take over the world!
0 Kudos
Message 7 of 9
(3,771 Views)
Solution
Accepted by topic author Malcolm_Myers

Well, I think I've fixed it.  After much digging I found that LabVIEW does not allow dynamic VIs to have private scope.  Of course, it didn't just let you know that, it told you the class was broken and that the VI needed to be fixed.  Ooh, thanks!  How my VIs came to have dynamic connectors I do not know as I always ask for static.  Nevertheless it somehow chose to change this of its own accord without telling me.

 

Anway, it all looks ok now, but it would be nice to have clearer error explanations!  And clearer help files, dynamic dispatch is covered in part on several different help pages, having it all in once place would just be too obvious I suppose!

 

Thanks for all your help, especially tst!

 

Malcolm

Certified LabVIEW Architect and LabVIEW Champion specialising in Noise, Vibration and Harshness
0 Kudos
Message 8 of 9
(3,762 Views)
Many of the issues you address are much better in LV2012. If you are going to be using classes a lot, you should really upgrade. There are a bunch of nasty bugs in earlier versions.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 9 of 9
(3,752 Views)