On Mar 29, 2021, at 7:41 AM, Pietryla, Tony wrote:
>
> You could change your calc record to this:
>
> record(calc, "$(KEIT):CalcCurrent")
> {
> field(SCAN, "1 second")
> field(INPA, "$(KEIT):Charge PP")
> field(CALC, "LA-A")
> }
Unfortunately the CALC expression doesn’t have access to the fields LA through LL, although they can be read by other records through DB links or via Channel Access.
On 3/29/21, 7:33 AM, Donny Domagoj Cosic wrote:
> However, when I corrected this error as you suggested, the result was
> still always 0. Changing the order of NPP before PP should have solved
> this problem but it didn't.
Marty’s suggestion has been used as the standard “rate of change” database in EPICS training courses for well over 20 years, but it doesn’t work if the record which is the source of the data (your "$(KEIT):Charge” record) is asynchronous, which yours is since it uses Streams. When the PP link processes that record Streams sends the request for data to your Keithley 6514 device, but the device support is not allowed to wait for a response because that would stop the IOC until the reply comes back. What happens instead is that after the I/O operation has been started the PP link just returns whatever value was in the ai.VAL field at the time and the calculation uses that.
> Using Marks suggestion of setting B to A after the calculation
> ("B-A;B:=A") works as expected and yields the correct result. This
> solves my problem, but I still dont understand why Marty's suggestion
> didn't work.
Mark’s approach still doesn’t solve the problem that the PP link to your ai record is always returning the previous reading. That might not matter in your case, but if it could this database solves that problem:
record(ai, "$(KEIT):Charge") {
field(DESC, "Measure Charge")
field(DTYP, “stream") # Typo fixed, this was "steam"
field("@devKeithley6514.proto measureCharge() $(PORT)")
field(SCAN, "1 second")
field(FLNK, "$(KEIT):CalcCurrent")
}
record(calc, "$(KEIT):CalcCurrent") {
field(SCAN, "Passive")
field(INPA, "$(KEIT):Charge NPP")
field(CALC, "B-A;B:=A")
}
- Andrew
> Dana 29.03.2021 13:48, Smith, Martin via Tech-talk je napisao(la):
>> Hi Donny,
>>
>> Because the Charge record is Passive scan and is being processed
>> (presumably) only by
>> the calc record what you are saying makes sense. the calc record
>> processes the charge
>> record first for link A using a PP link causing it to get a new
>> value, then it gets that new
>>
>> value again using link B without processing (NPP) the charge record.
>>
>> I think what you really want is this:
>>
>> record(calc, "$(KEIT):CalcCurrent")
>> {
>> field(SCAN, "1 second")
>> field(INPA, "$(KEIT):Charge NPP") # Get the current value of Charge
>>
>> field(INPB, "$(KEIT):Charge PP") # Process charge record then get the
>> new value
>> field(CALC, "B-A") # You may need to change this to A-B if you want a
>> positive value assuming the charge is always increasing
>> }
>>
>> You need to get the current value first then process the record to
>> get the new value.
>>
>> Marty
>>
>> -------------------------
>>
>> FROM: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Donny
>> Domagoj Cosic via Tech-talk <tech-talk at aps.anl.gov>
>> SENT: Monday, March 29, 2021 6:35 AM
>> TO: Tech-talk <tech-talk at aps.anl.gov>
>> SUBJECT: Rate of change calculation
>>
>> Hello,
>>
>> I am trying to calculate the rate of change of a record using a calc
>> record as follows:
>>
>> record(ai, "$(KEIT):Charge")
>> {
>> field(DESC, "Measure Charge")
>> field(DTYP, "steam")
>> field("@devKeithley6514.proto measureCharge() $(PORT)")
>> field(SCAN, "Passive")
>> }
>>
>> record(calc, "$(KEIT):CalcCurrent")
>> {
>> field(SCAN, "1 second")
>> field(INPA, "$(KEIT):Charge PP")
>> field(INPB, "$(KEIT):Charge NPP")
>> field(CALC, "B-A")
>> }
>>
>> The calc record always returns 0. If I change the calc to B+A, to
>> check
>> what is going on, I always get double the charge. It seems like the
>> PP
>> and NPP are both returning the same value even though the actual
>> charge
>> is changing. Any ideas on why this would be happening or suggestions
>> would be greatly appreciated.
>>
>> Thank you in advance,
>> Donny
>>
>> --
>> Donny Domagoj Cosic
>> Institut Ruđer Bošković, Bijenička cesta 54, 10000 Zagreb,
>> Croatia
>
--
Complexity comes for free, simplicity you have to work for.
- Replies:
- Re: Rate of change calculation Arnold, Ned D. via Tech-talk
- Re: Rate of change calculation Donny Domagoj Cosic via Tech-talk
- References:
- Rate of change calculation Donny Domagoj Cosic via Tech-talk
- Re: Rate of change calculation Smith, Martin via Tech-talk
- Re: Rate of change calculation Donny Domagoj Cosic via Tech-talk
- Re: Rate of change calculation Pietryla, Tony via Tech-talk
- Navigate by Date:
- Prev:
Re: Phoebus lock down BOB Tynan Ford via Tech-talk
- Next:
Re: Rate of change calculation Arnold, Ned D. via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Rate of change calculation Pietryla, Tony via Tech-talk
- Next:
Re: Rate of change calculation Arnold, Ned D. via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
|