New to LVOOP - need help

[TedFrancis]

---

@Kevin_Price wrote:

Note that I was editing my reply while you were responding to the original.  As to latest questions:

You would instantiate one AI object and one DI object.  I'm pretty sure it'd then be helpful to cast them to "look like" parent object wires using "To More Generic Class" in the Class palette.  I *think* this would be needed if you wanted to make an array of these child objects to loop through.  

   So then you'd have two of these parent-looking but child-acting objects and you'd definitely use a shift register to hold them so the same objects keep getting acted upon with every iteration.  The Read function (in my suggested layout that I'm not terribly excited about) on the diagram would be the "virtual" parent Read function, and dynamic dispatch would know which child function to call based on the actual object riding on the parent-looking wire.

-Kevin P

---

Thank you

[Kevin_Price]

Got our replies overlapping again.

I've *done* some LVOOP, but I don't generally find it real natural to *think* LVOOP for app architecture and class design.  Hopefully others can give you additional advice here.  Meanwhile, making distinct "Read" functions in each child class without having one in the parent kinda does solve the problem I didn't like in my layout.  However, it also reduces one of the major benefits of using an LVOOP approach.

The times I've used it, the "magic" happens when you can write app-level code solely in terms of parent functions.  Then all manner of child objects can be hurled through the same code path.  You wouldn't need to have branching logic to call either the AI's "Read" or the DI's "Read" depending on which kind of child was be acted upon.  Once you start putting all that branching logic scaffolding back in, it's kinda not in the spirit of LVOOP.

Not saying this as a purist, just that the drive toward abstraction at the top level of the app is where LVOOP yields a lot of its benefit to help make up for the development overhead of accessor functions, inheritance trees, override methods, etc.  Unless you get back most of that abstraction benefit, then the overhead may not be worth it.  In my (limited) experience.

-Kevin P

[TedFrancis]

---

@Kevin_Price wrote:

Got our replies overlapping again.

I've *done* some LVOOP, but I don't generally find it real natural to *think* LVOOP for app architecture and class design.  Hopefully others can give you additional advice here.  Meanwhile, making distinct "Read" functions in each child class without having one in the parent kinda does solve the problem I didn't like in my layout.  However, it also reduces one of the major benefits of using an LVOOP approach.

The times I've used it, the "magic" happens when you can write app-level code solely in terms of parent functions.  Then all manner of child objects can be hurled through the same code path.  You wouldn't need to have branching logic to call either the AI's "Read" or the DI's "Read" depending on which kind of child was be acted upon.  Once you start putting all that branching logic scaffolding back in, it's kinda not in the spirit of LVOOP.

Not saying this as a purist, just that the drive toward abstraction at the top level of the app is where LVOOP yields a lot of its benefit to help make up for the development overhead of accessor functions, inheritance trees, override methods, etc.  Unless you get back most of that abstraction benefit, then the overhead may not be worth it.  In my (limited) experience.

-Kevin P

---

I agree with what you said.  I was going to use the AE for DAQmX functions that I had written for structured programming originally in this APP but that is not in the spirit of LVOOP.  However it seems trying to wrap DAQmX functions in a class leaves me without the polymorphism benefit we should receive by using classes in the first place

[Ben]

---

@TedFrancis wrote:

---

....  However it seems trying to wrap DAQmX functions in a class leaves me without the polymorphism benefit we should receive by using classes in the first place

---

I have done it but I am not allowed to give it away.

The strict nature of LV's wires does present a challenge to using LVOOP at higher levels in LV but it is do-able.

Instead of trying to get the data out (since this is the stumbling at this point in teh discusion) leave the data in the Class and ask what are you going to do with the data that does come out.

Plot It?

Display it in an idicator?

Log it to file?

Check for safety violations?

If you add a method something like Update, each child calss can do what ever is appropriate for that type of data.

Analogs can access a Chart using a control ref to a chart and push updates to a logger.

Ben

[TedFrancis]

---

@Ben wrote:

---

@TedFrancis wrote:

---

....  However it seems trying to wrap DAQmX functions in a class leaves me without the polymorphism benefit we should receive by using classes in the first place

---

I have done it but I am not allowed to give it away.

The strict nature of LV's wires does present a challenge to using LVOOP at higher levels in LV but it is do-able.

Instead of trying to get the data out (since this is the stumbling at this point in teh discusion) leave the data in the Class and ask what are you going to do with the data that does come out.

Plot It?

Display it in an idicator?

Log it to file?

Check for safety violations?

If you add a method something like Update, each child calss can do what ever is appropriate for that type of data.

Analogs can access a Chart using a control ref to a chart and push updates to a logger.

Ben

---

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.

[Ben]

---

@TedFrancis wrote:

---

...

---

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 strongly believe there is a limit to how far we SHOULD go with LVOOP in LV. Sure in theory you can go "full-LVOOP" but that obfuscates thw elegance lf LV.

Concider adding to the "Init" of the DAQmx class a Queue ref input. Forr those that are not passing to a queue it will be a no-op. For Analogs the queue is used in the "Update" method and then you handle reading from the queue as if no LVOOP involved.

Ben

[TedFrancis]

---

Concider adding to the "Init" of the DAQmx class a Queue ref input. Forr those that are not passing to a queue it will be a no-op. For Analogs the queue is used in the "Update" method and then you handle reading from the queue as if no LVOOP involved.

If I understand this - the Update method is DD and will accept the data of the class being pushed to it and then can process accordingly.  Im confused about the queue ref. Would you please elaborae

1. Where exactly is the queue ref placed? What is the "init"?

2. Am I passing a reference to the DAQmx class from the Data Acq loop to the processing loop

---

[Ben]

I fear I am harming you more than I am helping!

This may help

or

maybe this

or

one of these

Final thought for now. Stop thinking about HOW to code it and focus on WHAT to code.

The big picture will tell you what methods you need, the details will be handled in the Child classes.

Ben

[crossrulz]

---

@Ben wrote:

I strongly believe there is a limit to how far we SHOULD go with LVOOP in LV. Sure in theory you can go "full-LVOOP" but that obfuscates thw elegance lf LV.

---

As someone who uses LVOOP in all projects, I could not agree more.

I am feeling like we are just going into a deep black hole here.  Is OOP and inheritence even needed here?  So let's take a step back.  What exactly is the goal here?

[TedFrancis]

Is OOP and inheritence even needed here?  So let's take a step back.  What exactly is the goal here?

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

There will also be a DD vi to handle the processing and analysis of the data which will vary from part to part as well 

Typically I would use a QSMH with a DAQ loop and then paralell loops to handle the display, analysis and graphing of the data.  This approach, which I have used over and over , forces me to use many case structures, which I'm trying to get away from.

Additionally, since many of these functions are used with each app i write, I felt developing classes would speed development time and scalibility when adding new parts to the family