Where is the difference - 10 times X1 vs 1 times X10
-
would probably need the acceleration, jerk and step settings to answer it (not that i could i any more detail than that)
-
@JBisc said in Where is the difference - 10 times X1 vs 1 times X10:
Why is the firmware not optimizing that?
Because its not the machines/firmwares job to do such optimisation. That's the slicers task.
-
Is there a way to suppress deceleration? Lets assume I want to move straight with G1 and want to keep the current speed without decelerating and you want to change in a (tangent) arc. How would this be possible?
-
unless the moves are pretty short, the slicer or cam software will deal with it reasonably well. what are you trying to achieve?
-
@JBisc, try two moves of 50mm each. How does it behave, slowing in the middle and reaccelerating? This will give you a hint what happens with 1mm moves.
-
I just wanted to check, if it would be possible to replace G02 and G03 command by interpolating and making small G01 steps. But this is now significant slower and therefor a big disadvantages even if I am able to perfectly approximate the arc with my "lines".
-
@JBisc said in Where is the difference - 10 times X1 vs 1 times X10:
I just wanted to check, if it would be possible to replace G02 and G03 command by interpolating and making small G01 steps. But this is now significant slower and therefor a big disadvantages even if I am able to perfectly approximate the arc with my "lines".
there is a plugin for octoprint that will analyze your gcode and try to fit curves so it replaces a bunch of G0/G1with G2/G3
https://community.octoprint.org/t/new-plugin-anti-stutter-need-testers/18077it reduces g-code significantly in some cases (a lot if you for e.g. use gyroid infill). I have not tested it myself but ppl report very good results with it
-
@gtj0 said in Where is the difference - 10 times X1 vs 1 times X10:
Acceleration and jerk are applied to each move. The firmware would have to read ahead to optimize that and that's not always possible nor would the optimization algorithm be trivial.
In this particular case, yes, if you send 100 times G1 from console with break between them it will do 100 moves with accel, travel, decel; but if this is in gcode file you are executing it's actually firmware's job to read ahead, see that it's moving in same direction at same speed so that deceleration is not required nor that there is any jerk so 100 times G1 should be executed 100% identical as single G1 doing the same move. I have not tested this with RRF, always assumed it works like that, but I did test this with number of cnc controllers (mach3, linuxcnc...) and they behave exactly like that (assuming relative moves in the op's example), I doubt RRF would behave differently
-
@ChrisP said in Where is the difference - 10 times X1 vs 1 times X10:
Because its not the machines/firmwares job to do such optimisation. That's the slicers task.
Actually, no. It is controller's task (RRF in this case). It is firmware that decides how to perform the move and by looking ahead knows that there will be no change in direction/speed so no need to decelerate till the final move. Yes, slicer in 3D printing application should not generate such code but that's irrelevant, if it does the firmware needs to handle it properly. The only issue with this type of code with 8bit boards is the memory size and cpu speed so having this many short moves can overload the parser and the planner so it can be slow for that reason but it should not be a problem with 32bit controllers
-
@arhi I share arhi's opinion. That could the job of the firmware to avoid these unnessesary decelerations.
-
It think it's a matter of wording here. Should the firmware be able to execute the commands given accurately - yes!
Optimisation implies that the firmware should be able to see (in this case) a series of G1 X1, recognise what's happening and convert it into G1 X100, for example. So I maintain that no, the slicer should optimise and the firmware should execute the commands correctly as if whatever had generated the gcode had optimised it. -
@ChrisP said in Where is the difference - 10 times X1 vs 1 times X10:
accurately
Very interesting word when it comes to motion control.
G1 X0 Y0 G1 X100 Y0 G1 X100 Y100In a world where machines have inertia, the only way to execute line 2 and 3 of the above 'accurately' is to come to a full stop at the end of line 2. All motion planners that look ahead use various approximations to go around that corner, and can be tuned with acceleration, jerk, or good ol Mach 3 even had a way to 'turn off' what they called 'constant velocity' when a change of angle exceeded a configurable value.
All such tuning trades time-to-cut vs accuracy-at-direction-changes. Regardless of which motion planner is involved. I remember tuning mach to make visually decent shapes in a particular cut, and seeing cut time (for about 100 repeats, on a 24 x 48 sheet of material) vary from one hour to as much a four hours, depending on all those settings. Unfortunately the one hour cuts were unusable.
Better motion planners to a better job of direction changes, and/or are more tune-able.
Anyway...
The point being that experimentation with repeated G1 X1 vs G1 X20 vs G1 X50, etc, etc, are well warranted. FROM A FILE. Only.
Delta / Kossel printer fanatic
-
@ChrisP that example firmware should execute exactly the same move (10x X1 vs 1x X100), no "replacement" need to take place, that should just be normal behavior of the firmware. And yes, as danal said, from a file only, if you execute that from console there is no way to do look ahead
-
@Danal ah, the cornering is the everlasting story but I don't think it applies to op's question. What is better, how to do it better, what works for milling, what works for laser, what works for FDM ... not the same things for sure, and even identically named algorithms in different controllers work differently, let alone different algorithms for same thing :). But what OP asked, as you too agree if I understood you correctly, the firmware will execute an identical move in both cases assuming it's reading from a file and not getting it from the console with pauses (the way RRF put stuff in queue IIRC even from the console if sent fast enough look ahead will work).
I'm still hoping slicers will start to use G2/G3. The work Brad (formerlurker) put into that plugin is great. I hope some slicer maker will hire him to embed that into it, so far it is very promissing.
-
I agree that moving in a straight line seems as though it would involve none of the cornering effects. So X10 twenty times should be the same as X200.
However... that's us as humans. The various algorithms are going to look ahead and calculate the 'juncture' and they will absolutely calculate the angle as zero... but, that may or may not mean all that much. Still could be undesired differences.
And let me be clear: I absolutely don't know what any of the planners are going to do with a zero angle juncture, much less what Duet specifically does. That's why the experiments...
-
Just for a super quick test, I ran the following on a CoreXY:
G1 X10 Y10 F10000 G91 G1 X10 ... repeat enough times to move 300... G90 G1 Y20 G1 X10So 30 G1 X10 moves relative moves for 300mm, then a sidestep to force two 90 degree corners on the planner, and then a single move 300mm back. All at F10000 , roughly 167mm/sec.
Listening to this, each move sounds IDENTICAL.
Then ran:
G1 X10 Y10 F10000 G91 G1 X1 ... repeat enough times to move 300... G90 G1 Y20 G1 X10That is 300 individual X1 moves.
This was interesting. Started the same, then sagged, badly, then dipped even more, then came back up just a little and finished with less change, but VERY clearly slowed down, maybe half, from the single long moves or the X10 moves.
Not scientific, but VERY clear.
Duet 3 + Pi, running RC8 and DSF 2.0.0
-
@Danal I would call that a bug
... I'm some ~12 hours to finish the print and will check myself on the cartesianI'm not familiar with RRF source yet but for e.g. if you look how smoothieware (the one I am kinda familiar with) does it if the angle between the lines is less than ~1 degree ( cos(theta) +-0.95 ) it will not at all calculate junction deviation, no deceleration, it will go through the junction full speed; If the angle is larger than ~1 degree then corner speed is approx
sqrt( acceleration * junction_deviation * sin_theta / (1.0 - sin_theta))there used to be a bug, don't remember if in this calculation or another one where the calculation was not done only if the angle was zero but floating point is ugly about zero so this was changed to be larger value
(EDIT: I see they changed this to 0.9999 cos(theta) some years ago
) -
@arhi said in Where is the difference - 10 times X1 vs 1 times X10:
@ChrisP that example firmware should execute exactly the same move (10x X1 vs 1x X100), no "replacement" need to take place, that should just be normal behavior of the firmware.
Yup, we agree then.
@Danal Interesting test. And agree that is a bug. Are you able to try it standalone without the Pi? It's also be interesting to try at slower feedrates to see it there's a limit.
-
Out of curiosity, I can't imagine a scenario where a slicer would generate multiple segmented moves for what would be a single, longer move. So what are the circumstances where such multiple, short, single axis, segmented moves would need to be accomplished? Does CAD software generate such moves and if so why?
-
It's a question of throughput. A lot of work has to be done to process each of those G1 X1 commands, and there is a limit to the rate at which the Duet+firmware can read and process a long run of them and stitch them together.
There is also a limit to the length of the movement queue, and all the time the firmware has to allow for the possibility that it may have to decelerate to zero speed when it reaches the end of the queue, because there may be no more moves. On Duet 3 the movement queue is 60 moves long. So with 1mm long moves, the speed won't exceed sqrt(2 * 60 * A) where A is the configured X acceleration.
