Sniffing on GPIB communication using C#

[Nick_F]

We are using some third party software and there are some bugs in it. I would like to make a program in C# that would listen to the GPIB communication taking place between the computer and all instruments connected. When I match a particular command sent to a specific GPIB address, I want to send my own commands, to override the original command. I suspect this could cause a crash in case I happen to send the commands at the same time with the main software (however I am able to do it manually by sending the commands with a delay, when I know there is no other communication on GPIB). I use NI Spy (NI Trace) for manual debugging, but I am not sure if I can use it from within my own program (or maybe there is a better alternative).

Thanks,

Nick

[JÞB]

---

@Nick_F wrote:

We are using some third party software and there are some bugs in it.

---

This line actually made me laugh.

---

When I match a particular command sent to a specific GPIB address, I want to send my own commands, to override the original command.  

---

OK, what is sending the improper command to what instrument?

---

  (or maybe there is a better alternative).

---

Of course, there is a better way! It is suggested by the first line of your post.  STOP using the faulty 3rd party software and re-write the driver to do things correctly.

[Nick_F]

For example, the software zeroes a power sensor, but it forgets to turn off the signal generator that is connected to it (this happens via power splitters and RF relays). So, when I know it is the time to zero the power sensor, I want to give the command to turn off the signal generator before the zeroing actually takes place (the command would be something like RF_OUTPUT OFF). In some cases the software can not adjust the level of a signal generator to a desired level (of course it can't, if the level is already too high and it keeps increasing the level in steps of 0.1dB, until the limit of 30 steps was reached). Then it graciously prompts the operator to set the level manually...

In some other cases, it sends a set of two commands in a single line - one command works fine for one model of instruments, the other works fine for another model. If I test the instrument which responds to the second command, because after the first invalid command it will disregard any remaining commands sent in a single line, it won't have the chance to execute the proper command.

We can't stop using the third party software - by third party I mean it's not made by myself - it is very complex software, it executes thousands of commands, generates reports, etc. And I am not a developer, I am a technician that operates the software (I also made many programs of my own). I asked the developers to fix these issues (and they fixed many), but they focus on new software, they simply don't have the time to fix the minor problems in the old programs. We can run the programs, but this involves us sometimes crawling on the floor and quickly pressing some sequences of keys on some instruments 🙂 So, it sort of works.

But it would be good if I could intercept the GPIB communication and apply some "patches" when necessary.