New to LVOOP - need help

[crossrulz]

---

TedFrancis wrote:

I believe that polymorphism will be a major benefit in the app im writing, .  Im writing a series of test sequences to test a family of valves. The sequences will vary from part to part, so I will have a dynamic disptach vi that will perform these sequences based on the part chosen as opposed to a case structure to handle the variations

---

So make the valve under test the object.  You will have a different class for each specific valve all inheriting from the parent (family valve).  You can setup whatever DAQ you need to inside of the initialization method (keep the task inside of the parent object).  The analysis methods can handle the data however they need to.

[TedFrancis]

Thats the direction that Im going and Im understanding that part of it.  My post earlier asked how to communicate with paralell loops. Typically I enqueued my data to each of the loops that needed it.  I think now I have to enqueue a reference to the class to the loops that need that data. I have read that I can only use a single element queue which if true, would create a problem - I think. Im sampling data in the 5Khz range.

---

[crossrulz]

What I have done for a somewhat similar program was I had a data acquisition loop that then used User Events to send the data everywhere.  Whoever registered for the data would get it via an Event Structure.  The other loops I had included State Machine/data processing and logging.  So I had my processing loop just recieve the data from the DAQ loop and process it.  Results were then sent to the logging loop.

Now where the OOP came into play.  I actually could get data from different instruments, so those were one type of object.  From what I am hearing, this is not a concern for you.  I also had different types of ways to process the data, so those were a different family of objects.  This is all the OOP you should worry about at this point in time.

So the conclusion I am trying to get to is that your processing objects should not care where the data is coming from, as long as it is all there.  Just have a loop performing the DAQ and send it to whoever cares.  The processing loop can then do whatever with the data.  Do not have the DAQ task in your processing object.

[TedFrancis]

So the conclusion I am trying to get to is that your processing objects should not care where the data is coming from, as long as it is all there.  Just have a loop performing the DAQ and send it to whoever cares.

I agree.  Its the sending part im unsure of. Would sending a reference of the class to each loop requiring the data be an appropriate soulution? 

[crossrulz]

You should only have 1 processing loop.  Use a queue or User Event to send the data to that loop and let the object methods process the data.  If the processed data is needed somewhere else (logging, display in graph), then make sure the object methods format the data properly to send to those other loops.

[TedFrancis]

I thought that sending data in a queue violates encapsulation. Have I misuderstood this?

[crossrulz · Accepted solution]

In this case, the raw data does not need encapsulated.  Any process variables should be encapsulated in the object.  If you need "old" data for part of the process, that can be encapsulated in the object.  But the fresh data straight from the DAQ, no reason for encapsulation.

[TedFrancis]

I have a better understanding of this now - thank you everybody for your help !

[Ben]

---

@TedFrancis wrote:

I have a better understanding of this now - thank you everybody for your help !

---

The best way to say thank you to crossrulz is to click that star next to his posts.

If there was a sinlge post that really made a diffrence, mark that as a solution.

The frequent flyers hree can not Kudo (the star thing) themselves so they have to be earned through good answers.

Ben

[Yamaeda]

---

---

Thanks Ben.

I will be displaying, logging to file and graphing.  This will be done in a paralell loop. typically I would send data through a queue but it is my understanding in LVOOP this would violate encapsulation.  Im thinking I need to create a reference, since objects are by-val but I'm unsure of the actual implemnentation of this.

---

I see you've already got an answer, but i had to comment on this.

Having functions to Get or Set data is in no way a violation of encapsulation. Direct access and manipulation of the data from another place is. If you e.g. have an AE with the data instead you have no protection of the data and although you might implement it so that noone touches it, it's not encapsulated.

As to LVOOP and by-value, G# and GOOP uses references to the objects. G# also inherits from a core G# object (inspired from C#) so you can send a G# object ref as event data and work with any object in the consumer.

/Y