Closed DivingDuck closed 1 month ago
@DivingDuck let me know if you think we should wait for the solution to be tested on Prusa's firmware. I expect it to work well but you never know.
I wish I have a Prusa for testing on my hand, but I don't. Let us wait this week whether we get a response on our request in #1421. We should merge it end of the next week w/o further tests if not.
@rockstorm101, this one is ready to merge. See latest comments of #1421
Maybe we should think about a new release that incorporate all updates we did since 2.1.0?
Maybe we should think about a new release that incorporate all updates we did since 2.1.0?
Yeah, absolutely, since this change fixes a regression I think we must release at least the fix. I'd say we do a minor release with all updates (i.e. go for a 2.2.0 release). What do you think?
We have a plan - sounds good to me 🙂
For reference pls. see issue #1421
I found in my firmware test 3 different behaviors to newer Marlin versions. So we have now 3 variants:
M110 N-1
for resetting the gcode line number in the printerN-1 M110
N-1 M110
andM110 N-1
N-1 M110 + line checksum
My solution for this is adding back the old behavior and combine this with the actual implemented Prusa modification:
self._send("M110 N-1", -1, True)
. This ends in sendingN-1 M110 N-1*125
and both, the old firmware from Marlin and for Smoothieware are happy with the gcode.Up to now there is no tester available for this solution with an actual Pusa firmware.
The pull request includes in addition 2 little gcode test files: quicktest.gcode and quicktest.dfx for testing repeated prints arc_test.gcode for testing the printer capability of arc movements in xyz axis Both gcode files needs only a half minute for testing and are located in the folder testfiles. Let me know if I should delete them