FR - Allow G-Code Upload

Request: Allow G-Code generated in other CAM apps.

I’d love to use the tools and workflows I use with other CNC systems with my Goliath. It would be ideal to have a mode that allows me to run Slingshot as I would Mach3, to send my files directly to the Goliath for cutting.

CAMBAM, for example, is very inexpensive and deals with a LOT of the things I find to be a deficiency with Slingshot - better source file import, many better path generation tools, lots of libraries for materials and tooling, and a lot more basic CAD operations you can do inside of the CAM software.

CAMBAM is also highly customizable, so G-Code commands that might be specific to the Goliath could be included.

I do realize there may be path optimizations that are specific to the Goliath, but I’d consider this “use at your own risk” - and ideally Slingshot could analyze the g-code to make sure it’s not going against the operation of the machine and drive it off the work surface.

Something like “you can cut 4x8ft plywood provided you have 2ft of extra space on the top and left side”

Mach3 has a similar way to physically preview the cut by jogging around to make sure you aren’t going to hit a clamp, etc.


Hi, as mentioned, at the moment it is not possible to generate the G-Code externally and then import it as the one produced by Slingshot is tailor-made for Goliath. But we will definitely pass on your feedback to the technical department, thank you very much!

Hi, I have the same Idea or Problem so to say, but using Autodesk Fusion 360. The good news is that Autodesk allows to modify its g code generators using a subset of java routines. I’ve done such adaptions for different, older cnc machnines. If I had a description of the goliath g code commands I could try to program a specific g code generator for goliath. I would be open to provide it to the goliath community as an open source piece of software… Is there any change I could get a description of the g code commands goliath uses and/or some sample files?

1 Like

You can pull your historical g-code files out of the app folder. I haven’t been bothered to do the reverse engineering yet, but it’s not hidden.

Injecting modified g-code files back into the app shouldn’t be impossible, but it isn’t an easy “feature”

1 Like


It seems that you have an experience with CNC. You are voicing my same concern for many of the issues that I find desirable for Goliath use.

How long have you been using Goliath?

Is there any common knowledge on the dimensions of the wasteboard surrounding the board to be cut?


I received my Goliath back in June 2022 - so not long - but I have experience with CNC going back years.

I’m not an “expert”, but given my experiences with… every other CNC I’ve used (from Chinese no-names to enterprise-grade systems), this one is bunk.

Does it work? Kinda/sorta/sometimes. Is it frustrating? Yes.

I was about to rant about “no new software or firmware since May”, but I see new Slingshot software and Goliath firmware was released while I was at Burning Man. I haven’t had a chance to test the latest stuff.

Honestly the wasteboard dimension calculation seems… random to me?

My issue here is mostly a lack of transparency, months and months between software and firmware releases, and lack of any sort of support for doing anything with the system besides what we’re slowly spoon-fed.

I’ve attempted to visualize the g-code generated by Slingshot with open-source systems. The basic pathing is standard (from what I can see), but there is certainly custom positioning g-code that’s being sent to the Goliath that’s not a standard “rapid” move (retracted positioning)


Thanks for your reply. This goes a long explaining the replies or the lack thereof a reply in questions to

My guess is that they have their hands filled with a number of “New Product” details. I wish them the best possible success since I have had plenty of experience with shepherding new automated products in the biotech industry. It can be overwhelming at times.

The nature of the translation transport of the router cutter is a challenging one. It is not surprising that some of the more refined aspects of existing developed CNC tool path generation from CAD projects present hurdles to overcome from the basis of their design and how Slingshot has been engineered.

I am interested in how Slingshot how edits its paths to be able to understand how to plan for the wasteboard requirements for operation. As I begin to understand this it seems that the nature of the wasteboard is wrapped up in the positioning of Goliath.

I took a look at your CamBam CNC Software and was wondering if this might be used for Carbide 3D Nomad, Pocket CNC, or god forbid a CarveWright? I believe that I know your answer and look forward to your reply.


I’ve used CamBam on everything except a very high-end cabinetry CNC mill. If it’s a 2.5D mill, it’ll likely work as long as it doesn’t need custom g-code.

