GOOP Across a Network

[bbean_labview@altavista.com]

Is it possible manipulate a GOOP object on a remote machine? I am
trying to create a GOOP object for an instrument that is connected to a
remote machine. I would like to be able to query and manipulate the
instrument's object data on the local machine, but the actual read data
method for the instrument needs to be executed on the remote machine.

My initial thought process was to create a method to read the
instruments data, then call that method via a Call by Reference Node
(passing the object reference through the call by reference node). But
I get an error that indicates the object is not found/doesn't exist.

Has anyone who GOOPs tackled remote instrumentation before? Is there
an easy way to do this with GOOP? I know how to
pass data via VI
Server or call by reference node, but I am interested in trying out
GOOP and have hit a little roadblock.


Sent via Deja.com http://www.deja.com/
Before you buy.

[alkazaa]

bbean_labview@altavista.com schrieb:

> Is it possible manipulate a GOOP object on a remote machine? I am
> trying to create a GOOP object for an instrument that is connected to a
> remote machine. I would like to be able to query and manipulate the
> instrument's object data on the local machine, but the actual read data
> method for the instrument needs to be executed on the remote machine.
>

Right, the 'instrument read method' has to be executed on the remote
machine. But the GOOP object is created and exists on the local machine.

>
> My initial thought process was to create a method to read the
> instruments data, then call that method via a Call by Reference Node
> (passing the object reference through the call by reference node). But
> I get an error that indicates the object is not found/doesn't exist.
>
> Has anyone who GOOPs tackled remote instrumentation before? Is there
> an easy way to do this with GOOP? I know how to pass data via VI
> Server or call by reference node, but I am interested in trying out
> GOOP and have hit a little roadblock.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

In order to access the intrument, the GOOP object has to call a read sub
vi on the remote machine via the VI-Server mechanism. It needs to know the
reference to the the remote 'read instrument.vi'. This VI-reference is part
of the (local) GOOP object's private data and MUST exist in the local
object's data space. This means that 1) either it is opened ('created') in
the GOOP object's init method and closed ('destroyed') in the destructor
method or 2) is created and destroyed immediately before and after the
remote VI call. I clearly prefer method 1) since it has less overhead.
In order to open the remote VI-reference you have actually to open two
refs: one to the remote LV application, which is fed into the 'Open
strictly typed VI-reference' to get the ref to the remote 'Read
instrument.vi'. (I am not sure at this stage whether the ref to the remote
LV application has to be alive all the time or whether it may be destroyed
after succesfully calling of 'Open strictly typed VI-reference'. I guess it
has to be open all the time, but it is easy to find out by trial and
error.)


I did a project where the main application offers the possibility to
plug-in any (sourcing or measuring) instrument, provided a driver interface
VI with a well defined structure exists (or is written for it). The
advantage is that a large and very complex application can easily (by
writing just one VI) be extended to use ANY available instrument. The
information which instruments could be used is communicated to the main app
by text-based ini files. I could get this working only with the GOOP
approach and don't see any realistic chance without using OO paradigms
(regardless of the language used). Of course, in my project the next
natural step would be to use (in addition to the instrument's VISA, GPIB or
serial address) a host machine name to identify the remote machine where
the instrument is hooked up to and then call remote instruments as easily
as local ones.


This having said I want to issue a call to all GOOPers who follow this
thread:
It seems this small(?) community is growing and it would be nice to have a
list of people using GOOP. I suggest to send me short mail, 'outing'
yourself as GOOPers, maybe with a brief description of planned or finished
projects that use GOOP. I would then distribute the answers to all those
who responded.



Franz Ahlers

[bbean_labview@my-deja.com]

Franz,

Thanks for your detailed reply. I'm new to GOOP and OO paradigms, but
I think they would work well once I grasp the concepts. One person
here has essentially created objects for some our instruments; however,
they're done in C++ and require dll calls (gets messy when dll's are
missing or in the wrong place, but I guess its a good technique because
it seems that's how many of the standard LabVIEW vi's Queues,
semaphores, etc are developed). Anyway, he has been helpful in
introducing me to the concepts of OO but I'm having difficulty
translating practices used C such as abstract classes, virtual methods,
virtual tables, overiding, overloading etc because I can't see how they
are carried out in LabVIEW (and I've never done OO programing in C++).

For instance, say you create a multimeter object in LabVIEW. If you
have different instances (HP, Tektronix, etc) you still end up using
case statements inside the methods to impelement the instrument calls.
Does anyone one know NI's plans for advancing GOOP. I know
polymorphism has been introduced in LabVIEW 6.0, but is it true
polymorphism? My understanding from the manual is that you can only
one level of a VI can have polymorphism. In other words you can't have
polymorphic VI's inside a polymorphic VI.

Thanks again. Also see more disjointed rambling below.

Brian

In article <39EE968F.84440E29@ptb.de>,
franz.ahlers@ptb.de wrote:
> bbean_labview@altavista.com schrieb:
>
> > Is it possible manipulate a GOOP object on a remote machine? I am
> > trying to create a GOOP object for an instrument that is connected
to a
> > remote machine. I would like to be able to query and manipulate the
> > instrument's object data on the local machine, but the actual read
data
> > method for the instrument needs to be executed on the remote
machine.
> >
>
> Right, the 'instrument read method' has to be executed on the remote
> machine. But the GOOP object is created and exists on the local
machine.
>
> >
> > My initial thought process was to create a method to read the
> > instruments data, then call that method via a Call by Reference Node
> > (passing the object reference through the call by reference node).
But
> > I get an error that indicates the object is not found/doesn't exist.
> >
> > Has anyone who GOOPs tackled remote instrumentation before? Is
there
> > an easy way to do this with GOOP? I know how to pass data via VI
> > Server or call by reference node, but I am interested in trying out
> > GOOP and have hit a little roadblock.
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
> In order to access the intrument, the GOOP object has to call a read
sub
> vi on the remote machine via the VI-Server mechanism. It needs to
know the
> reference to the the remote 'read instrument.vi'.

It seems like the read "read instrument.vi" would contain all of the
calls to the instrument to avoid having to open multiple vi references
for different "reading" functions. For that matter, it would seem like
you would want your vi to be called "read/write instrument.vi" so that
you could read the instrument and change its settings all through one
remote vi call. I was also wondering if this "read/write
instrument.vi" would created using the standard GOOP wizard or GOOP
techniques such as the GOOP Timer
(http://www.calbay.com/timing/GOOPTimer.htm). At what point do you
disconnect yourself from GOOP and just use the traditional instrument
driver functions in your methods?

This VI-reference is part
> of the (local) GOOP object's private data and MUST exist in the local
> object's data space. This means that 1) either it is opened
('created') in
> the GOOP object's init method and closed ('destroyed') in the
destructor
> method or 2) is created and destroyed immediately before and after the
> remote VI call. I clearly prefer method 1) since it has less overhead.
> In order to open the remote VI-reference you have actually to open two
> refs: one to the remote LV application, which is fed into the 'Open
> strictly typed VI-reference' to get the ref to the remote 'Read
> instrument.vi'. (I am not sure at this stage whether the ref to the
remote
> LV application has to be alive all the time or whether it may be
destroyed
> after succesfully calling of 'Open strictly typed VI-reference'. I
guess it
> has to be open all the time, but it is easy to find out by trial and
> error.)
>
> I did a project where the main application offers the possibility to
> plug-in any (sourcing or measuring) instrument, provided a driver
interface
> VI with a well defined structure exists (or is written for it). The
> advantage is that a large and very complex application can easily (by
> writing just one VI) be extended to use ANY available instrument. The
> information which instruments could be used is communicated to the
main app
> by text-based ini files. I could get this working only with the GOOP
> approach and don't see any realistic chance without using OO paradigms
> (regardless of the language used). Of course, in my project the next
> natural step would be to use (in addition to the instrument's VISA,
GPIB or
> serial address) a host machine name to identify the remote machine
where
> the instrument is hooked up to and then call remote instruments as
easily
> as local ones.
>
> This having said I want to issue a call to all GOOPers who follow this
> thread:
> It seems this small(?) community is growing and it would be nice to
have a
> list of people using GOOP. I suggest to send me short mail, 'outing'
> yourself as GOOPers, maybe with a brief description of planned or
finished
> projects that use GOOP. I would then distribute the answers to all
those
> who responded.
>
I haven't committed to GOOP yet. Mainly because I haven't spent enough
time attempting it. I guess I want to make sure I have the structure
correct before I go re-writing code that all ready works pretty well.
However I sit here every day and see how the C++ guy made instrument
and objects and think that OO works perfectly for instrument
development. Does anyone have any sample code developed with the GOOP
wizard for an instrument object? That would be really helpful.
> Franz Ahlers
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.

