Meant to say "will init the scope only if you tell it to"
Here's the block diagram of the init function in the driver I pointed you to. As you can see, it has nothing to do with IVI.
Ok, thanks Dennis. I didn't pick up on that driver in my initial search because it specifies the TDS784A.
Anyhow, I loaded the driver, and opened the associated VI's. The main difference is that these all require the same kind of handle be created, but the paramter type in this set is VISA. It appears to be the same issue, but now I have to create a VISA session. How is that better than an IVI session?
Apologies for the ignorant questions. Whatever happened to reading and writing ASCII strings to and from the instrument over the GPIB? I thought the idea was to make the comunications to the instruments easier. VISA and IVI both appear to be additional levels of complexity that make the program control more obtuse. What am I missing?
An IVI driver is written in LabWindows/CVI (C code) and then built into a dll so unless you have LabWindows, you cannot change anything in the driver. With IVI, you have to manually create sessions in MAX whereas the VISA references are created automatically when you do a scan for instruments. So, IVI is much more complex. With VISA, you read and write just like you did with GPIB functions. The difference is that the VISA Resource Name is a little smarter in that it includes the interface type (i.e GPIB0::3::INSTR where '3' is the GPIB address). You can open any of the VISA subVIs and just click on the resource name and select the resource. You can even use strings but why type something when you can pick from a list?
VISA actually made things much simpler because you can use the same code for GPIB, serial, VXI, USB, Ethernet, PCI, and PXI instruments. VISA was introduced around LabVIEW version 4 and everyone was encouraged to use it soon after that and certainly by LabVIEW 5, the future was clear that VISA was going to be the standard. There is very little reason to use the lower level functions anymore.
Lastly, you don't have to use the initialize function with VISA. It really does nothing much except give you the option to reset the instrument and query for it's identity.
p.s. VISA is also portable. Not that you would ever want to, but you can use VISA programs with GPIB cards from other vendors. That is not possible with the NI GPIB functions.
Whatever happened to reading and writing ASCII strings to and from the instrument over the GPIB?
You still can, using VISA. 🙂
You can even try out the commands within MAX, or you can create a simple interface in LabVIEW using VISA to try out the commands. There is a lot of flexibility available to you. I would stay away from IVI, unless you want to experiment with it.
Thanks Ray. For this VI, we plan to proceed with the VISA based driver. Longer term, we intend to do some more elaborate things, and the reality is that the Tek IVI driver has more capabilities. So, we will probably get back into it down the road.
Thanks all, its been an education. LabVIEW certainly has changed.
Hello Dennis, I've been using the VISA Driver at least for some code aspects with some limited success. Turns out among other things, those device specific codes needed to be re-written for the TDS784.
Anyhow, the one persistent problem I am having is that the VISA Read function is getting the waveform preamble OK but does not seem to be getting the waveform itself. I've tried many things, including setting a large buffer size etc, and all I am getting back is the Preamble plus the text CURV #12, where CURV is the Tek command to dump the waveform and the scope is at address 12; but then no data. The Preamble is coming across just fine though.
The driver you suggested loops the Read with blocks of 65000 bytes. I have set the Read for a file size of 500000 bytes, and that did not help. I see quite a variety of posts of other people having trouble getting the waveforms across (I know they are relatively large), but don't see any solutions. Any suggestions? Is there something about the looping that helps other than quantity of data - timing or something?
What is being reported in the preamble? What command are you sending to request the curve?
Hi James and thanks for the response.
I'm going to need a little more time with this. We did get the instrument to transmit what appears to be the waveform data by performing a RECORDSNAp Write to set the Start and Stop limits and breaking up the string commands into single command Writes in a Sequence structure; which is a little tedious, but seems to be working. Perhaps, this particular scope just can't handle the semicolon delimited command strings and needs separate Write operations for each command.
Anyhow, I'll post back after a little more work once I'm sure what is going on. Does not appear to be a LabVIEW issue.