(And likely works for some custom g-code machines too, as you can very the “flavour” of g-code it generates.)

It’s worth the $70 or whatever it costs.

Generally I’ve used it to generate g-code for Mach3 machines.

I also find myself using it for basic CAD operations - it is “basic” things, but vastly more than Slingshot can do with CAD features. And better file format imports -AutoCAD files with proper scale!

Often I’ll make something in Illustrator and then bring it into CamBam as a vector, lay it out, add more simple CAD elements in CamBam (need a rounded corner box outline? easy!), set the CAM up (with the ability to order my operations and set tabs automatically or manually), and then use CamBam to virtually multiply it and nest it out to my workspace size for making multiples.

If I need to adjust the original, the nested duplicates automatically update.

“Export G-code” and load into Mach3. Done. (I’m sure a GRBL controller would be just as simple.)

There’s no reason the g-code for Goliath couldn’t be generated with a plugin for CamBam if we knew all the secret sauce and someone was motivated to do it.

Open Source everything, please.

If you prefer open source, I think you’re better off with the Maslow (Maker Made M2).

I mean, you’re not wrong.

But Goliath is novel and I think it’s an amazing piece of hardware if it just wasn’t hindered by the software and firmware.

I plunked down my money because I believe in it - and now I want to see it be the amazing machine it should be.

1 Like

I agree with you when you say it should be possible to manipulate the G-code before sending it to Goliath.

As a consequence, the projects in Slingshot should be splitted in a graphical part and in a G-code part making it possible to send stored G-code directly to Goliath.

But I don’t think everything should be open sourced in order to achieve this (although that would be nice).

I will gladly take closed-source that’s fully functional. :grin:

But given the cadence of releases and the speed of bug fixes, I think the project is in danger of becoming abandoned.

A project with dedicated hardware and we see releases every 3 months - with a huge backlog of major reported bugs? That’s verging on unacceptable.

If we had some open sourced code (or even full documentation of the backend and g-code), at least there’s a flicker of a chance that this could be carried on.

I’m certainly going to be spending some time reverse-engineering the ecosystem to see how it functions.

I’m FAR from promising anything, but I’d really like to at least have a basic grasp of how I could send my own g-code to the machine outside of Slingshot. Even a basic Python script to communicate with the robot would be a nice short-term goal for me.

I do have a vague sense that the manufacturer hasn’t locked this out, at least. But they haven’t made it easy either.

1 Like

Hah, I’d settle for some sort of an API that would allow me to communicate to the device. Hell, it might even take some of the load of off Springa. There are enough people here with the skillset and the motivation the contribute. We’re all here because we want the device to work


Hello Troy and blazingeclipse,

The current situation seems a bit worrying. I am only a novice expecting that as time passes with the use of Goliath I will become more proficient in the system’s use. On the whole, is the experience with Goliath been positive or more problematic?


@JimP - I mean, it’s hard to say.

The system is unique. There’s moments of absolute brilliance… but that’s shat on by the software deficiencies.

The hardware works reasonably well. There’s issues with dust collection in my experience - but also being able to pause the robot and clean it out, and it goes right back to where it should be? I wasn’t expecting how well that seems to work.

It’s all over the place. The portability is amazing. The cuts are reasonably accurate - although I have some doubts about it being as precise as a regular CNC. Perfect circle is smooth and round, for example, but the cut isn’t dimensionally accurate on X and Y. It’s “consistently wrong”, so that may simply be a code problem.

The lack of being able to use properly dimensioned files (like DXF) is infuriating. The CAM operations are weak - even lacking the ability to reorder your operations.

The problem in my mind is the coupling of the software with the hardware. You have zero options but to accept what we’re given.

Any other machine I’ve used has lots of ways to get to the end result, should you desire - apart from a very high-end system where it’s bespoke but “enterprise grade”.

I’ll always prefer a proper gantry system over this - but I also can’t put a ShopBot in a Home Depot 102L bin and cart it around. :grin:

3 posts were split to a new topic: Goliath Aternative: Cubio X