Maslow Home Maslow Community Garden Newsletter

Buffering and making sure I'm up to date

So, I have a simple file that cuts pretty well except that MakerCAM, except that MakerCAM evidently decided that my 1/4" radius turns should be about 50 g-code commands (strangely enough, they’re actual “arc” commands, but not “just one arc.”

If it helps, I’d be glad to put my nc file into a github issue as an example of “communication is slower than I’d like”…

I’ve noticed that it slows down considerably while making those turns, so I figured it was a buffering issue… (raspi0w, cpu usage 84%) but if I turn buffering on in Maslow Settings, nothing works. If you press a jog button a bunch of times, it eventually errors out with SLED NOT MOVING, but it doesn’t seem consistent.

Which leads to question 2:
I have it pulled from github on the pi0w, and I updated it with git last night, but my Z axis dialog doesn’t look like the one in https://github.com/WebControlCNC/WebControl/issues/53 … even though it says the pull request was merged…

I’d love to work on this, but I want to make sure I’m starting with a known version… so my fixes can go in cleanly later;
git pull says “up to date” (source: https://github.com/WebControlCNC/WebControl.git) and
git status says “nothing to commit”…

so… why am I not seeing a new Z dialog?

Makercam is written in the fast disappearing Adobe flash, just saw yet another article about another browser that’s yanking flash support. Inventables Easel and Carbide3D’s Carbide Create are the two most common beginner choices for a little router I also work with. CC had a grid display limit until recently, it would work but not have a grid in larger workspaces.
It was recently changed to 96x96" or twice the Maslow’s cutting area.

Oh I know… I plan to move on, but I figured this was a perfect “NC file with problems”…
Ideally, the Arduino should have about 5-10 commands ready to go so it shouldn’t change speeds unless told to or it’s just not capable.

Err… Update: “Just not working” was because I forgot to plug in the power supply. The Pi0W is quite happily supplying power to the Arduino, but not the servo motors (egg on my face - just if it’s “unbuffered” it immediately says SLED NOT MOVING" and that prompts me to plug it in…),

I turned on Buffering, and even though it goes down to 26 from 127 during the run, it’s still very slow in the corners.

So… not sure if it’s a Holey Firmware issue or a Webcontrol issue…

1 Like

I’ll let one of the developers comment, but the planner in the current Maslow firmware isn’t very sophisticated. There is an ongoing effort to port the kinematics to grbl but I haven’t followed it lately.

After recently purchasing an ESP32 grbl board I’m hoping they’ll use that as a base. Getting it to work with a non-maslow Cartesian router is today’s planned project

1 Like

There is not currently any planner in the maslow firmware,it just executes
things directly.

There is a gcode optimizer that’s being worked on (I saw a couple posts in the
topic earlier today) try running your gcode through that and see how it does.

David Lang

1 Like

There’s a rough limit of around 10 GCode commands per second, which isn’t necessarily the same thing as the number of lines.

I wrote a ‘free-standing’ GCode optimiser / linter, which I’m still working on.
https://forums.maslowcnc.com/t/command-line-utility-to-clean-gcode/

I don’t have it doing arc to arc (G2, G3) deduplication yet, although I’ve had a go at it. It does do a lot of other path and general GCode optimisations though, so it still may be useful for you.

One of the big reasons for writing it is to try and reduce the number of commands generated by some overly finicky path fitting algorithms that different GCode generators use (Fusion 360, estlcam, etc.)

However, there is another bit of behaviour that could be happening here, although considering its MakerCam I’d say probably not. I’m pretty sure for Fusion 360 at least that there’s an option to get it to ‘slow down’ when going around corners, maybe MakerCam is doing that? (but again I don’t think so)

So, I went and tried several CAM programs and a lot of them did “tons of lines for the corners” (which surprised me… I didn’t think my corners were complicated; they’re a convex curve of a constant radius so…?)

MakerCAM does it, and so does Carbide Create.

ESTLCam makes them the way they should be (so I know what I’m buying next).

Looking at the file for Carbide Create, it’s sending lots of line segments instead of an arc…
The example “wrong bit” for MakerCAM is:

G1 X16.4729 Y0.447
G3 X16.485 Y0.4476 I0 J0.125
G1 X16.5419 Y0.4532
G3 X16.573 Y0.4603 I-0.0121 J0.1244
G1 X16.6258 Y0.4797
G3 X16.6491 Y0.4912 I-0.0432 J0.1173
G1 X16.6977 Y0.5217
G3 X16.7211 Y0.5407 I-0.0665 J0.1058
G1 X16.7613 Y0.5824
G3 X16.7787 Y0.6049 I-0.0899 J0.0869
G1 X16.8078 Y0.6535
G3 X16.8204 Y0.6819 I-0.1072 J0.0643
G1 X16.837 Y0.7375
G3 X16.8417 Y0.7613 I-0.1197 J0.0359
G1 X16.8473 Y0.8182
G3 X16.8479 Y0.8303 I-0.1244 J0.0121
G3 X16.8465 Y0.8489 I-0.125 J0
G1 X16.8381 Y0.9044
G3 X16.8353 Y0.9183 I-0.1236 J-0.0185
G1 X15.7851 Y4.8356
G1 X15.7204 Y5.0771
G1 X15.0992 Y7.3947
G3 X15.0959 Y7.405 I-0.1207 J-0.0324
G1 X15.0792 Y7.4508
G3 X15.0674 Y7.475 I-0.1175 J-0.0427
G1 X15.041 Y7.5167
G3 X15.0272 Y7.5346 I-0.1056 J-0.0669
G1 X14.9939 Y7.5707
G3 X14.973 Y7.5888 I-0.0919 J-0.0848
G1 X14.9327 Y7.6166
G3 X14.9148 Y7.6269 I-0.071 J-0.1029
G1 X14.8704 Y7.6477
G3 X14.8459 Y7.6562 I-0.0531 J-0.1132
G1 X14.7987 Y7.6673
G3 X14.7737 Y7.6706 I-0.0286 J-0.1217
G1 X14.725 Y7.672
G3 X14.7004 Y7.6702 I-0.0036 J-0.1249
G1 X14.6517 Y7.6619
G3 X14.6406 Y7.6594 I0.0211 J-0.1232
G1 X14.1573 Y7.5303
G3 X14.1468 Y7.527 I0.0323 J-0.1208
G1 X14.101 Y7.5103
G3 X14.0768 Y7.4984 I0.0427 J-0.1175
G1 X14.0351 Y7.4721
G3 X14.0172 Y7.4583 I0.0669 J-0.1056
G1 X13.9811 Y7.425
G3 X13.963 Y7.4041 I0.0848 J-0.0919
G1 X13.9352 Y7.3638
G3 X13.925 Y7.3459 I0.1029 J-0.071
G1 X13.9041 Y7.3015
G3 X13.8956 Y7.277 I0.1132 J-0.0531
G1 X13.8845 Y7.2298
G3 X13.8812 Y7.2047 I0.1217 J-0.0286
G1 X13.8799 Y7.1561
G3 X13.8798 Y7.1526 I0.1249 J-0.0036
G3 X13.8816 Y7.1314 I0.125 J0
G1 X13.8899 Y7.0828
G3 X13.8924 Y7.0716 I0.1232 J0.0211
G1 X14.0849 Y6.3538

vs
simply

G01 X1.00456 Y10.33524
G03 X1.46134 Y10.07152 I0.36179 J0.09921
G01 X1.94825 Y10.20199

[The coordinates aren’t apples-to-apples because everybody likes to pick their origin]

Anyway… solution found (and since I can specify enter/exit in EstlCam, I don’t need tabs as much as I used to, so even better), but… if the devs want a nc file that “is slow but ought not to be”… I’ll be glad to upload it [here or github].

Please do - here or Github - I like to fling different nc files at my code to see what it does

check your original drawings, can you make the corners just be shrp joins of
straight lines rather than having any curves on the corners?

David Lang

Guitar stands: makercam.nc (58.4 KB)

Maslow toodles along fine… until it hits a curve. Then it goes into hurky-jerky-I-can-do-this but slowly mode.

That’s typical for lots of tiny movements.

David Lang

What’s arc deduplication?

I sort of remember remember you mentioning line segment to arc conversion (coffee’s still kicking in), which is one of my favorites, but deduping is a head scratcher

I’ve been distracted lately getting the Mooselake manor sorted out after the knee induced 19mo abandonment (the swamp rats took good care of the Maslow on the wall) and might have missed them.

Too many cam programs will raise to safe height and then plunge back into the next layer in the same location and/or plunge with a lot of air cutting (G1 instead of G0 to the safe height or actual material contact). Did you have a chance to look at this behavior?

Hat off to you. I’ve talked about taking a stab at a gcode optimizer while muttering at poor code for many years, you actually followed through and did it. Greatly appreciated!

I have the grbl_ESP32 Zenbot Mini ready for a test on this rainy day, will see what the optimizer does with it, assuming the ZB doesn’t smoke or break something else. It’s in the Mooselab, hopefully the swamprats haven’t ventured down there

It’s where you have two arcs of the same rotation (G2 & G2 for instance) and their respective centers and radius (I & J) are within your defined tolerance. They can be converted to a single G2.

This one is on the hit list, because it “should be easy”. I needed to get the logic and maths heavy linear to arc, and arc to linear conversions done properly first.

Well @Thormj’s code sample provides me another interesting case to tackle. This kind of stuff:

G1 X16.4729 Y0.447
G3 X16.485 Y0.4476 I0 J0.125
G1 X16.5419 Y0.4532
G3 X16.573 Y0.4603 I-0.0121 J0.1244

Alternating G1 and G3 (or G2). This is path fitting gone mad.
Definitely something for me to add to the optimiser code.

For example, that first G3 in the code sample above is a point to point distance of just 0.012" (0.31mm). I’m thinking of converting all such very short arcs to lines (change them to G1 and throw away I, J & K), and then process the whole lot with a linear to arc deduplication and let it recalculate things properly.

Time to write up an issue on my repo I think …

And here’s what my GCodeClean came up with after I added some new functionality to convert very short arcs (G2, G3) to straight lines (G1).
GuitarStand-gcc.nc (24.6 KB)

I’ve only looked at this in WebControl, I haven’t tried cutting it.

I’ll try that tonight and let you know how smooth the motion is.