Experimental Physics and
Industrial Control System

Benjamin Franksen <[email protected]> · Tue, 14 Sep 1999 22:02:41 +0200

Dirk Zimoch wrote:
> 
> I've written a generic device support that should be able to talk
> to all fieldbus devices, which do I/O as a stream of bytes.
> I call it the Stream Device.
> ....

This is cool! I believe this could be the ultimate replacement for
devCommonGpib. It also seems that it could make a 'generic GPIB driver'
obsolete or at least much simpler. Why in hell didn't you tell us about
this earlier? We've been trying to figure out how to design a unified
GPIB support all the while. Gosh.

I very much like the idea of having a single (Stream) device support and
handling the device specific stuff in protocol files. I'd even support
this as the general approach in EPICS to such devices, if there wasn't
the problem of converting existing GPIB device supports and databases
(maybe this will be less critical with unbundled hardware support, but
it should be considered at least).

If the definition(s) of the interface(s) to low level-drivers for GPIB
are not yet irrevocably nailed down, I'd strongly recommend that we
collaborate in this. We already have three incompatible GPIB drivers, a
situation I am desperately trying to solve. Let's not repeat the MEDM
story with GPIB support, please!

Another point: While reading your web-pages, I stumbled over the
following two statements; this is, I think, of general interest:

1) "Some record supports want fields to be set by the device support
(ROFF, ESLO, MASK, SHFT). The Stream Device Support touches
none of them with one exeption: the MASK field of mbb* records is
shifted left by SHFT bits. The other fields can be specified in the
.db file even though the Record Reference Manual says that the DCT can
not set them."

I remember that there has been some discussion about MASK and SHFT in
the tech-talk, with the result that these are to be made DCT fields in
the mbb* records. Obviously this didn't make it into the Record
Reference Manual. I heard no similar thing about ROFF and ESLO (though I
would GREATLY appreciate if it were so). Our EPICS release (3.13.1)
says:

aiRecord.dbd:
	field(ESLO,DBF_DOUBLE) {
		prompt("Rawto EGU Slope")
		special(SPC_NOMOD)
		interest(2)
		initial("1")
	}
aoRecord.dbd:
	field(ESLO,DBF_DOUBLE) {
		prompt("EGU to Raw Slope")
		special(SPC_NOMOD)
		interest(2)
		initial("1")
	}

and similar (no promptgroup) with ROFF. Has there ever been a version of
EPICS in which these fields are DCT, and why then was it changed back?
(BTW, in 3.13.1, ROFF is obsolete and is replaced by EOFF). I think
there should be a way to make Stream support set ESLO & EOFF for linear
conversion (depending on EGUL & EGUF) as with other device supports.

2) Concerning the INP/OUT field for INST_IO link type: "You have 78
characters after the @, even though the Application Developers's Guide
says you only have 35 characters (Version 3.13.0.beta4)."

What about the CA limitations here? And: will this be compatible with
Andrew's new link support proposals (for R3.14)?

Ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System