Just wanted to create a reference here in the forum to some work that has been going on with electronics and firmware around the MaslowCNC. This info may interest folks that are looking for a little more out of their machine and GRBL compatibility. May be a platform to build on for a 2nd generation or Pro-version. All the available information can be found at:
MaslowDue
8 Likes
excellent contribution, keep going
2 Likes
yes, it was mentioned on the fb page if anyone wants to see it in action.
Being able to accelerate/decelerate in/out of corners and other benefits would be really great!
2 Likes
So the original is not grbl?
Is this in conjunction with the coordinated xyz (grading) capability or are we already able to do that?
Thank you for your patience and your answers as I am still just at the stage where I’m trying to get my new computer to accept Ground Control to merely get back to cutting! This sounds very exciting and promising 
.
Isn’t that a CAM issue?
I could be mistaken, but I thought changing speeds during a cut was beyond the ability of the current Maslow.
I am pretty sure I’ve been able to do it. It is a setting in HSM CAM for Inventor, and I do notice that with the “cut slower in corners” setting enabled, the Maslow takes quite a while getting around tight corners. I haven’t really compared it with that setting disabled on the same part, though.
Changing the speed that the Maslow is moving should be just a matter of setting the speed with an “F” command in the g-code.
Yes. The GRBL core coordinates all 3-axis, so now full contouring is possible.
1 Like
Thanks for the info. Do you know how many people are using it?
For the Maslow Due firmware, just me at this point.
2 Likes
This is awesome! Great work and excellent documentation!
3 Likes
This is awesome.
Based upon a review of the code, it looks like you consolidate all the calibration model factors into a single set of x, y scaling factors, correct? I don’t know much about GRBL, but if someone wanted to incorporate additional variables/factors, does GRBL allow for that?
Also, the choice of a Due over a mega is “due” to the need for more processing power, correct?
1 Like
Yes. The Due is required for a couple of things; more horse-power, and more timers.
The corrections all happen in the bottom of the system.cpp file. I am considering doing a matrix adjustment (LUT that uses 150mm grid over entire work area) but I have not set out to do so, and it leaves a little room for someone else to contribute. : )
Note that what ever you correct going in must be backed out. In GRBL, since the sender applications want to read the machine position back, you have to transform in both directions. (rectangular to triangular to rectangular). You will find the settings in settings.cpp and reporting.cpp and you can add as many things as you like – just leave the core GRBL stuff as it is.
2 Likes
That’s what my optical calibration model does. I’ve gotten distracted with other projects to focus on it more, but it does result in improvements.
Understood… I see you have separate routines for that as what you have is pretty basic trigonometry. The stock firmware does the forward calculations through an iterative function that calls triangularInverse until an error is minimized. I assume its because there’s no readily available inverse of triangularInverse.
Is there a certain range of $xxx that would be best to use for additional variables?
No certain types, both float and int are supported. As far as address $xxx, I think it is a matter of just wedging stuff in whereever you find it. You can also create special storage in the eeprom.cpp module (as I did with saved machine position.)
1 Like
you can fake it in CAM (breaking one g-code line into several with different
feed rates), but the feed rates change abruptly between line segments.
grbl allows you to set an acceleration limit and a max cornering value and ramp
speeds up and down smoothly to keep the cornering forces within range (depending
on the angle of the corner, etc)
David Lang
2 Likes
It is, but that’s due to the limits of the firmware, grbl doesn’t have that
limit.
David Lang
1 Like
So the original is not grbl?
no, we try to be grbl compatible, but it’s not grbl
Is this in conjunction with the coordinated xyz (grading) capability or are we already able to do that?
we should already be able to do that.
On Tue, 19 Mar 2019, Madgrizzle via Maslow CNC Forums wrote:
The stock firmware does the forward calculations through an iterative function that calls triangularInverse until an error is minimized. I assume its because
there’s no readily available inverse of triangularInverse.
That’s correct, nobody has been able to define simple calculations that work, so we have to take the iterative approach.
New question, does the due have the same problem with floating point numbers (single precision only), or are you able to use double precision?
Due handles doubles just great!
1 Like
good to hear, on the larger workspace of the maslow, single floats start running into limits.
how do you handle calibration?