We have an application where we need to specify a file (a DSP executable) to be downloaded (via
EPICS) to a target system. We are using the technique of specifying the filename with a stringout record,
with the assumption that the file is in the current working directory of the IOC to stay within the 40
character limit of the stringout record.
To try to improve on that situation, I have developed a "file selector" record. In addition to
working around the 40 character limit of the stringout record, this record is actually file system aware. It
can be used to navigate through a file system (or portion of a file system), and do useful things like send
back a (filtered) directory listing to the user to make selections from (providing a remote view of the file
system as seen by the IOC), and validate the existence of the selected file or directory.
Following the mantra of the eXtreme Programming movement (release early, release often), I've
attached source code and user documentation for an "alpha" version of this record. I'd like to see whether
or not there is broad interest in such a record, solicit user feedback on features, ask for assistance filling
in support for "other" (non-VxWorks) systems, e.g. RTEMS. In its current form, this record only fully
supports file systems based on the VxWorks netDrv device driver. There is also support for any properly
behaving POSIX-compliant file systems (which VxWorks nfsDrv and MS-DOS file systems emulate), but
without filtering support at this point.
One caveat with this record is that it works around string length constraints by implementing the
VAL field as an array of strings, one string for each pathname element (e.g. "usr", "sbin", "arp"), and by
implementing the directory listing field (FLIST) in a similar manner. There are a couple issues with this
approach:
1) Each element is still constrained to 40 characters. Therefore it will not be possible to select a
file or directory element whose name exceeds 40 characters, and all files reported in
directory listings are truncated to 40 characters as well.
2) Standard display manager applications (MEDM, EDM) do not handle arrays of strings well.
Commandline tools such as caget/caput do fine (though camonitor does not). Until and
unless display manager applications handle arrays of string fully, any user interface to this
record will have to be of a custom design (Java, Tkl/k, or even a perl script using
caget/caput).
A second caveat is that so far the record is focused on our particular needs (using VxWorks
netDrv). It may not compile and run on a non-VxWorks (e.g. LINUX) environment without removing the
VxWorks-specific code. Even on VxWorks systems, this record relies on the presence of support for the
VxWorks "pipe driver" (pipeDrv) to function properly.
In anyone has a need for such a record, I encourage you to "kick the tires" of this one and let me
know what you think. Also if there alternate ideas about how to use EPICS as a conduit to specify a file to
be used by the IOC, I'd like to hear them as well.
Attachment:
0-9.tar.gz
Description: GNU Zip compressed data
- Replies:
- Re: File selection tools Tim Mooney
- Navigate by Date:
- Prev:
Re: autosave/restore software fails Tim Mooney
- Next:
Re: File selection tools Tim Mooney
- 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: autosave/restore software fails Tim Mooney
- Next:
Re: File selection tools Tim Mooney
- 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
|