RE: Questions about creating a Model 3 Driver for stepper motor axis

[Paul-Elie GUILLOT via Tech-talk <tech-talk at aps.anl.gov>]

Hi Mark,

Thank you very much for all your answers, it helped me a ton!

 

I have some comments and questions:

 

Based on my cinematic configuration (stepper motor with absolute encoders), I implemented the Retry strategy with RMOD ‘Unity’, RTRY 5 and RDBD at the same values as ERES.

I will use FRAC, I have initialize at 0.98.

• As I want to use the backlash mechanism of motor_record, I saw the field ‘NTM’. Will it interfere with the backlash compensation? Is it a requirement to set it to “NO” to use the backlash?

 

Encoder ratio seems to have been introduced as you explained as the ratio . I was misled by the phytron driver that uses it as a ratio to apply on encoder counts polled from the axis.

I have then not implemented the set_encoder_ratio.

I did not implement the DLY field but in my PLC controller I only return the Motion Done (DONE) in MSTA after a settling time to filter the encoder counts.

• Does it seem like a good way to operate?

 

I have added 2 records in my database to handle the axis error and axis error reset mechanism.

To do so, I have redefined the function ‘SetIntegerParam’ from asynMotorAxis (I still call the base class function at the start).

After the base call, I have define my own record management (ie. Resetting the axis)

• Does it seem like the right way to do it?

 

Again as I am using absolute encoders, I did not implement the ‘home’ function form asynMotorAxis.

But I was concern with the user trying to issue directly step command after a hardware reset, as the stepper motor loses its position.

However, I noticed the field RSTM define as ‘Restore Mode’, but I did not find extensive information about this field.

But looking in devMotorAsyn.c, it seems to be used in init_controller which is used in init_record, I understood that init_record is used by the motor record in the same fashion as the build_trans function, is that correct?

In init_controller based on RSTM filed, it sends a set_position command to the motor based on the Dval/mres.

Which seems to be the exact behavior, I was looking for. I have then defined the set_position function in my driver and initialize the filed RSTM as “Always”.

• Does it seem correct to you?

 

On my controller creation, do I need to be careful on the initialization? Like by implementing a force first call to poll or something like that to feed initial values to the record?

How does the initialization of a record start? I saw in the phytron driver, it implements a function ‘epicsInitHookFunction’ where it locks the controller until at least one poll is done.

In practice, is there any need to have such function? I did not see anything like that on other drivers.

 

Thank you so much for your help and time

Best Regards

Paul-Elie GUILLOT

Technology Manager in Automation and Robotics

Téléphone: +33 (0)4 76 44 98 93

 

 

20 rue du Tour de l'Eau

F-38400 St Martin d’Hères Cedex

Phone : +33 (0)4 76 44 12 96

irelec-alcen.com

 

IRELEC after sales services – please send your request to support at irelec-alcen.zendesk.com

 

Any disclosure, use, dissemination or reproduction (either whole or partial) of this message or the information contained herein is strictly prohibited without prior consent of Irelec.

 

 

 

 

De : Mark Rivers <rivers at cars.uchicago.edu>
Envoyé : jeudi 18 janvier 2024 01:48
À : Paul-Elie GUILLOT <peguillot at irelec-alcen.com>; tech-talk at aps.anl.gov
Objet : RE: Questions about creating a Model 3 Driver for stepper motor axis

 

Hi Paul-Elie,

 

• I see that when creating an axis controller using the class asynMotorController, it creates a lot of parameters then linked to a motor record by their names (the string passed to the createParam() function), is that correct?

 

Yes, that is correct.

 

• How does each axis has its own set of parameters while connected to the same asynMotorController, is it because the asynMotorAxis class creates an AsynUser which connects to the controller?
  By doing this, it creates a separate set of parameters for the axis with the pasynUser_?

 

No, that not quite correct.  Asyn address devices using a string “port name”, and an integer “address”.  There is a single parameter table for the controller.  That is  2-D table [numParameters, numAxes].   So there is an entry for the velocity of each axis, etc.

 

• I heavily rely on the record programming to carry out advanced functions, such as backlash compensation and closed loop motion on the encoder.
  Do you have experience in those matters? How will the system reach a specific encoder position? Will it use a linear term between encoder ticks and motor steps?
  But if the axis is not linear enough, there will be issues in reaching the position?
  If I understand correctly, usually motors use the FRAC and RTRY mechanism to reach a encoder position with a certain number of retry?
  In practice, how do most people operate with an encoder? Do they use  the motor in open loop and monitor the encoder, or do they set UEIP at 1 and use FRAC motion?

 

Retries are most commonly used with stepper motors with encoders, or some other readback mechanism.  For servos we generally rely on the controller to close the loop.  The motor record is then not involved in doing any feedback operations.

 

