Re: record logic tips

["Mooney, Tim M. via Tech-talk" <tech-talk@aps.anl.gov>]

Hi Mark,

If the number of target values is less than seven, I would use a transform record to calculate which target value the device is near, and an scalcout to select the target name.

record(transform, "calcTargetNum") {

    field(CMTA, "$curr : current value")

    field(CMTB, "$target1")

    field(CLCC, "(abs($curr-$target1) < $deadband) ? 1 : 0")

    field(CMTD, "$target2")

    field(CLCE, "(abs($curr-$target2) < $deadband) ? 2 : 0")

    field(CMTF, "$target3")

    field(CLCG, "(abs($curr-$target3) < $deadband) ? 3 : 0")

    field(CMTH, "$target4")

    field(CLCI, "(abs($curr-$target4) < $deadband) ? 4 : 0")

    field(CMTJ, "$target5")

    field(CLCK, "(abs($curr-$target5) < $deadband) ? 5 : 0")

    field(CMTL, "$target6")

    field(CLCM, "(abs($curr-$target6) < $deadband) ? 6 : 0")

    field(CMTO, "$deadband")

    field(CMTP, "target number if within deadband, else 0")

    field(CLCP, "c+e+g+i+k+m")

    field(OUTP, "scalcout.A PP")

}

record(scalcout, "targetName") {

    field(AA, "unidentified target")

    field(BB, "Target 1")

    field(CC, "Target 2")

    field(DD, "Target 3")

    field(EE, "Target 4")

    field(FF, "Target 5")

    field(GG, "Target 6")

    field(CALC, "@@a")

}

If the number of target values is greater than seven, I might use a second transform record.  If the number of target values is larger than 14, I'd use State Notation Language.

Tim Mooney (mooney@anl.gov) (630)252-5417
Beamline Controls Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab

---

From: Tech-talk <tech-talk-bounces@aps.anl.gov> on behalf of Davis, Mark via Tech-talk <tech-talk@aps.anl.gov>
Sent: Monday, October 21, 2019 8:10 PM
To: Peterson, Kevin M. <kmpeters@anl.gov>; tech-talk@aps.anl.gov <tech-talk@aps.anl.gov>
Subject: Re: record logic tips

 

The following is a rough draft of the sort of thing I was thinking of. 
Again, if anyone has suggestions (or warnings) about such an approach,
please send them to me.


A template for each number/string pair that is along these lines:

      A bo record that you write to trigger (via an FLNK) the processing
of an ao record in which the number value is stored.

      When processed, the ao record writes its value to the device record

      An scalcout record that monitors the readback from the device
record (using a CP link) and compares it to the numeric value.  If the
difference is within a specified deadband, then it writes the
corresponding string value to a specified record (the one which contains
the description of the current location or a default string like
"invalid location").

A sort of brute-force approach (not especially efficient or elegant),
but I think this is sufficient to handle the task of making sure that
the current device position string is correct when it IS near one of the
specified positions.  And it should work for any number of positions.

Insuring the current position description is set to the default value
when the device position is NOT close to one of the specified positions
is a bit trickier.  Avoiding possible false negatives would seem to
require that the number/string pairs all be in a list so you can insure
each new readback position has been compared to all the specified
positions before changing the current position description to the
default value.

Mark


Mark Davis NSCL/FRIB Control Systems Software Engineer davism50@msu.edu
On 10/21/2019 3:23 PM, Peterson, Kevin M. wrote:
> Mark,
>
> configMenu in autosave provides some of the functionality you need:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__epics.anl.gov_bcda_synApps_autosave_autoSaveRestore-5FR5-2D6-2D1.html-23configMenu&d=DwIGaQ&c=nE__W8dFE-shTxStwXtp0A&r=D7ZiziuMQuq40HlGYOZPBg&m=kJ2NiaVrHahMbA9PoEvNK35cJNj1ozy-xXUGg0nVDFw&s=OqMKihffD17fPhzkOWVBThP6Kptxio68P0fKuxiId-4&e=
>
> It doesn't, however provide this functionality:
>
>> Logic that monitors the current readback of the device record.
>> Whenever the position is close to (within some specified deadband)
>> of the numeric value in one of the numeric/string pairs, it copies
>> the associated string to the one that describes the current readback.
>> When the readback is NOT close to one of the numeric values, it will
>> write something like "Invalid position" to the description string.
> If configMenu is used to put the device into a specific state, the
> currName value is correct.  If the device is changed manually, the
> currName value is incorrect.
>
> Note: while it is easy to add a named config via a channel-access
> client, the only way to delete a config is to delete the .cfg file.
>
> Kevin
>
> On 10/21/19 1:04 PM, Davis, Mark via Tech-talk wrote:
>> Hi all,
>>
>> I have a new task that I figured those of you with much more
>> experience crafting clever record logic could help with:
>>
>>
>> The components that need to be supported:
>>
>> A record for some device to which setpoints stored in other records
>> are to be written (e.g. a motor record).
>>
>> A string value that provides a description of the current readback of
>> the device record.
>>
>> Pairs of numeric and string values.   For each pair, the number
>> represents one of the setpoints an operator can chose to have written
>> to the device record and the string represents a user-readable
>> description of what the associated number represents (e.g. the
>> thickness or type of material to place in the path of the beam, the
>> size of a whole in a metal plate, etc).
>>
>> The operators can change the string (and possibly the numeric) values
>> whenever they want.  Changes must be persistent (i.e. changes are
>> saved to a file and restored when the IOC restarts, probably using
>> autosave).
>>
>> Logic that monitors the current readback of the device record.
>> Whenever the position is close to (within some specified deadband)
>> of the numeric value in one of the numeric/string pairs, it copies
>> the associated string to the one that describes the current readback.
>> When the readback is NOT close to one of the numeric values, it will
>> write something like "Invalid position" to the description string.
>>
>> And of course it has to be relatively simple for the person
>> configuring the IOC to change the # of numeric/string pairs
>> supported for a device.
>>
>>
>> No doubt I can cobble something together that will do the job, but I
>> figured someone out there will have already dealt with a similar
>> need and can provide something much simpler, more flexible, and less
>> cumbersome than what I am likely to create on my first attempt.
>>
>> Any tips or suggestions would be much appreciated.
>>
>> Thanks, Mark Davis NSCL/FRIB