[Greg_McKaskle2]

> Is it possible manipulate a GOOP object on a remote machine? I am
> trying to create a GOOP object for an instrument that is connected to a
> remote machine. I would like to be able to query and manipulate the
> instrument's object data on the local machine, but the actual read data
> method for the instrument needs to be executed on the remote machine.
>
> My initial thought process was to create a method to read the
> instruments data, then call that method via a Call by Reference Node
> (passing the object reference through the call by reference node). But
> I get an error that indicates the object is not found/doesn't exist.
>
> Has anyone who GOOPs tackled remote instrumentation before? Is there
> an easy way to do this with GOOP? I know how to pass data via VI
> Server or call by reference node, but I am interested in trying out
> GOOP and have hit a little roadblock.
>

As already pointed out, the GOOP references only mean something to the
VIs that made them, on the machine where the create occurred. That is
because each Create Instance VI allocates memory and returns a reference
to the memory. Other applications and other machines can't directly
reference it.

That doesn't mean that you are stuck though. The reference number still
makes sense to the VI that created it. If you use the VI Server to execute
the GOOP access VIs on the remote machine, giving it the reference that it
created, then it will work fine. It has no idea where the call is coming
from, and doesn't care.

To avoid having VI Server Call By Reference VIs all over your local diagram,
you might want to consider making a proxy. A proxy is a thin communication
wrapper that looks like the GOOP VIs, but doesn't do the work. The proxy
just asks the remote machine to do the work, and returns the result. To
build one, just make a copy of the GOOP VIs to the local machine, delete
the contents of the diagrams and have them use VI Server to do the execution
on the remote machine. If you want the proxy to be general, then you may
want to add an input that gives you the reference to the LV where these will
be run. If you don't want to generalize, have them get the reference from
a global, and make sure its setup before the first call.

Greg McKaskle

[bbean_labview@my-deja.com]

In article <39EEF60D.7A588AFC@austin.rr.com>,
gmckaskle@austin.rr.com wrote:
> > Is it possible manipulate a GOOP object on a remote machine? I am
> > trying to create a GOOP object for an instrument that is connected
to a
> > remote machine. I would like to be able to query and manipulate the
> > instrument's object data on the local machine, but the actual read
data
> > method for the instrument needs to be executed on the remote
machine.
> >
> > My initial thought process was to create a method to read the
> > instruments data, then call that method via a Call by Reference Node
> > (passing the object reference through the call by reference node).
But
> > I get an error that indicates the object is not found/doesn't exist.
> >
> > Has anyone who GOOPs tackled remote instrumentation before? Is
there
> > an easy way to do this with GOOP? I know how to pass data via VI
> > Server or call by reference node, but I am interested in trying out
> > GOOP and have hit a little roadblock.
> >
>
> As already pointed out, the GOOP references only mean something to the
> VIs that made them, on the machine where the create occurred. That is
> because each Create Instance VI allocates memory and returns a
reference
> to the memory. Other applications and other machines can't directly
> reference it.
>
> That doesn't mean that you are stuck though. The reference number
still
> makes sense to the VI that created it. If you use the VI Server to
execute
> the GOOP access VIs on the remote machine, giving it the reference
that it
> created, then it will work fine. It has no idea where the call is
coming
> from, and doesn't care.
>

