Experimental Physics and
Industrial Control System

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

Oh noes, I made the same mistake as the guy recently on tech-talk: I
passed &prec->val where I should pass prec->val. The  C type checker
can't tell the difference because we told it not to bother (by using
void*). You don't want to know how many hours this has cost me.

Why is ist that one sees such errors only after hitting the send button?

Cheers
Ben

Am 02.04.20 um 17:46 schrieb Ben Franksen via Core-talk:
> 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