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

mathematical issue #284

Open
petaflot opened this issue Aug 19, 2024 · 7 comments
Open

mathematical issue #284

petaflot opened this issue Aug 19, 2024 · 7 comments

Comments

@petaflot
Copy link

The idea is to write a tool to get the best jerk and acceleration values at a given height for a machine.

I tried ChatGPT 4o but it proved to fail repeatedly in the most obvious and absurd ways ; since I'm not a math wizard I was hoping someone here could help...

jerk_acceleration_velocity_position

@GaylordLivingston
Copy link

GaylordLivingston commented Aug 19, 2024 via email

@petaflot
Copy link
Author

I am not sure I understand all you want and why, but here are some elements of response. Since this is a purely mathematical question I fail to understand how all these elements matter, I will try to answer my best and if you lack information feel free to ask (and I will not be upset if you don't read all the info I provide)

  • machine is a heavily modified CR10S Pro v2, not much is left from when I got it. Frame and steppers are one thing that remain.
  • so far it is independent of material, cutting tool or extrusion, soldering or else : the idea is to get values for max accel and jerk (and possibly velocity, but this is secondary) and eventually - quite a fundamental I would say - max frequency the machine can tolerate without shaking too much. When printing/cutting/soldering, we're usually below these values anyway.
  • I don't really want to have those values set "per job" (this is way overkill for now), but per axis (and possibly per Z-value (or other of non cartesian, if applicable, depending on the machine configuration)
  • I mentioned frequency : based on the max jerk and accel values, providing we reach max velocity, the frequency is a consequence of those parameters, somewhat like the frequency of a pendulum depends on the value of the local gravity and air resistance. it's a sort-of obscure relationship but I believe it can provide decent estimates. If you take ie. "static" (not vision-based) input shaping this will depend on the height at which the gantry is standing, and (if the bed is mobile) on the shape of the object but we'll ignore this for now (so NOT job-based, too much work for now and personally I wouldn't build a machine with a moving bed for objects that are not flat)
  • The idea is really to set-and-forget, meaning run this test once, figure out the max tolerable values (maybe one set for quality prints and another for fast prints) and keep them for a lifetime (unless the gantry is modified to be more rigid)

in case you want to know more, there is a (needs update, but an issue prevents me from updating the website) https://www.engrenage.ch/i18n/blog/whale-printer/ (for the machine) and more on [a project I'm working on[(https://www.engrenage.ch/i18n/projects/superslice/) that yields super complex parts that cannot be obtained with a regular slicer (there is this prototype I would need to print whose gcode file is around 600MB in size, and this is just the beginning ; the details are so intricate that for full scale models it simply makes no sense to save the gcode to a file and then print it, rather pipe the gcode to the machine as it is generated). more to read here

@GaylordLivingston
Copy link

GaylordLivingston commented Aug 19, 2024 via email

@petaflot
Copy link
Author

petaflot commented Aug 20, 2024

@GaylordLivingston actually I'm sure you can help: max_jerk, max_accel and max_velocity are set by the user, so let me try to rephrase (this is on Marlin):

  • move the toolhead at (x0,0)
  • set max_jerk with M205 Xj
  • set max_accel with M201 Ta (making sure values set with M204 are not exceeded, increase that first if required)
  • set max_feedrate with M203 Xf
  • now, move the toolhead to (x0+x,0) so that the toolhead reaches max accel a with max jerk j (as per 1) until it reaches max feedrate f (with then zero acceleration), then immediately decelerate (not exceeding max jerk j nor max accel a (absolute values obviously) until the toolhead is at a complete halt ; with these constraints, there are a minimum time and distance required for the move. distance is to be set with G0 X(x0+x) Ff, the time required is a consequence of motion planning.

if it is too complicated to maintain a slope in the acceleration at the middle of the move (which is expected to be quite short), then it is tolerated that the central portion (of infinitesimal length) of the move is done at constant speed with zero acceleration, as shown in the first graph of 1 (actually, with a "symmetric" deceleration phase)

  • move the toolhead back at (x0,0) with safe values for jerk, accel and velocity
  • repeat the above procedure a number of times
  • if the stepper/driver cannot cope with the high jerk/accel/feedrate values, then - after a number of iterations - the toolhead will end not at (x0,0) but at (x0+xd,0) ; if xd is non null, then we have lost steps and we must decrease one of j, a or f.

does this make it more clear?

the initial ChatGPT prompt is the image I posted above, and then trying to refine it by emphasing on the constraints ; not once did it manage to produce a graph that had a smooth curve for the jerk, it frequently showed a graph with only positive acceleration yet velocity that would start at zero and still drop to zero, graphs were the position showed signs of "teleportation" (instant position changes), and so on...

Footnotes

  1. https://github.com/synthetos/TinyG/wiki/Jerk-Controlled-Motion-Explained 2

@petaflot
Copy link
Author

FYI, here are the full ChatGPT logs:

https://chatgpt.com/c/d461f997-4cc9-4e5f-96f2-9a24d9e3c771
https://chatgpt.com/c/560cc9fa-85f8-42c1-9cca-581b5522305b

I still fail to understand how people manage to find LLMs so great.. I rarely get useful answers :-S

@GaylordLivingston
Copy link

GaylordLivingston commented Aug 20, 2024 via email

@petaflot
Copy link
Author

Warning: Operating at or near the physical limits of the hardware will likely cause occasional errors in the move.

this is precisely the idea: compute the shortest path required too achieve max jerk, max accel and max velocity in order to tackle those physical limits, and therefore find out experimentally what these limits are

It may be simpler and cheaper to send your project to someone else who specializes in the process you need

This is actually what my job is about.

Begin by clearly articulating the desired result or process. This could include the specific tasks the machine needs to perform, the level of precision required, the speed of operation, and any other critical outcomes. Understanding the end goal will guide all subsequent decisions.

I am not building a machine, but a family of machines, as well a a set of procedures to physically test and tune the hardware.

I still fail to understand why you need so much information about the machine when what I seek is the answer to a purely mathematical, hence abstract, problem. At least, with all the details you provided, I know we are on the same wavelength regarding the intricacies of the entire process : however and as stated above, the answer I seek is purely theoretical and does not depend on the machine itself ; it is only about solving a 6th order differential equation.

If you are not able to answer, this is OK. Then I will need to either find someone else who is familiar with such equations and can solve it for me, and/or read and reverse engineer the code in order to answer that straightforward and purely theoretical question: using the Jerk-controlled motion algorithm, what is the shortest path required to achieve a given velocity without exceeding a given acceleration and jerk.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants