stepTimerQuantum introduces discretization error, which makes the
acceleration curves noisy.
In rampgen generate ramps for a single moving axis in addition
of two axes moving together.
Then, in test_ramp_gen, test a single axis moving accurately, while
allow for some discretization error when two (or more) axes are running.
Pulley doesn't result in an exact step count due to the fractional
count.result in an exact step count due to the fractional count.
Use Selector instead to test values exacly.
Still check Pulley and Idler, but allowing for a +/-1 step of rounding
error.
The parameter config::AxisConfig::uSteps was supposed to be
microstepping resolution, but it's instead being used as the driver's
MRES directly.
To avoid a runtime conversion, rename the field to mRes and define a new
enum listing all the possible (and valid) microstepping resolutions.
This simplifies the code and makes clear the stepsPerUnit scale.
Assign correct stepsPerUnit to all axes as a result, including working
limits.
- Add additional information in the output generated by rampgen in order
to allow recalculating the acceleration curves independently
- Implement motion ramp checks inside test_motion_ramp.py
test_motion_ramp reads the output of a merged stepping sequence and
splits the motion of each axis, checking the acceleration curves
independently.
This ensures both that the acceleration curves are correct (as generated
by the PulseGen class) and that the multiplexed moves are too.
The nominal rate is checked exactly, while the acceleration/deceleration
segment allow for some deviation from an ideal curve.
This is currently 5% for both expected speed and acceleration, with
an absolute limit of 20mm/s of maximum difference in each point.
- Remove motion::dual_move_ramp from the Catch2 tests and reimplement
it as a minimal c++ program for the ramp validation.
- Add a skeleton python validator to check the ramp output
- Use test "fixtures" to ensure the rampgen is run (both as a test,
and to generate output) when the test_motion_ramp.py is requested.
Introduces a nasty hack to forcefully write into the constexpr SPI descriptor's registers
(which is the correct way in ASM, but kind of cumbersome in C++ now)
Introduces:
- config::Unit: base class for physical quantities
- motion::AxisUnit: type-checked steps type
"config/unit.h" defines basic physical quantities, which are not
normally used elsewhere besides config.h.
"modules/axisunit.h" extends the modules::motion namespace with
Axis-aware units, with one type per axis per unit.
P_pos_t defines step positions for the pulley, I_pos_t for the idler,
etc. These are defined through the literar operators which are
similarly named and automatically convert a physical quantity to an
AxisUnit at compile time:
P_pos_t pulley_pos = 10.0_P_mm;
Besides type-checking, AxisUnit are otherwise identical to raw step
counts and are intended to be used along with the updated Motion API.
PlanMove/PlanMoveTo has been extended to support moves using these units
or physical quantities. Again, conversion is performed at compile time.
CurPosition() returns the live axis position, which in this
implementation is inherently expensive to compute.
This shouldn't be required for the MMU, but it /will/ come in handy to
check for the axis position/s in Motion tests.
Instead of stepping halfway, step ~1/3 of the way through.
This ensures we can check if the steps performed is correct due to the
internal step subtraction.
- Remove the combined PlanMove(a,b,c,rate) call. If we allow the units
of the various motors to be changed at compile time, the unit of
rate can vary between axes.
- Build PlanMove on top of the absolute PlanMoveTo.
- Add required stubs for TMC2130.
- Allow each axis mode to be set independently, since we have this
feature for free anyway.
- Rework internals to use PulseGen data types and structs.
Yuri D'Elia
Alex Voinea
D.R.racer
DRracer
Alan Dragomirecký