Experimental Physics and
Industrial Control System

"Davis, Mark via Tech-talk" <[email protected]> · Tue, 22 Oct 2019 01:10:56 +0000

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 [email protected]
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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System