Setting motor record HVEL has no effect

[hinxx]

[Not sure if this is the right place to report this, but for some reason https://github.com/EuropeanSpallationSource/motor repo has issue reporting disabled.]

When I try to use HVEL field of the motor record from https://github.com/EuropeanSpallationSource/motor it does not seem to have an effect on the speed of movement when homing (write 1 to HOMR) is initiated. The motion towards the home position is always slow.

[jeonghanlee]

@hinxx do you use the ecmc module for your motion controller? Or do you use only the ESS specific motor module? According to your comments, it looks for me you don't use the ecmc. If so, this is not the right place, please contact the main developer of ESS specific motor record repository.

I will close this issue within a week if so.

[hinxx]

Yes, I do have a motion controller with ecmc. That is how I found this place. As far as I know, that ESS specific motor module is only used with ecmc.

I was hoping someone here could help out.

[tboegi]

@jeonghanlee : Please do not close this issue yet. We need to dig into this.
According to my memory, the homing velocity is defined in the st.cmd of the IOC,
as part of the commissioning.
And the HVEL from the record is ignored.
I may be wrong, so that is why we need to dig into this.

And as a side-note: We use the ess-master version of the "epics motor module"
(which includes the motorRecord himself and much more files)
for both ecmc and TwinCAT. (And even if talking to TwinCAT system we ignore HVEL)

[anderssandstrom]

@hinxx, Yes it's like @tboegi states that HVEL is ignored and it is defined in st.cmd also for ecmc systems. Is this an important feature for you to be able to change homing velo during runtime?

[hinxx]

Is this an important feature for you to be able to change homing velo during runtime?

@anderssandstrom , thank you for asking; I would like to control HVEL at runtime, yes.

What follows is couple of questions I asked myself while working with the ecmc IOC (maybe I should put them in another ticket, but here they anyway).
To me it feels like motor record is a common view (abstraction if you will) of the underlying hardware + software (SDK, ecmc here?). Hence, if some EPICS motor module wants to claim "motor record" support/compatibility it should adhere to certain functionality and behavior (as documented in the official motor record docs).

I was looking at the official motor (record) docs while trying to operate the ecmc / ESS motor record fields. Sometimes the observed behavior was not as documented there; once I better understand what is happening I'll report my findings here. For now I just want to summarize my thoughts in the following questions:

• What are the actual differences between the ESS motor module and community motor module(s) when it comes to motor record field support? Is there a list of what is implemented and what not?
• Which motor record documentation can I look at when working with ESS motor module and its motor record? In case the implemented feature differs behavior from the upstream.
• I'm not sure on what is expected from a motor module when it comes to providing features/support for the motor record itself; Should I expect that all fields are supported, or just some mandatory ones, or just some that the devs decided to be relevant, or .. ? Is there are way to know which ones should be supported?
• I'm curious on what was the reason for ESS motor module to go its own way and not follow the community motor modules and their architecture (referring to the 'side-note' from @tboegi above)? If 30+ motor modules exist under the same umbrella then ESS motor module must be really different I guess.
• I would like think that in absence of other mature motor modules in https://github.com/epics-modules/motor/tree/master/modules to work with, the motorMotorSim motor module could be seen as a reference for behavior/features; Am I correct in expecting that?

I apologize if I missed or misunderstood the docs, there is a lot to take in.

Keep up the good work & thank you for your time!

[tboegi]

@hinxx : To not allow the user to control the homing velocity:
I think that the reason is that the velocity is defined in st.cmd while commissioning.
If a user sets a "too high" velocity, it is easy to damage your hardware.
So we tend to set a "safe" value here.
The fact that HVEL is ignored is done in the driver, not the record.
And the other questions: I am happy to answer them face-to-face.
Please try to not "overload" an issue on ecmc with lots of general questions...

[hinxx]

If a user sets a "too high" velocity, it is easy to damage your hardware.

But the user can set any velocity for normal movement, right? Wouldn't that, in case of user error, cause potential hardware damage as well?

And the other questions: I am happy to answer them face-to-face.

Appreciated, but what is the benefit of verbal exchange to the other users of this repo?

Please try to not "overload" an issue on ecmc with lots of general questions...

I'm sorry, I consider these questions quite specific to the ecmc, ESS motor module / record (with a hint of general knowledge for context). If there is something I can read up on the topics mentioned feel free to direct me there.

[MarkRivers]

I would like think that in absence of other mature motor modules in https://github.com/epics-modules/motor/tree/master/modules to work with, the motorMotorSim motor module could be seen as a reference for behavior/features; Am I correct in expecting that?

I'm not sure what you mean by that. There are many mature motor modules in that repository. Using the asynMotorController and asynMotorAxis base classes it is really quite easy to write a new driver that uses all of the capabilities of the motor record. You mainly just need to implement these methods from asynMotorAxis:

  virtual asynStatus move(double position, int relative, double minVelocity, double maxVelocity, double acceleration);
  virtual asynStatus moveVelocity(double minVelocity, double maxVelocity, double acceleration);
  virtual asynStatus home(double minVelocity, double maxVelocity, double acceleration, int forwards);
  virtual asynStatus stop(double acceleration);
  virtual asynStatus poll(bool *moving);
  virtual asynStatus setPosition(double position);
  virtual asynStatus setEncoderPosition(double position);
  virtual asynStatus setHighLimit(double highLimit);
  virtual asynStatus setLowLimit(double lowLimit);
  virtual asynStatus setPGain(double pGain);
  virtual asynStatus setIGain(double iGain);
  virtual asynStatus setDGain(double dGain);
  virtual asynStatus setClosedLoop(bool closedLoop);
  virtual asynStatus setEncoderRatio(double ratio);

Many drivers implement features beyond those in the motor record. If your controller is capable of coordinated multi-axis motion ("profile moves") then you can implement these methods:

  virtual asynStatus initializeProfile(size_t maxPoints);
  virtual asynStatus defineProfile(double *positions, size_t numPoints);
  virtual asynStatus buildProfile();
  virtual asynStatus executeProfile();
  virtual asynStatus abortProfile();
  virtual asynStatus readbackProfile();

Other controller-specific features (current control, advanced feedback parameters) can also be easily supported.

The Galil driver is an example of a very full-featured driver.
https://github.com/motorapp/Galil

[jeonghanlee]

@jeonghanlee : Please do not close this issue yet. We need to dig into this. According to my memory, the homing velocity is defined in the st.cmd of the IOC, as part of the commissioning. And the HVEL from the record is ignored. I may be wrong, so that is why we need to dig into this.

And as a side-note: We use the ess-master version of the "epics motor module" (which includes the motorRecord himself and much more files) for both ecmc and TwinCAT. (And even if talking to TwinCAT system we ignore HVEL)

@anderssandstrom does ecmc use the motor record? I thought, we moved its your own asyn based classes when I spent time to configuring the RT Linux configuration there. We saw the asyn-based ecmc version had the better performance.

@tboegi I will not close this, so do not worry about this.

[anderssandstrom]

@jeonghanlee, yes ecmc use motor record (but motion can also be executed without motor record by "normal" records). Anyway, what we found was that the motor record model 3 driver (like what @MarkRivers explains above) we used for ecmc at that time, EthercatMC, which we also used for our TwinCAT, was not optimised for RT. So, what we did was to write an ecmc dedicated model 3 motor record driver instead. By doing this we could direct call ecmc functions instead of parsing strings communicated through asyn like with EthercatMC resulting in much less RT jitter.

@hinxx, for most homing sequences ecmc uses 2 different velocities, one fast and one slow which are used for different steps of the homing sequence. So if we use HVEL then, I guess, the best would be to set both the ecmc velos to this value. I can make some tests.

Motor record:
ecmc uses the ESS version of motor record for historic reasons. Basically the intention was that both ecmc and the twincat system should work in more or less the same way (we started with TwinCAT and then we used the same setup for ecmc).I actually do not remember the reasons why we needed a custom motor record, this is @tboegi expertise.

[hinxx]

I'm not sure what you mean by that. There are many mature motor modules in that repository..

@MarkRivers : I believe there are. I wanted to say that since I do not have access to any of the hardware that those mature modules would work with, I'm resorting to motorMotorSim and treating that as the feature / behavior / implementation reference point.

@anderssandstrom : Thanks for the insights. If I understand correctly, ecmc is motor record model 3 driver implementing asynMotorController and asynMotorAxis just like any other model 3 driver would.

So if we use HVEL then, I guess, the best would be to set both the ecmc velos to this value. I can make some tests.

Thanks for looking into this.