New to LVOOP - need help

[Ben]

---

@tedf1966 wrote:

---

@crossrulz wrote:

I would say you need to shift your thought process.  LVOOP and Action Engines sort of do the same job and rarely work well together.  Get rid of the AE.  Instead, all of your state data should be inside of your object.  In this case, I am referring to your task reference.  Then each case/state of your AE should be a method of the class.

---

One more question. Wouldn't I need to have a parent Hardware class with children for Analog and Digital  because the private data is different for each. numerics and boolean respectively? The Parent class (Hardware would have the task Id and each child would have their own data - numerics for analog and boolean for digital

---

[TedFrancis]

Ben - it seems that your reply is blank. I do not see your response 

[Ben]

---

@tedf1966 wrote:

Ben - it seems that your reply is blank. I do not see your response 

---

That is an imbedded video from YouTube ....

https://youtu.be/JDSPwexlyTo

of the scene from My Fair Lady when Professor Higgins is declaring "I think she's got it!" (which then leads into The Rain in Spain).

Ben

[TedFrancis]

Hilarious - thanks 

I did have one more question 

One more question. Wouldn't I need to have a parent Hardware class with children for Analog and Digital  because the private data is different for each. numerics and boolean respectively? The Parent class (Hardware would have the task Id and each child would have their own data - numerics for analog and boolean for digital

[Ben]

" I need to have a parent Hardware "

An OOP architect may have a purely achademic answer but from where I sit, you COULD get away with making the Analog the parent and making the Digital a child of the Analog.

But it what you wote may be closer to "right".

Ben

[TedFrancis]

So...

Hardware (Parent)

Task Id - Private Data

Get, Set, Start, Stop, Close methods for Task ID

AI - (Child)

Numeric - Private Data

Read Data, write Data methods for Data

DI - (Child) 

Boolean - Private Data

Read Data, write Data methods for Data

Does that seem logical?

[Kevin_Price]

Some first thoughts and adjustments:

Hardware (Parent)

Task Id - Private Data

Get, Set: accessor methods for private Task ID

Start, Stop: regular methods

Read: "virtual" method with required override by children

AI - (Child)

Numeric - Private Data  (consider array for multi-channel and/or multi-sample data)

Read - override method, appropriate for AI hardware

Get - accessor function for private Numeric

DI - (Child) 

Boolean - Private Data (consider array of boolean for multi-channel data)

Read - override method, appropriate for DI hardware

Get - accessor function for private Boolean

Don't love the result I've given.  "Read" seemed useful as a parent-level function for abstraction reasons.  But since child overrides need the same terminal wiring, it can't return the acq data directly.  Thus the data needs to be stored in the object.  That still leaves your app with the need to know what kind of object it has to know which child accessor to call.  Yuck.

Watch for better answers...

-Kevin P

[TedFrancis]

---

@Kevin_Price wrote:

Some quick thoughts and adjustments:

Hardware (Parent)

Task Id - Private Data

Get, Set: accessor methods for Task ID

Start, Stop: regular methods

Read: "virtual" method with required override by children

AI - (Child)

Numeric - Private Data  (consider array for multi-channel and/or multi-sample data)

Read - override method, appropriate for AI hardware

DI - (Child) 

Boolean - Private Data (consider array of boolean for multi-channel data)

Read - override method, appropriate for DI hardware

-Kevin P

---

That makes sense

If I need to read both AI and DI simultaneously (in a while loop) -

1. Do I branch the Hardware class wire to each of their respective Read statements?

2. Does each branch of the Hardware class wire need to go to a shift register on the while loop?

[TedFrancis]

I get what your saying but each child can have its own read method and that will elimante the problem. Right?

---

@Kevin_Price wrote:

Some first thoughts and adjustments:

Hardware (Parent)

Task Id - Private Data

Get, Set: accessor methods for private Task ID

Start, Stop: regular methods

Read: "virtual" method with required override by children

AI - (Child)

Numeric - Private Data  (consider array for multi-channel and/or multi-sample data)

Read - override method, appropriate for AI hardware

Get - accessor function for private Numeric

DI - (Child) 

Boolean - Private Data (consider array of boolean for multi-channel data)

Read - override method, appropriate for DI hardware

Get - accessor function for private Boolean

Don't love the result I've given.  "Read" seemed useful as a parent-level function for abstraction reasons.  But since child overrides need the same terminal wiring, it can't return the acq data directly.  Thus the data needs to be stored in the object.  That still leaves your app with the need to know what kind of object it has to know which child accessor to call.  Yuck.

Watch for better answers...

-Kevin P

---

[Kevin_Price]

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