When you refer to GOOP VI's and GOOP "access" VI's do you mean the low
level Private Function Vi's (Classname Constructor, Classname Create,
Classname Destroy, etc)? Also, does this mean all activity for the
object is executed on the remote machine (construction, create,
methods, etc)?


> To avoid having VI Server Call By Reference VIs all over your local
diagram,
> you might want to consider making a proxy. A proxy is a thin
communication
> wrapper that looks like the GOOP VIs, but doesn't do the work. The
proxy
> just asks the remote machine to do the work, and returns the result.
To
> build one, just make a copy of the GOOP VIs to the local machine,
delete
> the contents of the diagrams and have them use VI Server to do the
execution
> on the remote machine.

When you say "have them use VI Server to do the execution on the remote
machine", do you mean:

1) Delete the contents of the diagram and leave the controls
2) Open an application reference to labview on the remote machine
3) Open a reference to the specified GOOP VI (with correct remote GOOP
VI path wired)
4) Wire the local VI's controls to multiple Invoke Nodes which use the
"Set Control Value" Method.
5) Use the Invoke Node with the "Run VI Method"
6) Read the values from the remote VI using multiple Invoke Nodes
with "Get Control Method"
7) Close VI Reference


Thanks a bunch for your help.
Brian

> If you want the proxy to be general, then you may
> want to add an input that gives you the reference to the LV where
these will
> be run. If you don't want to generalize, have them get the reference
from
> a global, and make sure its setup before the first call.
>
> Greg McKaskle
>


Sent via Deja.com http://www.deja.com/
Before you buy.

[Greg_McKaskle2]

> When you refer to GOOP VI's and GOOP "access" VI's do you mean the low
> level Private Function Vi's (Classname Constructor, Classname Create,
> Classname Destroy, etc)? Also, does this mean all activity for the
> object is executed on the remote machine (construction, create,
> methods, etc)?
>

I don't mean the low level VIs. I mean the exported VIs for a class.
The construction and all other activity occurs on the remote machine
in control of the client or local machine. So in otherwords, only the
VIs that a user of the GOOP object would use need to be wrapped.

> When you say "have them use VI Server to do the execution on the remote
> machine", do you mean:
>
> 1) Delete the contents of the diagram and leave the controls

Yes.

> 2) Open a
n application reference to labview on the remote machine

I'd probably open it once and store it, but yes, this will work too as
long as it is closed as often as its opened.

> 3) Open a reference to the specified GOOP VI (with correct remote GOOP
> VI path wired)

Yes, or Open the references earlier, along with the application reference,
and store them to be indexed when you need them. Again, as long as you
close the reference the same number of times that you open them, it will
work, but it will be faster to load these these once and reuse the reference.

> 4) Wire the local VI's controls to multiple Invoke Nodes which use the
> "Set Control Value" Method.
> 5) Use the Invoke Node with the "Run VI Method"
> 6) Read the values from the remote VI using multiple Invoke Nodes
> with "Get Control Method"

I'd use the Call by Reference instead. This lets you wire the controls
and indicators directly to the connector pane, almost as if it was a local
VI call. What you describe will work,
but it is harder, and if you don't
somehow synchronize the Run with the completion of the thing running, then
you could have problems. Again, the Call by Reference does this automatically.

> 7) Close VI Reference
>

Greg McKaskle

[Jörgen Jehander]

Hi,

