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

Improve acceleration algorithm #31

Open
peteruithoven opened this issue Aug 17, 2014 · 1 comment
Open

Improve acceleration algorithm #31

peteruithoven opened this issue Aug 17, 2014 · 1 comment

Comments

@peteruithoven
Copy link
Contributor

Peter: I was trying to speed up our lasercutter for engraving.
Using the following settings it engraves around the same speed as the native hardhard (Morntech).
motion.speed 800
motion.accel: 12000
But with a motion.accel more than 3000 it makes a complete mess of regular cut jobs. And even at 3000 and 100% it's clearly inaccurate (it can't make straight rectangles). At motion.accel 1300 30% it can be kinda accurate. At motion.accel 1000 1% speed starts cutting trough 4mm wood etc etc.
So there is a huge difference between what's a useful for engraving and cutting.

Anyway we can greatly increase the acceleration when it's just doing straight longer lines?
I know we can't make a exception for an engraving mode, because there is no (proper) engrave mode, VisiCut sends it as a regular cut job.

Jaap: At this time, accelleration and speed settings are for X and Y axis at the same time. The X axis can move much faster then
the Y axis, so it makes sense to have motion.accel and motion.speed seperately (and even Z?). Line cutting and engraving would then still use the lowest accelleration, but raster engraving can use the higher X settings.

Peter: Hi Jaap, I'm not fully following your post. You mean that acceleration and speed settings for X and Y axis are always the same? You think we should have separate motion configurations per axis?
The X axis can be faster because it's motor has to move a much smaller piece of the frame than the Y axis?
Good point, that sounds like something I might even be able to implement.

How does a separate motion configurations make sure line cutting and engraving use the lowest acceleration? Because I don't believe the hardware knows it actually engraving something.

Reinoud: Well, a cutting movement is always `just' a move from XY to X'Y' with the laser either on or off where as its engraving its actually generating a very fine pulse train representing the bits. Or is the engraving implemented as a heap of linear movements of say a few steps with the laser on or off?

@peteruithoven
Copy link
Contributor Author

One way of improving the accelleration might be to update to the latest GRBL. But since it looks like we changed grbl to enable laser control this is quite a task.

Last time I researched this there where no up to date NXP LPC ports of GRBL. Maybe Smoothieware (firmware for the Smoothieboard) uses a newer version, at least it's also for lasercutting.

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

1 participant