Re: Weird behaviour in wait=True when using epics.Motor.get(something, something, wait=True)

[Torsten Bögershausen via Tech-talk <tech-talk at aps.anl.gov>]

Hej again,

are we still wondering about callbacks and wait=True ?

 

Writing to VELO give one callback and one camonitor event here.

Writing to DLLM give 2 callbacks and 2 monitors. This feels like a bug to me,

but I don't think it worth to fix it.

The Record is processed twice, first because the update of the DLLM field.

And another time when the motor had been polled caused by a "GET_INFO"

transaction.

 

Back to the wait=True question, if anybody is interested.

Writing to CNEN with wait=True seems to wait for the Record to have processed

the command, it seems to me.

However, when the record has processed the command, and send it to the controller,

it doesn't mean that the controller has digested it fully.

What are you using CNEN for ?

Often it is used it for "enabling the amplifier".

Other definitions that I have seen are "closed loop" or "torque control".

 

We use it for "enabling the amplifier". Once the controller has received

the "enable", it make take 1 second until the amplifier is ready, and the motor

can be moved.

 

HTH
/Torsten

 

 

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Matt Newville via Tech-talk <tech-talk at aps.anl.gov>
Reply-To: Matt Newville <newville at cars.uchicago.edu>
Date: Thursday, 19 January 2023 at 20:25
To: "Marco A. Barra Montevechi Filho" <marco.filho at lnls.br>
Cc: SWC <swc at lnls.br>, "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Subject: Re: Weird behaviour in wait=True when using epics.Motor.get(something, something, wait=True)

 

Hi Marco, 

 

 

On Thu, Jan 19, 2023 at 9:43 AM Marco A. Barra Montevechi Filho <marco.filho at lnls.br> wrote:

Updates on testing:

So, i did the suggested test alternating CNEN (between 0 and 1), VELO (1 and 2), DHLM (4 and 5) and DLLM (-4 and -5) fields. Not because they have any particular physical meaning, but to understand if the behavior is similar in several motor record fields. I tested at least twice for each field.

I append the code for testing below and attach the logs as files. What i found interesting:

1 - In some tests, the first print from callback function is the first value in which the field was before changing (i.e., before the first caput in the code is called). In some other tests, the first print is the value only after being changed via caput. This suggests to me that the "add_callback" method by itself sometimes triggers a callback and sometimes doesnt. I remember having observed this behavior before with other PVs.

2 - In several parts of the log, callback prints the same value twice. This is more or less predictable: DLLM field for example seems to almost always trigger two callbacks at once, but there are cases like the end of Loop 6 in CNEN_LOG1 where it seems out of the pattern: CNEN almost always triggers only one callback, but in this loop i got two at once.

What i understand:

1 - some fields typically (but not always) trigger callbacks twice and some dont. 
2 - the add_callback method may or may not immediately call the callback function, even if no value has been altered in the PV.

What i dont understand:

1 - What are the causes of intermittence in behavior 1, such as observed in end of loop 6? 

2 - What are the causes of intermitence in behavior 2?

 

 

I suspect that the "sometimes get an initial callback" is because creating an `epics.Motor()` will make an initial connection for PVs to some fields, including

  'VAL', 'DESC', 'RTYP', 'RBV', 'PREC', 'TWV', 'FOFF', 'VELO', 'STAT', 'SET', 'LLM', 'HLM', 'SPMG', 'LVIO', 'HLS', 'LLS'

but will not create PVs on all of the other ~80 fields of the Motor record until you ask for them.  If you add a callback (to be clear, on "monitor events") when creating a PV, that will be called when it gets the initial value.  So for an `epics.Motor()`, PVs other than those above should get an event with the initial value on PV creation.

 

I also see that writing to the DHLM and DLLM of the Motor Record causes two nearly simultaneous events with the same new value.  I don't see that for all other fields, but the motor record is complicated, and setting some values will cause a cascade of events.  I suspect that setting DHLM will also set HLM (or maybe LLM if the direction is negative), which might then also update the DHLM value. 

 

Generic question: can these things be controlled or is it just something i have to live with?

 

General answer: Some things are easier to control than other things. 

 

If you first fetch the value of "CNEN" or "DHLM", and then add the callback, you should only see changes from that initial value (all assuming that connections happen in time).   

 

I don't know how to get only 1 callback if DHLM is changed.

 

--Matt