MakerCAM v Carbide Create

an open source, web based CAM package that works!

MakerCAM v Carbide Create

Postby GurneyHalleck » Wed Mar 13, 2019 9:11 pm

I literally just noticed MakerCAM while browsing this forum.
Is it still usable? I notice no posts since November.
I have a few issues with Carbide Create, but it seems to produce useable G-Code.
What advantage does MakerCAM have over Carbide Create?
This is all in my mind right now......I just do what the voices tell me.
GurneyHalleck
 
Posts: 15
Joined: Tue Mar 12, 2019 1:24 am
Location: Chicago - Southwest Suburbs

Re: MakerCAM v Carbide Create

Postby WillAdams » Thu Mar 14, 2019 12:14 am

MakerCAM's advantages:

- produces G2/G3 arcs
- drill feature
- Flash, so cross-platform, and a much smaller executable
- more capable Bézier curve tool

Carbide Create's advantages:

- doesn't require post-processing to shorted decimals
- local, stand-alone install
- V carving
- texture toolpaths
- 3D previewing
- support for ball-nosed endmills

It would be nice to get MakerCAM actively developed --- the idea would be for someone to port it to node.js or something similar.
Shapeoko 3XL #0006 w/Makita RT0701 Router w/0.125″ and ¼″ Elaire precision collets
Nomad 883 Pro #596 (bamboo)
WillAdams
 
Posts: 8476
Joined: Mon Apr 09, 2012 6:11 pm
Location: Pennsylvania --- south of the Turnpike, East of US-15

Re: MakerCAM v Carbide Create

Postby GurneyHalleck » Thu Mar 14, 2019 4:00 am

Thanks for the info.

Looks like MakerCAM is something I will be investigating further.

I wish I had the talents to develop something like MakerCAM. It's above my pay grade.
This is all in my mind right now......I just do what the voices tell me.
GurneyHalleck
 
Posts: 15
Joined: Tue Mar 12, 2019 1:24 am
Location: Chicago - Southwest Suburbs

Re: MakerCAM v Carbide Create

Postby GurneyHalleck » Thu Mar 14, 2019 6:38 pm

Regarding G2/G3, I recently created a .svg file with a circle and an arc (half circle) surrounded by a rectangle.

I noticed that the G-Code Carbide Create produced lacked the G2/G3 commands. I was surprised, as it seems to me that the information to produce a valid G2 or G3 code string was included in the object parameters in the xml code.

I would love to look under the hood of makerCAM.
This is all in my mind right now......I just do what the voices tell me.
GurneyHalleck
 
Posts: 15
Joined: Tue Mar 12, 2019 1:24 am
Location: Chicago - Southwest Suburbs

Re: MakerCAM v Carbide Create

Postby WillAdams » Fri Mar 15, 2019 1:20 pm

Looks like there's a new MakerCAM: https://github.com/makercam

The Flash based program at makercam.com was forked from: https://github.com/Jack000/PartKAM and I don't think the source ever deviated much.


If you'd describe the sort of work you wish to do, and how you wish to approach it, there might be a better option we could suggest.
Shapeoko 3XL #0006 w/Makita RT0701 Router w/0.125″ and ¼″ Elaire precision collets
Nomad 883 Pro #596 (bamboo)
WillAdams
 
Posts: 8476
Joined: Mon Apr 09, 2012 6:11 pm
Location: Pennsylvania --- south of the Turnpike, East of US-15

Re: MakerCAM v Carbide Create

Postby GurneyHalleck » Mon Mar 18, 2019 1:15 am

Regarding what I want to do, I'm brand new to this. Don't yet even have a machine. But I want to learn about the entire process. I have a 6" tall 2-story bombed out building for my wargaming table that I made from cardboard and spray painted. I want to cut this out and build it in plastic. Try to engrave some bricks or stones onto the walls. I'm intrigued by toolpath generation, and looked into the G2/G3 arc codes.

