Subject: |
RE: When an external device does not provide termination on TCP ASCIIstream replies |
From: |
"Allison, Stephanie" <[email protected]> |
To: |
"Dirk Zimoch" <[email protected]> |
Cc: |
Epics Questions <[email protected]> |
Date: |
Thu, 16 Jul 2009 16:09:36 -0700 |
Hi again Dirk,
> >> 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.
> >
>
> This is not a problem because StreamDevice uses two different timeouts:
> ReplyTimeout and ReadTimeout. ReplyTimeout is the time between the request and
> the reply which may be long any traffic dependent. But ReadTimeout is the time
> between the individual pieces of a message. If the message is guaranteed to come
> in one piece, 0 is fine here.
I tried it - it works as you say. This is exactly what I was looking for. I should've Read The Fine Manual - it is there.
Thanks for making my day,
Stephanie
> >> 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.
>
> This is really bad. Maybe not so bad on TCP connections where there are internal
> methods to check the integrity of a message. But on RS232 you would not notice
> when you get only half a message (maybe because of bad connection) and end up
> with "00.0". This is where the ReadTimeout would trigger.
>
> Thus I think it's safe to use terminator and ReadTimeout>0 on RS232 and no
> terminator and ReadTimeout=0 on TCP. It's a pity that one has to change the
> protocol depending on the bus type.
>
> > 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.
>
> This is harmless. With timeout 0 it consumes (almost) no time.
>
>
> Best regards,
> Dirk
>
>
>
> >
> > 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
> >
>
> --
> Dr. Dirk Zimoch
> Paul Scherrer Institut, WBGB/006
> 5232 Villigen PSI, Switzerland
> Phone +41 56 310 5182
- References:
- When an external device does not provide termination on TCP ASCII stream replies Allison, Stephanie
- RE: When an external device does not provide termination on TCP ASCIIstream replies Mark Rivers
- RE: When an external device does not provide termination on TCP ASCIIstream replies Allison, Stephanie
- Re: When an external device does not provide termination on TCP ASCIIstream replies Dirk Zimoch
- RE: When an external device does not provide termination on TCP ASCIIstream replies Allison, Stephanie
- Re: When an external device does not provide termination on TCP ASCIIstream replies Dirk Zimoch
- Navigate by Date:
- Prev:
Re: When an external device does not provide termination on TCP ASCIIstream replies Dirk Zimoch
- Next:
RE: Escaped strings from fullPathName.pl Rees, NP (Nick)
- 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: When an external device does not provide termination on TCP ASCIIstream replies Dirk Zimoch
- Next:
Re: When an external device does not provide termination on TCP ASCIIstream replies Burkhard Kolb
- 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
|