GOOP updating controls and indicators

[Joseph Oravec]

Hi,

I am finally looking at GOOP again and I'm a lot happier with it this time
now that LV6 is out and control references are available.

I'm looking at the ever-popular temperature-control example on NI's website
for guidance. I have a creator, a GUI-handler, an event-handler, and a
destructor in the main program with self-explanatory connections. In the fan
model they maintained two data locations; one on the front panel and one
within the object and the GUI-handler updated the object with each iteration
of the loop.

This works great until you want to programmatically modify properties.
Unless I'm missing something, the GUI-handler for the fan example returns a
value but wouldn't update the control/indicator properties. I'm left
with
two questions:

1. Is it possible to make the front panel control the items within the
object so I don't have to maintain data within both the FP and the object?
Seems somehow that with typedefs and control references I might finally have
enough to do it. This is where I had given up with LV5.1 because maintaining
two locations is tough.

2. Any other suggestions of tricks I'm missing.

-joey

[RayFarmer]

Hi Joseph,

The answers yes.

Create a reference to your control. Then paste this as a data memeber to your class. Then within your member functions your can use the property node to read and write to your front panel control. See attached llb.

Regards
Ray Farmer

[Joseph Oravec]

"Ray Farmer" wrote in message
news:506500000005000000D5560000-1007855737000@exchange.ni.com...
> Create a reference to your control. Then paste this as a data memeber
> to your class. Then within your member functions your can use the
> property node to read and write to your front panel control. See
> attached llb.

Thanks very much for the attached LLB. It looks very similar to what I was
doing, but you took a unique approach with DisplayDigitalWaveform. Very
cool.

I did see that you had "graph array" which you use to set the
control-reference in that VI. However I'm beginning to question why I even
want to store the data within the object instead of maintaining a single
copy on the front panel and accessing it by reference each time
. Your
example still maintains data on main.vi (written using the reference) and
the object, but it's more clean by doing the write inside a member function.

I'm beginning to question having two copies though. Of course, one good
argument is that storing data inside the goop object allows encapsulation
(private data). However all my data is public anyway. Any major performance
hit for using the reference nodes for every single write instead of the
typical bundle/unbundle inside a GOOP modify member function? Otherwise I
might consider only data on frontpanel and only reference inside object.

-joey

[RayFarmer]

Hi,

My class started out with the data stored but it changed during development to use the reference. I was undecided whether to take it out or leave it in for the moment. So I opted for the later.

Glad its been of some help
Ray

[Manno]

Hello there,
you guys sound pretty interesting. I have joined the labview programming world and I have been dealing with some mad projects. I wanted to start using Goop but the only problem that I have is setting up my hardware like my AI,AO and DIO channels. I wonder if you guys can bring me some light on that.
Thx,
Manno

[RayFarmer]

Hi Manno,

First thing to do is to download the goop toolkit.

Try this link to start with; http://zone.ni.com/devzone/conceptd.nsf/webmain/1A7B60096CE0CDA986256A9A0074E4EC?opendocument&node=DZ52067_US

Hope this gets you going
Ray Farmer

[Manno]

Yes, I have the GOOP toolkit already. what I wanna know is when do I impletment the hardware part. do I implement it in the create class for else where?

I have a sample vi that here that I was playing with, I will attach it for you guys to see. Please give some feedback on it.
Manno

[Manno]

Try this one if the first does not open well.

[Joseph Oravec]

"Manno" wrote in message
news:50650000000500000069600000-1012609683000@exchange.ni.com...
> Yes, I have the GOOP toolkit already. what I wanna know is when do I
> impletment the hardware part. do I implement it in the create class
> for else where?
>
> I have a sample vi that here that I was playing with, I will attach it
> for you guys to see. Please give some feedback on it.
> Manno

I took a look at your sample VI inside the LLB. It didn't load perfectly; I
didn't see the data members CTL. However I think that I got the general idea
of what you were doing.

Your "top-level" VI called TurnThemOn.vi is too complex because you have the
implementation details (DigPort write) on the diagram. For a possibly more
elegant solution, try the following ideas:

- Make your lampCreate VI accept any necessary parameters for "creating" the
object in question. This might be DAQ card, DAQ channels, frontpanel control
reference for a software lamp, etc. Store these within the object as
constants for later use. It seems to make sense to have multiple lamp
objects.

- Although this example was very simple, it helps to divide every piece of
data in the system into logical categories. On a recent labview project I
conceptualized three main groups: controls (sliders, parameters), indicators
(graphs), and things which cause events (menus, buttons).

- Handling (more like hiding) the hardware becomes easy at this point. You
have the object reference which holds all the data necessary to control the
device appropriately. Maybe create a member function like controlLamp.vi
which gets its necessary data from the object reference (DAQ channel
number?) and uses that to turn on/off the lamp correctly.

- How can you tell if your solution is elegant? The interface should be
abstracted from the implementation. If the hardware changes, will your
top-level VI have to change? Hopefully not, because the OO design allows the
programmer to use concepts at the top-level and details hidden in
lower-level functions. If the GUI changes, will the top-level VI have to
change? Also hopefully not, because the GUI simply inputs parameters,
displays results, and generates program events. The objects hold all the
data, and the top-level VI specifies the algorithm at a conceptual level for
processing that data. The interface doesn't have to change the algorithm.

- Once you're past this simple example, the design might become slightly
more difficult. For good performance you'll need to remember parallelism.
This brings up issues of race conditions, deadlock, VI atomicity,
re-entrancy, and all that fun stuff. Just watch out! GOOP is the only way to
do large Labview applications, but it exposes a lot of issues that basic
Labview programmers rarely have to worry about. Be warned!

Good luck with your efforts. Post any more questions, I certianly didn't see
many postings when I was getting used to this programming model. It might be
able to help others.

-joey

[Manno]

Wow!! That was deep. Joey, you give me the big picture. I will move with that. But one thing that I have to tell you too, if I did not any thing OOP background, I would definitely get to the terminologies that you used. Any novice programmer won't be able to follow what you said. Any programmer who happen to be a Labview programmer by trial and error will definitely out of place. GOOP will straight them up.

Thx Joey, I will keep you posted on any improvement. Let's keep it going like that hopefully two months down the road more people will understand the beauty of OOP,OOD and appreciate GOOP. It's beautiful.

Manno