On 7/28/10 10:33 AM, David Dudley wrote:
> Here’s a new one for you (Got Ralph and Michael going about how to do
> it, anyway ;-)
>
> Almost all of the PLC equipment we’re going to be using on NSLS/2 is
> connected on Ethernet.
>
> It is common practice in the communications modules now, to integrate an
> embedded WEB server into the device. Both the Siemens and Rockwell
> hardware we’re going to use have that capability, as well as most of the
> new generation of instrumentation.
>
> Does anyone have knowledge of an EPICS device driver that is capable of
> reading and interpreting a WEB page or XML page? Seems that this would
> be the most universal way to read data from all this differing
> equipment, if such a driver was available.
>
> David Dudley
Hi, David.
Are you asking about a generic EPICS device driver for communicating
with devices via HTTP and capable of interpreting HTML or XML, or are
you asking about existing drivers that do this for a particular device?
I've written two drivers that communicate w/ the device via HTTP and
then extract the needed information from an HTML response:
http://www.imca.aps.anl.gov/~jlmuir/sw/dli-epcr.html
http://www.imca.aps.anl.gov/~jlmuir/sw/websensor-em01b.html
These drivers use asyn but have hacks to deal w/ the connection getting
closed after each request which asyn did not handle well before asyn
4-13. According to the asyn 4-13 release notes, new behavior has been
added to handle this by specifying "http" as the protocol in
drvAsynIPPortConfigure. I haven't tried it yet.
Certainly something generic could be written to make it easy to
construct the HTTP request, handle any authentication, and handle the
response. This might provide something like the httplib module in Python.
I think it would get more difficult if you wanted to go beyond that. A
simple method for interpreting the response is to use regular expression
matching to extract the desired information. One would then typically
want to convert that text into some more appropriate value (e.g. a
double) in the driver.
A more powerful approach would be to actually provide an HTML or XML
parser allowing access to the response via SAX or a DOM. I'm not sure
how this would work for devices that return invalid HTML or XML
responses. I would bet that many devices do not actually respond with
valid HTML or XML.
Lewis
--
J. Lewis Muir
Software Engineer
IMCA-CAT
- Replies:
- Re: HTML Device Driver Pete Jemian
- References:
- HTML Device Driver David Dudley
- Navigate by Date:
- Prev:
Re: HTML Device Driver Pete Jemian
- Next:
Re: HTML Device Driver Pete Jemian
- 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: HTML Device Driver Pete Jemian
- Next:
Re: HTML Device Driver Pete Jemian
- 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
|