Hej Marco,
There is a possible race condition, when the IOC starts:
The record tries to read the position of the motor
from the driver, but the driver has not yet been able
to fully talk to the controller.
If I run
asynReport 10 MCU1
just before iocInit in st.cmd, I see things like this:
Parameter 8 type=asynFloat64, name=MOTOR_POSITION, value is undefined
Parameter 9 type=asynFloat64, name=MOTOR_ENCODER_POSITION, value is
undefined
(and may be have a look at
MOTOR_REC_RESOLUTION as well)
(You asynReport needs probably another name)
Before we dig into a possible solution:
Do you have time to try this ?
BR
/Torsten
On 2022-09-29 19:43, Marco A. Barra Montevechi Filho via Tech-talk wrote:
Hello all. We were having problems with Pmac 2-5-16 here at LNLS. The
problem was solved by Augusto Horita (in copy), but the behavior was
weird and we though maybe someone here knows why it is like that or
maybe reporting it in tech-talk would be useful for other people.
The IOC was compiled with EPICS base 3.15.6.
The particular instance that we were having trouble with had a set of
axis in the PVs such as:
BL:H:PB02:CS1:m1
the axis was configured with
pmacSetCoordStepsPerUnit("$(PPMAC_CS1_PORT)", 1, 1000)
and its MRES was set to 10E-3.
When initialized, the IOC sometimes showed the right values for .RBV and
.VAL fields, but sometimes showed values 10 times bigger than what
should be. Sometimes the *10 factor was only in .RBV, sometimes only in
.VAL and sometimes in both.
Augusto suspected this was due to failure in pmacSetCoordStepsPerUnit
since the default scale factor is 10000 (ten times bigger than what we
were using). So we suspected that the function was failing for whatever
reason and defaulting the scale factor to 10000 while MRES remained in
10E-3. Indeed, changing MRES to 10E-4 and
pmacSetCoordStepsPerUnit("$(PPMAC_CS1_PORT)", 1, 1000)
to
pmacSetCoordStepsPerUnit("$(PPMAC_CS1_PORT)", 1, 10000)
Solved the problem.
In the middle of the debug process, we struggled to find any error
message about the suspected failure in pmacSetCoordStepsPerUnit.
Is this absence of error message intentional? Is there a particular
debug method we should have used?
Has this been reported before?
Thanks for the attention. Best regards,
Marco
Aviso Legal: Esta mensagem e seus anexos podem conter informações
confidenciais e/ou de uso restrito. Observe atentamente seu conteúdo e
considere eventual consulta ao remetente antes de copiá-la, divulgá-la
ou distribuí-la. Se você recebeu esta mensagem por engano, por favor
avise o remetente e apague-a imediatamente.
Disclaimer: This email and its attachments may contain confidential
and/or privileged information. Observe its content carefully and
consider possible querying to the sender before copying, disclosing or
distributing it. If you have received this email by mistake, please
notify the sender and delete it immediately.
- Replies:
- Re: Suspicious behavior of Pmac 2-5-16 IOC. .RBV and .VAL showing wrong values. Mark Rivers via Tech-talk
- Re: Suspicious behavior of Pmac 2-5-16 IOC. .RBV and .VAL showing wrong values. Marco A. Barra Montevechi Filho via Tech-talk
- References:
- Suspicious behavior of Pmac 2-5-16 IOC. .RBV and .VAL showing wrong values. Marco A. Barra Montevechi Filho via Tech-talk
- Navigate by Date:
- Prev:
Re: CA library usage problem Andrew Johnson via Tech-talk
- Next:
Re: Suspicious behavior of Pmac 2-5-16 IOC. .RBV and .VAL showing wrong values. Mark Rivers via Tech-talk
- 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:
Suspicious behavior of Pmac 2-5-16 IOC. .RBV and .VAL showing wrong values. Marco A. Barra Montevechi Filho via Tech-talk
- Next:
Re: Suspicious behavior of Pmac 2-5-16 IOC. .RBV and .VAL showing wrong values. Mark Rivers via Tech-talk
- 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
|