Experimental Physics and
Industrial Control System

Hej Marco,

some (late) and hopefully useful response.

To my knowledge and understanding, writing to a motorRecord field with wait=True

does only make sense for the .VAL (or .DVAL, .RVAL) fields.

Because that what is what the motorRecord code is written to do.

I have been able to dig into the stuff a little bit more.

0) The motor is not moving: .DMOV is 1

1) we write 0 to the .CNEN field through channel access.

     The special() function in motorRecord is called with after=0

     The special() function in motorRecord is called with after=1

      A " WRITE_MSG(DISABL_TORQUE)" is send to the driver

    The record processes, process() is called

      Inside do_work() a GET_INFO is send to the driver

      The first callback is fired via recGblFwdLink()

2) Now things happen in parallel:

    2a) The driver polls the motorController (at least a model 3 driver does),

           which may take some milliseconds, when we have an asyn motor

           connected via ethernet.

          The poll() completes, and the record is processed again.

          The second callback is fired via recGblFwdLink()

     2b) The firmware inside the motion controller handles the

            TORQUE message. This can take µsec, milliseconds.

            Depending on the driver/controller, the TORQUE message

            may enable TORQUE control, closed loop, or enables the amplier.

            This variable/code is used for different things:

            It is heavily driver dependent, for what CNEN is used.

3)  The poller continues to poll in the background.

      If e.g. an encoder readback changes, the record will be processed again,

      and a  third, forth... callback is fired via recGblFwdLink()

      Another reason for a callback is when the driver detects that the amplifier is

      now on in the controller.

      This takes some hundred milliseconds in our system.

      A model 3 driver may write the parameter "motorStatusPowerOn_".

      The motorRecord reflects this bit in the .MSTA  field:

        if (msta.Bits.GAIN_SUPPORT)

        {

            unsigned short pos_maint = (msta.Bits.EA_POSITION) ? 1 : 0;

            if (pos_maint != pmr->cnen)

            {

                pmr->cnen = pos_maint;

                db_post_events(pmr, &pmr->cnen, local_mask);

            }

        }
        //

       So there is a possible readback of CNEN:
       When the value is changed inside the controller, by e.g. using an engineering tool,

       the driver is able to update the .CNEN field!
===================

I did some testing here, but couldn't make sense out of the number of callbacks either
(for the .CNEN field)

Depending on the timing, it seems as if callbacks can be "bundled" in some way.

If this is done on the IOC, or within python/pyepics, I don't know.

Probably a wireshark run would reveal more details.

As a kind of summary, integrating the answer from Mark, it looks as if

the "wait=True" feature make only sense when writing to the ".VAL" field,

and probably (not tested by me) to DVAL and/or RVAL.

That is what the motorRecord is designed for.

BR
/Torsten

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.