07-19-2010 12:32 AM
I know this is Met/Cal related problem and I should ask Fluke Metrology community for this - but just in case someone here has a similar problem or solution...
Problem: all the new MET/CAL procedures using IEEE2 or SCPI commands result in SQR wait errors. Analysis using GPIB bus capture with National Instruments NI Spy software indicates that MET/CAL tests for TestSRQ(1, FALSE (0)) forever (about 300,000 times before giving up). Changing the SCPI commands to plain IEEE work just fine (they don't seem to expect SRQ from the device at all). The tested DUTs should be fully 488.2 compliant (eg. Agilent DSO8064 oscilloscope).
A test was carried out with the following set up:
MET/CAL 7.2.51, MET/CAL Editor 7.20Z
Procedure: Agilent DSO8064A: (1 yr) CAL VER /9500,1Hd,DMM
version: 2007-11-06 Revision: 1.2
Example command from procedure:
1.016 SCPI *RST
Corresponding captured bus traffic:
1. ibtmo(0, T10s (13))
Process ID: 0x00000F14 Thread ID: 0x00000624
Start Time: 10:33:12.625 Call Duration 00:00:00.000
ibsta: 0x170 iberr: 11 ibcntl: 0(0x0)
2. Send(0, 0x0012, "*RST;*CLS;*SR...", 40 (0x28), DABend (0x02))
Process ID: 0x00000F14 Thread ID: 0x00000624
Start Time: 10:33:12.625 Call Duration 00:00:00.000
ibsta: 0x168 iberr: 0 ibcntl: 40(0x28)
3. Send(0, 0x0012, "*OPC", 4 (0x4), DABend (0x02))
Process ID: 0x00000F14 Thread ID: 0x00000624
Start Time: 10:33:12.625 Call Duration 00:00:00.000
ibsta: 0x168 iberr: 0 ibcntl: 4(0x4)
4. Send(0, 0x0012, "*ESR?", 5 (0x5), DABend (0x02))
Process ID: 0x00000F14 Thread ID: 0x00000624
Start Time: 10:33:12.625 Call Duration 00:00:00.000
ibsta: 0x168 iberr: 0 ibcntl: 5(0x5)
5. Receive(0, 0x0012, "1.", 511 (0x1FF), STOPend (0x100))
Process ID: 0x00000F14 Thread ID: 0x00000624
Start Time: 10:33:12.625 Call Duration 00:00:00.406
ibsta: 0x2164 iberr: 0 ibcntl: 2(0x2)
6. TestSRQ(0, FALSE (0))
Process ID: 0x00000F14 Thread ID: 0x00000624
Start Time: 10:33:13.062 Call Duration 00:00:00.000
ibsta: 0x164 iberr: 0 ibcntl: 2(0x2)
(6. repeated 300,000 times before MET/CAL gives up)
Do you have suggestions as to how to further troubleshoot this problem.
Sincerely
___________________________________________
Miikka Raninen
Technician
Accredited Calibration Laboratory
Finnish Airforces Materiel Command
Solved! Go to Solution.
07-22-2010 07:55 PM
Looks like you expect SRQ generation immediately after Operation Complete. Actually you get "1" from *ESR? query so the "operation" is actually complete. To generate an SRQ from this event, you need unfilter the related mask registers in advance.
*ESE 1 -- unfilter OPC bit on Event Status Register
*SRE 32 -- unfilter ESB bit on Status Byte Register
Both commands are required. Did you send them before the operation?
08-02-2010 02:35 AM
Checked line 10 with a multimeter on the GPIB-cable. It was cut inside the connector and no one had marked the cable as such. Should've done this weeks ago. ![]()