Maslow Home Maslow Community Garden

Easel vs MakerCam Software Discussion

#1

Hey all,

Been using makercam until this week when I decided to give inventables Easel software a try … and well …
its seems a little to simple in some ways. But much more robust in other ways.

I also like the fact it tries to give you a time estimate… even though its way off when cutting with maslow.

The time estimate is something I would love to see in ground control… and a timer of how long the cut has been running.

MakerCam
Can be very specific about the cut paths you want to use.
The ability to save SVG’s out of makercam is a great tool when doing multiple cut paths with a bit swap in between.

Easel
Significantly better layout and tools.
A detailed cut preview.
V-Carve.
More bit options.

Has anyone come across an accurate way to estimate the time a cut takes?
Have people been using Easel?
Am I the only one that wants to pull his hair out when using makercam?

Would love to hear anyones thoughts on their cad/cam software they use with the maslow.
TALK TO MEEEEEEEE hahaha

#2

I also use Easel as I also own an X-carve, but use Easel for both machines. I also purchased Vetric Vcarve Pro. Very happy with this one also, but expensive. I have yet to complete and cut a project with Onshape or Fusion 360, but that is what I am working on now. Fusion has video lessons I have been going thru.

#3

hmmm very interesting.

I havent head of Vetric before, but it seems like it could be a good option.
Looks like a full blown software.

I’m not against paying for something, I just want to find a program that can accurately give me a time estimate. Thats my number 1 request out of a software.

When 3D printing time plays a big role … I’ve only had my maslow for 4 weeks … but quickly learning this process is also very time consuming

#4

Time estimate is not available with maslow. I would say you cut something smaller from Easel with the Maslow, and figure out your time warp from the estimate using Easel, vs, using the Maslow. Then cut some other small item and see if your formula worked. Of course it is all dependant on how many bit lifts, position moves, etc. :thinking:

#5

Yea I guess thats what I’m saying we should work on a solution for.

Its a pretty simple calculation. time = distance/speed … all things that should be easy enough to determine.
The only thing that seems like a variable is the z axis pitch.

Im about to finish my contract in 4 weeks … so after that I’ll do a dive into understanding the gcode and see if I can come up with something. Hopefully this thread gets some traction and someone from this brilliant community is also hoping for a time estimate feature.

Hell even a more accurate % complete would be amazing.

#6

not completely, you can find how long it should take, but there is a per-command
delay that gets added to this, so if you have tons of tiny cuts, it can take
much longer than the claimed value

Also, if your g-code says to move at 100 inches/min and the machine only moves
at 30 inches/min, the estimate will be based on the g-code, not what the machine
can actually do.

there is an online g-code simulator that will show you the cut and give you a
time estimage.

#7

I know it’s been suggested. One of those addons that will come with time when someone with the know how can get it done. :smiley:

#8

Interesting, thanks for the comment.

Certainly going to give some deeper thoughts to this when I get some time. I still havent found time to learn/understand gcode. So thats gotta be the starting point … but this is my new winter goal. Get time estimates for maslow.

I just ran the gcode though the simulator … it said 13h … pheww… so this v-carved sign will probably take closer to 20h hahah

#9

also keep in mind that our Z axis is very slow, which can then slow everything
else down as well.

David Lang

#10

I’d like to see Ground Control support a timer also. It would be interesting if it could spit out a “summary” at the end of the toolpaths, g-code, time of cut, and data like that for later use.

I’d love to see GC allow for individual bit selection and total cut time on each. If a person was to label each of their bits, GC would then tell you “Oh, that 1/4” single flute upcut bit has a total of 28 hours on it". Of course you could keep track yourself, but the more stuff GC can do for me, the happier I am!

Back to the discussion at hand, I am exclusively an Easel user. I tried to learn some of the other programs and despite my relative tech savvy compared to many, I haven’t been successful with other programs. Easel is pretty simplistic but it seems like there are workarounds for lots of common tasks. Once you learn how to use the grid and shape sizes to accurately measure and place parts, it is pretty good.

I was going to suggest that you keep track of estimated vs. actual cut time, the more data points you get the closer you’ll get to a true estimate.

#11

This would be extremely usefull! Wish I knew how to program to accomplish it. I wonder if paying a phyton cnc code developer would help speed up useful implementation of these sort of issues. Go fund me could be set up and people can chip in to help . Just an idea, Open source volunteers might not have the time to figure it out?

#12

And there is an excessive amount of z action from makerCam! :bow_and_arrow:

#13

One way to reduce the z Action is to make separate profiles for each outline or pocket. That will cause makercam to group all the z movements for an outline or pocket together instead of grouping all the cuts of a particular depth and jumping all over the board. Then create the gcode for all those profiles together, and each one should finish before the z rises and the nit travels to the next.

#14

Is there a similar way to group pocket operations in easel?
I’m doing 3mm step down and first it does the internal part and then an outline (on the inside) which it does for all steps.
It would be useful to do all the internal movements before doing the outline

#15

Yes I have learned that, but it still seems to take a pass in a pocket, lift, move over, lower, etc. and move to random places in the pocket even though nothing would be in it’s way. any tips for that?

#16

CAD and CAM programs deal with each entity separately. It sounds like the pocket in question might have been drafted with separate lines instead of as a single object. Makercam would raise the bit to move between those lines even if the line ends are very near each other.

#17

Do we know why? Of two identical ellipses (in my "first posted project more to come " projects post on the guitar pick trays) one of them did it’s first pass without lifting the z. The rest of the passes on both were slower than molasses. (MakerCAM) :upside_down_face::warning:️ :man_shrugging:

#18

That ellipse sounds like it was a single entity. The other one sounds like it was mage up of many separate pieces. Can you post the SVG file?

#19

Here it is:
Pick%20Tray%20design

Hope you can figure something out about this.:pray:

I’m also going to take this opportunity to gently ask anyone who can help with my Firmware and Ground Control synchronization to visit for my sake. I am mentioning only to not hijack or interrupt.

Thank you. :bow_and_arrow:

Edit: This may just be more proof of computer problems but I promise I uploaded an svg up there.:man_shrugging:

#20

Pick%20Tray%20design
Pick%20Tray%20design