Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DEFAULT_MAX_ACCELERATION #3961

Closed
edwilliams16 opened this issue Jun 4, 2016 · 63 comments
Closed

DEFAULT_MAX_ACCELERATION #3961

edwilliams16 opened this issue Jun 4, 2016 · 63 comments
Labels

Comments

@edwilliams16
Copy link
Contributor

@edwilliams16 edwilliams16 commented Jun 4, 2016

Could you point me to some documentation on DEFAULT_MAX_ACCELERATION?
The wiki mentions DEFAULT_ACCELERATION and I'm unclear how these differ/interact.
I couldn't figure out how to search the closed issues to see if these had already been discussed...

@thinkyhead

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jun 5, 2016

I'm not sure where this is documented.

The DEFAULT_MAX_ACCELERATION values are used to limit the acceleration for each axis, so acceleration will go no higher than the given values. Depending on which axes are involved in a move, one or more of these values will be used.

The DEFAULT_ACCELERATION value is the acceleration initially applied to all planner moves, which is then constrained by DEFAULT_MAX_ACCELERATION for all the axes involved in the given move.

These acceleration settings are used when the planner sets acceleration for each stepper block. See the section of the planner.cpp function buffer_line starting with // Compute and limit the acceleration rate for the trapezoid generator. for the relevant code.

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 5, 2016

I've got it, I think. DEFAULT_MAX_ACCELERATION represents some per axis hardware limit - depending on mass, available torque etc. DEFAULT_ACCELERATION is then the tweakable parameter - while the previous parameter prevents you from setting it higher than the hardware allows.
Thank you for taking the time to answer my questions.

@thinkyhead

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jun 5, 2016

The DEFAULT_MAX_ACCELERATION values are used to initialize planner.max_acceleration_units_per_sq_second. You can change the planner.max_acceleration_units_per_sq_second array using the GCode command M201 Xn Yn Zn En or the LCD menu options Amax X, Amax Y, Amax Z, and Amax E. If you save to EEPROM the values you set here will be preserved across reboots.

The DEFAULT_ACCELERATION value is used to initialize planner.acceleration. You can change planner.acceleration using the GCode command M204 Pn or the LCD menu option named Accel. If you save to EEPROM the value you set here will be preserved across reboots.

@edwilliams16 edwilliams16 reopened this Jun 6, 2016
@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 6, 2016

