Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 7 Sep 2018 12:47:03 -0500

Hi Tim,

That code definitely looks kinkey, anything that relies on relative
thread priorities isn't going to work properly on an OS that doesn't
have a strict priority scheduler (Linux, Windows etc.).

Whether that's what's causing Mark's issue I can't say though, I did no
more than look at the routine you pointed to.

- Andrew

On 09/07/2018 12:15 PM, Mooney, Tim M. wrote:
> Hi Mark,
> 
> 
> I'll make a wild guess:  The function, soft_init(), in
> motor/motorApp/SoftMotorSrc/devSoftAux.cc, seems vulnerable to changes
> in EPICS base that might not have had consequences for other code I know
> of.  This code has always seemed a little hinky to me.  Do you see the
> error message "cannot find dbCaLink task." in the IOC console output
> after iocInit?
> 
> 
> Tim Mooney ([email protected]) (630)252-5417
> Beamline Controls Group (www.aps.anl.gov)
> Advanced Photon Source, Argonne National Lab
> 
> ------------------------------------------------------------------------
> *From:* Mark Rivers <[email protected]>
> *Sent:* Thursday, September 6, 2018 6:23:32 PM
> *To:* Peterson, Kevin M.; Mooney, Tim M.; Johnson, Andrew N.
> *Cc:* [email protected]
> *Subject:* Problems with soft motors
>  
> Hi,
> 
> 
> I am having a serious problem with soft motor device support.  These are
> databases that have worked fine for over 10 years.  The databases are
> the ones in motorApp/Db: pseudoMotor.db and sumDiff2D.db.
> 
> 
> The databases are very simple: there are 2 real motors and 2 soft
> motors.  One soft motor moves both real motors in the same direction,
> and the other soft motor moves the real motors in the opposite
> direction.  The readback of the first soft motor is the average of the
> real motors, while the other is the difference of the real motors.  The
> calculations are done in transform records.  There is also a transform
> record that calculates when the soft motors are done moving, which is
> just the logical AND of the real motor .DMOV fields.
> 
> 
> The main problem I am seeing is that the transform records are updating
> OK, but for some motors these values are not getting back into the motor
> record.
> 
> 
> Here is an example of the debugging output of the devSoft.cc when a real
> motor is moved, and the soft motors, pm5 and pm6 are updating during
> that real motor move.
> 
> 
> soft_dinp_func(): HARDMOVE set for 13BMD:pm5.
> soft_rdbl_func(): updated RMP = 901 for 13BMD:pm5.
> update(): dmov=0 for 13BMD:pm5.
> update(): DMOV=0 for 13BMD:pm5.
> soft_rdbl_func(): updated RMP = 23 for 13BMD:pm6.
> update(): dmov=1 for 13BMD:pm6.
> update(): DMOV=1 for 13BMD:pm6.
> soft_rdbl_func(): updated RMP = 930 for 13BMD:pm5.
> update(): dmov=0 for 13BMD:pm5.
> update(): DMOV=0 for 13BMD:pm5.
> soft_rdbl_func(): updated RMP = 80 for 13BMD:pm6.
> update(): dmov=1 for 13BMD:pm6.
> update(): DMOV=1 for 13BMD:pm6.
> soft_dinp_func(): Done moving set for 13BMD:pm5.
> update(): dmov=0 for 13BMD:pm5.
> update(): DMOV=1 for 13BMD:pm5.
> soft_rdbl_func(): updated RMP = 940 for 13BMD:pm5.
> update(): dmov=1 for 13BMD:pm5.
> update(): DMOV=1 for 13BMD:pm5.
> soft_rdbl_func(): updated RMP = 101 for 13BMD:pm6.
> update(): dmov=1 for 13BMD:pm6.
> update(): DMOV=1 for 13BMD:pm6.
> 
> In this case pm5 is working fine.  It detected that dmov initially went
> to 0, and so at the end of the move it set the VAL field to match the
> RBV field.
> 
> However, pm6 is not working correctly.  It is detecting the readback
> changes, but it does not get the correct value of dmov.  It always sees
> it as 1, not as 0 which it should.  This means that at the end of the
> move it does not set the VAL field to match RBV.  pm5 and pm6 are
> configured identically, and they both get their DMOV value from the same
> field of the same transform record.  Why does one work and one not work?
> 
> Here are some symptoms of the problem:
> 
> - Some soft motors work fine, and others do not, even when they are
> apparently configured identically.  For one set of soft motors in one of
> my IOCs there are no updates printed with debugging in devSoft.cc.  For
> these soft motors neither the RBV fields nor the VAL fields update at
> all when the real motors are moved.
> 
> - The behavior of a particular motor is always the same, through
> multiple reboots, i.e. it either works or does not work.
> 
> - This has all worked fine until this shutdown when I made a lot of changes:
>     Base 3.15.5 > 7.0.1.1
>     synApps modules (motor, calc, etc.): master January 2018 to master
> August 2018.
> 
> - The devSoft.cc has not changed since 2015 so that cannot be the problem.
> 
> - I tried reverting the motorRecord.cc to the commit from Jan. 4, 2018
> which is what I was using in the last run when it worked fine.  That did
> NOT fix the problem, which was very surprising.  This suggests that
> perhaps the problem has something to do with links in the transform
> record, or some change in base?
> 
> - I reverted the entire IOC application to the version I was running in
> the last run (3.15.5, master branch of synApps from January 2018) and
> all of the soft motors work fine.  This seems to prove it is some
> software change in base 7.0.1 vs 3.15.5, or a change in synApps since
> January.  But it is NOT the motor record itself.
> 
> Help!
> 
> Thanks,
> Mark
> 
> 
> 
> 
> 
> 
> 

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System