• My motors are able to do microstepping (decomposing a full step in 64 microsteps), should I implement this in the MRES field of the record, as not being 200 full steps but 12800 microsteps?
  I think so because I intend to give the motor positions in microsteps. Is there a low limit on the MRES value?

 

Yes, that is correct.

 

• On the system, we will be using absolute encoders, in that regard the encoder ratio is always 1 to transfer to encoder counts, correct?
  From my understanding, encoder ratio is mainly to interface with incremental encoders converting to raw A/B ticks in full encoder tick.
• Because from what I gathered the motorEncoderPosition_ must be linked to the Field REP and is the hardware counter of the encoder.

 

I think encoder ratio is for stepper motors, and is the ratio between motor steps and encoder counts.

 

• Is there a filter of some sorts on the encoder counts field or should I implement one directly on my Beckhoff controller and then use the delayAfterMove parameter to allow the encoder counts to stabilize?

 

Delay after move was mainly designed for servo controllers which may decide to report that a move is complete before the final settling is complete.

 

• As I have absolute encoder on all axis, for an axis the parameter motorhasEncoder_ is always at 1 as well as the motorStatusHomed_ . However, to use and encoder, the record needs to have the record field UEIP at 1.

Is it defined by the user, or should initialize UEIP at 1, in my template defined in “motor.substitutions.irelec” adding the field UEIP to my .db file (which is derived from basic_asyn_motor.db with some field added)?

 

You can define it in your database or in autosave.

 

• From what I understand, the motor record is defined by the motorRecord.cc and motorRecord.dbd and Model 3 drivers mainly interface with the devMotorAsyn.c, is it correct?

 

Yes, that is correct.

A change on a field of the record will be processed by motorRecord.cc and use the different functions I have redefined for my Driver (move, poll, etc…), is it correct?

 

Yes, that is correct.

Does the devMotorAsyn.c defines the support entry table required to process the record commands? (with the function start_trans, build_trans and end_trans)

 

Yes, that is correct.

Looking through the code, I understood that for Model 2 Driver and Support, one needs to defined the support entry table to process the record commands? (ex: MCB4B_build_trans function)

 

Correct.

 

In Model 3, it seems the asynMotorController directly handles the modification of its parameters by calling the needed function of an axis. How does the record interface with the asynMotorController parameters?

I can’t find where devMotorAsyn.c writes to the asynMotorController parameters.

 

It is done on the build_trans function. https://github.com/epics-modules/motor/blob/f8a3239f0678f8f3d75fd5cf2f9c717dc3db9426/motorApp/MotorSrc/devMotorAsyn.c#L480

 

It constructs a message and queues a request to write to the driver in this line:

https://github.com/epics-modules/motor/blob/f8a3239f0678f8f3d75fd5cf2f9c717dc3db9426/motorApp/MotorSrc/devMotorAsyn.c#L634

 

When the driver is ready the callback function is called

https://github.com/epics-modules/motor/blob/f8a3239f0678f8f3d75fd5cf2f9c717dc3db9426/motorApp/MotorSrc/devMotorAsyn.c#L654

 

It then writes integer and floating point parameters in the lines starting here:

https://github.com/epics-modules/motor/blob/f8a3239f0678f8f3d75fd5cf2f9c717dc3db9426/motorApp/MotorSrc/devMotorAsyn.c#L695

 

Those values write to asynMotorController, which then calls the axis functions.

 

Bottom line of this topic is: Can I use the record advanced functions such as backlash compensation even with a Model 3 Driver?  

 

Yes.

 

• The record always feed steps command to the controller if I understood the code correctly.

 

Yes.

However as I don’t have a home routine (due to absolute encoders), the open loop (step count) is reset at each hardware controller power reset.
Thus, the user should never do move_absolute in openloop. To disable it, I would like the UEIP to be always at 1? Or something should be done to set the open loop position using setposition based on the absolute encoder at the start of the controller?

It could be the home procedure, just sending a setposition() to the stepper based on the encoder position? Or does the home position require motion?

 

Your home function does not need to do anything, it can just report the absolute encoder position.

 

• I noticed there is no process of error catching on the motor and error resetting, is that correct?
  Should I always reset an axis in Error on my Beckhoff hardware controller or should I include command on my EPICS driver to do so, thus adding record for those specific actions?
  Because for example, if my motor reaches a hardware limit switch while in motion it will put itself in error state, which then needs an error reset using the MC_Reset.

 

You can handle that in your driver.

 

Mark

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Paul-Elie GUILLOT via Tech-talk
Sent: Wednesday, January 17, 2024 4:11 AM
To: tech-talk at aps.anl.gov
Subject: Questions about creating a Model 3 Driver for stepper motor axis

 

Hello to everyone at tech-talk,

I am currently working on implementing an EPICS driver for controlling axis which are stepper motors with absolute encoders.
My hardware controller is a Beckhoff PLC I am programming to interface with. I am planning to use mm as EGU.

