GPIB bus error c#remoting

[densmore]

I'm adding function into my data aquc. program so that I can communicate with a few instruments over IEEE 488.2 interface. I wanted the communication over 488.2 to be indpendent of the DAQ program to that incase something happens to the stand alone instruments we can still run the DAQ program. So I decieded to try remoting so that I can pass information from other programs to my daq program.

To test the idea I made a simple class (dtc) that has all the calls to the gpib card in it. I also made a server app. and a clinet app. In the client app I create an instance of the dtc and call methods that are in it's class. Everything works great if both the server and client are on the same machine. But I need the expandability for the gpib card
(server) to be on one machine and the client to be on another, connected over a network. When I run the client on a seperate computer. I get the following exception:


Unhandled Exception: System.InvalidOperationException: GPIB bus error ---> NationalInstruments.NI4882.GpibException : Gpib bus error
--- End of innter exception stack trace ---
at d.a(GpibStatusFlags )
at b.c(GpibStatusFlags )
at c.b(string )
at NationalInstrumenst.NI4882.device.write(string data)
at dtc..ctor(Int32 deviceadd, Byte instruadd)
at Client.Main()

I'm using C#. Can anyone help out?? Thanks

JMD

[Glenn Burnside]

From the exception you got back, I believe that your NI4882 object is actually instantiated locally on the client, rather than remotely on the server, and the exception is occuring because there is no board/instrument with which to communicate on the client. Is it possible that you are unintentionally still activating the dtc object locally?

What kind of remoting activation are you using to get an instance of the remote dtc class ? Is it server-activated or client-activated? Are you using the app.config file to define your remoting configuration, or are you doing it in code?

Glenn Burnside
National Instruments

[densmore]

I thought I was creating a server-activated object. I'm using the "new" method inside the client to create the object. And I'm using a app.config file to do the configuration. Any help would be useful. I've attached a zip om the code I'm using. Thanks

JMD

[Elton Wells]

I don't have the hardware setup to actually test this, but looking at your code and your config files, it looks like in both cases a local instance of the dtc object is created. One way that you can verify this is to run it locally, as when it seemed to be working, and then call RemotingServices.IsTransparentProxy on the dtc object. If RemotingServices.IsTransparentProxy returns false, the instance is local.

The main problem that I see is that you're configuring a server-activated object, but then attempting to create the object with a non-default constructor. Check out the MSDN article Server Activation for more details. In particular, from the first paragraph:

"Only a proxy is created in the client application domain when a client requests an instance of a server-activated type. However, this also means that only default constructors are allowed for server-activated types when you use the default implementations. To publish a type whose instances will be created with specific constructors that take arguments, you can use client activation or you can dynamically publish your particular instance."

Since you were configuring your object to be a server activated singleton, I'm guessing that changing to client activation is not going to work for you since this could enable multiple instances on the server. I think your best option will be to create the dtc object on the server and then publish it via RemotingServices.Marshal. If you really want server activation but with the ability to pass constructor parameters from the client, another option would be to create a singleton server activated dtc factory object, get a reference to that from the client, then call a factory method on this object with your parameters to get your remote dtc objects.

Also, one other little suggestion ... since you've created the IDtc interface and have built it in a shared assembly, I suggest moving the dtc implementation class to the server assembly, then making all calls to the dtc object through an interface reference on the client. That way you can update the implementation on the server if you want to without having to redistribute an updated shared assembly to the client.

Hope this helps.

- Elton