George, I'll stick my neck out on this one, maybe everyone gets a good laugh! I tend to avoid the whole VISA (trap) unless I have to, for example the "get waveform" driver on the new Tek scopes with the embedded PC works so well in terms of speed, I have to use it. Another situation where I didn't _have_ to was when I was presented with a new instrument and its VISA based drivers which amounted to a bunch of CIN nodes..."Does your instrument respond to and operate correctly with the GPIB commands as published in the manual?." "But we have all these nice VISA drivers with CIN nodes at the bottom level!" I've found sometimes that to get a GPIB device to work right, you just need to know precisely what's happening. That means I need to see what's being sent and what's coming back at the character level.
I can relate to the "too lazy to take care of the open/close/pass around references". Although I believe the "close reference" isn't a problem in the last few versions of LV. Years ago, I actually designed my own system based on an array of strings, which assigned equipment classes to the array elements. When the main VI was first run, a sub would search for existing equipment in each class (i.e. source, load, DVM, scope, function generator) and then, if found, load the GPIB address and a numerical type code into the corresponding array element. All my drivers were setup to read the appropriate element of this array and work with the instrument indicated. All the drivers use either the 488 or 488.2 function. My scope driver for "get waveform" can handle multiple instruments of different types and works as long as it has a valid GPIB address/type code string to start with. Multiple instrument definitions are simply character delimited... No opening VISA references, human readable where/what definitions, all the drivers work stand-alone as well as subs. Downside? All the drivers have explicit GPIB commands and I was not able to make much use of any provided instrument drivers, except to look at. Basically, it's get out the programmers manual, pull up my own LV driver code shell and start programming the specific functions I needed. I think the array of instrument classes with character delimited address and manufacturer codes is actually fairly easy to use. As the years go by, I do find myself forgetting things like "what instruments did I put in element 3?" or "what was that delimiter character again?" or "was the Agilent a type 1 or 2?" But with an example string near the array input on each driver, (saved showing the particular element for the class of instruments being driven) it's not rocket science to type in a GPIB address and instrument type code there yourself to get the driver to work stand-alone. I'm sure the scheme could be redesigned and simplified for human readability, ease of use to accommodate those poor, lazy scientists who are all, like I was, "stuck in the old days" when a GPIB address was a number in wholly-graspable string format. Not some dynamic hex value in a strange data type... BTW, you don't need to install the VISA layer at all, for any of these VIs to communicate over GPIB. Well, at least it used to be that way - dunno about the two latest versions. Joe Jasniewski Test Automation Engineer Intel Corporation 253-371-5652 ---------------------------------------------------------------------- Subject: Managing VISA Resources From: "George Gatling (Contractor)" <[EMAIL PROTECTED]> Date: Thu, 22 Jan 2004 22:45:17 -0500 I am trying to find a way to hide some of the book-keeping associated with VISA references. Take a scope, for example. I would like to create a VI "Get Waveform From Scope". I want this VI to be smart enough to open the VI reference if it is not open and then to be overhead friendly and keep it open as long as necessary. Catch #1: I want this VI to be able to talk to more than one scope. Catch #1: Reentrant is out because I do not want it trying to talk to the same scope at the same time from two places. I think I have a solution to this problem, but I do not know very much about how the VISA resource is handled (including during execution, when the top level VI finishes, and when the resource is used as part of a built app). First I write a VI that will grab the waveform (or do any other operation on the scope) and expects an opened reference. Then I put two calls to a "reference manager", on before the grabbing vi and one after. So all of my questions are focused on this "reference manager", which accepts a reference and an error and returns one of each. *** It uses a USR to store an array of VISA references. On "first call" it uses the instruments "Close.vi" on each element (if any) in the USR. I did this becuase it appeared that I still needed to clean up even after the top level VI completed previously. It then continues as if it could not find that reference in the USR. If this is not the first call it searches for the passed reference in the array in the USR. If it does not find an open ref (or this is the first call and hence the array is now empty) it calls the instruments "Initialize.vi" on the ref passed, uses build array to add this ref to the USR and then returns that ref and any error from the Init call. If it does find and open ref it returns that and the error passed in (assuming that is no error). If there is an error passed in and it found a ref in the USR, it closes that ref deletes it from the USR, and passes it and the error though to the output. **** This all seems to work well on our GPIB instruments, but I am having a very unidentifiable problem with it and one of our serial instruments (only serial instrument at the time). There are no error messages, but after one or two calls, the serial port appears to release and never reopen. The instrument is connected via an RS-232/ENET. Can anyone shed light on this situation in particular or on the problem of managing VISA references in particular? Can someone point me to detailed information on exactly what labview is doing with the references and what things the Open and Close primitives are up to? The main motivation here is that there is a lot of coding on the fly at the beginning of experiments here and many of the scientist are too lazy to take care and always open/close/pass around the references. They are stuck in the old days of the GPIB address string. (which was a very UNsatisfying arrangement IMHO) So I want to make them some very high level VIs like "Get Wavefrom", "Move Motor", "Get Spectrum", etc... but maintain similar efficiency as a VI that passes the reference all over the place. (In other words I don't want to repeatedly open and close the reference in these subVIs). I also want a solution that is relatively easy to apply to new functions... preferably using the wrapper calls I mentioned earlier. Thanks George Gatling Applied Technology Division, SFA Inc. Space Physics Simulation Chamber US Naval Research Laboratory 202-404-5405 (phone) 202-767-3553 (fax) If trees could scream, would we be so cavalier about cutting them down? We might, if they screamed all the time, for no good reason. --Jack Handy
