06-08-2010 11:56 AM
Sloppy - Thanks for the quick reply!! That seems to have solved the problems I was seeing, just by adding the FD0 command.
NewEnglandGuy - for what it's worth, here is a simple setup that I used to configure my source and make a couple measurements. The syntax is pretty self explanatory - we built a little wrapper app that sends the commands to either the SNA or the source.
[SNA WRITE] = DM0; # All inputs set to DC detection
[SNA WRITE] = SW0; # Non-Swept Mode
[SNA WRITE] = CW1; # CW mode ON
[SNA WRITE] = PT19; # Pass-thru address 19
[PASS THRU WRITE] = CW5000MZ; # Frequency set to 5GHz
[PASS THRU WRITE] = :POW:AMPL 16.0 dBm; # Amplitude set to 16dBm
[SNA WRITE] = FD0; # Format the data for ASCII
[SNA WRITE] = C1IA; # Perform a Channel 1 Input A abs pwr measurement
[SNA WRITE] = OV; # Output CW value
[SNA READ] # Read the data
[SNA WRITE] = C2IR; # Perform a Channel 1 Input Ref abs pwr measurement
[SNA WRITE] = OV; # Output CW value
[SNA READ] # Read the data
I was surprised that I was able to send the AMPL SCPI command to my source without telling it to switch to ":SYST:LANG SCPI" first , and then back to ":SYST:LANG 8757"
-Tim
06-08-2010 12:06 PM
Tim - thanks for the reply. Do you have the portion of the VI that has the write - that's really what I've been struggling with. Once I send the "OPSP" command, then the bus hangs up and I have to wait until it times up. Once it happens, the only way I can even start talking to it again, is do a Preset. I have to be doing something wrong with the write. I'm just looking for a small VI that I can look at that actually reads a trace back, and then I should be able to work it from there.
Thanks again
06-08-2010 01:53 PM
My software isn't in LV, it's just a C++ app I am running on a RedHat Linux machine.
We are just using "IB" calls provided with our NI driver. Here is the ibwrt command we use:
ibwrt( mSnaHandle, mCommand, commandString.size() ) & ERR )
Basically, where the handle is what was returned from our ibdev call, and the command is what I showed you in the last post, and the size is just the size of the string.
If you take a look at my first post and Sloppy's response, you might want to make sure you have all the EOS/EOI configured properly.
Make sure you terminate all your commands with a newline '\n'. I had to play around a little with all those settings till I got it working just right.
Hope that helps.
-Tim
06-09-2010 06:52 AM
sure, I've attached a Vi that will read a 401 point trace from ch2 and display it for you
I would point out that programming the 8757 is very easy under LV as compared to other compilers or languages I've used
I'm using a National Instruments PCI GPIB card under 488.2 with an 8757D that is currently connected to an 8350 sweeper as the RF source
Let me know how you make out
07-07-2010 03:16 PM
Sloppy - that worked great. I was trying to use the VISA commands, but I see you use the GPIB Read and GPIB Write. Do you ever use the VISA set of Intrutment I/O commands? I'm trying to understand the trade-off between the two different approaches.
07-07-2010 03:58 PM
I'm using the VISA stuff for some serial port work that im doing right now in LV, but no, I've not used it for GPIB.
07-07-2010 04:05 PM - edited 07-07-2010 04:09 PM
Let me offer my opinion.
VISA has been the recomended api for quite a few years. All of the certified drivers have to use VISA. VISA is portable. You can use a VISA driver with GPIB cards from any vendor that has a VISA driver for their card. VISA is also portable to different communication methods. A single VISA driver can be made to work with serial, gpib, ethernet, pci/pxi, vxi, and usb. The only times I have used the low level GPIB functions are for very old instruments that do not comply with IEEE-488.2 and I wanted to use the mode input of the GPIB Read/Write functions.
I think the VISA functions are more convenient. With VISA, you use the Resource Control and you can click on that to get a list of instruments. You can assign an alias to the resource (i.e. 'DMM') so that you do not have to remember the GPIB address. I also think it makes for cleaner diagrams when you simply wire the resource out to the resource in of the next function.
p.s. The wiring of resource names and error out/error in makes the sequence structure totally unnecessary.
07-07-2010 04:59 PM - edited 07-07-2010 05:02 PM
Dennis - thanks for that opinion. If they are supposed to be more portable, I'd ideally like to use them, but I can't seem to get it going in an attempt to duplicate Sloppy's example when I try using the VISA functions in place of the GPIB Read and GPIB Write. Any tips, or why I might be having this issue. It seems to be on the VISA Read (trying to send the OPSP - number of points that instrument is set up - command) - the bus seems to hang up.
Thanks
07-07-2010 05:13 PM
Guessing from the comments in the thread about the termination character, I'd say that is a likely source of the problem. Try appending that with your VISA Writes.
07-07-2010 08:13 PM
Tim - as you were the one to originally comment on it might be a terminator that I needed to add, do you have any examples where you have added these terminators? I'm not sure how you would do this within LabVIEW. Do you just add the \n after the command (ex. OPSP\n - for the OPSP command)?
Thanks