VXI and VME

cancel
Showing results for 
Search instead for 
Did you mean: 

NI-VISA

I have an obsolete message-based VXI instrument that is programmed in LabView 5.1.1 using VISA VIs. What I wish to do is replace the instrument with two register-based VXI instruments and write an aggregate software driver that parses the original message-base commands and uses the new register-based instruments to emulate the obsolete hardware.

The problem I am having is figuring out how to make VISA recognize and talk message-based to my aggregate driver. If I can achieve this, all the existing LabView application test programs would run without any changes except having to supply a new resource name to the VISA Open VI. Clearly, it is important that the existing VISA message-based API interface is retained to avoid having to modify the existing suite of LabView application test programs. Any guidance or ideas on how to accomplish this would be greatly appreciated.
0 Kudos
Message 1 of 7
(8,439 Views)
Hello,

It sounds like what you are talking about attempting is implementing conversion from messaged based commands to register level commands, but would like to maintain the existing programs (ie. message based VISA API). I would suggest that the effort in converting the message based commands to register level commands (ie. your aggregate driver) is no more than simply writing that code in LabVIEW where you provide a message based interface to the user, and then use the register level VISA VI's to make the calls. Having high level, message based VISA VI's sit on top (such as read and write) and simply trying to bypass VISA underneath to actually have another "aggregate" driver perform the I/O is really not using VISA at all. Can you consider one of the following:

1. Implement the register level communication using lower level VISA commands; you can provide the user a message based interface if you like.

2. Write the driver however you can in the language of your choice, build it into a dll, and then call that dll from LabVIEW to implement the message based user experience and interface.

If I have misinterpreted your post please clarify; if you have additional information or considerations repost and perhaps other suggestions can be derived!

Thank you,

Best Regards,

JLS
Best,
JLS
Sixclear
0 Kudos
Message 2 of 7
(8,422 Views)
Hello JLS,

Thank you for your prompt reply. This is greatly appreciated.

I take strong exception to your assessment that a solution “is no more than simply writing the code in LabVIEW where you provide a message based interface to the user.” The customer has many existing test applications that have many LabVIEW VISA Writes and VISA Reads sprinkled throughout the code. At a minimum, these will all have to be changed, tested and the new test applications certified if either of the two recommendations are followed. The cost of these changes and side effects of “if you touch it you own it” is not an economically viable solution. This is not a Government job.

What I need is a way for making Resman and VISA think that my aggregate software driver is a message-based VXI piece of hardware installed in the VXI chassis. This way, there are no application program changes required besides assigning the new resource name to the VISA Open VI. This also corrals the new code to one place (my driver) instead of spreading it across a “bushel-basket” of custom VIs. There are other advantages…

I would think that there would be some controlling flags, registry entries, dispatch tables, etc. that with the proper settings would allow me to do what I need to do. However, my knowledge of the inner workings of VISA, Resman, etc. is quite limited which is why I am looking for help and guidance from NI.

Best Regards,

EXS
0 Kudos
Message 3 of 7
(8,414 Views)
Hey EXS,

If I understand your problem correctly, you have an application or several applications that were designed in a way that they make direct calls to the instrument using VISA VIs and modifying every location that makes a call to VISA is to large of a task.

Typically, I would always recommend that when you are creating large applications or several applications, you should create a small set of sub VIs that perform tasks and inside of these VIs you place the VISA or driver calls. That way the main application doesn't ever touch the device/instrument specific code and it only makes calls to a small set of sub VIs that perform tasks. This way if the device ever changes all you have to do is change the set of sub VIs. As they say, "Hindsight is 20/20."

To fix your problem you are going to have to go deeper and since we are not going to give out the source code for VISA I recommend you create a device that can parse your old instruments commands and then output the new register level commands. At this point you probably think I am crazy to recommend that you create a new device, but NI has made this easy.

NI-Device allows you to create devices. As a matter of fact you can use it to create devices on your controller just using software. For example, with NI-Device Plus you could create a VXI-11 instrument on your controller that would show up in VISA, MAX, LabVIEW, etc as a VXI-11 instrument. You could program it to parse your old instruments commands and then perform the appropriate VISA actions. It only has a C++ API, but it is very powerful.

I hope this helps out,

Josh Prewitt
National Instruments
0 Kudos
Message 4 of 7
(8,390 Views)
EXS,

If the NI-Device solution sounds interesting to you as Josh presented it, we would be more than happy to answer further questions as to how this would help you. Since getting inside VISA is going to be difficult, and since VISA already provides a message-based interface to the types of hardware interfaces that NI-Device supports, this seems like a viable solution from a technical standpoint. From a financial point of view, there will be a considerable development-time investment. As you mention above, this could be minor compared with the cost of rewriting pre-existing application software.

Scott B.
GPIB Software
National Instruments
0 Kudos
Message 5 of 7
(8,369 Views)
Hello Josh and ScottieB,

We looked into the NI-Device product early on and it is not clear how it would work for our application. It looks like a tool set for generating code for the controller or the instrument at the other end of the instrument bus. Also, we ran into a similar inquiry on your discussion forum where somebody wanted to redirect VISA message-based traffic to a local application using DDE. In that instance, NI-Device was also recommended and eventually it was determined that it was an inappropriate solution.

What we are looking for is information that can help us interface my aggregate driver to work within the Resource Manager and VISA environment. We never anticipated the need for tweaking VISA or have any desire for access to VISA source. We are looking into alternative solutions at this time. We do appreciate your time and effort in helping us investigate a viable solution to our problem.

Best regards,

EXS
0 Kudos
Message 6 of 7
(8,362 Views)
Hello,

You would use NI-Device to develop an instrument that accepts exactly your message based command set (remember, NI-Device will require C++ development). You could develop this device with a GPIB, USB, or Ethernet hardware interface (your choice), but I'm thinking that Ethernet might be the cheapest, especially if you wanted to "run" the instrument on the PC on which your application software is running.

On your application PC, you would execute the instrument EXE. In your applications, you would point them to access TCPIP::ip_address::INSTR rather than VXI::whatever::INSTR. Your applications would send their message-based commands to the NI-Device instrument via ethernet (again, probably just to the local host), which would be written to do whatever is appropriate on the backend, such as register-based commands to actual instruments.

Hopefully this makes more sense.

Scott B.
GPIB Software
National Instruments
0 Kudos
Message 7 of 7
(8,349 Views)