In the OO world this issue is often referred to as distributed objects.
I have used GOOP for this in numerous projects since it makes it
possible to encapsulate all needed VI server programming for accessing
remote, distributed, objects. Here are some information about it.

How do you communicate with an object that is running on another
machine? Let us illustrate this by having a Climate_Controller object on
a remote machine running LabVIEW. The GUI, graphical user interface, to
the Climate_Controller object is supposed to execute on another machine.
How does the GUI communicate with the object running on another machine?
The solution is to have a mirror of the Climate_Controller object on the
GUI machine.

This is implemented by using the VI Server scheme for the communication
and a design pattern called Proxy.

A proxy object is used for controlling access to objects. In our case,
we would need a proxy object to create a mirror of the distributed ,
real, object. The proxy and the real object can then be placed on
different machines. Every time we need to access the real object we use
the proxy object. For more information about the Proxy design pattern
see Design Patterns, Elements of Reusable Object-Oriented Software, ISBN
0-201-63361-2 Erich Gamma, Richard Helm, Ralph Johnson and John
Vlissides.

The proxy pattern for classes to be distributed is based on two
different classes, the Real class and the Proxy class. The Real class is
the one to be distributed. The Proxy class controls the access to the
Real class, i.e. it performs the necessary communication using the VI
Server scheme.

The Proxy contains two specific attributes, a real refnum and an
application refnum, for identifying a specific connection to a Real
object. They are initialized in a method called Bind. This means for
example that the Real object often is created during the Bind method!
The Real object is then destroyed when the Proxy object is destroyed. A
connection between a Proxy object and a Real object is therefore
performed when the bind method is called on the Proxy object. After that
a successful bind has been executed it is possible to call a method on
the Proxy object and have the corresponding method invoked on the Real
object.

The Proxy object provides a gateway to the distributed Real object and
thus acts like a proxy object. Applications using proxy objects become
very powerful since they can control real objects, located everywhere,
very easy.

We are going to have a presentation about this topic on NI-DAYS here in
Sweden so we will publish the presentation together with some example
GOOP classes on our web, www.endevo.se. It will be available from mid
November.

J�rgen Jehander



In article <8sl78t$kli$1@nnrp1.deja.com>,
bbean_labview@altavista.com wrote:
> Is it possible manipulate a GOOP object on a remote machine? I am
> trying to create a GOOP object for an instrument that is connected to
a
> remote machine. I would like to be able to query and manipulate the
> instrument's object data on the local machine, but the actual read
data
> method for the instrument needs to be executed on the remote machine.
>
> My initial thought process was to create a method to read the
> instruments data, then call that method via a Call by Reference Node
> (passing the object reference through the call by reference node).
But
> I get an error that indicates the object is not found/doesn't exist.
>
> Has anyone who GOOPs tackled remote instrumentation before? Is there
> an easy way to do this with GOOP? I know how to pass data via VI
> Server or call by reference node, but I am interested in trying out
> GOOP and have hit a little roadblock.
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>


Sent via Deja.com http://www.deja.com/
Before you buy.

[bbean_labview@my-deja.com]

J�rgen,

I actually have the Design Patterns book you are referring to. I'll
study the proxy pattern in a more detail. As a whole, the book is a
little over my head for now because most of the discussion uses C++ and
Smalltalk as examples. I really need to see actual examples in LabVIEW
to fully understand the concepts they discuss in the book. So I look
forward to seeing your example GOOP classes on your website,
particularly the Proxy Class. In the meantime, I'll try to get the
guys at work to let me purchase the GOOP class notes you have on the
website.

Thanks for your help,
Brian

