LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

HP 33120A driver problems

Hi,
I have installed the Instrument drivers for the HP 33120A function generator (fg), that were supplied by NI, and managed to get it working across serial. But I get an error message actually on the fg when the initialise vi is run in Labview. I narrowed the problem down to the the init function of hp33120A.dll. Error -113 which is defined to be

"Undefined header
A command was received that is not valid for the function generator. You may have misspelled the command or it may not be a valid command...."

Even though communication is not compromised by this, an error box comes up on the fg screen. Any help is appreciated.

Cheers.
0 Kudos
Message 1 of 13
(6,134 Views)
> I have installed the Instrument drivers for the
> HP 33120A function generator (fg), that were
> supplied by NI, and managed to get it working
> across serial. But I get an error message actually
> on the fg when the initialise vi is run in Labview.

I haven't used the NI driver, but I wrote the HP VEE
"Classic" driver for this instrument. There are
several things that have to be done differently when
using RS232 than when using GPIB. If the NI driver
does not handle these two cases differently, I can
guarentee that you will have problems.

Les Hammer
Les.Hammer@CompleteTest.com
0 Kudos
Message 2 of 13
(6,134 Views)
All functions of the hp33120A.dll operate correctly over serial except for the init function. Is the code for hp33120A.dll available? Can anyone direct me to where I could find this.

Cheers.
0 Kudos
Message 3 of 13
(6,134 Views)
If someone has access to the dll source code, could you please list the init function?

Other requirements for successful RS232 communication with the 33120:

1) The computers have gotten faster since the 33120 parser was made.
You can easily over-run the parser. Try 10 mSec wait statements between
sending a query and receiving the answer. Wait another 10 mSec
before sending another command or query.

2) Init should send an Interface CLEAR before doing anything else.

3) Init should send "*RST;*CLS", not just "*RST"

4) RS232 needs to send "SYST:REM" after the reset.

5) Send the "STAT:PRES" command if and only if you have the Phase Lock Option.
(Hmmm, could this be the problem? Is this command being sent all the ti
me?)

6) Do an "*OPC?" query to sync when done.

Les.Hammer@CompleteTest
0 Kudos
Message 4 of 13
(6,134 Views)
I looked at the source code for the old CVI driver and in the LabVIEW driver. I am currently using the IVI driver for the 33120 and I suspect that is what Big-C is using. I don't have the source code for the IVI driver but I suspect the init function is similar to the other two. The only thing in the Init is the command IDN? and the the command RST*. The driver gives the user the option of doing one, both, or none. It would help if Big-C would try the Init function with the various options and see which is causing the error. I never see an errors but then I'm using GPIB. If one of the commands does need to be edited, download the LabVIEW driver since LabWindows/CVI would have to be purchased to modify the IVI driver.
0 Kudos
Message 5 of 13
(6,134 Views)
If it helps further, I highlighted the execution of the hp33120A.dll init function and the error came up upon completion of it. So it is definitely the cause of it. But I would also like to see the init function.

Thanks for your time Les.
0 Kudos
Message 6 of 13
(6,134 Views)
Yes I am using the IVI driver for the 33120, I am using version 4.2 that I obtained off the NI web page.

[ I downloaded it from the following link: http://zone.ni.com/idnet97.nsf/9b2b33e1993d877786256436006ec498/fdfa63edb4a238bd862568ab005fbd39?OpenDocument ]

I tried the hp33120a Initialise with Options.vi with all the different options available, and still no luck. 😃 That was something I tried earlier.


Thanks for your suggestion and effort.
0 Kudos
Message 7 of 13
(6,134 Views)
Here's the .c file for the driver. Since I can use the driver without any problems over GPIB, you might want to look at the code specifically for RS-232. I briefly noticed one comment in the function hp33120a_DefaultInstrSetup about the SYSTEM:REMOTE command. If you do find a command that is causing the instrument to report an error, contact NI so that they can fix the bug. As a work around, immediately after the init function, call the error query function to clear the instrument's error buffer.
0 Kudos
Message 8 of 13
(6,134 Views)
Here's the .c file for the driver. Since I can use the driver without any problems over GPIB, you might want to look at the code specifically for RS-232. I briefly noticed one comment in the function hp33120a_DefaultInstrSetup about the SYSTEM:REMOTE command. If you do find a command that is causing the instrument to report an error, contact NI so that they can fix the bug. As a work around, immediately after the init function, call the error query function to clear the instrument's error buffer.
0 Kudos
Message 9 of 13
(6,134 Views)
Thanks for the code, Dennis. That shows:

static ViStatus hp33120a_DefaultInstrSetup (ViSession vi, ViBoolean reset)
{
/* some stuff deleted for brevity here,
including variable declarations */

if (interface != VI_INTF_ASRL)
viCheckErr( viPrintf (io, "%s*CLS;*ESE 1;*SRE 32;"));
/* *** Huh? a %s without a parameter **BUG** */
else
{
/* The manual for hp33120a states:
- The "SYSTEM:REMOTE" command must be sent whenever communicating over RS-232.
- The communication must be set up with TWO stop bits
- The function generator uses DTR/DSR handshaking
*/
viCheckErr( viPrintf (io, "SYSTEM:REMOTE"));
/* **BUG??** Y
ou're sending this before setting the stop bits/etc ??? **/
viCheckErr( viSetAttribute (io, VI_ATTR_ASRL_STOP_BITS, VI_ASRL_STOP_TWO));
viCheckErr( viSetAttribute (io, VI_ATTR_ASRL_FLOW_CNTRL, VI_ASRL_FLOW_DTR_DSR));
}
viCheckErr( viPrintf (io, ":FORM:BORD NORM;:APPL:SIN 1000.0, 0.05, 0.00;",
(reset) ? "*RST;" : ""));
/* Now you are supplying a parameter without a %s ??? ***BUG** */


/* I forget how the firmware works in the 33120, but the driver
that I wrote sent the "SYST:REM" after the "*RST" was sent --
and resent the SYST:REM every time a *RST was done. The reset might
take it out of SYST:REM.

My driver used SYST:REM, instead of the full SYSTEM:REMOTE. So I
know the abbreviated version works. Some instruments had defects in
the command set. I don't remember about the 33120, so I can't guarentee
that the long form works.

While looking up other things, I found:
http://www.hhdsoftware.com/
They have a serial
bus monitor for $70. It should be able to tell you
what commands are really being sent. It might be a useful debugging tool.

Les.Hammer@CompleteTest.com
0 Kudos
Message 10 of 13
(6,134 Views)