LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

HP 4145 Graphics Plot.vi from the instrument library, gives an error when run on HP 4145A!

I am new to LabVIEW. I am trying to run HP 4145A using LabVIEW's instrument driver. All the vi's in HP 4145 Example.vi work except one important one, HP 4145 Graphics plot.vi. When I run this it gives an error ' HP 4145 Receive Message".It does the measurement and displays on the equipment screen but not on the computer screen. To me it seems like measurement data is not being output to the computer. Any help will be greatly appreciated!
0 Kudos
Message 1 of 15
(8,533 Views)
Hi Natasha,

I do not have HP4145A, but HP4155B - Parameter Analyser. The big advantage of LabVIEW is: graphical possibilities. You only need to download the traces from your Analyser and feed a X/Y - Graph. This might be a workaround, if this sub.vi does not do it's job. Find attached a Frontpanel from one of my sweep - solutions. If you need more detailed advice - let me know............

regards
wha
0 Kudos
Message 2 of 15
(8,527 Views)
Natasha,

I downloaded the LabVIEW intrument driver from our web site. It was designed for the 4145B. You many need to pull out the user's manual for the 4145A and see how the commands in the Receive Message VI differ from your instrument. That VI looks at index 15 of the status return array of booleans for an error. Your instrument may be a different value or this VI is incorrect.

Please post a response with what you find out. Thank you.

Randy Hoskin
Applications Engineer
National Instruments
http://www.ni.com/ask
0 Kudos
Message 3 of 15
(8,527 Views)
Natasha-

I am having the same issue with my 4145B. A work around is to put a delay in, but I'm looking for a better fix. It appears that the 4145B is not ready to send the data until after the experiment has run. I put a delay of 50 ms per X step and the error does not usually occur. A shorter delay will give the error more often.

This fix is quite a hack, and I still can not download the Y2 axis or the X axis from the 4145B. I thought that GPIB was suppose to deal with these timing issues. I also tried the 2 GPIB wait VIs included with Labview, but no luck.

Did you find a good solution to the Receive error problem? Does anyone else know how to deal with this (appears to be timing and GPIB) issue?

- Casey
0 Kudos
Message 4 of 15
(8,528 Views)
Aloha Natasha,

did you ever get to talk sucessfully to your 4145A? I am about to embark on the same quest using the NI USB-GPIB cable/device.

Any and all info would be greatly appreciated.

Mahalo, Randy
0 Kudos
Message 5 of 15
(8,425 Views)
Aloha Casey,

did you ever get to talk sucessfully to your 4145A? I am about to embark on the same quest using the NI USB-GPIB cable/device.

Any and all info would be greatly appreciated.

Mahalo, Randy
0 Kudos
Message 6 of 15
(8,423 Views)
Hello,

What is likely happening is the instrument is being addressed as a talker before it is ready... adding a delay would make sense if this is the case! I will have this formally looked at internally!

Thank you, and the short answer to your apprehensions is that you should not have problems. But definitely repost if you do and I'll help you out!

Thanks,

JLS
Best,
JLS
Sixclear
0 Kudos
Message 7 of 15
(8,408 Views)

Hello all,

 

In my search for a way to get data from my HP4145A with CVI, I came across this thread.  I have an Agilent USB-GPIB converter that I use all the time but I use the VISA layer instead of GPIB calls so all the platforms I install programs on work.  I did not have success with the commands in the manual and this setup (USB-GPIB and laptop) and so reverted to my desktop and brute force GPIB commands.  In both cases, I was able to get the instrument to do things but could get no data back.  I finally used the HP4145 driver (*.fp) supplied by National Instruments and found that the instrument has a wait state that was causing the problem.  During this wait state which I believe is the ancient instrument processor trying to catch its breath, the downloaded driver polls the bus with 'ibrsp'.  When this finally goes to the value of one, the data is asked for and comes back one byte at a time.

 

I found this by turning on NI-SPY (great tool) and watching the drama unfold.  When I turned off NI-SPY, my program would hang.  I theorized that the ancient instrument processor (again) could not keep up with the barage from my newer hardware and so in the 'hp4145_measure' function on line 476 in the driver (filename HP4145.c), I added a delay in the while statement at the end as below.

 

Original:

while (serial_poll != 1)
            ibrsp (instr_bd[instr_id], &serial_poll);

 

Modified

while (serial_poll != 1)
     {      

     ibrsp (instr_bd[instr_id], &serial_poll);

     Delay(0.1);

     }

 

Adding this delay actually made the program run faster and it worked without having NI-spy on.  Cool.

 

I hope this helps some other schmo out there.  Happy coding.

 

timLesher

0 Kudos
Message 8 of 15
(8,223 Views)
I am currently using a 4145A.  I tried adding a delay in hp4145.c  Unfortunately, it's still not receiving any data return from the system.  I constantly returns "Receive Message" error.  Any other suggestions?
 
Thanx
0 Kudos
Message 9 of 15
(7,929 Views)
Hello GaryY,
 
Are you able to make the instrument start a measurment or get any other sign that a command gets to the insturment?  If not then something else is wrong and adding the delay will not help.  If you are able to programatically control the insturment in any way, I would suggest using NI_SPY and step through each line of your code in the area where you are having trouble. 
If you could provide more detail, I (or anyone else out there) could get more specific.
 
timLesher
0 Kudos
Message 10 of 15
(7,924 Views)