Go to file

Yuri D'Elia 04631677cc Motion/PulseGen: implement move chaining and end-speed control 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.		2021-08-30 12:49:34 +02:00
.vscode	Add vscode configuration to allow easier switching among firmware and unit tests	2021-05-31 12:28:47 +02:00
cmake	Define missing definition of CMAKE_OBJDUMP	2021-06-15 06:53:03 +02:00
lib	Add first unit test	2021-05-13 17:35:08 +02:00
src	Motion/PulseGen: implement move chaining and end-speed control	2021-08-30 12:49:34 +02:00
tests	Motion/PulseGen: implement move chaining and end-speed control	2021-08-30 12:49:34 +02:00
utils	Make cmake show verbose errors on failure	2021-08-12 17:50:39 +02:00
.clang-format	Disable preprocessor code indentation	2021-07-07 16:33:03 +02:00
.cmake-format.py	Prepare parts of the build system	2021-04-19 07:03:47 +02:00
.gitignore	Prepare parts of the build system	2021-04-19 07:03:47 +02:00
.pre-commit-config.yaml	pre-commit: handle cmake files in subdirectories	2021-07-12 10:45:35 +02:00
CMakeLists.txt	Add -fno-rtti to ensure no RTTI is generated	2021-08-24 16:16:34 +02:00
Doxyfile	Update doxyfile + document modules namespace	2021-06-30 07:39:31 +02:00
README.md	Update description of the build process	2021-04-19 07:03:47 +02:00
version.txt	Prepare parts of the build system	2021-04-19 07:03:47 +02:00

README.md

Prusa-Firmware-MMU-Private

How to prepare build env and tools

As the first step extract the AVR-GCC to some dir, e.g. /home/user/AVRToolchainMMU/avr8-gnu-toolchain-5.4.0

Add /home/user/AVRToolchainMMU/avr8-gnu-toolchain-5.4.0/bin to your PATH.

mkdir .dependencies
cd .dependencies
mkdir gcc-avr-5.4.0
cd ..
utils/bootstrap.py

bootstrap.py will now download all the "missing" dependencies into the .dependencies folder:

clang-format-9.0.0-noext
cmake-3.15.5
ninja-1.9.0

Note: bootstrap.py will not try to download the AVR-GCC as there is already a directory called gcc-avr-5.4.0. This will be fixed when we find out where to download the correct packages reliably.

How to build the preliminary project so far:

Now the process is the same as in the Buddy Firmware:

utils/build.py

builds the firmware.hex in build/mmu_release

In case you'd like to build the project directly via cmake you can use an approach like this:

mkdir build
cd build
cmake .. -G Ninja -DCMAKE_TOOLCHAIN_FILE=../cmake/AnyAvrGcc.cmake
ninja

Should produce a firmware.hex file as well.