Documentation or Guide for Current Path Planning?

DocTrucker

Would synax including 'e' like the following would be invalid?

G1 X1.2e2 Y234 Z23 E1 F3600

If so I guess the white space is essential or the above would be saying move the E axis 2 and 1mm?

(not got machine running at the moment!)

dc42

@doctrucker said in Documentation or Guide for Current Path Planning?:

Would synax including 'e' like the following would be invalid?
G1 X1.2e2 Y234 Z23 E1 F3600
If so I guess the white space is essential or the above would be saying move the E axis 2 and 1mm?

~~Yes on both counts~~. I'm sorry, I misread your post. G1 X1.2e2 Y234 Z23 E1 F3600 is valid. You need a space before an E parameter, but not before other parameters.

DocTrucker

Thanks.

So G1X10Y10Z10 is invalid, as is G1 X1e1 Y10 Z10, with the correct syntax being G1 X10 Y10 Z10 with the X, Y, and Z being any order after the G1 in addition to the optional S and or H parameter.

If you issued a command like the following would the second X override the first or would the machine return an error?

G1 X1 X10 Y10 Z10

Likewise in the gcode definition for G1 it has the following statement:

Feedrate

G1 F1500
G1 X50 Y25.3 E22.4

In the above example, we set the feedrate to 1500mm/minute on line 1, then move to 50mm on the X axis and 25.3mm on the Y axis while extruding 22.4mm of filament between the two points.

G1 F1500
G1 X50 Y25.3 E22.4 F3000

However, in the above example, we set a feedrate of 1500mm/minute on line 1, then do the move described above accelerating to a feedrate of 3000 mm/minute as it does so. The extrusion will accelerate along with the X and Y movement, so everything stays synchronized.

This confuses me a little as in both cases the machine needs to accelerate from 0 to 1500, the only difference being in the second example it has to continue to accelerate once it achieves 1500 in order to achieve 3000.

...or is this trying to say:

Feedrate

G1 F1500
G1 X50 Y25.3 E22.4

In the above example, we set the feedrate to 1500mm/minute on line 1, then move to 50mm on the X axis and 25.3mm on the Y axis while extruding 22.4mm of filament between the two points.
The machine accelerates to 1500 as fast as the acceleration limits in the config file and gcode file allow, and then continues to the end of the vector.

G1 F1500
G1 X50 Y25.3 E22.4 F3000

However, in the above example, we set a feedrate of 1500mm/minute on line 1, then do the move described above accelerating to a feedrate of 3000 mm/minute as it does so. The extrusion will accelerate along with the X and Y movement, so everything stays synchronized.
The machine accelerates to 1500 as fast as the acceleration limits in the config file and gcode file allow, and then continues to accelerate to 3000 over the remainder of the vector.

In both examples the machine maybe carrying upto 1500mm/min from a previous move if the machine was not already stationary.

dc42

@doctrucker said in Documentation or Guide for Current Path Planning?:

So G1X10Y10Z10 is invalid, as is G1 X1e1 Y10 Z10

Those are both valid. You can omit spaces that separate the parameters, except for the space before an E parameter.

DocTrucker

Thanks. I'll have to tweak my regex a little then!

If the feedrate is changed during a move does the machine reach that speed as fast as the acceleration limits in the config file (or gcode file) allow or is it timed to reach the final speed at the end of the move?

Considing the following example:

(Start stationary at X0, Y0 Z0)
F1000
G1 X0 Y10 Z0
F2000
G1 X0, Y20 Z0 F3000
G1 X0, Y30 Z0 F4000
(Finish stationary at X0, Y30 Z0)

The velocity profile would be:

From (0,0,0) accelerate as fast as permitted to 1000mm/min and continue at 1000mm/min to end of move.
From (0,10,0) accelerate as fast as permitted to 1000mm/min and continue to accelerate to 3000mm/min at end of move.
From (0,20,0) accelerate at an appropriate rate to reach 4000mm/min by the end of move from a starting 3000mm/min, but then start deceleration as fast as permitted in order to reach 0 velocity at the end of the vector. Never reaching a feedrate of 4000mm/min.
Zero velocity at (0,30,0)

dc42

@doctrucker said in Documentation or Guide for Current Path Planning?:

(Start stationary at X0, Y0 Z0)
F1000
G1 X0 Y10 Z0
F2000
G1 X0, Y20 Z0 F3000
G1 X0, Y30 Z0 F4000
(Finish stationary at X0, Y30 Z0)

The F1000 in line 1 will behave exactly as if it appeared in the G1 command in line 1. The F2000 command in line3 will be ignored because the F3000 in line 4 overrides it. The last move will accelerate to 4000 at the configured acceleration, continue at 4000, and then slow to be no faster than the Y jerk speed by the end of the move.

DocTrucker

Thanks again, the wiki page / documentation is a little confusing there!

Which of the following best describes how the jerk is applied:

As a permitted instantaneous change in speed of an axis regardless of starting speed. (in other words the velocity could change from (-0.5 * jerk) to (0.5 * jerk) or (1.0 * jerk) to (2.0 * jerk) on a single axis.
If the difference between 0 and the current velocity is less than jerk the speed can instantaneously be changed to 0, or +/- Jerk so long as that does not cross 0 velocity.
Only at the start and end of a print move with the exception of the E axis.

DocTrucker

...ok pieced together from previous threads from various users I will make the following assumptions about 'Jerk'.

It is treated as the maximum instantaneous change in velocity, not necessarily from or to zero, and can cross zero.
It is applied between G1 moves, and at the end of a sequence of G1 moves.
If the change in requested feedrate from one move to the other is less than 'Jerk' then there will be no other acceleration before or after the Jerk.
It is not applied to the start of moves from stationary.
It is treated as the maximum instantaneous change in velocity, not necessarily from or to zero, and can cross zero.

dc42

RRF currently applies jerk only between pairs of extruding moves. So if an extruding move is followed by a non-extruding move, it will come to a stop between the moves. This has been criticised because it doesn't support coast-to-end, so I may change it (although coast-to-end is a poor substitute for pressure advance).

DocTrucker

@dc42 Thanks that's enough for me to get a decent start on my gcode parser.

Other unasked questions relating to acceleration/deceleration may come out in the wash when I get to estimating travel time.

This is predominately an exercise to get back up to speed with Python, but also to better understand the details process.