Experimental Physics and
Industrial Control System

Michael Davidsaver via Core-talk <[email protected]> · Wed, 23 Jan 2019 20:06:19 -0800

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
> 
>  
> 
>  
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System