New to LVOOP - need help

[TedFrancis]

Hello all.

Im new to LVOOP but have been programming in Labview for 10 years. 

I have written an AE for DAQmX functions (Initialize task, Get Timing Information, Set timing information, Start, Read, Stop and clear. I want to wrap this in a Hardware class and am not sure i have done so properly.  I have attached snippets of a child of the Hardware class (AI class).  My  questions is

1. Is is okay to wire the AI class to the Shift Register or will i be instantiating additional objects as i call different cases

[crossrulz]

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.

[TedFrancis]

Thank you for your reply.  So there should be a seperate method that calls the DAQmx read, start clear etc tasks?

[Ben]

EDit: Crossrulz said what I said with less words.

While LVOOP and AEs can co-exist, in a very basic sense they are two different froms of implementing common ideas. Encapsulation is one.

I think of the two approaches (LVOOP vs AE) differently.

When developing an AE, the encapulated data is IN the AE.

When developing a LVOOP class the encapsulated data is in the wire.

So one can be thought of as the other turned inside out.

Both approach have restictions that come with them. LVOOP has all of the rules and restictions regarding what is allowed to get at what data and AE's have a single instance and teh AE itself can only be executing in one thread at a time.

Not being a super-duper-LVOOPer, I will speculata that what you have developed is a Singleton design pattern.

If a SIngleton is what you want then fine. But if on the other hand you want to create a LVOOP class that will let you work with mulitple DAQ deveices at the same time, the AE aprt has to go.

Recall above I said the two approaches can be thought of the other turned inside out.

In a LVOOP for DAQ devices the reference to the DAQ device can be stored in the wire. Storig the reference in the wire will let you have multiple wires on your diagram each with their own DAQ task ref. Each of the Actions that we would included in an AE become methods that act on the ref stored in the wire.

The LVOOP wires (one for each instance of the Class) can be stored in shift registers of the VIs that use the available menthods. So instead of the data being inside the AE the data is stored in the wire of the callers.

I will stop there becuase I am not sure if I am helping or not.

Ben 

[Kevin_Price]

My LVOOP experience is pretty modest, but something about the code I see "feels" a little off.

I think the main thing is that the whole AE structure seem to exist to support the shift register containing the DAQmx task.  But if you're going to share that 1 task among all objects, it isn't clear what purpose the class serves.  

If you're making a hardware class to abstract out some common behavior of many instantiated objects, the DAQmx task would belong as a data member of the class (or one of its children, depending on how abstract you're getting).  Then each object has its own task, carried around on the object wire.  Further, instead of an AE-like structure to support multiple actions, you'd make multiple member functions that each perform one of those actions.

Generally, the features offered up by an AE (persistence of state, shared access to single copy of data without copies) are typically handled by member data and member functions in LVOOP.  The USR's aren't needed for state b/c the object wire carries the data.  The AE wrapper isn't needed because member functions mediate access to object data.

-Kevin P

P.S.  Started this before seeing other replies, finished after them.  We're all more or less telling you the same stuff though.

[TedFrancis]

That was very helpful, thank you. Im confused about the following point -

In a LVOOP for DAQ devices the reference to the DAQ device can be stored in the wire. Storig the reference in the wire will let you have multiple wires on your diagram each with their own DAQ task ref. Each of the Actions that we would included in an AE become methods that act on the ref stored in the wire.

Could you elaborate on that point:

1.Storing the refernece in the wire - does this mean having the task Id as part of the private data.

2. I thought branching wires instantiated other objects

[crossrulz]

---

tedf1966 wrote:  1.Storing the refernece in the wire - does this mean having the task Id as part of the private data.

---

Exactly

---

@tedf1966 wrote:2. I thought branching wires instantiated other objects

---

What wires are you branching?  I think what Ben was trying to convey is that you could have multiple objects of the same type each containing their own private data.  The Action Engine (without doing some fun stuff inside of it) only holds the state of 1 "object".

[Ben]

---

@tedf1966 wrote:

That was very helpful, thank you. Im confused about the following point -

In a LVOOP for DAQ devices the reference to the DAQ device can be stored in the wire. Storig the reference in the wire will let you have multiple wires on your diagram each with their own DAQ task ref. Each of the Actions that we would included in an AE become methods that act on the ref stored in the wire.

Could you elaborate on that point:

1.Storing the refernece in the wire - does this mean having the task Id as part of the private data.

2. I thought branching wires instantiated other objects

---

1) Yes

2) Not always. If the wire-branch feeds two operations where one of them does not modify the code, LV will schedule the non-modify work first and then the same data will be used by the other branch.

When I wrote that I was not nessearily speaking of branching a wire. I was imagining a caller State Machine having two shift registers, with a highspeed DAQ controlled by one wire and a lowe spped daq in the other wire. The same LVOOP functions would be used in both wires but used for two different daq devices. That is just one of the nice features of LVOOP. Sinc ethe protected data is not INSIDE the functions you can have multiples. To do the same thing with an AE, you would have to clone the AE.

Ben 

[TedFrancis]

I have a better grasp of this now.  Thank you all for your time and input !!

---

[TedFrancis]

---

@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