Hi Marcel,
I use the followin GPIB command table with asy/vxi11 support:
static struct gpibCmd gpibCmds[] = {
/* Param 0, SRQ handler*/
{&DSET_LI, GPIBSRQHANDLER, IB_Q_HIGH, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0},
/* Param 1, Enable SRQ*/
{&DSET_BO, GPIBCVTIO, IB_Q_HIGH, NULL, NULL, 0, 0, boSRQonOff, 0,
0, NULL,NULL,NULL },
};
With this setting it seems working to detect SRQ on IOC as I expected. I
don't have any experience with GPIBREADW, so it may not help you to
resolve the problem, but I report my experience with the table above.
For SRQ, my IOC has two records to detect SRQ on IOC side.
=========
record(longin,"$(OSC):SRQHandler") {
field(DTYP,"SRQGpib")
field(INP,"#$(PORT) A$(A) @0")
field(FLNK,"$(OSC):srqCount.PROC")
}
record(calc,"$(OSC):srqCount") {
field(DESC, "Count sollicited SRQs")
field(CALC, "A+B")
field(INPA, "$(OSC):srqCount")
field(INPB,"1")
field(EGU, "interrupts")
}
record(bo,"$(OSC):enableSRQ") {
field(DTYP,"SRQGpib")
field(OUT,"#$(PORT) A$(A) @1")
field(PINI,"NO")
field(ZNAM,"disable SRQ")
field(ONAM,"ebnable SRQ")
}
=======
So, when SRQ is detected on IOC the counter record , $(OSC):srqCount,
will be incremented.
It also includes other records using StreamDevice support to send SCPI
commands to the device.
After setting SRE and ESE registers to generate SRQ upon OPC and enable
SRQ with the "$(OSC):enableSRQ" record, I got the following record of
operation on IOC.:
==============
epics> dbgf OSC:srqCount
DBF_DOUBLE: 6 <- value of counter before this operation
epics> dbpf OSC:DEBUG "*IDN?;*OPC;" <- send SCPI command for value and
ask to generate OPC event.
2020/07/16 09:17:26.632 L0 addr -1 queueRequest priority 0 not lockHolder
2020/07/16 09:17:26.632 L0 schedule queueRequest timeout in 10.000000
seconds
DBF_STRING: "*IDN?;*OPC;"
2020/07/16 09:17:26.632 asynManager::portThread port=L0 callback
2020/07/16 09:17:26.632 L0 addr -1 queueRequest priority 0 not lockHolder
2020/07/16 09:17:26.632 L0 schedule queueRequest timeout in 0.100000 seconds
2020/07/16 09:17:26.632 asynManager::portThread port=L0 callback
2020/07/16 09:17:26.632 L0 -1 vxiWrite numchars 12
2020/07/16 09:17:26.633 L0 -1 vxiWrite
*IDN?;*OPC;
*IDN?;*OPC;\n
2a 49 44 4e 3f 3b 2a 4f 50 43 3b 0a
2020/07/16 09:17:26.633 L0 addr -1 queueRequest priority 0 from lockHolder
2020/07/16 09:17:26.633 L0 schedule queueRequest timeout in 3.000000 seconds
2020/07/16 09:17:26.633 asynManager::portThread port=L0 callback
2020/07/16 09:17:26.633 L0 vxiSetEos 1
\n
0a
epics> 2020/07/16 09:17:26.643 L0SRQ SRQ
2020/07/16 09:17:26.643 L0 asynGpib:srqHappened
2020/07/16 09:17:26.643 L0 addr -1 queueRequest priority 1 not lockHolder
2020/07/16 09:17:26.644 L0SRQ SRQ
2020/07/16 09:17:26.644 L0 asynGpib:srqHappened
2020/07/16 09:17:26.734 L0SRQ SRQ
2020/07/16 09:17:26.734 L0 asynGpib:srqHappened
2020/07/16 09:17:26.734 L0 -1 vxiRead
TEKTRONIX,DPO4034B,C010921,CF:91.1CT FV:v1.38
TEKTRONIX,DPO4034B,C010921,CF:91.1CT FV:v1.38 \n
54 45 4b 54 52 4f 4e 49 58 2c 44 50 4f 34 30 33 34 42 2c 43
30 31 30 39 32 31 2c 43 46 3a 39 31 2e 31 43 54 20 46 56 3a
76 31 2e 33 38 20 0a
2020/07/16 09:17:26.734 L0 vxiSetEos 0
2020/07/16 09:17:26.734 asynManager::portThread port=L0 callback
2020/07/16 09:17:26.734 L0 asynGpib:srqPoll serialPollBegin
2020/07/16 09:17:26.735 L0 asynGpib:srqPoll serialPoll addr 0 statusByte
60 <--- asyn/asynGPIB/asynGPIB.c line 264. the next "if" statement will
executed.
2020/07/16 09:17:26.735 L0 asynGpib:srqPoll serialPollEnd
dbgf OSC:srqCount
DBF_DOUBLE: 7
==============
As this log shows, IOC detect SRQ and process records related to this SRQ.
I hope this information help.
Regards,
Noboru Yamamoto
J-PARC accelerator control group
KEK, JAPAN
On 2020/06/22 20:54, Mark Rivers via Tech-talk wrote:
Hi Marcel,
I am not an expert in VXI-11. I don't know if the SRQ functionality in VXI-11 using the old devGpib device support has ever been tested. It looks like you are getting the 5 second timeout on recognizing the SRQ response defined here:
devGpib/devSupportGpib.c:#define DEFAULT_SRQ_WAIT_TIMEOUT 5.0
I don't know what the expected sequence of events is to recognize the SRQ, which as you said appears to have happened OK.
I am including tech-talk in this reply in case someone else can help.
Mark
________________________________
From: marcel.wurm at ptb.de <marcel.wurm at ptb.de>
Sent: Monday, June 22, 2020 5:11 AM
To: Mark Rivers
Subject: SRQ over VXI
Hello Mark,
i`m trying to use a written and working GPIB driver for a Keysight 2985 over a VXI-11 connection instead.
But i`m struggling a little bit with the SRQ-signal.
The VXI-11 connection and communication works good with these lines in the "st.cmd"-file: (i added the mask lines for some debug information)
vxi11Configure("L0", keyem01.ahf.ptb.de, 0, 2.0, "inst0", 0)
asynSetTraceMask("L0", 0, 0xff)
asynSetTraceIOMask("L0", 0, 0xff)
I set the i3address for the used driver to "00".
The functions work and i get correct values for some reading operations.
But the functions which were implemented with GPIBREADW and waiting for SRQ don`t work.
Reading Operation with a function without SRQ:
2020/06/22 11:24:16.610 A2980:keyem0100sourceGetVolt queueReadRequest
2020/06/22 11:24:16.610 L0 addr -1 queueRequest priority 2 not lockHolder
2020/06/22 11:24:16.610 L0 schedule queueRequest timeout
2020/06/22 11:24:16.610 asynManager::portThread port=L0 callback
2020/06/22 11:24:16.610 A2980:keyem0100sourceGetVolt queueCallback
2020/06/22 11:24:16.610 A2980:keyem0100sourceGetVolt prepareToRead
2020/06/22 11:24:16.611 L0 -1 vxiWrite numchars 11
2020/06/22 11:24:16.613 L0 -1 vxiWrite
:SOUR:VOLT?
:SOUR:VOLT?
3a 53 4f 55 52 3a 56 4f 4c 54 3f
2020/06/22 11:24:16.613 A2980:keyem0100sourceGetVolt writeIt
:SOUR:VOLT?
:SOUR:VOLT?
3a 53 4f 55 52 3a 56 4f 4c 54 3f
2020/06/22 11:24:16.618 L0SRQ SRQ
2020/06/22 11:24:16.618 L0 asynGpib:srqHappened
2020/06/22 11:24:16.618 L0 addr -1 queueRequest priority 1 not lockHolder
2020/06/22 11:24:16.620 L0 -1 vxiRead
+0.00000000E+000
+0.00000000E+000\n
2b 30 2e 30 30 30 30 30 30 30 30 45 2b 30 30 30 0a
2020/06/22 11:24:16.620 A2980:keyem0100sourceGetVolt gpibRead nchars 17
2020/06/22 11:24:16.620 A2980:keyem0100sourceGetVolt gpibRead
+0.00000000E+000
+0.00000000E+000\n
2b 30 2e 30 30 30 30 30 30 30 30 45 2b 30 30 30 0a
2020/06/22 11:24:16.621 asynManager::portThread port=L0 callback
2020/06/22 11:24:16.621 L0 asynGpib:srqPoll serialPollBegin
2020/06/22 11:24:16.623 L0 asynGpib:srqPoll serialPoll addr 0 statusByte 04
2020/06/22 11:24:16.623 L0 asynGpib:srqPoll serialPollEnd
Reading Operation with a function which waits for SRQ:
2020/06/22 11:24:56.827 A2980:keyem0100rawData queueReadRequest
2020/06/22 11:24:56.827 L0 addr -1 queueRequest priority 2 not lockHolder
2020/06/22 11:24:56.827 L0 schedule queueRequest timeout
2020/06/22 11:24:56.828 asynManager::portThread port=L0 callback
2020/06/22 11:24:56.828 A2980:keyem0100rawData queueCallback
2020/06/22 11:24:56.828 A2980:keyem0100rawData prepareToRead
2020/06/22 11:24:56.828 L0 -1 vxiWrite numchars 6
2020/06/22 11:24:56.830 L0 -1 vxiWrite
:READ?
:READ?
3a 52 45 41 44 3f
2020/06/22 11:24:56.830 A2980:keyem0100rawData writeIt
:READ?
:READ?
3a 52 45 41 44 3f
2020/06/22 11:24:57.045 L0SRQ SRQ
2020/06/22 11:24:57.045 L0 asynGpib:srqHappened
2020/06/22 11:24:57.045 L0 addr -1 queueRequest priority 1 not lockHolder
2020/06/22 11:25:01.826 A2980:keyem0100rawData waitTimeout
2020/06/22 11:25:01.826 L0 addr -1 queueRequest priority 2 from lockHolder
2020/06/22 11:25:01.826 L0 schedule queueRequest timeout
2020/06/22 11:25:01.826 asynManager::portThread port=L0 callback
2020/06/22 11:25:01.826 A2980:keyem0100rawData queueCallback
2020/06/22 11:25:01.826 A2980:keyem0100rawData readAfterWait
2020/06/22 11:25:01.826 asynManager::portThread port=L0 callback
2020/06/22 11:25:01.826 L0 asynGpib:srqPoll serialPollBegin
2020/06/22 11:25:01.828 L0 asynGpib:srqPoll serialPoll addr 0 statusByte 54
2020/06/22 11:25:01.828 L0 asynGpib:srqPoll serialPollEnd
But the message:
2020/06/22 11:24:57.045 L0 asynGpib:srqHappened
shows that there was a recognized SRQ over the vxi connection.
But it seems that the values were not read after the SRQ.
Thanks and
Best regards
Marcel Wurm
Physikalisch-Technische Bundesanstalt
7.25 Informationstechnik Berlin-Adlershof
Albert-Einstein-Straße 15
12489 Berlin
Tel.: +49 30 3481 7166
E-Mail: marcel.wurm at ptb.de
--
Noboru Yamamoto
Accelerator Control group
J-PARC center/KEK & JAEA
--------
web: http://www-acc.kek.jp/EPICS_Gr/default.html
- References:
- Re: SRQ over VXI Mark Rivers via Tech-talk
- Navigate by Date:
- Prev:
RE: HiSLIP support(experimental) for asy/stream device. Mark Rivers via Tech-talk
- Next:
Stream device - general concept how to use Christian Pauly via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: SRQ over VXI Mark Rivers via Tech-talk
- Next:
Does IOC name have any restrictions ? Hitesh Dhola via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
<2020>
2021
2022
2023
2024
|
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·