-
Notifications
You must be signed in to change notification settings - Fork 142
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
Consider optimizing stepper speed and/or making pen speed constant #55
Comments
I can see where this comes from. I suppose the question is whether the speed rate there is to set the maximum speed at which the steppers turn, or to set a speed that the pen should travel at. The present method gives "constant" pen speed, regardless of the angle that a line is being drawn. There are some use cases where this does potentially make a difference. One could certainly argue that it would be optimal, for example with the diamond engraving tool or electro-kista, to have a uniform drawing speed. On the other hand, the "constant" pen speed is anything but, right now, because of projection mapping-- especially towards the poles of the object. It does make pen lines have uniform thickness near the equator, though. Perhaps the optimal solution would be to try to optimize the pen speed to be constant over the entire surface, compensating for the fact that more steps are required at the poles. |
I get it now - thanks for broadening my perspective on the eggbot! I'll close the issue tomorrow, unless you want it left open as a reminder of the possibility of addressing the variability of the "constant" pen speed - particularly approaching the poles as it affects engraving and wax deposition. |
Yes; please leave it open. It's good food for thought on future speeds. I'll edit the title to reflect. |
One possible UI interface for this type of thing: We could use the "Enable engraver" selection box to enable the constant-drawing-speed mode, potentially with correction for the map projection. |
Oooh, that sounds like the perfect UI method, no additional user input required! |
Eggbot.py uses the customary Euclidean distance measure to calculate the time required for each move, using plot_utils.distance. Because of this, a move of delta x = delta y = n is calculated to take about 41% more time than a move of e.g. delta x = 0, delta y = n.
"Of course" you say - the distance is 41% greater! But wait...each stepper is still only moving n steps!!
The increased time has only resulted in decreasing the stepping rate of each of the two orthogonal stepper axes. Thus a movement to a point at 45 degrees will have the stepper motors moving at only about 70.7% of the user-specified stepping rate.
Since the two axes of movement are orthogonal, could not each stepper move independently based on the user-specified steps per second, with the "larger-number-of-steps" axis being the ruling factor? If this were true, then the proper distance measure would be
max( abs(x), abs(y) )
rather than( x^2 + y^2 )^.5
I think the proper name for this metric is a "maximum metric" - it's (very) vaguely like an inverse taxicab metric.
If we assume that a typical plot has a relatively uniform distribution of movement angles, then the plotting time improvement from changing to this metric would be about ( pi/4 - sin( pi/4 )) / ( pi/4 ) or about 10%. A single test of a randomly-chosen eggbot svg file resulted in a measured improvement from 638 seconds to 578 seconds, = about 9.4%.
I readily acknowledge that I am not cognizant of all the factors that went into the design process,
but am just wondering out loud if this distance measure is perhaps a reflex of our conventional Euclidean impulses, rather than a considered decision.
The text was updated successfully, but these errors were encountered: