... looks like I've been able to reduce the code by 80B by using the
clamp999() function. There are other spots this function can be used as
well, I didn't touch those yet.
upon request from our Service dept. - it is to do the same stuff like
Shipping prep., but keep the printer's stats intact. Still, this has to
be verified and may undergo some further changes.
Acceleration settings need to be saved in UVLO, since these are often
changed/set during a print. This is especially important for travel and
retract acceleration, which is usually set once per-print.
Saving and restoring is not 100% correct.
We save the current front-end value, which might ahead of the backend
when UVLO is triggered. Print acceleration, likely the most significant,
should be saved in the block buffer to be accurate.
Acceleration needs to be restored after the UVLO Z repositioning is
performed, using an M204 command. This is correct, however we don't save
the _temporary_ max acceleration limits set via M201, which could be
higher than the saved limits (via M500). This could result in lower
clamped values compared to the original print.
Maximum acceleration/jerk/feedrate limits should _all_ be saved in UVLO
in the future.
Allow to separate extrusion and travel acceleration settings using M204,
as Marlin 1.1.x and 2.x does using M204 T.
This allows to reduce the number of instructions required during
printing, since resetting the acceleration for travel moves is no longer
required and can be done a single time during the print.
Provision for this parameter was pre-existing, but not implemented.
M204 has two forms: the lagacy format (Marlin <1.1):
M204 S[print-acc] T[retract-acc]
and the newer format:
M204 P[print-acc] R[retract-acc] T[travel-acc]
The distinction in the MK3 FW is done based on the presence of the P
parameter. If P is seen, the new format is adoped. In the new format
however, M204 T was ignored until this change.
To keep backward compatibility, M204 S[acc] will set both print and
travel acceleration, which is identical in behavior to recent versions
of Marlin.
Depending if SD or USB/host print the firmware sends
- SD print: `// action:paused` or `// action:resumed` are send to inform USB/Host
- USB/host print: `// action:pause` or `// action:resume` are send to trigger the USB/host to handle it
- USB/host must handle `// action:pause` and `// action:resume` correctly to work
- Tested with Octoprint
- It handles every thing correctly
- Any combination of Octoprint and/or LCD `pause` and `resume` working correctly
- Tested with Pronterface
- It pauses BUT doesn't send the printer in pause position, and so it is not possible to `resume` from LCD menu
- I guess some Macros can fix that.
- Repetier Host/Server documentation shows that it should work. Not tested.
Could save 56 bytes in first step and additional 38 bytes adding `MSG_PAUSE_PRINT` to messages.c/.h
Updated `lang_en*.txt`
@todo Polish translation is 19 characters long (it still fits) BUT should be corrected to 18 chars.
It was left in the code in one of the refactoring/optimization passes.
It really didn't do any harm, but was limiting the performance of the
skipping algorithm.
+ some verification code added - will be removed after successful tests
fastio relies on macros for pin definitions, so we cannot use the const
declaration in Sd2PinMap or the arduino's definition.
Declare SDA/SCL_PIN into pins.h based on the current MCU, which is
identical in all our variants.
Remove the conflicting/unused declaration in Sd2PinMap.
