Experimental Physics and Industrial Control System
My first thought is that this is another effect of the RPRO propagation change.
Though I don't see anything asynchronous here, nor any CA links.
(I've looked at transformRecord though)
You should be able to get some more information by setting TPRO=1 on all record, and also adding
> var(dbAccessDebugPUTF, 1)
to your ioc shell script.
> ... Note that the _lim record appears to contain a serious logic error. ...
To ask the obvious question. Have you tried correcting this?
On 1/23/19 3:50 PM, Mark Rivers via Core-talk wrote:
> Folks,
>
>
>
> I updated from 7.0.1 (actually some commit between 7.0.1) to 7.0.2. We discovered today that a very old database that has worked fine for 15 years stopped working. It is a database to run Pico Motors, which are piezo actuators controlled via RS-232. I have attached the database, and it is also on Github here: https://github.com/epics-modules/ip/blob/master/ipApp/Db/picoMotor.db .
>
>
>
> The device can only work in relative moves in steps.
>
>
>
> For this discussion the problem can be restricted to these 3 records.
>
>
>
> _pos is an absolute drive field. We write to that from CA clients. It writes to the _rel record with PP.
>
>
>
> _rel is a transform record that computes the relative move amount. It forward links to the _lim field, and sends the computed relative move to the _trunc record, which eventually sends it to the device.
>
>
>
> _lim is a limit checking record. It compares _pos to software limit values and sets high and low limit flags if they are exceeded.
>
>
>
> grecord(ao,"$(P)$(S):$(D):pM$(M)_pos") {
>
> field(DESC,"PicoMotor Position in EGUs")
>
> field(DTYP,"Soft Channel")
>
> field(SDIS,"$(P)$(S):$(D):pM$(M)_movn.VAL NPP NMS")
>
> field(FLNK,"0")
>
> field(OUT,"$(P)$(S):$(D):pM$(M)_rel.A PP MS")
>
> field(PREC,"3")
>
> }
>
>
>
> grecord(transform,"$(P)$(S):$(D):pM$(M)_rel") {
>
> field(DESC,"Convert EGUs to rel steps")
>
> field(FLNK,"$(P)$(S):$(D):pM$(M)_lim.PROC")
>
> field(CLCD,"(A>B)?(A-B):(A<B)?(-1*(B-A)):0")
>
> field(CLCE,"NINT((1/C)*D)")
>
> field(CLCF,"A")
>
> field(CLCH,"G=0?E:G=1?((-1)*E):E")
>
> field(INPA,"0")
>
> field(INPB,"$(P)$(S):$(D):pM$(M)_prev.VAL NPP MS")
>
> field(INPC,"$(P)$(S):$(D):pM$(M)_res.VAL NPP MS")
>
> field(INPG,"$(P)$(S):$(D):pM$(M)_dir.VAL NPP MS")
>
> field(OUTC,"0")
>
> field(OUTD,"0")
>
> field(OUTE,"0")
>
> field(OUTF,"$(P)$(S):$(D):pM$(M)_prev.VAL PP MS")
>
> field(OUTG,"0")
>
> field(OUTH,"$(P)$(S):$(D):pM$(M)_trunc.A PP MS")
>
> field(PREC,"6")
>
> field(CMTC,"user input EGUs/step")
>
> field(CMTD,"rel change in EGUs")
>
> field(CMTE,"rel change in steps")
>
> }
>
>
>
> grecord(transform,"$(P)$(S):$(D):pM$(M)_lim") {
>
> field(CLCD,"A>=C?1:0")
>
> field(CLCE,"A<=B?1:0")
>
> field(INPA,"$(P)$(S):$(D):pM$(M)_pos.VAL PP MS")
>
> field(INPB,"$(P)$(S):$(D):pM$(M)_pos.DRVL PP MS")
>
> field(INPC,"$(P)$(S):$(D):pM$(M)_pos.DRVH PP MS")
>
> field(OUTD,"$(P)$(S):$(D):pM$(M)_hi.VAL PP MS")
>
> field(OUTE,"$(P)$(S):$(D):pM$(M)_lo.VAL PP MS")
>
> }
>
>
>
> Note that the _lim record appears to contain a serious logic error. The INPA, INPB, and INPC links to the _pos record are PP. This is almost certainly not what was intended. They should probably be CP so the record processes whenever those POS fields change.
>
>
>
> However, with this logic error the database has worked fine, including with 7.0.1.
>
>
>
> However, with 7.0.2 it no longer works. What happens now is that the _pos and _rel records process twice in rapid succession. _pos -> _rel -> _lim -> _/pos ->/_rel
>
>
>
> The second processing of _rel computes a relative distance of 0 counts, because _prev now equals _pos. This calculation happens before the previous relative move command is sent to the controller, with the net result being that every move command sent to the controller is now for 0 counts and it never moves.
>
>
>
> I am able to fix the problem by changing the PP links in _lim to CP links, as I think was intended.
>
>
>
> My question is why did it ever work, and what has changed in 7.0.2 that caused it to stop working?
>
>
>
> Thanks,
>
> Mark
>
>
>
>
>
- Replies:
- Re: Strange change in behavior from 7.0.1 to 7.0.2 Mark Rivers via Core-talk
- References:
- Strange change in behavior from 7.0.1 to 7.0.2 Mark Rivers via Core-talk
- Navigate by Date:
- Prev:
Strange change in behavior from 7.0.1 to 7.0.2 Mark Rivers via Core-talk
- Next:
Re: Strange change in behavior from 7.0.1 to 7.0.2 Mark Rivers via Core-talk
- Index:
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:
Strange change in behavior from 7.0.1 to 7.0.2 Mark Rivers via Core-talk
- Next:
Re: Strange change in behavior from 7.0.1 to 7.0.2 Mark Rivers via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
<2019>
2020
2021
2022
2023
2024