Experimental Physics and
Industrial Control System

[email protected] (Nick Rees) · Wed, 27 Sep 95 14:30:12 HST

A little while ago Rozelle suggested:

> There are other problems with the Capfast symbols which could be fixed if
> someone wanted to take on the job of doing so.
> It might be useful to open up a discussion of what fixes are actually needed.

...

> Problems I have seen with the most commonly used symbols are:
> 1.  OUT and INP fields are defined as typ VAL.  This generates an error from
> e2sr which clutters up the output so that real errors can be missed.
> This was done because the default value for the OUT or INP field is a hardware address.
> However, if you set the typ to PATH, it doesn't complain and you can tell when
> you get a real error.
> 
> 2.  Problems with SIOL as mentioned above.
> 
> 3.  The VAL port for a PID record should be an input port rather than an output port.
> (Actually the VAL port for the Ao and Bo record is most logically an input port)
> 
> A work around for all of these problems is to make changes in the instances of the
> symbols used for your particular schematic.  Even the last one.  Capfast seems
> to see no problem in having a user defined input port called VAL as well as an output
> port with that name.

I have been doing my first real work with Capfast (the new Motif
version), and what I have done is:

1. Developed a new set of Motif style menus for Capfast. The basis for
   this was the menus delivered with the Microsoft Windows version of
   Capfast (which Phase 3 gave me on demo once). We have been using these,
   plus the Beta release of the native Solaris version of Capfast 
   for some time now with much success.

2. Developed a basic property rules file for Epics.

3. Replaced the dfan symbol that is delivered with a new one. The one
   that is delivered bears little resemblance to the one in the
   distribution - presumably it is a historical artefact.

4. Made SIOL an output link on the relevant records.

5. Developed a shell script which goes through a list of *.sym files and
   used it on my epics symbols. It does the following:

   a. Made NPP/PP and NMS/MS visible in a small font adjacent to all ports
      that are links (i.e. have pproc() and palrm() properties). I find
      this valuable since it tells me which ports are links and also helps
      decode the database logic.

   b. Made all typ() properties except those in hwinput and hwoutput
      symbols default to path, rather than val. I have not found a use for
      val except for the hardware I/O symbols.

   c. Removed all typ(U?) properties. In my experience most links are
      already on the symbols and so user defined ports tend to be record
      fields. The presence of these typ(U?) properties (but no ppalrm and
      pproc properties) caused a number of warnings and resulted in me 
      posting a question to the exploder a little while back.

   d. Arranged all the port names in a uniform way (centred on the port
      leads, and just above them)

I think this deals with all of Rozelle's points except for I/O problems
on the VAL field. In fact, all ports which are field references should
be defined to be bi-directional ports, not input or output, since only
links have a direction associated with them. I don't mind having the
VAL field on the RHS of the symbol - even now if you connect a OUTLINK
to it it will push data into it (despite it being a Capfast output
port). With my new symbols I just tell people that if there isn't NPP/NMS
next to the port then it is a field reference and so is bi-directional.

Comments, suggestions anyone?

Nick Rees

Joint Astronomy Centre                    Ph:       +1 (808) 961-3756
660 N. Aohoku Place                       Fax:      +1 (808) 961-6516
Hilo, HI.  96720                          Internet: [email protected]

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System