Experimental Physics and
Industrial Control System

Ben Franksen via Core-talk <core-talk at aps.anl.gov> · Thu, 2 Apr 2020 17:46:50 +0200

Here is a short update.

tl;dr: Ralph had it right.

For the envisioned array put modifier, I am now side-stepping server
side filters as suggested by Ralph. Instead I have added a simple
structure which I coined "address modifier":

typedef struct {
    long start;
    long incr;
    long end;
} dbAddrModifier;

dbChannel now contains a pointer to such a thing, which is NULL by
default and gets allocated and initialized if the PV name has a [s:i:e]
modifier (JSON syntax is not supported). I added two functions to
dbAccess: dbPutModifier and dbPutFieldModifier that work like dbPut and
dbField, respectively, only with an extra parameter of type
dbAddrModifier*. The old dbPut/Field functions call these with a NULL
pointer, so this is fully source compatible. (May later replace these
with macros.)

The implementation is straight-forward and works as far as I have tested
it (which is: not much yet).

I am now in the process of writing unit tests. In my naivety I thought
it would be a simple matter to start with Dirk's linkFilterTest,
copy-paste that and adapt it. The first problem here is that in base
there is no array valued output record type. So I grabbed the simple
arrRecord from test/ioc/db, and turned that into an output record. For
reasons that are completely unclear to me I can't seem to get this to
work at all. Every time I process the OUT link it writes only zeros,
even if the link is specified with a plain PV name (w/o any modifiers).

I have now picked my test patch and applied it on top of Dirk's branch
dbChannelForDBLinks. Same result. I am now posting some code in the hope
that someone spots where I have made a mistake.

Here is the record type definition:

include "menuGlobal.dbd"
include "menuConvert.dbd"
include "menuScan.dbd"
recordtype(arrout) {
  include "dbCommon.dbd"
  field(VAL, DBF_NOACCESS) {
    prompt("Value")
    special(SPC_DBADDR)
    pp(TRUE)
    extra("void *val")
  }
  field(OUT, DBF_OUTLINK) {
    prompt("Output Link")
  }
  field(NELM, DBF_ULONG) {
    prompt("Number of Elements")
    special(SPC_NOMOD)
    initial("1")
  }
  field(FTVL, DBF_MENU) {
    prompt("Field Type of Value")
    special(SPC_NOMOD)
    menu(menuFtype)
  }
  field(NORD, DBF_ULONG) {
    prompt("Number elements read")
    special(SPC_NOMOD)
  }
  field(OFF, DBF_ULONG) {
    prompt("Offset into array")
  }
  field(DOL, DBF_INLINK) {
    prompt("Desired Output Link")
  }
}

And this is my process routine (I checked that init_record correctly
allocates the VAL array and loads it with the data from my DOL):

static long process(struct dbCommon *pcommon)
{
    struct arroutRecord *prec = (struct arroutRecord *)pcommon;
    long status;

    prec->pact = TRUE;
    /* read DOL */
    if (!dbLinkIsConstant(&prec->dol)) {
        long nReq = prec->nelm;

        status = dbGetLink(&prec->dol, prec->ftvl, &prec->val, 0, &nReq);
        if (status) {
            recGblSetSevr(prec, LINK_ALARM, INVALID_ALARM);
            return (status);
        }
        prec->nord = nReq;
    }
    /* soft "device support": write OUT */
    status = dbPutLink(&prec->out, prec->ftvl, &prec->val, prec->nord);
    if (status) {
        recGblSetSevr(prec, LINK_ALARM, INVALID_ALARM);
        return (status);
    }
    recGblGetTimeStamp(prec);
    recGblFwdLink(prec);
    prec->pact = FALSE;
    return 0;
}

Cheers
Ben

Am 30.03.20 um 09:49 schrieb Ralph Lange via Core-talk:
> On Mon, 30 Mar 2020 at 06:08, Johnson, Andrew N. via Core-talk
> <core-talk at aps.anl.gov <mailto:core-talk at aps.anl.gov>> wrote:
> 
>>     I gets worse though. If we add put/write filters to the picture, then
>>     the feature is no longer "no cost". In fact, supporting it is not
>>     possible without a lot of overhead.
> 
>     I agree that put filters are probably completely different to
>     get/monitor filters, and there will probably be only a few put filters.
> 
> 
> The longer I think about it, the more I think that "put filters" should
> indeed be something completely separate. Maybe the put variant should
> not be called "filter" in the first place, but... "operator"? "manipulator"?
> The data is different. (Mostly no meta data, no timestamp, no "from the
> record" type.) The operation is different (as seen in the array case).
> There are no pre-queue / post-queue considerations. Many very reasonable
> filters have no equivalent put-thing.
> 
> Filters and put-things could share configuration and instantiation
> mechanism, maybe in a separate namespace - to e.g. allow "arr" and the
> "[]" to point to the filter and the put-thing.
> Limitations and restrictions could easily apply to one direction only.
> (Chained array filters are ok, chained array put-things are not.)
> 
> I think such an approach could simplify the implementation.
> 
> Cheers,
> ~Ralph

-- 
...it is impossible to speak of a depoliticized economy as the liberals
do, or of a separation between economic exploitation and political
oppression as the Marxists articulate. The basic distinction, rather, is
between power and creativity...
             -- Jonathan Nitzan and Shimshon Bichler: Capital as Power

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System