Open Nibbels opened 6 years ago
Interesting problem. The problem here is what is the slowest allowed interval, so that the explicit acceleration computation does not lead to such instabilities that you would loose steps.
In fact both solutions are wrong if I think about it. The problem is that you need the maxInterval for the driving axis and here we have one value for all axis also they differ in steps per mm and acceleration - the 2 parameter defining the minimum speed for that axis.
Problem is that this always give a minimum speed that might be higher then you want. Thinking about it it might be possible to ignore this if we set the matching jerk to 2 * minimumSpeed. The problem only arises during acceleration/deceleration so for lower speeds we just start right away with the low speed and if higher speeds are wanted, we start with minimum jerk/2 which is the minimum speed already.
Only problem is if jerk wanted is lower then that. That would not be possible any more but on the other side is already not possible due to enforcing the minimum speed which would then be higher then jerk.
Digging into it I see it was added here:
https://github.com/repetier/Repetier-Firmware/commit/90ad59adb8e05151f3f3108f758b254c9ffe5222
I think computing this for y as well and setting jerk to 1.41* min speed (for diagonal) would make that condition useless and the stepper timer much faster.
Only have to think about the minimum speed and if it is safe to assume it does not accelerate.
Thx for https://github.com/repetier/Repetier-Firmware/commit/e76875ec2d04bd0dbfdd9a157270ee03f4731d5f I just grabbed the code.
I will test it this weekend.
Hello again :)
This problem is not a real problem for normal firmware operation, but could be of interest to you. Again: I am working with some very old version of Conrad Electronics RFx000 Printers which I am patching for some weird reasons like getting a "good working Printer". These days I've kind of completed fixing things: But one more detail here ...
Topic for fastreaders: Slowest E-only extrusion is not possible.
On my stony way through the code I got to these lines:
https://github.com/repetier/Repetier-Firmware/blob/7fd6f244661c4b84508055b742e3075ad0d06cb5/src/ArduinoAVR/Repetier/motion.cpp#L2475
https://github.com/repetier/Repetier-Firmware/blob/7fd6f244661c4b84508055b742e3075ad0d06cb5/src/ArduinoAVR/Repetier/motion.cpp#L2459
The actual limit (maxInterval ) seems to get set here: It is only "made by" X, Y, Z. https://github.com/repetier/Repetier-Firmware/blob/7fd6f244661c4b84508055b742e3075ad0d06cb5/src/ArduinoAVR/Repetier/Printer.cpp#L499
One tiny problem: I made this test script for myself (https://github.com/Nibbels/Repetier-Firmware/blob/community_development/Repetier/RF.cpp#L2742) This script is extruding slowly at the beginning. The speed rises. I do this to test my nozzles possible flow.
The trick is that I am using force sensors which measure the weight between extruder and hotend. Data gets logged -> Excel -> Diagram ... http://www.rf1000.de/viewtopic.php?f=23&t=1620&hilit=d%C3%BCse+geschwindigkeit&start=20#p16758.
The source of my problems are these E-only moves in a row. (Yes thats weird for normal operation of a printer, thatwhy I wrote "contrived") Well, all worked fine until I took your commit about the lines in the first two links atop. Afterwards the extrusion script was broken, because it was way to fast.
Fix:
&& move->isXYZMove() fixed my Problem.
You might just close and ignore this, because maybe I dont see the point. You know better :) In case you know that my fix is completly wrong, please tell me.
Greetings