In article <8snemo$dc4$1@nnrp1.deja.com>,
J�rgen Jehander wrote:
> Hi,
>
> In the OO world this issue is often referred to as distributed
objects.
> I have used GOOP for this in numerous projects since it makes it
> possible to encapsulate all needed VI server programming for accessing
> remote, distributed, objects. Here are some information about it.
>
> How do you communicate with an object that is running on another
> machine? Let us illustrate this by having a Climate_Controller object
on
> a remote machine running LabVIEW. The GUI, graphical user interface,
to
> the Climate_Controller object is supposed to execute on another
machine.
> How does the GUI communicate with the object running on another
machine?
> The solution is to have a mirror of the Climate_Controller object on
the
> GUI machine.
>
> This is implemented by using the VI Server scheme for the
communication
> and a design pattern called Proxy.
>
> A proxy object is used for controlling access to objects. In our case,
> we would need a proxy object to create a mirror of the distributed ,
> real, object. The proxy and the real object can then be placed on
> different machines. Every time we need to access the real object we
use
> the proxy object. For more information about the Proxy design pattern
> see Design Patterns, Elements of Reusable Object-Oriented Software,
ISBN
> 0-201-63361-2 Erich Gamma, Richard Helm, Ralph Johnson and John
> Vlissides.
>
> The proxy pattern for classes to be distributed is based on two
> different classes, the Real class and the Proxy class. The Real class
is
> the one to be distributed. The Proxy class controls the access to the
> Real class, i.e. it performs the necessary communication using the VI
> Server scheme.
>
> The Proxy contains two specific attributes, a real refnum and an
> application refnum, for identifying a specific connection to a Real
> object. They are initialized in a method called Bind. This means for
> example that the Real object often is created during the Bind method!
> The Real object is then destroyed when the Proxy object is destroyed.
A
> connection between a Proxy object and a Real object is therefore
> performed when the bind method is called on the Proxy object. After
that
> a successful bind has been executed it is possible to call a method on
> the Proxy object and have the corresponding method invoked on the Real
> object.
>
> The Proxy object provides a gateway to the distributed Real object and
> thus acts like a proxy object. Applications using proxy objects become
> very powerful since they can control real objects, located everywhere,
> very easy.
>
> We are going to have a presentation about this topic on NI-DAYS here
in
> Sweden so we will publish the presentation together with some example
> GOOP classes on our web, www.endevo.se. It will be available from mid
> November.
>
> J�rgen Jehander
>
> In article <8sl78t$kli$1@nnrp1.deja.com>,
> bbean_labview@altavista.com wrote:
> > Is it possible manipulate a GOOP object on a remote machine? I am
> > trying to create a GOOP object for an instrument that is connected
to
> a
> > remote machine. I would like to be able to query and manipulate the
> > instrument's object data on the local machine, but the actual read
> data
> > method for the instrument needs to be executed on the remote
machine.
> >
> > My initial thought process was to create a method to read the
> > instruments data, then call that method via a Call by Reference Node
> > (passing the object reference through the call by reference node).
> But
> > I get an error that indicates the object is not found/doesn't exist.
> >
> > Has anyone who GOOPs tackled remote instrumentation before? Is
there
> > an easy way to do this with GOOP? I know how to pass data via VI
> > Server or call by reference node, but I am interested in trying out
> > GOOP and have hit a little roadblock.
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> >
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>


Sent via Deja.com http://www.deja.com/
Before you buy.

[Niels Harre]

Hi J�rgen,

A simple question:
Is the Bind method - you are refering to below - embeded in the creator of
the Proxy class?

Thanks in advance.

Niels Harre, M.Sc.

DHI Water & Environment
Agern All� 11
DK-2970 H�rsholm
Phone: +45 45 16 92 00
Direct phone: +45 45 16 94 75

mailto:nha@dhi.dk or mailto:niels@harre.dk
http://www.dhi.dk

....a merger between Danish Hydraulic Institute and VKI - Institute for the
Water Environment


"J�rgen Jehander" wrote in message
news:8snemo$dc4$1@nnrp1.deja.com...
> Hi,
>
> In the OO world this issue is often referred to as distributed objects.
> I have used GOOP for this in numerous projects since it makes it
> possible to encapsulate all needed VI server programming for accessing
> remote, distributed, objects. Here are some information about it.
>
> How do you communicate with an object that is running on another
> machine? Let us illustrate this by having a Climate_Controller object on
> a remote machine running LabVIEW. The GUI, graphical user interface, to
> the Climate_Controller object is supposed to execute on another machine.
> How does the GUI communicate with the object running on another machine?
> The solution is to have a mirror of the Climate_Controller object on the
> GUI machine.
>
> This is implemented by using the VI Server scheme for the communication
> and a design pattern called Proxy.
>
> A proxy object is used for controlling access to objects. In our case,
> we would need a proxy object to create a mirror of the distributed ,
> real, object. The proxy and the real object can then be placed on
> different machines. Every time we need to access the real object we use
> the proxy object. For more information about the Proxy design pattern
> see Design Patterns, Elements of Reusable Object-Oriented Software, ISBN
> 0-201-63361-2 Erich Gamma, Richard Helm, Ralph Johnson and John
> Vlissides.
>
> The proxy pattern for classes to be distributed is based on two
> different classes, the Real class and the Proxy class. The Real class is
> the one to be distributed. The Proxy class controls the access to the
> Real class, i.e. it performs the necessary communication using the VI
> Server scheme.
>
> The Proxy contains two specific attributes, a real refnum and an
> application refnum, for identifying a specific connection to a Real
> object. They are initialized in a method called Bind. This means for
> example that the Real object often is created during the Bind method!
> The Real object is then destroyed when the Proxy object is destroyed. A
> connection between a Proxy object and a Real object is therefore
> performed when the bind method is called on the Proxy object. After that
> a successful bind has been executed it is possible to call a method on
> the Proxy object and have the corresponding method invoked on the Real
> object.
>
> The Proxy object provides a gateway to the distributed Real object and
> thus acts like a proxy object. Applications using proxy objects become
> very powerful since they can control real objects, located everywhere,
> very easy.
>
> We are going to have a presentation about this topic on NI-DAYS here in
> Sweden so we will publish the presentation together with some example
> GOOP classes on our web, www.endevo.se. It will be available from mid
> November.
>
> J�rgen Jehander
>
>
>
> In article <8sl78t$kli$1@nnrp1.deja.com>,
> bbean_labview@altavista.com wrote:
> > Is it possible manipulate a GOOP object on a remote machine? I am
> > trying to create a GOOP object for an instrument that is connected to
> a
> > remote machine. I would like to be able to query and manipulate the
> > instrument's object data on the local machine, but the actual read
> data
> > method for the instrument needs to be executed on the remote machine.
> >
> > My initial thought process was to create a method to read the
> > instruments data, then call that method via a Call by Reference Node
> > (passing the object reference through the call by reference node).
> But
> > I get an error that indicates the object is not found/doesn't exist.
> >
> > Has anyone who GOOPs tackled remote instrumentation before? Is there
> > an easy way to do this with GOOP? I know how to pass data via VI
> > Server or call by reference node, but I am interested in trying out
> > GOOP and have hit a little roadblock.
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
> >
>
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

[Jörgen Jehander]

Hi Niels

Yes the Bind method should be called inside the Create method. Therefore
the Bind method should be private and not a public method in the Proxy
class.

J�rgen

