I looked at my protocol file for serial communication with the lksh 340
and found the following:
# Lakeshore 330/332/340 Temperature Controller Protocol File
Terminator = CR LF;
#############################################################################
# Lakeshore Common Commands
idn {
out "*IDN?"; in "%39c";
}
I remember switching from %s to %39c to make it work, but can’t remember
if I ever found out why this change was needed.
--
Rodney R. Porter
On 5/11/07 10:01 AM, "Matthew Pearson" <[email protected]>
wrote:
Hi,
I've been trying to get a Lakeshore 340 temperature controller
working via a Agilent E5810A Ethernet to GPIB gateway. I can run a
soft IOC and communicate successfully using an AsynRecord, writing
to the AOUT field and reading the result back from the AINP field.
However, I would like to use the 340 via streams. My protocol file
looks like:
Terminator = CR LF;
ReplyTimeout = 1000;
getID {
out "*IDN?";
in "%s";
}
And the record tied to this, is:
record(stringin, "$(P):ID") {
field(DTYP, "stream")
field(INP, "@ls340.proto getID L0 12")
}
If I process the record, then the IOC prints:
************************
epics> 2007/05/11 15:55:45.125 L0 addr 12 queueRequest priority 0
not lockHolder
2007/05/11 15:55:45.125 L0 schedule queueRequest timeout
2007/05/11 15:55:45.125 L0 callback
2007/05/11 15:55:45.125 L0 addr 12 queueRequest priority 0 not
lockHolder
2007/05/11 15:55:45.125 L0 schedule queueRequest timeout
2007/05/11 15:55:45.125 L0 callback
2007/05/11 15:55:45.125 L0 12 vxiWrite numchars 5
2007/05/11 15:55:45.128 L0 12 vxiWrite
*IDN?
*IDN?
2a 49 44 4e 3f
2007/05/11 15:55:45.128 L0 addr 12 queueRequest priority 0 from
lockHolder
2007/05/11 15:55:45.128 L0 schedule queueRequest timeout
2007/05/11 15:55:45.128 L0 callback
2007/05/11 15:55:45.128 L0 vxiSetEos 0
2007/05/11 15:55:45.140 L0 12 vxiRead
L
L
4c
2007/05/11 15:55:45.140 BL16I-EA-LS340-01:ID: asynOverflow:
2007/05/11 15:55:45.140 BL16I-EA-LS340-01:ID: I/O error from device
2007/05/11 15:55:45.140 BL16I-EA-LS340-01:ID: Protocol aborted
*************************
This is with all asyn tracing turned on.
The equivalent printout for the AsynRecord, is:
****************************
2007/05/11 15:57:53.682 L0 addr 12 queueRequest priority 0 not
lockHolder
2007/05/11 15:57:53.682 L0 schedule queueRequest timeout
2007/05/11 15:57:53.682 L0 callback
2007/05/11 15:57:53.682 mp49:asyn:Record: asynCallbackProcess, state=3
2007/05/11 15:57:53.683 mp49:asyn:Record flush
2007/05/11 15:57:53.683 L0 12 vxiWrite numchars 5
2007/05/11 15:57:53.685 L0 12 vxiWrite
*IDN?
*IDN?
2a 49 44 4e 3f
2007/05/11 15:57:53.685 mp49:asyn:Record: nwrite=5, status=0, nawt=5
*IDN?
*IDN?
2a 49 44 4e 3f
2007/05/11 15:57:53.741 L0 12 vxiRead
LSCI,MODEL340,342162,042304
LSCI,MODEL340,342162,042304\r\n
4c 53 43 49 2c 4d 4f 44 45 4c 33 34 30 2c 33 34 32 31 36 32
2c 30 34 32 33 30 34 0d 0a
2007/05/11 15:57:53.741 mp49:asyn:Record: inlen=40, status=0, ninp=29
LSCI,MODEL340,342162,042304
LSCI,MODEL340,342162,042304\r\n
4c 53 43 49 2c 4d 4f 44 45 4c 33 34 30 2c 33 34 32 31 36 32
2c 30 34 32 33 30 34 0d 0a
2007/05/11 15:57:53.741 mp49:asyn:Record: inlen=29,
nbytesTransfered=29, ntranslate=31
**********************************************************
And this seems fine, the write and read works and I get back the
result which I want.
Any ideas about the problem with the streams record?
I have attached my IOC startup file too.
Thanks,
Matthew