I created a simpler .svg file with a frame and a 10 mm circle object centered at 140, 40. After the G0 command to position the tool to start carving the circle, Carbide Create produced about 200 G1 line segments to complete the path around the circle. MakerCAM produced 32 arc segments using the G3 command. HumanCAM did it with one G2 command: G2X150.0Y40.0I-10.0J0.0

I have some offset problem, since Carbide Create placed the circle at 140, 36, and MakerCAM placed it at 140, 60. I picked clockwise. MakerCAM and Carbide Create went counter-clockwise. I'm baffled why MakerCAM created so many segments, and with so many different 'arc center points'. The center point was 'given' in .svg file, and the 4 circle vertices must have been calculated in MakerCAM since they are hard coded with no fraction. I downloaded PartKam and started looking through the code. Looking first for where the .svg file is parsed. And I realized that I did not know how to get the equation for an ellipse from the sgv code. Stuck there now.

Relevant svg code:

<g
inkscape:label="Layer 1"
inkscape:groupmode="layer"
id="layer1">
<rect
style="fill:none;fill-opacity:1;stroke:#6d0f0f;stroke-width:0.2;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="rect49"
width="168"
height="72"
x="24"
y="201" />
<circle
style="fill:none;fill-opacity:1;stroke:#6d0f0f;stroke-width:0.2;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
id="c+140+40"
cx="140"
cy="237"
r="10" />
</g>
Attachments
Hand-Code-G2.nc
Modifed to use the G2 command
(664 Bytes) Downloaded 2 times
This is all in my mind right now......I just do what the voices tell me.
GurneyHalleck
 
Posts: 15
Joined: Tue Mar 12, 2019 1:24 am
Location: Chicago - Southwest Suburbs

Re: MakerCAM v Carbide Create

Postby WillAdams » Mon Mar 18, 2019 11:06 pm

MakerCAM created multiple paths because it has to approximate the Bézier curve using arcs.

Also, it's my understanding that it's preferred not to make a full circle in G-Code because that can be ambiguous to certain G-Code interpreters.

I would suggest using a 3rd party previewer such as CAMotics or GrblGru to test things out. Also note that Carbide Motion may not accept some ways in which folks hand-code G-Code.
Shapeoko 3XL #0006 w/Makita RT0701 Router w/0.125″ and ¼″ Elaire precision collets
Nomad 883 Pro #596 (bamboo)
WillAdams
 
Posts: 8476
Joined: Mon Apr 09, 2012 6:11 pm
Location: Pennsylvania --- south of the Turnpike, East of US-15

Re: MakerCAM v Carbide Create

Postby Xaracen » Tue Apr 16, 2019 4:03 pm

Just read this! I was unaware that others were still looking to update Makercam. I started doing this a couple of months ago, and I've no idea how to use github. I found a free utility called FreeFlashDecompiler which lets me replace ActionScript3.0 files and code snippets and recompile to a .swf file. It has its quirks, but I now have a good workflow, and more to the point a working updated version.

It's called FlatCam and it rectifies some of makercam's issues, primarily the hard-coded tooling defaults, and a few other things that were bothering me.

I have no previous experience with OOP or ActionScript, and I know I'm just tinkering around the edges, but as I was getting more familiar with it I saw other possibilities. The following is extracted from a working diary and tidied up.

Changes to Makercam.swf incorporated as FlatCam.swf/exe

1. Defaults to metric, instead of imperial. I'm a Scottish engineer in Europe, my choice. :D

2. Single set of hard-coded CAM tooling defaults with a more flexible approach to unit change. For some parameters, eg tool-diameter, converting to another unit rarely has sensible results, so unit change just changes the title, eg a 0.5mm tool diameter becomes 0.5", so not directly comparable, but there's no good reason they need to be, it's rare to find a metric bit that's the same physical diameter as an imperial one.
Cut-depths can be any value so again we just change the unit title. But for others, like the feed/plunge rates, the unit change uses a suitable conversion factor, not necessarily 25.4 but 25, so that 500mm/min becomes 20"/min, and vice versa.
My choices don't suit you? see items 3 and 5 :D