I have read multiple documentation and I have started to implement a driver based on the Model 3 drivers, I have heavily inspired myself from the MCB4B Driver for ACS and the Phytron driver.

I am starting to get a better understanding on how it works but I still need clarifications on some points. Would you be so kind to help me on those matters?

 

First of all,

• I see that when creating an axis controller using the class asynMotorController, it creates a lot of parameters then linked to a motor record by their names (the string passed to the createParam() function), is that correct?
• How does each axis has its own set of parameters while connected to the same asynMotorController, is it because the asynMotorAxis class creates an AsynUser which connects to the controller?
  By doing this, it creates a separate set of parameters for the axis with the pasynUser_?

 

• I heavily rely on the record programming to carry out advanced functions, such as backlash compensation and closed loop motion on the encoder.
  Do you have experience in those matters? How will the system reach a specific encoder position? Will it use a linear term between encoder ticks and motor steps?
  But if the axis is not linear enough, there will be issues in reaching the position?
  If I understand correctly, usually motors use the FRAC and RTRY mechanism to reach a encoder position with a certain number of retry?
  In practice, how do most people operate with an encoder? Do they use  the motor in open loop and monitor the encoder, or do they set UEIP at 1 and use FRAC motion?

 

• My motors are able to do microstepping (decomposing a full step in 64 microsteps), should I implement this in the MRES field of the record, as not being 200 full steps but 12800 microsteps?
  I think so because I intend to give the motor positions in microsteps. Is there a low limit on the MRES value?

 

• On the system, we will be using absolute encoders, in that regard the encoder ratio is always 1 to transfer to encoder counts, correct?
  From my understanding, encoder ratio is mainly to interface with incremental encoders converting to raw A/B ticks in full encoder tick.

Because from what I gathered the motorEncoderPosition_ must be linked to the Field REP and is the hardware counter of the encoder.

• Is there a filter of some sorts on the encoder counts field or should I implement one directly on my Beckhoff controller and then use the delayAfterMove parameter to allow the encoder counts to stabilize?
• As I have absolute encoder on all axis, for an axis the parameter motorhasEncoder_ is always at 1 as well as the motorStatusHomed_ . However, to use and encoder, the record needs to have the record field UEIP at 1.

Is it defined by the user, or should initialize UEIP at 1, in my template defined in “motor.substitutions.irelec” adding the field UEIP to my .db file (which is derived from basic_asyn_motor.db with some field added)?

 

• From what I understand, the motor record is defined by the motorRecord.cc and motorRecord.dbd and Model 3 drivers mainly interface with the devMotorAsyn.c, is it correct?
  A change on a field of the record will be processed by motorRecord.cc and use the different functions I have redefined for my Driver (move, poll, etc…), is it correct?
  Does the devMotorAsyn.c defines the support entry table required to process the record commands? (with the function start_trans, build_trans and end_trans)
  Looking through the code, I understood that for Model 2 Driver and Support, one needs to defined the support entry table to process the record commands? (ex: MCB4B_build_trans function)

In Model 3, it seems the asynMotorController directly handles the modification of its parameters by calling the needed function of an axis. How does the record interface with the asynMotorController parameters?

I can’t find where devMotorAsyn.c writes to the asynMotorController parameters.

Bottom line of this topic is: Can I use the record advanced functions such as backlash compensation even with a Model 3 Driver?  

 

• The record always feed steps command to the controller if I understood the code correctly.
  However as I don’t have a home routine (due to absolute encoders), the open loop (step count) is reset at each hardware controller power reset.
  Thus, the user should never do move_absolute in openloop. To disable it, I would like the UEIP to be always at 1? Or something should be done to set the open loop position using setposition based on the absolute encoder at the start of the controller?

It could be the home procedure, just sending a setposition() to the stepper based on the encoder position? Or does the home position require motion?

 

• I noticed there is no process of error catching on the motor and error resetting, is that correct?
  Should I always reset an axis in Error on my Beckhoff hardware controller or should I include command on my EPICS driver to do so, thus adding record for those specific actions?
  Because for example, if my motor reaches a hardware limit switch while in motion it will put itself in error state, which then needs an error reset using the MC_Reset.

 

I need it’s a lot of questions, I hope it is clear enough.

In any case, thank you for your time and help.

 

Paul-Elie GUILLOT

Technology Manager in Automation and Robotics

Téléphone: +33 (0)4 76 44 98 93

 

 

20 rue du Tour de l'Eau

F-38400 St Martin d’Hères Cedex

Phone : +33 (0)4 76 44 12 96

irelec-alcen.com

 

IRELEC after sales services – please send your request to support at irelec-alcen.zendesk.com

 

Any disclosure, use, dissemination or reproduction (either whole or partial) of this message or the information contained herein is strictly prohibited without prior consent of Irelec.