MET/CAL programming and 9500 calibrator

[gkrik - 2008]

Hi to all!

I have a question regarding programming with MET/CAL and communicating with the Wavetek 9500 calibrator.
We are using the 5.11 version of MET/CAL and we are trying to write a procedure for the calibration of the 9500. The problem is, that when a querie is sent to the 9500, unexpected SRQs occur.
To be more specific: even sending the simplest query, for example the *IDN? command, will result a message like this (not when the query is send, but when we use the command to read the response): "E2109: unexpected SRQ (boad=0, IEEE-488 address=10, status byte=96)"
(10 is the address of the 9500).
If I press "advance" (in the editor run-time mode), the procedure continues and the response is actually read. But this is no solution of cource and moreover the procedure needs continuous user intervention.
I am also convinced that this behaviour has to do with the 9500 GPIB implementation.

Does anyone have some tip or comment on that?
(other commands, that do not cause a response from the 9500 are normally executed).

 

[Hershal]

I don't know the ins and outs of the programming.....I suspect there is someone here who does however.

Hershal

 

[Jesse - 2010]

I'm not familiar with the workings either. I forwarded your request to someone in my organization who is, his response:

=============================================================================
STEP FSC RANGE NOMINAL TOLERANCE MOD1 MOD2 3 4 CON
1.001 ASK- R N P F V
1.002 IEEE [SRQ OFF]
1.003 IEEE *IDN?[I$]
1.004 DISP [MEM2]



I hope this helps the guy out. If he has the FLUKE 9500 on port 100, then he needs to include IEEE [SRQ OFF] to avoid the error. Of course, we have a higher version of metcal, but it should still work the same.

Tell him to send us part of the code that he is using, if this does not work for him.


Hope this helps.

 

[gkrik - 2008]

Jesse, thank you and your colleague very much for your reply.

Unfortunately, the [SRQ OFF] command is not valid for our case (it is valid only in DEMO mode or if someone has two IEEE boards-we have one).
A test code that we used is the following:

1.001 IEEE [@9500] SYSTATE?[I$]
1.002 DISP [MEM2]
1.003 IEEE [@9500] *IDN?[I$]
1.004 DISP [MEM2]
1.005 END

(the original procedure is of course much larger, but we used this simple one, in order to isolate the problem-it is enough to demonstrate it).

When 1.001 or 1.003 are executed, the program is interrupted from an SRQ. However, if you choose advance, it seems to run smoothly. That is, one could use it, provided that someone checks it constantly, in order to advance it! That if of course not an ideal solution...