Experimental Physics and Industrial Control System
|
With asynDriver the same goal can be attained in a more generic fashion.
One solution is as follows:
The code, lets call it thalesDriver would use two portNames. Lets call
them psuedoPort and actualPort.
For psuedoPort, thalesDriver would call registerPort and
registerInterface just like an actual serial driver.
It would create an asynUser for actualPort, i. e. it would just be a
normal asynUser.
The code details could be very similar to what Eric has already done.
Some advantages of using asynDriver rather than gpibCore are:
1) This solution will work on all supported architectures, i.e. vxWorks,
Linux, RTEMS, win32, solaris, darwin.
2) The asynTrace facility will work on both psuedoPort and actualPort..
3) Connection management will work on both psuedoPort and actualPort.
4) By implementing some of the new register interfaces, the generic
register based device support can be used. Thus no special device
support would be needed.
5) Since gpibCore no longer has anyone to support it, asynDriver will
have a longer lifetime :-)
NOTE: I was supporting gpibCore. asynDriver is the successor to gpibCore
plus much more.
Marty Kraimer
Eric Williams wrote:
I just thought I'd throw this solution out so it would be in the
archives if someone else needed it.
We have a RS-232 device we wanted to control with EPICS (a Thales
Optem zoom lens control stepping motor drive) that reported its status
on a continuous basis. The IOC was a Linux box running 3.14 with the
GpibCore driver used to talk to the serial port.
Because the device didn't wait for a command but instead sent its
status periodically, the serial port's input buffer would fill up and
cause GpibCore to get an error and dump EPICS as soon as you tried to
process any of the records going to the device's port. I thought
about digging into the driver and making it more tolerant of babbling
devices, but abandoned that idea in favor of an easier solution.
I built a filter daemon which would open the serial port to the device
and pick up the input stream, decode the status, and store it
locally. The other side of the filter was through a pseudo-tty which
emulated the device's command set, passing on commands to the device,
but with the addition of a new command to read the local copy of the
current status. This daemon ran in the background, and the GpibCore
driver would talk to the pseudo-tty port instead of the serial port.
The daemon was auto-started through the standard Linux init mechanisms.
--
Eric Williams
Advance Light Source
Lawrence Berkeley Lab
- References:
- Babbling serial device Eric Williams
- Navigate by Date:
- Prev:
R3.14.6 Sequencer (for hpux) bug Kristi Luchini
- Next:
R3.14.6 sequencer compliation error on hpux Kristi Luchini
- 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:
Babbling serial device Eric Williams
- Next:
genSub records with EPICS 3.14.4 and g++ 3.3 - solaris Wayne Dahl
- 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
|
ANJ, 10 Aug 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|