Skip to content

Change the way that kinematics classes included and discovered #1110

Open
@dc42

Description

@dc42

In RRF 3.6 the mechanism for introducing new sensor types and discovering the correct class when executing M308 was changed, by having the sensor classes construct a self-organising list that can be searched. I propose to do the same for kinematics classes. This will make it easier to introduce new kinematics classes and simplify the mechanism for including or excluding kinematics classes in particular firmware builds. It will also make M669 commands clearer because the parameter will be a kinematics short name rather than a number that has to be looked up.

The step to do this are:

  1. Ensure that each linemaocs class has a short name that is suitable for use as a string parameter. In most cases the existing short name should do. In a few cases it may be necessary to change the short name.
  2. Change the M669 command so that the K parameter accepts the short name of the required kinematics as the parameter value. For backwards compatibility the existing commonly-used kinematics numbers will still be accepted too. Numbers will not be assigned to new kinematics.
  3. Implement the same self-organising list mechanism that we use for sensor classes.
  4. Define a standard create function and implement it in each kinematics class, replacing any existing create functions.
  5. Change M669 to search the list for the required kinematics short name. If a kinematics number is provided instead then we can either use an array to map the numbers to short names, or we can store the kinematics numbers (where allocated) in the list as well as the names.

Metadata

Metadata

Assignees

Labels

internal enhancementchange to improve the internal working of RRF that is not a direct change to features/performance

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions