Re: Download Gpib Card Driver And Visa32 8
Edelira Longinotti
Basically GPIB allows you to control instruments like Power Supplies, Signal Generators, Oscilloscopes, Signal Generators, etc. You need to install or connect a GPIB interface card (PCI, PCMCIA or USB) to your PC and install the corresponding GPIB driver.
VISA is a standard API that sits on top of the GPIB driver and it allows you to use the same programs to control your instruments regardless of the type of GPIB card that you have installed in your PC (most cards are made either by National Instruments or by Agilent/Hewlett-Packard).
The cool thing about this library is that it opens AutoIt to a whole new kind of automation (instrument automation). Normally you would need to use some expensive "instrumentation" environment like Labwindows/CVI, LabView or Matlab to automate instruments but now you can do so with AutoIt. The only requirement is that you need a VISA compatible GPIB card (all cards that I know are) and the corresponding VISA driver must be installed (look for visa32.dll in the windows\system32 folder).
I've tried to make the function descriptions in the attached "visa.au3" library as clear as possible, and I've put a small (commented) example at the bottom of the file. I've even put the C code prototypes of the visa32.dll function there (also commented) for those that might be interested.
There is only one limitation that I know of, which is that the GPIB queries only return the 1st line of the device answer. This is not a problem in most cases, as most devices will always answer with a single line anyway.
Please let me know if what you think, if you are able to make it work (I only have a National Instruments card so I'd like to see other people try it with an Agilent card) or if you have any trouble or suggestion.
I recommend that you try first to execute the _viFindGPIB function (as shown in the example at the bottom of the file) and see if you can find any instruments. You can also have a look at the examples in the _viExecCommand function description.
Ah! Another neat thing about this is that you can use it to open a TCP SOCKET, as VISA gives you access to the TCP stack by means of the "TCPIP[board]::host address::port::SOCKET" descriptor. However the limitation on the queries could be a problem in this case.
I don't know if many here know but GPIB is very important in the test industry. I use TestStand at work, but they charge you 5000$ for the development license and 500$ for the user license (that is true, you also pay to use the programs that you write!). I don't write often in these forums because as I said I use much more TestStand than AutoIt. But this could change that
This is what I call luck. I just found about AutoIt from a colleage at work 5 days ago and I told him: "This thing would rock if it had ActiveX and GPIB support". And bam! less than a week later someone "hears" my wishes and creates this GPIB library and I think that someone is working in ActiveX too!
I work in a lab at a major chip maker company and we use GPIB all the time (we use LabView for most of our programs). I haven't had a chance to try this library yet, but I will as soon as I can. In the mean time, if it does what it says it does I would like this to be added to the default installation of AutoIt.
JdeB gave me some feedback on my code and I will do some small changes to it soon. Right know it shows some message boxes in case of error but I will remove them and change the returned error codes instead.
One suggestion, could there be a "test function" added that would show you a GUI were you could search instruments and send them commands, queries and reset the BUS is there is aproblem (like the VISA interactive tool from National Instruments).
the reason why I named that function _viFindGPIB instead of _viGpibFind is that it is basically a wrapper around the _viFindRsrc function, and I wanted to keep my function names as close as possible to the VISA library functions. I did not call it _viFindRsrc because I think that in the context of autoit it is much clear to use GPIB instead of Rsrc (which stands for resource) as its only purpose is in fact finding GPIB resources (I do a search for GPIB instruments only).
I tried the library and it works very well for the most part. I found a little problem, though. The reset function does not work properly (it shows an error message box). All the other functions work very well.
actually I already found that problem and I have fixed in a new version of the file. It was silly mistake. I had not been able to make my GPIB bus hung, so I could not try to reset the bus. I tested all the other functions very thoroughfully and I found no problems with it. I am glad to see that you have no problems either.
Is this correct? I have a Rohde & Schwarz CMU200 that I need to automate and it requires that you use secondary addresses for almost everything. I would like to try it next week so I would be nice if you could confirm that it works.
The card is old since I would not like to go for newer drivers from the official National instruments site since I have a 16 bit program that needs to access the card. Also the driver CD that came with card is now molded which is not useful anymore.
National Instruments has removed NI-488.2 17.0 and earlier from theNI-488.2 Download Page. If you require an earlier version of the NI-488.2 driver, please reach out to NI Support to request for the specific driver version.
Uncheck the additional services provided by NI as these will only increase the number of unneccessary processes and services running in the background. In the older versions of NI-VISA, the option to uncheck GPIB-488.2 driver from NI was present in the installer. However the current version automatically checks for the GPIB driver pre-installed and accordingly proceeds with the installation to avoid conflict.
A successful installation creates visa32.dll and visa64.dll dynamically linked libraries. DLL files are shareable libraries which can be ported as it is across systems offering convience of using software without recompiling on new systems. They act like patches.
After the installation, look out for the install location; usually the C:\\Windows\system32 and search for visa32.dll and visa64.dll. If they are present there, then PyVISA-py can detect them without fuss. If they are not present there (for some reason), then proceed to the alternative installation
For some reason, my VISA installation has not generated the DLLs at the location. I searched for visa* (* is called a wild card evaluating to any character set like 32.dll or 64.dll) across the WINDOWS directory and found a visa32.dll at C:\Windows\SysWOW64\visa32.dll.
I am using LabVIEW source code developed by a company that creates instructional chemical engineering equipment (i.e. small scale heat exchangers, distillation columns, etc.) that is meant for their distillation column. The purpose of this software was to be able to edit the code to allow for different methods of data analysis and control. The program also requires a supplied USB driver for communication with the hardware.
My issue that I am encountering is that when I run the main vi file of the project and turn on the data acquisition and control hardware, I run into communication port errors after around 2-5 minutes. The errors occur in sub VI's labeled "SetAnalogueOutput" and "ReadAnalogueDigital" which, to my knowledge, are used to read the USB through VISA functions. The program then prompts me to check the communication port and restart the application. This issue only occurs when I turn on the hardware. Whenever I run the program by itself, it properly recognizes the communication port and does not run into any errors.
When I look in NI MAX, the communication port is shown to be unknown after the error occurs and unplugging and replugging the USB cord is the only way for MAX to recognize the port. In addition, Windows Device Manager has no trouble recognizing the communication port throughout this time. I looked around the forums for a similar issue and did not find anything. I contacted the company and they suggested using a shorter USB 2.0 cable and temporarily disabling anti-virus software as it supposedly can cause spikes in data transfer. I have tried both of these solutions and neither have worked for me.
Additional Information: The original software to run this distillation column is an executable application of the LabVIEW program that does not allow for modification or viewing of the VI files. This software runs perfectly fine with no issue in regards to communication.
1- Am I correct in assuming the server device (in this case, a BeagleBone) needs to behave differently if using VISA than raw TCP? (I was under the impression VISA could run over TCP, but I'm honestly confused here)
I'm a bit confused on what to search for here. The device will need to communicate to devices running any random TCP connection, but I thought VISA would work for this. Am I right, or have I missed the concept completely?
b1e95dc632