visa control of an executable running on the host PC

[Mike....]

I write executables for my customer using LabVIEW.  My customers often use other programming environments, such as Visual BASIC or C.  They also control instruments remotely using the VISA layer.  They are comfortable with the concepts of sending commands to instruments using VISA. I have a request from a customer to also be able to control my executable using the VISA layer.  They would treat my executable as if it were another instrument.  They would manually launch the executable on their PC.  Then they want to address it from their programming environment (maybe Visual BASIC, or C, or Matlab) using the TCPIP::localhost::instr address and send commands to my executable program.  In my executable I would monitor for these commands, and then respond to them as needed. My question is, is there an easy way to do this?  A simple example would help me tremendously.  The example I am looking for would be a LabVIEW executable that would monitor the "address" TCPIP::localhost::instr for a *IDN? command.  An outside test program would send this command to the VISA address TCPIP::localhost::instr.  When the executable receives the command, it would reply with "Hello."  If I can get this far, then I can use this model to implement the commands that are required to control the executable. Thank you for any help. 

[smercurio_fc]

Would they be willing to control your program via ActiveX? You can enable the ActiveX server in your app and they can simply control it that way.

[Mike....]

Thank you for the response.

No, active X would not be welcome.  They want to send commands using the VISA layer, to keep things consistent with the rest of their program.

[smercurio_fc]

In that case it seems that you're basically looking to be like an instrument vendor who wants to adhere to the VXIplug&play's VISA specification for their instrument. This seems to me like a tall order. I assume you could get the VISA spec from the IVI foundation. That would probably contain the information you're looking for.

Just to see what happens when you send an *IDN? command to an instrument over VISA I ran Wireshark, and I noted a bunch of packets going back and forth between my computer and the instrument over several different ports. The packet that contained the actual *IDN? command was one of them. Whether or not you can safely ignore the other packets I have no clue. 

[Mike....]

Thanks for the response.

Yes, making my executable "look like" a VXI PnP instrument is exactly what I want to do...

If I have to program this from scratch, I agree that this is a tall order.  But I was hoping that NI already implimented what I need...

Certainly, they have the portion that allows me to send commands to an instrument and read responses from an instrument using VISA.  My question is if there is a way to use the same VISA read routine in my executable to monitor and wait for a command to come from somewhere else, and when the command comes in, can I then respond to it using the VISA write routine?

I am assuming that this is not possible, but maybe I am wrong? 

If it is not possible, perhaps someone has done something similar that I can use, such as the TCP read and write, which I have never used before.

My end goal is to provide my customer with a well known and easy way to send the commands to my executable.  (By using a VISA write.)  This way I know that they already have the capability in their existing programs, and they will be able to do this will little effort from their side. 

So it would be ok for me to use a TCP read (or any other approach) in my executable as long as it can intercept the VISA write that was sent from my customer's program (which is not written in LabVIEW). 

Asked from another ponit of view altogether, is there a way to impliment the equivilent of NI-Spy in a LabVIEW executable.  This would at least allow me to monitor all VISA traffic, and I can scan the traffic for commands that are intended for my executable.  That would solve 1/2 of the problem, and would be a start. 

Thanks again for the response.

[Dennis_Knutson]

It sounds like your customer is being a bit unrealistic. The typical thing to do would to provide them a dll that any c programmer should be able to call and is probably already being done in their programs. This idea of emulating an instrument is pretty far off the norm. I have heard of external pc's being used to emulate an instrument.

And I don't believe it is possible to use any VISA Reads or Writes in your program.

[RavensFan]

Would it truly be that hard?  If you have your basic LabVIEW program, then add in another parallel loop that handles the communication.  It listens for commands on a TCP/IP channel.  Parses them out and passes the commands into the real part of the program.  If there is a response, it reads a local variable, queue, action engine, whatever and passes a response back out.

It would all be VISA communication.  It wouldn't be at the level where the computer shows up as some sort of instrument in MAX which is what I think would be the ridiculous request.

[Dennis_Knutson]

I'm not sure it would work. The calling program would be writing to a VISA resource. That's no different than what we do in LabVIEW. If that VISA resource does not exist, would you not get an error indicating invalid resource? I'm not sure what it would really take to simulate a VISA TCP/IP resource. For VXI-11, it's quite complex and requires a VXI-11 server.

[smercurio_fc]

---

Ravens Fan wrote:

Would it truly be that hard?  If you have your basic LabVIEW program, then add in another parallel loop that handles the communication.  It listens for commands on a TCP/IP channel.  Parses them out and passes the commands into the real part of the program.  If there is a response, it reads a local variable, queue, action engine, whatever and passes a response back out.

It would all be VISA communication.  It wouldn't be at the level where the computer shows up as some sort of instrument in MAX which is what I think would be the ridiculous request.

---

The problem is that the short capture I did with Wireshark indicates there's other packets being sent back and forth that are not commands. These are probably part of the VISA spec, but as to what they are I have no idea. I also have no idea how the low-level VISA API would interpret not seeing these packets from the "instrument". If they're part of the communication would it interpret it as an error?

[Mike....]

I guess this is a good discussion.  I have seen this type of thing provided before, where software emulates an instrument.  I liked it a lot because I could control the software from LabVIEW without doing anything special at all.  (VISA writes and reads.)  But I agree this is a bit off the normal track. 

If I can not do it with VISA writes and reads, is there a chance I can do it with the TCP writes and reads?  It looks like this is a good way to send messages between two different programs, and LabVIEW supports it for sure.  My concern is if my customer will be able to easily send the commands to a TCPIP port in their software.  Again, Visual BASIC, C and Matlab are common programs that my customers will have.  Do they also support this type of thing?

If it is common for all of these programs to support TCP writes and reads, then I will go in that direction.

Thank you for any additional advice on this topic.