I'd just like to confirm a few things before I drop this.

  1. DEFAULT_ACCELERATION and DEFAULT_MAX_ACCELERATION (all axes) are all in mm/sec^2
    (The code has reference to units/sec^2 - but I take it that somewhere unit=mm)
  2. DEFAULT_ACCELERATION refers motion in the x/y plane (at least for Cartesian 3D printers). (Comments imply x/y/z/e)
  3. Acceleration in the E-axis in printing moves (neglecting advance) is scaled to the acceleration in the x-y plane, by essentially the ratio of the filament cross-sectional areas leaving and entering the extruder.
  4. Given (3) and that typically DEFAULT_MAX_ACCELERATION(E) > DEFAULT_MAX_ACCELERATION(X,Y), DEFAULT_MAX_ACCELERATION(E) is never limiting in a printing move.
  5. Given (4), the effective range of adjustment is 0<DEFAULT_ACCELERATION<max(DEFAULT_MAX_ACCELERATION(X,Y).

Thanks for your patience in this.

@Roxy-3D

This comment has been minimized.

Copy link
Member

@Roxy-3D Roxy-3D commented Jun 6, 2016

You can cross #1 off your list. The units are mm/sec^2

@Blue-Marlin

This comment has been minimized.

Copy link
Contributor

@Blue-Marlin Blue-Marlin commented Jun 6, 2016

Everywhere in the configs, where you read mm/s or mm/s^2 replace it by units/s or units/s^2. Where unit is the unit you used in DEFAULT_AXIS_STEPS_PER_UNIT. Theoretically you can use inch, foot or km or nm, but because of the limited exactness of our calculations (float, long) you'll get the best results for something around mm, where the numbers are not too small and not to large..

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 6, 2016

So that has handled #1 nicely...

@Roxy-3D

This comment has been minimized.

Copy link
Member

@Roxy-3D Roxy-3D commented Jun 6, 2016

So that has handled #1 nicely...

Well, As Blue-Marlin says... The units can be anything. But I've only seen units specified as mm/sec^2.

@thinkyhead

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jun 7, 2016

  1. DEFAULT_ACCELERATION refers motion in the x/y plane (at least for Cartesian 3D printers). (Comments imply x/y/z/e)

@edwilliams16 DEFAULT_ACCELERATION is used to set the default value of planner.acceleration. The current value of planner.acceleration is applied to new planner blocks that include moves in X, Y, or Z, and also E.

DEFAULT_TRAVEL_ACCELERATION is used to set the default value of planner.travel_acceleration. The current value of planner.travel_acceleration is applied to new planner blocks that include moves in X, Y, or Z but not E.

DEFAULT_RETRACT_ACCELERATION is used to set the default value of planner.retract_acceleration. The current value of planner.retract_acceleration is applied to new planner blocks if they only include moves in E. (Not just retract moves, it appears.)

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 7, 2016

I'm obviously not explaining myself very well - or I don't understand how things work. Let's take a simple case where the trapezoid is just a triangle, accelerating from zero up to a velocity and then decelerating back to zero.
Let's suppose we are making a printing move in the x direction, where we move a distance 2d while extruding a distance 2d_e of filament in a time 2t. Let the x-acceleration be a, and the extruder acceleration be a_e (all in mm, secs or your favorite units).
Then d =a t^2/2 and d_e = a_e t^2/2 and so a_e = a (d_e/d).
So the acceleration of the E-axis (in mm/sec^2) is much smaller than the acceleration of X-axis (in mm/sec^2), by the ratio of d_e/d, which is also the ratio of the extrusion cross-sectional area to the filament cross-sectional area.
So the "default acceleration" cannot refer to both E and X because their values differ by a factor of 16 or so. I conclude that the number one assigns to DEFAULT_ACCELERATION is an x/y plane acceleration. It does however feed through in the code to determine the much smaller E (and Z) accelerations.

@thinkyhead

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jun 8, 2016

The code itself says it best. Here's what planner.buffer_line does with the configured acceleration values…

// Compute and limit the acceleration rate for the trapezoid generator.
float steps_per_mm = block->step_event_count / block->millimeters;
long bsx = block->steps[X_AXIS], bsy = block->steps[Y_AXIS], bsz = block->steps[Z_AXIS], bse = block->steps[E_AXIS];
if (bsx == 0 && bsy == 0 && bsz == 0) {
  block->acceleration_st = ceil(retract_acceleration * steps_per_mm); // convert to: acceleration steps/sec^2
}
else if (bse == 0) {
  block->acceleration_st = ceil(travel_acceleration * steps_per_mm); // convert to: acceleration steps/sec^2
}
else {
  block->acceleration_st = ceil(acceleration * steps_per_mm); // convert to: acceleration steps/sec^2
}
// Limit acceleration per axis
unsigned long acc_st = block->acceleration_st,
              xsteps = axis_steps_per_sqr_second[X_AXIS],
              ysteps = axis_steps_per_sqr_second[Y_AXIS],
              zsteps = axis_steps_per_sqr_second[Z_AXIS],
              esteps = axis_steps_per_sqr_second[E_AXIS],
              allsteps = block->step_event_count;
if (xsteps < (acc_st * bsx) / allsteps) acc_st = (xsteps * allsteps) / bsx;
if (ysteps < (acc_st * bsy) / allsteps) acc_st = (ysteps * allsteps) / bsy;
if (zsteps < (acc_st * bsz) / allsteps) acc_st = (zsteps * allsteps) / bsz;
if (esteps < (acc_st * bse) / allsteps) acc_st = (esteps * allsteps) / bse;

block->acceleration_st = acc_st;
block->acceleration = acc_st / steps_per_mm;
block->acceleration_rate = (long)(acc_st * 16777216.0 / (F_CPU / 8.0));
@Roxy-3D

This comment has been minimized.

Copy link
Member

@Roxy-3D Roxy-3D commented Jun 8, 2016

The code itself says it best.

Joao won't like this: But the code is the ultimate documentation! :) But of course, that only works if you can read the code.

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 8, 2016

We're talking past each other. I've read that code already. It calculates an acceleration, using the default and the limits. I'm hoping I don't have to read stepper.cpp to figure how it is really used.
block->acceleration is a physical quantity, measured in mm/sec^2. WHAT IS IT THE ACCELERATION OF? - given, if you believe my argument above, that, for instance, the acceleration in the E-axis is much smaller than in the x/y plane.
Perhaps I'm just supposed to treat DEFAULT_ACCELERATION as a number to be plucked out of the air - not representing any physical motion? But that seems unlikely.

@thinkyhead

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jun 8, 2016

block->acceleration … WHAT IS IT THE ACCELERATION OF?

It is the acceleration rate of the whole move,
already constrained to the lowest acceleration of all the axes involved.

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 8, 2016

Indeed it is... But as a value, it is representative of the acceleration in the X/Y plane or what?
The code is the embodiment of some physical model. In that model DEFAULT_ACCELERATION is a physical quantity (in mm/sec^2) representing acceleration of something. What? I'm really not that interested in trying to trace it all through the code. I want to know what it represents in the physical model. I assume the code authors know what that is. When I set it to a value, it helps if I know what physical quantity it represents. Making all the max accelerations infinite, if I print a straight line along the x-axis, what is the relation between DEFAULT_ACCELERATION and the acceleration of my extruder along the x-axis at the beginning and end of the trapezoid? I don't know how to make the question any clearer.

@Roxy-3D

This comment has been minimized.

Copy link
Member

@Roxy-3D Roxy-3D commented Jun 8, 2016

What? I'm really not that interested in trying to trace it all through the code. I want to know what it represents in the physical model.

@edwilliams16 I am absolutely insisting on a more polite tone here. I'm not gong to compromise on that. Please be respectful even if you are frustrated.

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 8, 2016

I apologize if I came over as impolite. I realize you are all volunteers and don't have to tell me anything. I just seem to be going around in circles, asking the same question in as many different ways as I can come up with. It's fine if you don't know the answer. Tell me that, and I'll stop asking the question.

@paulusjacobus

This comment has been minimized.

Copy link
Contributor

@paulusjacobus paulusjacobus commented Jun 8, 2016

@edwilliams16 https://github.com/edwilliams16 I have been through the
code a thousand times and even had a look at other firmware like Sailfish,
and Sprinter. The all use the same base code from Grbl with small changes.

The code is the embodiment of some physical model. In that model DEFAULT_ACCELERATION is a physical quantity (in mm/sec^2) representing acceleration of something. What?

Since you can set the acceleration for each axis, I always assumed that the
trapezoid calculations use the assigned acceleration per Axis. The code in
this issue trail seems to do that within an array (4 axis x,y,z and e).

Does that answer your question? Is the question, are the calculations for
the axis all based on one default acceleration figure or are the
calculations based on specific acceleration setting per axis? (I think the
latter is the answer)

On 8 June 2016 at 15:00, edwilliams16 notifications@github.com wrote:

I apologize if I came over as impolite. I realize you are all volunteers
and don't have to tell me anything. I just seem to be going around in
circles, asking the same question in as many different ways as I can come
up with. It's fine if you don't know the answer. Tell me that, and I'll
stop asking the question.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#3961 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AIOTKc-tyN_7GEDC8ooGCF57iXMw53mbks5qJkyGgaJpZM4IuM55
.

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 8, 2016

I'm not having much success finding out how the Grbl/Marlin planner code actually works. The code is dense and I've found virtually nothing in the way of documentation. I'm delighted to talk to someone who has dug into this.

Since you can set the acceleration for each axis, I always assumed that the
trapezoid calculations use the assigned acceleration per Axis. The code in
this issue trail seems to do that within an array (4 axis x,y,z and e).

I don't see how this can be true. Suppose we print a single straight line in the x-direction - one block - with the x-velocity a trapezoid as a function of time. We want even deposition along the line, so the extrusion rate has to follow the same trapezoidal shape as a function of time, with the extrusion rate at every point on the trapezoid directly proportional to the x-velocity. Thus the accelerations on the X and E axes also are directly proportional, and not independently specifiable. (At the risk of derailing the thread, "advance" breaks this proportionality, making the extruder velocities greater in the acceleration phase and smaller during deceleration, by an amount proportional to the acceleration.)
So DEFAULT_MAX_ACCELERATION is a vector (over X,Y,Z,E). The code quoted above forces the accelerations finally used to not exceed the maximum values for each axis, one by one.
However, DEFAULT_ACCELERATION is a scalar - once this is limited, if required, by the axis limits, only a single value should be required in (and is provided to) the stepper routine, because the accelerations used by each axis are direct multiples of this single value.
My question is which, if any, of the proportional accelerations for the four axes is the acceleration passed to the stepper (which in turn derived from DEFAULT_ACCELERATION). My guess it is in fact none of them, but is the acceleration in the X/Y plane (i.e. the derivative of the speed in the X/Y plane) - at least that's how I would have done it.

@paulusjacobus

This comment has been minimized.

Copy link
Contributor

@paulusjacobus paulusjacobus commented Jun 8, 2016

@edwilliams16 I could not find a description on how it works via google either. So i went to Github/grbl to look it up. The code is very detailed described in github/grbl. From what I read in the code comments (see an extract from grbl/stepper.c) the multiple axis are synced with each other through a smoothing algorithm which implies that each axis has its own trapezoid calculation but I might be wrong.

The Stepper Driver Interrupt" - This timer interrupt is the workhorse of Grbl. Grbl employs
the venerable Bresenham line algorithm to manage and exactly synchronize multi-axis moves.
Unlike the popular DDA algorithm, the Bresenham algorithm is not susceptible to numerical
round-off errors and only requires fast integer counters, meaning low computational overhead
and maximizing the Arduino's capabilities. However, the downside of the Bresenham algorithm
is, for certain multi-axis motions, the non-dominant axes may suffer from un-smooth step
pulse trains, or aliasing, which can lead to strange audible noises or shaking. This is
particularly noticeable or may cause motion issues at low step frequencies (0-5kHz), but
is usually not a physical problem at higher frequencies, although audible.
To improve Bresenham multi-axis performance, Grbl uses what we call an Adaptive Multi-Axis
Step Smoothing (AMASS) algorithm, which does what the name implies. At lower step frequencies,
AMASS artificially increases the Bresenham resolution without effecting the algorithm's
innate exactness. AMASS adapts its resolution levels automatically depending on the step
frequency to be executed, meaning that for even lower step frequencies the step smoothing
level increases. Algorithmically, AMASS is acheived by a simple bit-shifting of the Bresenham
step count for each AMASS level.

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 8, 2016

I wouldn't have read it that way. Bresenham is a venerable fast algorithm for drawing diagonal lines across a computer screen at slopes incommensurate with the screen resolution. It generalizes in an obvious way to multiple dimensions and to a counter that is not tied to an axis pixel position. I presume this applies to the stepper algorithm in that for each tick of an ISR you to look to see if it is time to send a stepper pulse to each of the axes. We are "drawing straight lines" in (X,Y,Z,E,t) space in that the ratio of the step rates is constant at each point on the discrete time axis (same trapezoid, but digitized differently depending on the scale!).
AMASS I take to be a smoothing scheme that dithers the steps in some clever way - not calculating multiple trapezoids, but digitizing multiples of the same trapezoid. The purpose of AMASS is to get rid of undesired artifacts created by more straightforward digitization. But it may take some digging and math to confirm this.
Thanks for the reference. Though I'm not much closer to an answer to my question...

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 8, 2016

If I just want to try to figure this out for myself, it looks like I can put SERIAL_* commands of various kinds in the code to dump info to serial output. Is there a debugging primer somewhere?

@Roxy-3D

This comment has been minimized.

Copy link
Member

@Roxy-3D Roxy-3D commented Jun 8, 2016

No primer...

But on the SERIAL_ commands to print stuff to the host... Don't go crazy and print too much. You will lose a lot of output. You can put a delay(100); after each line to make sure you don't over burden the host program when printing a lot. Lastly... Don't use too many of the macros that end in PGM because that puts the text in the program memory. At some point, the text won't really be there. There seems to be some limit to how much PGM text you can declare.

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 8, 2016

SERIAL_ECHO_START;
SERIAL_ECHOPAIR(varname1,var1);
delay(100);
SERIAL_ECHOPAIR(varname2,var2);
...

would do it? I start up the host, then send individual G-CODES and look at the serial output?
One SERIAL_ECHO_START?
SERIAL_ECHOPAIR is overloaded with different data-types?

Thanks

@Blue-Marlin

This comment has been minimized.

Copy link
Contributor

@Blue-Marlin Blue-Marlin commented Jun 8, 2016

@Roxy-3DPrintBoard
The limit is 64k.

@Roxy-3D

This comment has been minimized.

Copy link
Member

@Roxy-3D Roxy-3D commented Jun 8, 2016

The limit is 64k.

In the past... I've had problems when I had a bunch of debug messages stored in program memory. I don't know what I had, but it was well under 8KB. I don't know what was going wrong. But I do know just deleting some of the messages let me add other messages.

@thinkyhead

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jun 8, 2016

My guess it is in fact none of them, but is the acceleration in the X/Y plane

If your move includes the X or Y plane, but not the Z or E plane, then your acceleration will only be constrained by the max acceleration and max rates of the X and Y planes.

But if you include Z or E you will find that your acceleration may differ, if the default acceleration for Z or E is lower than that for X and Y.

Consider:

DEFAULT_MAX_ACCELERATION      {3000,3000,100,10000}
  • DEFAULT_ACCELERATION: Default for a move with X, Y, and E
  • DEFAULT_ACCELERATION: Default for a move with Z only, also
  • DEFAULT_RETRACT_ACCELERATION: Default for a move with E only
  • DEFAULT_TRAVEL_ACCELERATION: Default for a move with X and Y only but not E

If you include the Z axis in a move, the acceleration will be constrained to no more than 100mm/s/s. If a move only includes the E axis, its acceleration will be (essentially) unconstrained, since E accelerates at 10000mm/s/s.

There is only a single trapezoid for each linear move. Once we know which axes are moving together, and the target movement rate, then a single trapezoid is generated which applies to the whole move. As for chaining moves together, again, the acceleration part, which determines the "slope" of the trapezoid, is always constrained by the lowest acceleration value of the axes that are involved in the move.

Similarly, the max feedrate constrains the speed of a given move based on all the axes involved in the move, making sure that none of the axes exceeds its own maximum.

@thinkyhead

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jun 9, 2016

That was my next plan, to follow the code and paste snippets here for your benefit. But I'm sure you can do that yourself easily enough. If you discover a concise answer, please post it here.

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 9, 2016

OK. Here is how it works - assuming a printing move, with, in principle, all 4 axes active:

DEFAULT_ACCELERATION is a scalar quantity it represents the user-desired acceleration along a segment in 3-space. Since z-motions are tiny compared those in x and y, it is essentially the desired acceleration in the x/y plane in mm/sec^2.
If there are no limitations put on it, it is passed to the stepper routine as block->acceleration
(Which answers my long standing question of what does it represent)
Checks are made to ensure that the components of DEFAULT_ACCELERATION in the x/y/z directions
do not exceed the three corresponding spatial components of DEFAULT_MAX_ACCELERATION.

So, for instance if I print a 45 degree line, DEFAULT_ACCELERATION can exceed the x/y components of DEFAULT_MAX_ACCELERATION by sqrt(2) before triggering a reduction. (Which all makes good physical sense.)
In addition, a check is made to make sure the maximum extruder acceleration is not exceeded - but given typical values, it appears this won't happen in practice - and the coding gets intricate it did. So, I'll pass on that.

The stepper wants to work in steps. There ends up being a "primary axis" on which there is the largest number of steps. The key internal appears to be block->acceleration_st (also acc_st) which is related to the physical (x/y)-plane acceleration by
block_acceleration_st = block_acceleration *steps_per_mm

where steps_per_mm is the no of steps in the primary direction divided by the physical 3D path length in mm.

If I have it wrong, please let me know.

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 9, 2016

So I believe the answers to my questions of two days ago were:

  1. yes
  2. yes - strictly along the 3D path. Except for z-only moves effectively in the X/Y plane
  3. yes
  4. yes
  5. Approximately. Actually
    0 < DEFAULT_ACCELERATION < sqrt(DEFAULT_MAX_ACCELERATION(X)^2 +DEFAULT_MAX_ACCELERATION(Y)^2 +DEFAULT_MAX_ACCELERATION(Z)^2)
@thinkyhead

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jun 9, 2016

I'm happy that you sorted it out. Incidentally, we are always looking for more contributors who can help with Marlin documentation. https://github.com/MarlinFirmware/MarlinDocumentation

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 9, 2016

A minor change that would make the code more readable would be to rename'
axis_steps_per_sqr_second to max_acceleration_steps_per_sq_sec to make its relation to max_acceleration_units_per_sq_second transparent.

(in planner.cpp)

@thinkyhead

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jun 9, 2016

that would make the code more readable

Always a welcome thing. I'm not too fond of "per_sqr_second" and "per_sq_second" as a suffix for "per-second-per-second" either. I might just go for "per_s2" since we know what it means in this context.

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 9, 2016

Great. Shorter is better. More descriptive is better. The next person ploughing through the code maybe won't have to create a dictionary like me!

And strictly steps_per_mm should become steps_per_unit and block->millimeters should be block->units if you want to maintain that units aren't necessarily mm. But if you go that route, there would need to be clarification in Configuration.h that the conventional unit is mm so that innocent users reading units/sec^2 in the comments would know what was meant.

In fact, it might be better in the example configurations (which thus refer to particular machines) to comment that unit has been chosen to mm (in the #define steps_per_unit) and retain the mm/sec^2 etc. comments in the other defines.

@thinkyhead

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jun 9, 2016

Well actually, once we get to the planner and stepper level, everything is expressed in mm. So we could actually change "units" to "mm" in many places and it would be more accurate.

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 9, 2016

If, as Blue-Marlin said earlier in the thread, the only connection of the code to physical displacements of the machine is through DEFAULT_STEPS_PER_UNIT, the planner and stepper are indifferent to the choice of unit - except for the dynamic range of the variables.

Those machines that print houses by extruding concrete might want bigger units...

@thinkyhead

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jun 9, 2016

the planner and stepper are indifferent to the choice of unit

At some level we have to choose a standard unit of linear measurement. In the case of Marlin, that standard unit is the millimeter and I can guarantee that is never going to change.

@thinkyhead

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jun 9, 2016

Those machines that print houses by extruding concrete might want bigger units...

That's some big printing! Marlin can express up to 1334 miles in millimeters before it runs out of bits.

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 9, 2016

It would indeed be trivial for your concrete printer guy to just hack DEFAULT_STEPS_PER_MM and use Marlin to build your house.

@Blue-Marlin

This comment has been minimized.

Copy link
Contributor

@Blue-Marlin Blue-Marlin commented Jun 10, 2016

Until yesterday we have been perfectly able to use any unit we want. But the inch-mode requires the 'unit' to be mm now.

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 10, 2016

It appears Marlin doesn't support G20/G21 unlike most other firmware.

@Blue-Marlin

This comment has been minimized.

Copy link
Contributor

@Blue-Marlin Blue-Marlin commented Jun 10, 2016

Support inches, fahrenheit, and kelvin #3985. Merged yesterday. :-(

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 10, 2016

Things move faster than light around here. Comment today, happens yesterday.

@thinkyhead

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jun 10, 2016

"Being is faster than light."

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 10, 2016

I'm now trying to establish the physical meaning of "acceleration" in the case of retraction (E-only) moves. In the following snippet from Marlin_main.cpp:

inline void gcode_M200() {

  if (get_target_extruder_from_command(200)) return;

  if (code_seen('D')) {
    float diameter = code_value();
    // setting any extruder filament size disables volumetric on the assumption that
    // slicers either generate in extruder values as cubic mm or as as filament feeds
    // for all extruders
    volumetric_enabled = (diameter != 0.0);

Shouldn't "disables" be "enables"? I assume the normal situation is volumetric disabled and extrusions are specified in mm.

Additionally in

   * Add a new linear movement to the buffer. x, y, z are the signed, absolute target position in
   * millimeters. Feed rate specifies the (target) speed of the motion.
   */
  void plan_buffer_line(float x, float y, float z, const float& e, float feed_rate, const uint8_t extruder);

is the argument "e" in units of mm of filament?

Assuming things are as I think they are, I've concluded that for retraction (E-only) moves
DEFAULT_RETRACT_ACCELERATION is indeed the acceleration of the filament in mm/sec^2 and is limited by DEFAULT_MAX_ACCELERATION(E)
For travel and printing moves the accelerations are that of the print head. For travel moves the x/y/z components of the DEFAULT_TRAVEL_ACCELERATION are limited by the corresponding components of DEFAULT_MAX_ACCELERATION. For printing moves in addition the induced acceleration of the filament is limited by DEFAULT_MAX_ACCELERATION(E).
These are appropriate, IMO, and I will try to document them so that physicists like me don't get hung up on them.

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 10, 2016

I also attempted to clarify the documentation and create a pull request. Hopefully I succeeded. If it did, I'll give it a final tweak.

@thinkyhead

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jun 11, 2016

Shouldn't "disables" be "enables"?

Sure looks like it. Old typo, I guess.

@thinkyhead

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jun 11, 2016

plan_buffer_line

Incidentally, the current code uses planner.buffer_line().
It's always better to refer to the current code with me.

is the argument "e" in units of mm of filament?

No. It's in the current units – either linear or volumetric. Consider this line in planner.buffer_line

  block->steps[E_AXIS] *= volumetric_multiplier[extruder];

The volumetric_multiplier is simply 1.0 when volumetric is turned off.

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 11, 2016

Point taken - I got the latest bugfix - but it has a comment:

/**
 * Planner::buffer_line
 *
 * Add a new linear movement to the buffer.
 *
 *  x,y,z,e   - target position in mm
 *  feed_rate - (target) speed of the move
 *  extruder  - target extruder
 */

and the line you quoted

block->steps[E_AXIS] *= volumetric_multiplier[extruder];

is applied (indirectly) to the argument inside the procedure. So I'm guessing that in fact e is in mm. Correct?

@thinkyhead

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jun 11, 2016

Yes, I suppose that's right, after all. The e term is mm. I guess the volumetric multiplier is pre-figured so it can apply to mm.

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 12, 2016

Thank you.
The e input for Planner::buffer_line is in mm, unless volumetric is enabled in which case it is in mm^3 - which I take it is what you meant by "current units". And as far as I can tell, this is still true when INCH_MODE_SUPPORT is active.

To calculate steps (block->steps(EAXIS)) it is effectively (neglecting extruder_multiplier)
e * axis_steps_per_unit * volumetric_multiplier
volumetric_multiplier is either 1 or 1/filament_area_in_mm2

If I want to modify my documentation pull request to make additional clarifications, is that straightforward - or I wait for the current one to be approved? I have yet to learn about git.

@thinkyhead

This comment has been minimized.

Copy link
Member

@thinkyhead thinkyhead commented Jun 12, 2016

If I want to modify my documentation pull request to make additional clarifications, is that straightforward?

More or less. You make the changes and add a new commit, then you can simply git push to add the commit to the PR. You can also use git rebase -i to combine, squash, and reword commits, but you must then use git push -f to force-push the changes to your PR, because previously-pushed commits may be dropped and replaced.

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 12, 2016

I did the edit via the web interface - so I'll have to watch my git videos to understand what you are saying.

It's a matter of taste, but find the idea that a routine's argument could have different dimensions, let alone units, confusing.
If I understand the concept of volumetric extrusion and the use of filament diameter sensors correctly, one multiplies the slicer extruded length by a correction factor

required_extruded_length = (nominal_filament_diameter/measured_filament_diameter)^2 * (sliced_nominal_filament_diameter/nominal_filament_diameter)^2 * extruded_length_Gcode

I would have applied these dimensionless correction factors in one place so there is a clean separation between routines that use code units (now mm & sec) and those that live in user space.
Or if efficiency reasons require them in different places, at least apply each as dimensionless ratios, not multiplying by an area outside some routine and dividing by an area in another.

@edwilliams16

This comment has been minimized.

Copy link
Contributor Author

@edwilliams16 edwilliams16 commented Jun 12, 2016

I again used the web interface to clean up some of the configuration documentation. It looks like it worked, and will suffice until I figure out how to do edits in the Jekyl stuff I dutifully set up on my Mac.

@jbrazio

This comment has been minimized.

Copy link
Member

@jbrazio jbrazio commented Jul 16, 2016

Closing due to inactivity.
Please re-open this issue if still valid.

@jbrazio jbrazio closed this Jul 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.