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”…
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…
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
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.
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:
[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].
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.
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.
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.