Intercept a GPIB controller data

[cdavel2]

Hi,

In short, I need to be able to intercept the commands from a GPIB controller to a device that the controller thinks is on the bus.

I have a bus with a controller and one device. I want to be able to be able to replace that device with another device of the same type, but requires commands in a different format (for instance, different spectrum analyzers).

I cannot change the code on the controller device in any way.

I have a WinSystems PC/104 system with a PC/104 GPIB board to do the process.

My idea is to:

   Add another GPIB board to the bus (the PC/104 card);

   Intercept the commands from the controller;

   Change the syntax so the device will understand and send it on;

   Intercept the status reply from the device; 

   Change the syntax and return the status to the controller.

My questions are:

Can this be done?

Since the controller is the CIC and I can't change that, how can I send the commands to the device?

Do I need to split the bus into two separate ones (two cards)?

Any help with this will be greatly appreciated.

Thanks,

Dave

[Snowman 6008]

It sounds like this application is a perfect candidate for IVI http://www.ni.com/ivi/  IVI was designed so that you could swap out different third party instruments of the same generic type without modifying any of your application code.

What you are suggesting would require quite a bit of programming, and would be very fragile. Instead of requiring a single GPIB card and an instrument to work correctly, it would require the correct items sent from the controller, to be read in correctly by the second card, translated sent out again, read in correctly etc... you are essentially adding an additional two areas for bugs and errors to enter your program for every one command sent. I would strongly recommend against this architecture.

In order for you to translate the commands, you would need to know the correct syntax anyway, so why not just start off with a fresh program. It would be easier to write a new program than it would be to write a translation program, not to mention, just like in real-life translation you can run across the problem of  arguements that are not directly translatable. So if your device is IVI compliant, and you wanted to save yourself a larger headache in the future, programming a new application using IVI would be your best bet. That way you could swap out instruments without modifying code easily in the future.

[Albert.Geven]

That is only possible when the IVI instrument driver for at least one of the machines was available.

I don't believe in IVI anymore. The idea was good but debuggng in C is much worse than in LabVIEW.

So as long as IVI is not possible in native LabVIEW I won't join the IVI train.

This said, maybe you can put a software interface on the same spot as NI-spy. This hooks in very low and displays before data is send to the bs and also intercepts before data is sent to the application.

But that is translating and errorprone again.

I only can wish you goodluck and a boss that allows modifying or rewriting the code.