Add Stop Decel and Quick Stop Decel parameters to Elmo Platinum Drive

[richardw347]

Quick PR to expose the Stop Decel (SD) and Quick Stop Decel (SD) parameters.

I'm working on an application which involves lifting a heavy load using a vertical axis with limit switches. It's very helpful to be able to set these deceleration parameters, especially SD which is used when a limit switch is hit.

I've tested this PR with our own platinum twitter drives, and I've also updated and tested all the epd test cases, except the network test as I don't have the beckoff el3602.

Also another note I didn't run a make format for this PR as it made quite a lot of other changes to files I didn't touch. Happy to submit a separate formatting PR.

[d-loret]

@richardw347, thanks for your contribution.

I'll need some time to take a closer look at your change because from what I remember, the JSD driver, or potentially the Fastcat wrapper (C++ wrappers for JSD drivers), have other configurations that might indirectly nullify these couple parameters. Were you able to confirm those decelerations are actually followed by the motor in your tests?

Are you also using Fastcat? We would also need an update there so that sensible values are selected when they are not explicitly provided.

I'm very busy this week, but I'll try to get to it as soon as possible.

[richardw347]

@d-loret

I'm not using Fastcat, I'm building our ROS 2.0 driver layer on top of JSD. We've got some particular requirements namely adding a FSoE master and slave to the network so I'm trying to get as close to the problem as possible.

I've tested this on our hardware and it works well, the parameters definitely do kick in when you hit limit switches or engage quick stop.

Will also definitely take a look at Fastcat if it's setting parameters. I'm about to start looking at how easy it is to set all parameters for commissioning and these controllers have an excessive number of parameters!

[alex-brinkman]

@richardw347 - These make sense to expose in the small SDO table that we had to introduce in the platinum (the Gold does not need this look-up FWIW)

The rationale for the configuration parameters is to permit the application to change these values more easily between tests or to abstract configuration to more natural "Engineering Units" (EU) (e.g. set Amps rather than hard-to-remember counts conversion factor)

Q: Do you find that these parameters are needed to change between startup sessions? or can they be set once after the drive is tuned and fixed?

If the latter, I would advocate we keep them out of the configuration required by JSD at startup.

If the former, we should also expose the same parameters to the Gold-line drives before merging.

[richardw347]

@alex-brinkman you ask some interesting questions.

I'm in the initial testing phase on our platforms so being able to set and update these parameters at startup is very useful.

Additionally I like to have an automated validation for safety critical parameters within the application in case it's missed or set incorrectly during commissioning for whatever reason. In our vertical lifting application if we miss an end-stop because if an incorrect deceleration parameter it's going to speed past into a hard stop and lead to some damage.

As I said in my previous post I'm very happy to leave this un-merged, I'm just a big believer in contributing back and found it useful to be able to set these parameters for our use case.

Also we only have platinum drives so far so I'm afraid I'm unable to validate and changes to that side of the code base. Happy to collaborate with someone on it.

[alex-brinkman]

Yep, I believe in open-source too ;) I'm thrilled to see this software is being used in the wild.

I'll bring it up to our dev team and see what the consensus is. Either way, thank you very much!

[alex-brinkman]

We are not going to pursue adding these into the baseline EPD configuration. Setting these in the GPRM Is sufficient for most applications and confirming their value can always be achieved by as async SDO read after initialization and before use if a given application is paranoid about some safety-critical value.

@d-loret Is the EPD Two-letter command dictionary used for any public-facing interface? If so, I take this request and add it into the dictionary. Otherwise, we can close this request.

    ...
    {"QS", 0x325C},
    {"SD", 0x3295},
    ...

[d-loret]

We are not going to pursue adding these into the baseline EPD configuration. Setting these in the GPRM Is sufficient for most applications and confirming their value can always be achieved by as async SDO read after initialization and before use if a given application is paranoid about some safety-critical value.

@d-loret Is the EPD Two-letter command dictionary used for any public-facing interface? If so, I take this request and add it into the dictionary. Otherwise, we can close this request.

    ...
    {"QS", 0x325C},
    {"SD", 0x3295},
    ...

The Elmo command to dictionary object dictionary is used internally during initialization of the driver.

[d-loret]

@richardw347, I think it would be feasible to add these parameters in JSD but I would need to make a corresponding change in Fastcat before moving forward with this so that our existing systems behave the same after the change.

I also realized that you will require a FSoE master for your application. However, FSoE is not currently supported in JSD. So this is something you might want to take into consideration too.