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.