Re: read status nin "" 0 error with

[Ana Malagon <atmalagon@gmail.com>]

Changing -1 to 19 works, as does moving the TraceMask line below iocInit, thanks!

I realized that I had set respond2Writes incorrectly (it was 0, now have it set to -1). Changing this removes the "read status "" nin 0" error, however I still only get back 0 when I try to query the frequency. From the log messages, it seems like it's reading 14 characters though? At first glance I don't see anything pointing to an error in these messages, unless it's the timeout message, which occurs for both Get and Set. Eric, I'm not quite sure how to set the flags in prologixGPIBConfigure?

Output messages from ioc below:

############################################################################

## Start any sequence programs

#seq sncxxx,"user=admxHost"

epics> 2014/12/10 13:11:11.704 L0 19 prologixRead 7 EOM:0x6

2014/12/10 13:11:11.704 SDCARLO:GET:POW gpibRead nchars 7

2014/12/10 13:11:11.704 SDCARLO:GET:POW gpibRead

2014/12/10 13:11:11.704 asynManager::portThread port=L0 callback

2014/12/10 13:11:11.704 SDCARLO:GET:ON_OFF queueCallback

2014/12/10 13:11:11.704 SDCARLO:GET:ON_OFF prepareToRead

2014/12/10 13:11:11.704 L0 19 prologixWrite

2014/12/10 13:11:11.705 SDCARLO:GET:ON_OFF writeIt

2014/12/10 13:11:11.818 L0 19 prologixRead 1 EOM:0x6

2014/12/10 13:11:11.818 SDCARLO:GET:ON_OFF gpibRead nchars 1

2014/12/10 13:11:11.818 SDCARLO:GET:ON_OFF gpibRead

2014/12/10 13:11:11.818 asynManager::portThread port=L0 callback

2014/12/10 13:11:11.818 SDCARLO:IDN queueCallback

2014/12/10 13:11:11.818 SDCARLO:IDN prepareToRead

2014/12/10 13:11:11.818 L0 19 prologixWrite

2014/12/10 13:11:11.818 SDCARLO:IDN writeIt

2014/12/10 13:11:11.930 L0 19 prologixRead 43 EOM:0x6

2014/12/10 13:11:11.930 SDCARLO:IDN gpibRead nchars 43

2014/12/10 13:11:11.930 SDCARLO:IDN gpibRead

epics> dbpr SDCARLO:GET:FREQ

ASG:                DESC: Query Frequency ouput MHz         DISA: 0

DISP: 0             DISV: 1             NAME: SDCARLO:GET:FREQ

RVAL: 0             SEVR: NO_ALARM      STAT: NO_ALARM      SVAL: 0

TPRO: 0             VAL: 0

epics> dbpf SDCARLO:SET:FREQ 112014/12/10 13:11:54.927 SDCARLO:SET:FREQ queueWriteRequest

2014/12/10 13:11:54.927 L0 addr 19 queueRequest priority 2 not lockHolder

2014/12/10 13:11:54.927 L0 schedule queueRequest timeout

2014/12/10 13:11:54.927 asynManager::portThread port=L0 callback

2014/12/10 13:11:54.927 SDCARLO:SET:FREQ queueCallback

DBR_DOUBLE:         11

epics> 2014/12/10 13:11:54.927 SDCARLO:SET:FREQ gpibWrite

2014/12/10 13:11:54.927 SDCARLO:SET:FREQ writeMsgDouble

2014/12/10 13:11:54.927 L0 19 prologixWrite

2014/12/10 13:11:54.927 SDCARLO:SET:FREQ writeIt

2014/12/10 13:11:54.927 SDCARLO:GET:FREQ queueReadRequest

2014/12/10 13:11:54.927 L0 addr 19 queueRequest priority 2 not lockHolder

2014/12/10 13:11:54.927 L0 schedule queueRequest timeout

2014/12/10 13:11:54.927 asynManager::portThread port=L0 callback

2014/12/10 13:11:54.927 SDCARLO:GET:FREQ queueCallback

2014/12/10 13:11:54.927 SDCARLO:GET:FREQ prepareToRead

2014/12/10 13:11:54.927 L0 19 prologixWrite

2014/12/10 13:11:54.927 SDCARLO:GET:FREQ writeIt

2014/12/10 13:11:55.080 L0 19 prologixRead 14 EOM:0x6

2014/12/10 13:11:55.080 SDCARLO:GET:FREQ gpibRead nchars 14

2014/12/10 13:11:55.080 SDCARLO:GET:FREQ gpibRead

dbpr SDCARLO:GET:FREQ

ASG:                DESC: Query Frequency ouput MHz         DISA: 0

DISP: 0             DISV: 1             NAME: SDCARLO:GET:FREQ

RVAL: 0             SEVR: NO_ALARM      STAT: NO_ALARM      SVAL: 0

TPRO: 0             VAL: 0

On Wed, Dec 10, 2014 at 12:47 PM, Eric Norum <wenorum@lbl.gov> wrote:

Would changing the -1 to 19 in the existing commands in the existing location work, too?

On Dec 10, 2014, at 12:42 PM, Mark Rivers <rivers@cars.uchicago.edu> wrote:

--------
WARNING: At least one of the links in the message below goes to an IP address (e.g.10.1.1.1), which could be malicious. To learn how to protect yourself, please go here: https://commons.lbl.gov/x/_591B
--------

> I’m at a loss then.  I have no idea why enabling ASYN diagnostic messages is having no effect.

 

I know why it is happening.  Ana is doing this before iocInit.

asynSetTraceMask("L0", -1, 0xFF)

The problem is that using the address of -1 on asynSetTraceMask set the trace mask of all device address that are currently connected to that asyn port.  However, at that point the GPIB device at address 19 has not yet been connected, so its asynTraceMask does not get set.

The solution is to move that line to after iocInit.  You won’t see any trace information that should happen as part of iocInit, but you will see everything after that command is issued.

We might want to change the way asynSetTraceMask($(PORT), -1, MASK) works to avoid this confusion.  Someone else ran into this a couple of weeks ago.

Mark

 

 

 

-- 
Eric Norum
wenorum@lbl.gov