Also from Mark. A related, and more serious, regression related to the PUTF/RPRO change. 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 > 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 > > > > >