On 09/07/2018 06:47 PM, Andrew Johnson wrote:
> 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.
> long soft_init(void *after)
> {
> int before_after = (after == 0) ? 0 : 1
Device support init() is called with 'int'. So this test behaves
unpredictably when sizeof(void*) != sizeof(int).
soft_motor_task() is accessing records w/o locking. Also, access
of union members 'mr->dinp.value.constantStr' vs. '.pv_link' w/o first
testing 'mr->dinp.type' CONSTANT vs. CA_LINK/DB_LINK seems to me a recipe
for surprise.
> - 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
>>
>>
>>
>>
>>
>>
>>
>
- Replies:
- Re: Problems with soft motors Mark Rivers
- RE: Problems with soft motors Mark Rivers
- RE: Problems with soft motors Mark Rivers
- References:
- Problems with soft motors Mark Rivers
- Re: Problems with soft motors Mooney, Tim M.
- Re: Problems with soft motors Andrew Johnson
- Navigate by Date:
- Prev:
Re: Problems with soft motors Mooney, Tim M.
- Next:
Re: Problems with soft motors Mark Rivers
- 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 Andrew Johnson
- Next:
Re: Problems with soft motors Mark Rivers
- 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
|