Experimental Physics and
Industrial Control System

Henrique Almeida <[email protected]> · Fri, 27 May 2016 10:29:31 -0300

 Mark, I think this behavior is incorrect, because it does not respect
the value of MDEL and MPST.

2016-05-27 10:10 GMT-03:00 Mark Rivers <[email protected]>:
> It is all really the same thing, which is the behavior of asynPortDriver. It only does callbacks to device support when a value changes.  This is the desired behavior most of the time. You can currently easily work around that by setting 2 different values before calling callParamCallbacks. I will add a forceCallbacks() method for the next release of asyn.
>
> You need to keep in mind that even if the driver does the callback to device support, the record may not post a new monitor on the value, depending on the record type and the value of the MDEL field.
>
> Mark
> Sent from my iPhone
>
>> On May 27, 2016, at 2:42 AM, Torsten Bögershausen <[email protected]> wrote:
>>
>> To my understanding,
>> we are talking about 3 different things:
>>
>> a) an asyn record
>> b) a motor Record
>> c) Area Detector
>>
>> I can only talk about b), and there is no update,
>> you still need a workaround in the driver, at least for now.
>>
>> How the area detector is related to the motor update, I don't know.
>> HTH
>>
>>
>>
>>> On 27/05/16 04:49, Henrique Almeida wrote:
>>> I don't think so, I had this problem on Wednesday while writing an areaDetector
>>> IOC that updates a waveform record whenever a new image is saved. If the same
>>> file name is used twice in a row, the second callback does not emit a monitor
>>> event. I'm using EPICS base 3.16 and asyn and areaDetector github master branch.
>>>
>>> Em 26/05/2016 10:08, "Mark Davis" <[email protected] <mailto:[email protected]>>
>>> escreveu:
>>>
>>>    On 5/26/2016 1:52 AM, Torsten Bögershausen wrote:
>>>    I remember that Mark Rivers had said something about changing it so that a
>>>    callback would happen for parameters for which the appropriate
>>>    setXxxParam() function was called, even if the value had not changed.  And
>>>    I THINK that it made it in to one of the more recent versions, but if so, I
>>>    don't remember which one.
>>>
>>>    Mark Davis, FRIB/NSCL
>>>
>>>>    To my knowledge,
>>>>    there is no update.
>>>>    In our driver, we do it like this:
>>>>
>>>>        /* If not moving, trigger a record processing at low rate */
>>>>        if (!nowMoving) setDoubleParam(pC_->motorPosition_,
>>>>    newPositionInSteps + 1);
>>>>        setDoubleParam(pC_->motorPosition_, newPositionInSteps);
>>>>
>>>>    And I added a test case:
>>>>    https://github.com/EuropeanSpallationSource/MCAG_Base_Project/blob/master/epics/test/500_DLY-STOP.py
>>>>
>>>>
>>>>    Out of curiosity:
>>>>    Which kind of device are you using ?
>>>>
>>>>
>>>>>    On 25/05/16 23:50, Ford, Christopher wrote:
>>>>>    Hi,
>>>>>
>>>>>    In 2015 there was some discussion on Tech-Talk about how to force a
>>>>>    callback for a parameter that had not changed values.
>>>>>    Mark Rivers suggested a work-around, as shown below.
>>>>>    I wonder if anyone has an update on the situation since then?  Has any
>>>>>    other method appeared?  Or did you have success with the work-around?
>>>>>
>>>>>    Thanks,
>>>>>     -Chris Ford, SLAC
>>>>>
>>>>>    On16 Nov 2015 Mark Rivers writes:
>>>>>>    If a driver wants to force a callback there is a method that does not
>>>>>>    require any changes to the base classes, e.g. exposing statusChanged_
>>>>>>    as protected or adding a new
>>>>>>    isMotorRecordnowFilterButAlwaysProcess_ flag.  The driver simply needs
>>>>>>    to set a parameter to a different value from present and then back to
>>>>>>    its current value, for example
>>>>>>     setDoubleParam(pC_->motorPosition_(position+1.);
>>>>>>     setDoubleParam(pC_->motorPosition_(position);
>>>>>>     callParamCallbacks();
>>>
>>>
>>>    --
>>>
>>>    Mark Davis
>>>    NSCL/FRIB Control Systems Software Engineer
>>>    [email protected] <mailto:[email protected]>
>> a

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System