LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

The Private Data Control of a LabVIEW Class is Locked

Hi - I understand that if a class is used in two projects then it is locked - to edit it you need to close one of the projects.  But if a class is used in a single project but on two targets (say a PC and a cRIO) then the class is still locked.  So is it then true that to make a change to the class I need to close the whole project every time?  This doesn't seem right - but maybe this is just the way it is?  What if is a communication class you are developing that for instance can only be tested properly when used on two separate targets?

 

Does anyone have any insights into this?

 

Thanks.

 

Message 1 of 10
(2,524 Views)

@AnthonV wrote:

Hi - I understand that if a class is used in two projects then it is locked - to edit it you need to close one of the projects.  But if a class is used in a single project but on two targets (say a PC and a cRIO) then the class is still locked.  So is it then true that to make a change to the class I need to close the whole project every time?  This doesn't seem right - but maybe this is just the way it is?  What if is a communication class you are developing that for instance can only be tested properly when used on two separate targets?

 

Does anyone have any insights into this?

 

Thanks.

 


Insight? Ideas maybe.

 

LabVIEW does a wonderful job of protecting itself from ... us. It is not fool proof (there is nothing fool proof to a cleaver fool, as I have learned repeatedly from LV R&D*).

 

What would happen if you deploy and run a class on one target and then edit the class to change the data type and then run it on the other node?

 

The locking behaviour make perfect sense to protect against me doing something stupid*.

 

Ben

 

* I once type cast a class as an arry of its parent class and got away with it for mile of wire and code and only failed when it came time to write it to disk. Feedback from R&D ws "Don't do that!'.

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 2 of 10
(2,515 Views)

Thanks for the thoughts Ben, I suppose next you are going to break the news to me that LabVIEW will never give us a pointer (I'm still holding thumbs for that one Smiley Wink).

 

Yes I do see the logic behind it, but nothing stops you from updating a typedef used in more than one application instance (last time I checked) so I cannot see why classes would be different.

 

Anthon

0 Kudos
Message 3 of 10
(2,504 Views)

@AnthonV wrote:

Thanks for the thoughts Ben, I suppose next you are going to break the news to me that LabVIEW will never give us a pointer (I'm still holding thumbs for that one Smiley Wink).

 

Yes I do see the logic behind it, but nothing stops you from updating a typedef used in more than one application instance (last time I checked) so I cannot see why classes would be different.

 

Anthon


Although I can not cite a reference I get the impresion that the VLOOP people look at type defs as a flawed implementation of LVOOP. It is too late to fix the type definitons but LVOOP can still be saved (from us).

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 10
(2,500 Views)

Ironically I erased the following from my previous reply before sending:  "After all, classes are just typedefs dressed up in a fancy wrapper".  But I suppose I might be stepping on a couple of toes if I typed that...

Message 5 of 10
(2,495 Views)

@AnthonV wrote:

Ironically I erased the following from my previous reply before sending:  "After all, classes are just typedefs dressed up in a fancy wrapper".  But I suppose I might be stepping on a couple of toes if I typed that...


And what a wonderful elegant wrapper it is.

 

Smiley Wink

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 10
(2,493 Views)

But seriously, I've been delaying using GOOP for years even though I used OOP extensively in other languages.  This was mainly as I was expecting it being more trouble than it was worth and just a wrapper for typedefs (and also as it was impossible to get the training course to run at the local office).  However, since I've been committing to it (slowly at first) there is no going back for me.  I mostly code for performance critical real-time apps and if you apply the same performance principles (preventing copies etc) there is no reason to get worse performance (I think).

 

Are there any docs that discuss performance considerations with GOOP, GOOP and RT, etc?

 

Anthon

0 Kudos
Message 7 of 10
(2,487 Views)

I avoided GOOP for the smae reason but LVOOP is a different animal. From What I recall, dynamic dispatched VIs will introduce a small performance hit but its small and I mention it not to mislead.

 

There are some papers and I belive the title was something like "LVOOP the decisions behind.." Its here somehwere.

 

 

LVOOP unlike the old GOOP is perfectly capbale of working "in-place" with data copies only occuring on wire branches.

 

DVR will help with those situation where a class needs to be accessed from parallel threads.

 

Ben

 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 8 of 10
(2,483 Views)
(now replying from my nokia so typing skills are reduced) Admittedly i still use seingle elementt q's and not value references but i'll need to make that change too sometime soon. Maybe a dvr is just a seq in a fancy wrapper.
Thanks for the thoughts, looks like i'll just have to accept the annoyance with locked class dependencies for now.
Anthon.


0 Kudos
Message 9 of 10
(2,479 Views)
Message 10 of 10
(2,461 Views)