LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LVOOP object state sharing between concurrent loops in a class VI


nathand wrote:

Ben wrote:

NI has carefully never said that the class wire is just a reference. If you look at the VI the LVOOP creates, you will see that they are the form where the icon connectors are on the root of the diagram and on the icon connector so the data is not necessarily copied into the LVOOP method but can be acted on in-place (see teh Clear as Mud thread).


I'm pretty sure a class wire acts just like a cluster, with exactly the same rules about in-place operations, which items are stored inline (fixed-size data types) versus stored as references (strings and arrays), and when a copy is made.


 

Thank you Nathan for "Listening to what I meant and not what I wrote."! 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 11 of 22
(2,853 Views)

In place is an excellent way of handling this, as tst says, and it sounds like that would possibly be the right choice.  However, you may have the same issues with the In Place Element Structure as you do with semaphores simply because when you actually reference the object, nothing else can access this bit of memory thereby causing other attempts to reference the object in question hang until the object is dereferenced.

 

Cheers, Matt

0 Kudos
Message 12 of 22
(2,851 Views)

mtat76 wrote:

...However, you may have the same issues with the In Place Element Structure as you do with semaphores simply because when you actually reference the object, nothing else can access this bit of memory thereby causing other attempts to reference the object in question hang until the object is dereferenced.


There is one crucial difference - a semaphore only provides the lock. A DVR/SEQ manages the actual data as well, which is my understanding of what the OP wanted (essentially by-ref OOP, which is quite a common request).


___________________
Try to take over the world!
0 Kudos
Message 13 of 22
(2,839 Views)

tst wrote:

There is one crucial difference - a semaphore only provides the lock. A DVR/SEQ manages the actual data as well, which is my understanding of what the OP wanted (essentially by-ref OOP, which is quite a common request).


The original poster said they wanted a way to pass data between loops, where those loops happen to be inside of a VI that's part of a LVOOP class - or at least, that was my reading of it.  If that's true, I'd ask: "What would you do if this VI wasn't part of a class?"  I don't think there was any request for a by-ref object.
0 Kudos
Message 14 of 22
(2,834 Views)
I think you're right and I misunderstood the question. Based on my current understanding of the problem, I would probably still use a SEQ/DVR (if it's generated in an Init method, it will be shared among all instances which come out of that method), but I think my understanding of the problem is not good enough.

___________________
Try to take over the world!
0 Kudos
Message 15 of 22
(2,822 Views)

toad wrote:
Hi all, What's the best way of transfering the state of an object between 2 loops on a class VI? ....

 

 Any ideas? Phill


This is how I transfered the state.

 

SendState.png

 

 

I should have thought of this earlier.

 

Ben

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

I hope I'm not hijacking the thread here, but I was wondering how the approach would differ if the loops were running in separate VIs?  Say for example you create  an object in your main VI, but you want to periodically update the object in a subVI launched with VI server...  Would you use a named single element queue, store the class in an action engine/functional global, or something else entirely? 

 

Thanks,

JasonP - CLD

0 Kudos
Message 17 of 22
(2,806 Views)

Jason P wrote:

I hope I'm not hijacking the thread here, but I was wondering how the approach would differ if the loops were running in separate VIs?  Say for example you create  an object in your main VI, but you want to periodically update the object in a subVI launched with VI server...  Would you use a named single element queue, store the class in an action engine/functional global, or something else entirely? 

 

Thanks,

JasonP - CLD


 

 

Unamed. See above.

 

The code I showed

 

SendState.png 

 

is the method executed by each instance when the main app is trying to save the state of all of the VI launched plug-ins.

 

 

 

Ben 

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 18 of 22
(2,802 Views)
Thanks to all of you for your very interesting discussions and observations! I'm thinking of trying the queue as we are using 8.5.1 I presume I can limit the queue to contain a single entry, and that the get/put operations are atomic. Regards Phill
0 Kudos
Message 19 of 22
(2,793 Views)

Hi all

 

Does anyone know what the concurrency / thread safety aspects of In Place Structures and data reference read / write elements?

 

I'm revisiting the original problem and am trying the class reference solution.

 

I create a reference to my controller class object and pass this to my various views.

 

This allows the views to communicate directly with the controller from an in place structure.

 

I'm just worried whether I need to protect access to the class controller.

 

Regards

 

P

0 Kudos
Message 20 of 22
(2,228 Views)