This introduces a new #define UNITTEST_MOTION which is used to control
the testing scenario:
- Normal tests, we allow the stub to override the built-in definition.
- For motion tests, we stub the lower-level classes and test the
effective implementation
We also repeat the prototype of the function, which IMHO is more
readable and more flexible: we need to use inline for the real
definition, which would require even more macros otherwise.
If the queue is full and a new move is queued, panic!
Introduce a new error code QUEUE_FULL to help diagnose situations where
the queue is handled improperly: likely one of the state machines not
waiting for the previous actions to finish.
PulseGen::PlanMove returns a boolean if the queue cannot be moved.
We could extend this to Motion::PlanMove, however all moves would then
have to check for this. Having a global check such as this ensures
we never ignore such situation.
Allow to chain moves by adding one extra parameter to the PlanMove[to]
functions: ending speed.
A move will always be accelerated from the last speed towards end ending
speed. The following:
PlanMove(100._mm, 50._mm_s, 50._mm_s);
PlanMove(200._mm, 100._mm_s);
Will first move the axis 100mm, accelerating towards 50mm/s, then
accelerate again to 100mm/s. The move will for then decelerate towards a
full stop after reaching 300mm in total.
Acceleration can be changed for each segment, so that a custom
acceleration curve can be created:
SetAcceleration(10._mm_s2);
PlanMove(100._mm, 50._mm_s, 50._mm_s);
SetAcceleration(100._mm_s2);
PlanMove(100._mm, 50._mm_s, 50._mm_s);
The ending speed might not always be reached, depending on the current
acceleration settings. The new function "Rate()" will return the ending
feedrate of the last move, if necessary.
AbortPlannedMoves accepts a new "halt" parameter to control how moves
will be chanined when interrupting the current move. By default
(halt=true) the move is completely interrupted.
When halt=false is requested, a subsequent move will be chained starting
at the currently aborted velocity. This allows to chain moves in reponse
to events, for example to accelerate the pulley without stopping as soon
as the FINDA is triggered, it's sufficient to interrupt the current move
followed by a new one:
PlanMove(maximum_loading_lenght, slow_feedrate);
... wait for PINDA trigger ...
AbortPlannedMoves(true);
PlanMove(bowden_lenght, fast_feedrate);
will seamlessy continue loading and transition to the fast feedrate.
Jerk control has been simplified. It now handles only the maximal
velocity change of the last segment, which doesn't require reverse
planning.
Add a new parameter "halt" (default to true) to control the stopping
behavior:
- halt=true: no subsequent moves will be planned, motions stops abruptly
- half=false: a new move will be chained after the current one
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.
Besides Unload Filament, which only operates on active slot, all other
top level state machines check the validity of the command's parameter.
If the parameter is out of range for available slots, they return
ErrorCode::INVALID_TOOL now.
Extracted from the previous FW, may need some tuning based on units selected
for each of these axes (degrees, millimeters) - waiting for an update
of the motion implementation.
Updated starting conditions of the unit tests to reflect the global configuration.
MMU-58
3d-gussner
Alex Voinea
D.R.racer
Yuri D'Elia