Experimental Physics and
Industrial Control System

"Allison, Stephanie" <[email protected]> · Wed, 15 Jul 2009 14:02:48 -0700

Hi Dirk,

Thanks for your reply.

> Have you tried to set ReadTimeout=0 ?

Yes, setting ReadTimeout to 0 works but I haven't yet tested it on a busy network.  I fear that if I set ReadTimeout to 0 and the network is a little slow between the time I send the request and the time the reply is ready, the read will return an error.

> Can you give an example of such a message? Any constant string at the end can be
> used as a terminator, not just CR or LF.

I send "MEAS:VOLT?;"  and I receive "00.009" with no terminator (see below for asyn output).  This is an example of a fixed-length reply where I can use MaxInput of 6 and the reply read will not timeout.  But not all replies are fixed length like this one.

2009/07/15 13:45:26.642 118-PSD5 flush
2009/07/15 13:45:26.642 134.79.35.216:8003 flush
2009/07/15 13:45:26.642 134.79.35.216:8003 write.
2009/07/15 13:45:26.642 134.79.35.216:8003 write 11
MEAS:VOLT?;
2009/07/15 13:45:26.642 118-PSD5 addr -1 queueRequest priority 0 from lockHolder
2009/07/15 13:45:26.642 118-PSD5 schedule queueRequest timeout
2009/07/15 13:45:26.642 118-PSD5 callback
2009/07/15 13:45:26.642 134.79.35.216:8003 read.
2009/07/15 13:45:26.727 134.79.35.216:8003 read 6
00.009
2009/07/15 13:45:26.727 118-PSD5 read
00.009
2009/07/15 13:45:26.727 134.79.35.216:8003 read.

Note the last "read" above is not necessary but is done anyway since there's no terminator.

Thank you,
Stephanie

> Allison, Stephanie wrote:
> > Hi Mark,
> >
> > Thanks for your reply.  I'm currently using stream version 2.2 and asyn version 4.9 on
> epics base 3.14.8.2.  I'm unable to get stream to work without timeout when the
> InTerminator is set to "" (meaning no terminator) and MaxInput=0.  Stream/asyn always
> waits ReadTimeout even though it has received the reply (it just doesn't know it has the
> *complete* reply).   If I set maxInput to a large number, then it also waits ReadTimeout
> waiting for extra input it'll never receive.
> >
> > I would really like to use stream instead of writing my own support on top of asyn just for
> this case.  Does anybody know how can I set up stream so that the InTerminator is "",
> maxInput is 100, but there is no need to wait for anything more after something...anything >
> 0 chars is received?   I still want to use a reasonable ReadTimeout for when things slow
> down a bit on the network.  Maybe I can use devGpib for this case, though stream would be
> better.
> >
> > Thank you,
> > Stephanie
> >
> >> -----Original Message-----
> >> From: Mark Rivers [mailto:[email protected]]
> >> Sent: Tuesday, July 14, 2009 10:16 AM
> >> To: Allison, Stephanie; Epics Questions
> >> Subject: RE: When an external device does not provide termination on TCP
> ASCIIstream
> >> replies
> >>
> >> Hi Stephanie,
> >>
> >> I think you should be fine.  Many TCP devices don't sent terminators,
> >> unlike their serial counterparts.  In your st.cmd file you just don't
> >> define an input or output EOS for that driver, and you don't put a
> >> terminator in your protocol file.  The TCP driver does not loop waiting
> >> for maxChars, it just reads the message.  TCP delivers "complete"
> >> messages, so you will get the complete response, not just a partial
> >> response.
> >>
> >> Mark
> >>
> >>
> >> -----Original Message-----
> >> From: [email protected]
> >> [mailto:[email protected]] On Behalf Of Allison, Stephanie
> >> Sent: Tuesday, July 14, 2009 11:58 AM
> >> To: Epics Questions
> >> Subject: When an external device does not provide termination on TCP
> >> ASCIIstream replies
> >>
> >> Hello,
> >>
> >> We're testing a Genesys power supply (provided by Lambda-TDK) to which
> >> the vendor has added a TCP interface (I believe specifically by request
> >> of EPICS sites).  Burkhard Kolb at GSI provided me the protocol file for
> >> stream/asyn support for this type of device (thanks!).  However, the
> >> firmware has changed recently and one change is to remove the terminator
> >> from the reply strings.  Some replies are fixed-length so I can change
> >> the protocol file for these (to use maxInput).  However some replies are
> >> not fixed-length and I need to find support for those - I do not want to
> >> rely on a timeout to know that the reply is finished.  The vendor has
> >> suggested that (1) I assume the reply will never get fragmented and just
> >> allocate 100 bytes and take whatever I get and (2) block on the receive
> >> (which is not an option for an IOC).
> >>
> >> Does anybody have experience with such devices (TCP ASCII SCPI commands
> >> that have no reply terminators and no fixed-length reply strings) and
> >> can recommend a solution?
> >>
> >> Thank you,
> >> Stephanie Allison
> >> SLAC National Accelerator Lab
> >
> >
> >
> 
> --
> Dr. Dirk Zimoch
> Paul Scherrer Institut, WBGB/006
> 5232 Villigen PSI, Switzerland
> Phone +41 56 310 5182

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System