Experimental Physics and
Industrial Control System

Tim Mooney <[email protected]> · Sat, 12 Jul 2003 17:41:26 -0500

re...,

"Hoff, Lawrence" wrote:
> 
>         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.

Maybe the record should have its own "current working directory", so you aren't vulnerable to someone
changing the IOC's cwd.

> ...
>         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).

If you're forced into custom GUI code anyway, why bother with the EPICS string type?  Custom code
can easily make any array of char behave as a string, and CA has no problem with char arrays of
fewer than 16000 bytes.  If you're thinking about a rendezvous sometime in the future with
enhanced standard clients, I'd guess those clients will support long strings before they support
arrays of short strings posing as long strings.

However, we have used EPICS strings to specify a file path.  With saveData (which needs a path
to write data files) we split the path into just two EPICS strings: the NFS mount point, and the
path relative to that mount point.  We did this because custom GUI code was not an option;
because this arrangement allows us to hide from the user the fact that a complete file path from
an IOC might look different than the equivalent path from a workstation; and because it allows us
to use access security to constrain the mount point, so that users can't make the mistake of
specifying a file path that the IOC is not permitted to use.

-- 
Tim Mooney ([email protected]; 630-252-5417)
Advanced Photon Source
APS Operations Division
Beamline Controls & Data Acquisition Group

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System