HP8703 GPIB is locked and it won't respond to GPIB Clear, DevClear, or ResetSys

[SeanOKeefe]

Hi All,

I have just received an (old, used) Agilent 8703A and have run into a problem with a locked GPIB if I do the following:

1) send the OUTPFORM command to get the formatted data

2) use VISA READ and read 6500 bytes, WHICH IS NOT ENOUGH BYTES TO GET ALL THE DATA 

That's all it takes.  If I re-execute just the VISA READ, I get nothing, and a timeout.

No normal GPIB commands work. 

I can execute GPIB Clear and DevClear without error, but also without effect.

ResetSys Function fails with a timeout

VISA CLEAR runs without error, but also without effect 

The status byte that is returned is the same in the error state as it is in the normal operation state. 

VISA GPIB send IFC fails with error --> VISA:  (Hex 0xBFFF0067) The given session or object reference does not support this operation. 

If I set the # of bytes to read to a huge #, then everything works fine.

If something goes wrong with this box, I would like to be able to trap this error, clear the bus, and continue.

 (if not, then the code will crash, I'll have to manually save the system state, press PRESET, then recall the system state, and then restart any LabVIEW code)

Thank you,

Sean 

[smercurio_fc]

With old instruments this is pretty common. Since setting the number of bytes to a really large number works, what do you have against that?

The command set for that instrument seems to be quite similar to the 8753C (we've got one of those stone-age instruments in our lab). Thus, my guess is that you can calculate how many bytes to read in the same way. With the 8753C it was the number of points * bytes per point + 4. The bytes per point is set via the FORM command (FORM1 = 6 bytes/point; FORM2 = 8 bytes/point, FORM3 = 16 bytes/point, ...). The constant of 4 is a fixed header. 

[SeanOKeefe]

Hi All,

I had that same thought, but I was worried about other commands hanging the system also.

In the meantime, I have tried a few other things, and it seems like the bus can still hang, even with a large # of bytes in the field (65000).

SO, I went back to the 'old-school' approach.  Moving my code to VISA just seems overly complicated at times.  So, I rewrote the code to use the old-fashioned GPIB WRITE and GPIB READ .vi's.  There is no byte count, so I gave it a try.

So far, it works perfectly!  I just need to make sure that the timeout is appropriate if I'm sending lots of data.

I'm using FORM2 for formatting.  It's much faster than the ASCII transfer.

Sean 

[smercurio_fc]

I was being facetious in my comment about putting in a large number of bytes for the byte count....

---

SeanOKeefe wrote:

So, I rewrote the code to use the old-fashioned GPIB WRITE and GPIB READ .vi's. There is no byte count, so I gave it a try.

---

I don't know what you're talking about. The GPIB Read function has (and requires) a byte count value. 

[SeanOKeefe]

You're right, I have my GPIB read set to 99999999 bytes, so I've just ignored it.

I can run the GPIB read over, and over again, and it works.  I am wondering whether or not I have a problem if I run it too fast.

I tried the repeat run, and it failed. 

Maybe it can't dump another dataset until it finishes another sweep.

The proper sequence might be

SINGLE

wait until complete (OPC? or query sweep time and wait that long + a little bit)

OUTPFORM

READ data

set to Continuous

Also, I can run the GPIB code several times, and use other VISA-coded commands along the way, but when I run the VISA-based OUTPFORM, it usually crashes.

I've set it to 51 points, and a ~1/2 second sweep, so I don't have to wait long before I run things.

If I run the GPIB code too quickly, then it tends to fail.

Sean 

[SeanOKeefe]

OK, I found it!  It has nothing to do with GPIB of VISA (and that also makes sense).

In debug mode, the code always works, so it seems to be a communications problem with the old (ancient) equipment.

Attached is a screendump of the very simple code.

Debug mode works, so I decided to add a much smaller delay into the code to try to find the problem.

I added 4 PROBEs to the diagram.  I can run just fine with all 4 there.

If I delete 10, it works.

9 & 10, it works

8, 9, & 10, it works.

BUT, if I delete 7, it crashes.  (I have repeated this exercise a couple times, with both GPIB- and VISA-style code.)

The FORM2 command seems to be making the internal microprocessor 'think' a little bit harder than the rest of the commands.

And, it gets confused if it gets another command before it's ready.

SO, it looks like I've found the problem, and I'm guessing that it is an equipment problem and not a communications problem.

Does this seem reasonable to you??

And probably explain why all of the "clear the bus" commands seem to work, but the unit still won't communicate? 

(REN, IFC, DCL all work but *RST confuses it) 

Thanks!

Sean 

Message Edited by SeanOKeefe on 02-17-2010 02:47 PM

[Lars_L]

Hey Sean,

From looking at your code screenshot, it looks like you are performing a synchronous write before 7 and an asynchronous write before 8. Was this intended? To change the mode, right click on the VISA Write command and click Synchronous I/O Mode and select which mode you prefer. If you're not sure which you need for your application, here is a NI KnowledgeBase that goes over the two modes and the differences:

KnowledgeBase 3D9B8E4B: The Effect of Asynchronous vs Synchronous VISA Write and Read functions

Let me know what you think!

Lars

[SeanOKeefe]

Hello Lars,

I didn't even notice that.   I never intentionally set synchronous or a-syncronous operation - it is an downloaded subroutine from a MUCH more modern piece of equipment.  I'll try a couple experiments, and plan on setting it to synchronous operation for all subvi's.

I'll report back with my findings.

Thank you! 

Sean 

[SeanOKeefe]

Hello Lars,

I changed all of the reads and writes to Synchronous, and also to A-Synchronous.  The icons need the watch (asynchronous) in order to have any chance of working, which seems totally counter-intuitive.  I would have thought that the synchronous would be the right solution - i.e. lock the system until each command is done.

From trials with the GPIB and VISA versions of the code, it looks like there is a need for a 10msec delay after the "FORM2" command.  5msec will crash the box (must PRESET equipment to recover).

The attached code FAILS EVERY time.  Change to a-sync (with clock), and it RUNS EVERY time. 

It seems to be an equipment and not a LabVIEW issue.  

Sean 

Message Edited by SeanOKeefe on 02-23-2010 07:07 AM

[Dozer]

Hi Sean,

I am currently running an OLD HP8703A in my lab. It works pretty well when doing measurement locally, do you have any idea how to get the data out to PC? 

Best,

Zihao