visa control of an executable running on the host PC

[Dennis_Knutson]

All languages will support reads and write to TCP/IP but thats not quite the same thing as using a VISA interface. If they are willing to change to TCP/IP instead of VISA Reads and Writes, why would they not accept a change to read/write to a dll. That would be something pretty simple on your end I would imagine.

[RavensFan]

I think I see what you are saying.  I had to go back and take a closer look at the TCP/IP functions.  I was thinking they were using the same purple wires as a serial port or other VISA resource, but no, they are using their own connection reference wire.  I deal with basic VISA resources such as serial ports.  I don't do things like VXI or GPIB.

I think the architecture I was thinking of would work just fine and would be the way to go, but isn't using a VISA resource.  So if there truly is a requirement that this be a "VISA" resource, the question is why?  I think it would be much easier for a VB or C programmer to work with TCP/IP functions in those languages than VISA?

[Dennis_Knutson]

---

Ravens Fan wrote:

.... 

I think it would be much easier for a VB or C programmer to work with TCP/IP functions in those languages than VISA?

---

But text programmers are brain dead.

[Mike....]

Just to make one thing clear:  The absolute easiest thing for my customer to do is a VISA write / read.  Nothing else is easier for them.  They are already using this tool in their existing programs.  I have not guarentee that they are willing to use any other methods.  My only chance is to show them something that is so simple to do, and so similar to a VISA read/write that they just accept it.

From my point of view the TCP write and read looks like the next closest fit.  I myself have never made  a DLL or passed commands to a DLL.  So while it may be easy, it is not the direction I would have gone.

That said, how would I proceed?  Would I write a DLL that accepts commands from my customer's program, and then sends them to my LabVIEW executable?  Do I write a DLL in LabVIEW?

[smercurio_fc]

I think you misunderstood what was mentioned regarding TCP/IP and DLLs. These are two different implementations.

TCP/IP:

You can create a TCP Listener for your program that waits for a connection and then just waits for commands. Once it receives one it parses it, executes it, and then returns a response if necessary. All of this would be done in pure LabVIEW. No DLLs. Examples ship with LabVIEW to show you how to do data clients and servers. Your customer would open a TCP/IP session in the same way they open a VISA session and they would create the commands in the same way they currently do. Instead of doing a visaSession.viWrite they would do the same action with a TCP/IP write.

DLL:

This method means that you build your code into a DLL using the Application Builder. You select functions to export, making sure you choose appropriate datatypes that don't require special memory management like clusters containing strings, or other fancy things like that. Your customer would load the DLL in their code and then call the exported functions. An example of an exported function would be setting a parameter.

[Mike....]

Thank you for the clarification.

Based on that, the DLL approach is out.  My program has an extensive graphical user interface.  I would only provide a way for the customer to access a few of the main operations remotely.  But I expect they will do a mixture of interacting with the executable's GUI to configure the program, and then resort to sending commands from their remote program for the iterative stuff.  (For example, get new data, save results to file, repeat...)

The TCP approach does sound like the next best option so far.