In article <8ta3sj$moo$1@news.net.uni-c.dk>,
"Niels Harre" wrote:
> Hi J�rgen,
>
> A simple question:
> Is the Bind method - you are refering to below - embeded in the
creator of
> the Proxy class?
>
> Thanks in advance.
>
> Niels Harre, M.Sc.
>
> DHI Water & Environment
> Agern All� 11
> DK-2970 H�rsholm
> Phone: +45 45 16 92 00
> Direct phone: +45 45 16 94 75
>
> mailto:nha@dhi.dk or mailto:niels@harre.dk
> http://www.dhi.dk
>
> ...a merger between Danish Hydraulic Institute and VKI - Institute for
the
> Water Environment
>
> "J�rgen Jehander" wrote in message
> news:8snemo$dc4$1@nnrp1.deja.com...
> > Hi,
> >
> > In the OO world this issue is often referred to as distributed
objects.
> > I have used GOOP for this in numerous projects since it makes it
> > possible to encapsulate all needed VI server programming for
accessing
> > remote, distributed, objects. Here are some information about it.
> >
> > How do you communicate with an object that is running on another
> > machine? Let us illustrate this by having a Climate_Controller
object on
> > a remote machine running LabVIEW. The GUI, graphical user interface,
to
> > the Climate_Controller object is supposed to execute on another
machine.
> > How does the GUI communicate with the object running on another
machine?
> > The solution is to have a mirror of the Climate_Controller object on
the
> > GUI machine.
> >
> > This is implemented by using the VI Server scheme for the
communication
> > and a design pattern called Proxy.
> >
> > A proxy object is used for controlling access to objects. In our
case,
> > we would need a proxy object to create a mirror of the distributed ,
> > real, object. The proxy and the real object can then be placed on
> > different machines. Every time we need to access the real object we
use
> > the proxy object. For more information about the Proxy design
pattern
> > see Design Patterns, Elements of Reusable Object-Oriented Software,
ISBN
> > 0-201-63361-2 Erich Gamma, Richard Helm, Ralph Johnson and John
> > Vlissides.
> >
> > The proxy pattern for classes to be distributed is based on two
> > different classes, the Real class and the Proxy class. The Real
class is
> > the one to be distributed. The Proxy class controls the access to
the
> > Real class, i.e. it performs the necessary communication using the
VI
> > Server scheme.
> >
> > The Proxy contains two specific attributes, a real refnum and an
> > application refnum, for identifying a specific connection to a Real
> > object. They are initialized in a method called Bind. This means for
> > example that the Real object often is created during the Bind
method!
> > The Real object is then destroyed when the Proxy object is
destroyed. A
> > connection between a Proxy object and a Real object is therefore
> > performed when the bind method is called on the Proxy object. After
that
> > a successful bind has been executed it is possible to call a method
on
> > the Proxy object and have the corresponding method invoked on the
Real
> > object.
> >
> > The Proxy object provides a gateway to the distributed Real object
and
> > thus acts like a proxy object. Applications using proxy objects
become
> > very powerful since they can control real objects, located
everywhere,
> > very easy.
> >
> > We are going to have a presentation about this topic on NI-DAYS here
in
> > Sweden so we will publish the presentation together with some
example
> > GOOP classes on our web, www.endevo.se. It will be available from
mid
> > November.
> >
> > J�rgen Jehander
> >
> >
> >
> > In article <8sl78t$kli$1@nnrp1.deja.com>,
> > bbean_labview@altavista.com wrote:
> > > Is it possible manipulate a GOOP object on a remote machine? I am
> > > trying to create a GOOP object for an instrument that is connected
to
> > a
> > > remote machine. I would like to be able to query and manipulate
the
> > > instrument's object data on the local machine, but the actual read
> > data
> > > method for the instrument needs to be executed on the remote
machine.
> > >
> > > My initial thought process was to create a method to read the
> > > instruments data, then call that method via a Call by Reference
Node
> > > (passing the object reference through the call by reference node).
> > But
> > > I get an error that indicates the object is not found/doesn't
exist.
> > >
> > > Has anyone who GOOPs tackled remote instrumentation before? Is
there
> > > an easy way to do this with GOOP? I know how to pass data via VI
> > > Server or call by reference node, but I am interested in trying
out
> > > GOOP and have hit a little roadblock.
> > >
> > > Sent via Deja.com http://www.deja.com/
> > > Before you buy.
> > >
> >
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.