Re: Suspicious behavior of Pmac 2-5-16 IOC. .RBV and .VAL showing wrong values.

[Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>]

> 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)

MOTOR_REC_RESOLUTION gets its value from the motor record via a CP link, so it will not be sent to the driver until after the call to iocInit.

Mark

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Torsten Bögershausen via Tech-talk <tech-talk at aps.anl.gov>
Sent: Friday, September 30, 2022 12:56 AM
To: Marco A. Barra Montevechi Filho <marco.filho at lnls.br>; tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Cc: Augusto Yoshio Horita <augusto.horita at lnls.br>
Subject: Re: Suspicious behavior of Pmac 2-5-16 IOC. .RBV and .VAL showing wrong values.

 

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.
>