3. New Edit dialog 'Set Defaults'. This lets you edit the current CAM defaults for the session without affecting any existing toolpaths, but new tool-paths will see them as their initial values. The hard-coded defaults will return when you reload FlatCam. But you don't need to re-edit them all over again, see item 5 :D

4. Edit Preferences now has extra settings to enable/disable some features.

5. Current default/edited CAM parameters can be saved along with tool-path details in a saved svg, if enabled in preferences. When you load the svg again, the saved defaults become the active ones. You can now have project-specific defaults! The downside is that Flash Player disallows automatic file loading/saving so you need to manually do the save or load. The upside to the downside is that you choose the name of the file when you save or load, so you can have multiple settings files, one for every project if you want.

6. M, T gcodes can be excluded from Gcode export, enable/disable in preferences. Benefits some grbl/cnc users, (inc me). This setting is saved with the svg settings feature.

7. A new setting is a finish Z-height parameter in 'Set Defaults'. This sets the height of the final z-lift at the end of the Gcode file. That used to be the safety height, but it usually suits me to lift it up well clear of the job so that I can get easier access to the finished work-piece. A 1mm safety-height isn't useful as a finished height of 20mm.

8. Decimal precision applied to Gcode export and Dialog text fields, no. of digits is set in preferences, and saved with the svg settings feature. I know that other makercam variants have something similar.

9. Page-Up, Page-Down keys zoom the display in and out in addition to [+] and [-] buttons and the mouse-wheel.

10. Home key centres the grid origin in the display. Ctrl+Home sets grid origin to bottom left of display. A lot of my cnc jobs start with x, y, z zeroed on the centre of the piece.

11. Typing space characters in Dialog text-fields no longer invokes Hand cursor.

12. Unit change now includes previously overlooked parameters, eg. plungerate.

13. If the save settings option is ticked an svg file can be saved even if no paths exist, ie a settings only svg. If the save settings option is unticked, the save svg menu reverts to original Makercam mode so no paths then no file save.

All of the above are working.

Future plans or issues to deal with.

14. Identify and correct issue with pocketing concentric ellipses/circles. ** well over my payscale, too!! This was one of the reasons I decided to update makercam if I could, as mentioned in a couple of other posts. It is going to require a lot more in-depth understanding of the code to fix than I suspect I can cope with, but thankfully I have a couple of easy workarounds that can be made in the drawings before exporting as svg, so this is less of an issue now. Also, others are looking at this too.

15. Amend circle and ellipse creation to correct the hatching glitch, and might possibly help with items 15 and 16. **low priority as I only use the makercam drawing functions for testing code changes, to make sure I haven't broken anything. I note that if you export makercam's own circles and re-import them the hatch glitch vanishes. The glitch has no effect on the Pocket bug as far as I can see.

16. Svg issues re width, height, and viewBox. A 1cm circle being exported from Makercam and reimported can fail to be rendered because the height is wrongly set at 0cm. SVG spec says that a zero width or height must not be rendered.
Makercam isn't correctly identifying the extents of the saved paths, nor correctly positioning them if they are rendered.
Not fixed properly, but a cheap hack is in place and works. **low priority, same as 15.
Shapeoko v1 #????
500mm Y-slides with dual Y-steppers
375mm dual X-axis gantry
150W DC ER11 Sable2015 spindle
conductive probe via spindle shaft/toolbit (can probe while spinning!)
Arduino Uno running grbl v0.9i with grblShield v4.
Xaracen
 
Posts: 120
Joined: Sat Apr 20, 2013 7:41 am


Return to MakerCAM

Who is online

Users browsing this forum: No registered users and 0 guests