Experimental Physics and Industrial Control System
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
- Replies:
- Re: Problems with soft motors Michael Davidsaver
- References:
- Problems with soft motors Mark Rivers
- Re: Problems with soft motors Mooney, Tim M.
- Navigate by Date:
- Prev:
Re: Problems with soft motors Mooney, Tim M.
- Next:
Re: Problems with soft motors Kevin Peterson
- 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: Problems with soft motors Mooney, Tim M.
- Next:
Re: Problems with soft motors Michael Davidsaver
- 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