Interesting: The folks at ShopBot have open-sourced their alternative to g-code, called openSBP.

http://www.opensbp.com/

http://blog.makezine.com/archive/2009/04/s...TC-0D6B48984890

Of course, there don't seem to be many software tools available yet, but they do have a g-code to openSBP converter available....

I ran across a SketchUp to sbp code converter, looks kind of interesting.

SketchUp is a really intuitive 3D program, I ran across some other sites on getting SketchUp files into a CNC format.

I'm going to have to install SketchUp 7 this weekend and see if I can get anywhere with this stuff.

It's great to see more software developers opening their APIs up, and inviting criticism and potential improvement.

My complaints/concerns:

• Given that they wanted to make the code human reable (GCode is fairly obscure) they certianly abreviate everything.
• The name ties the language to a product. Namely the Shopbot line (notice the SB in openSBP). This does not seem to give other manufacturers incentive to develop for the platform.
• There is no community yet for this. For instance my critique should be on their website however there is no outlet for this at the moment. It seems to be coming, which is a step in the correct direction.
• It uses programmatic syntax that hearkens to BASIC. There are plenty of reasons this language has fallen from glory, I won't list them here.
• There does not yet appear to be anything on how the language is actually utilized. What kind of hardware is there aside from Shopbot equipment?

Greg M. pretty much hit the nail on the head.

I'd like to add:
- Gcode is already available, well known, and developed. There are almost limitless resources for learning about Gcode via its userbase. As a side benefit to being a nearly ancient programming language, it is completely platform agnostic, & doesn't care what CNC machine you're running, how the code was generated, or what computer/controller/interpreter you are using.
- Gcode is freely and easily generated from and converted between almost every known 3d or 2d format, including other competing machine control languages- such as HPGL or Gerber.
- Gcode is already essentially (if not explicitly) an open platform. The fact that there are different flavors of Gcode point to the fact that developers have already made their own versions that suit their products. AFAIK there's no reason (other than practicality and compatibility) that you couldn't develop your own. EMC, which uses a variant of RS274NGC, has a thriving userbase that works with its developers to constantly improve the front-end, the back-end, and the Gcode its self. If you want to see a function implemented, just tell them, and if enough agree, it'll get added to the roadmap and someone will develop it.
- Despite the fact that there are several flavors of Gcode, most are either directly compatible with each other, or are easily converted.
- Gcode is already a high level programming language (not too unlike BASIC) that is capable of math, logic loops, numeric variables, can make external calls to value tables, other Gcodes, executables, and scripts.
- Gcode (seemingly) shares most of the functionality of openSBP.
- Gcode is extendable (ok, not sure if that's a word.. but you know what I mean) by writing your own executables and naming them in the Gcode nomenclature. Meaning that functionality can be expanded/tailored to suit your needs.
- Gcode has several very capable and mature interpreters that are capable of all manners of kinematics and IO.
- This isn't so much a Gcode thing, but EMC (which my respect for is continually growing) already allows for direct motion control via Python. It's back-end allows for nearly infinite expansion and configurability.

It's not that I think that openSBP sounds bad per se, it's just that most of its claimed advantages.... aren't advantages it really has. In fact, it seems like a smaller, less popular, less understood, less supported, and weirder version of Gcode. Kind of like OS2 verses Windows - they both did more-or-less the same thing, it's just that one was completely unpopular for anything other than ATMs.

It's just that I don't think the world really *needs* another gcode-like programming language. What's needed are intuitive front ends that make numeric control easy- regardless of how that control is achieved... And that's not something that openSBP will accomplish.

I think you both made some really good points. I'm in agreement that sticking to g-code really seems like the obvious choice....

TBH I was bringing it up more for some discussion about CNC programming in general, rather than having any ideas of actually using it. Thanks for your insights...

http://www.ecabinetsystems.com/ has come out with a new iteration of their free cabinet software that runs on shop bots not just on their proprietary Thermwood machines

Ok. Sorry if it seemed as if I were just shooting your suggestion down. I do like G-code more and more every day though.. On the other hand, there are several other machine control languages which I feel are just as good.

This doesn't mean that improvements couldn't be made. When I used to program in HEX (yes, I did, and no I did not like it) I craved a higher level language. But that does not mean gcode should be made obsolete. It would be cool to see a higher level language than gcode that could be directly translated into gcode. Much like C or C++ code usually does not run as written, but instead gets compiled into juicy executable programs. If an intuitive, human understandable machine control language was written, I would argue it should translate itself into gcode or one of its brethren.



Those are some nice bits about gcode history. Is it somewhere up on the EMC website or something?



While gcode can make those constructs Robin, I will agree with the openSBP folks that they are not intuitive (abbreviations and intuition do not inherently mix). I just do not think openSBP makes those constructs nicer by any significant margin.



Python is a fairly cool language. Personally I favor Ruby, but whetever they are both solid languages. I assume you are talking about examples like this:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.p...Code_Generators



I couldn't agree more Robin. gcode (and others) do not really need to be human readable, or even human understandable (aside from a small portion of society of course) unless of course you have to tune and optimize your operations in such a way that your tools that generate your gcode do not allow.

Ultimately, the idea of a higher level language that translates into gcode actually does appeal to me. I just think it would require a large concerted effort, and a bunch of time.

The list of potential improvements for Gcode are as limitless as the day is long... For example, one of the left-overs of its original design... In fact what was considered a design feature in its day is the command G1, also known as coordinated move. Now, G1 (as opposed to G0, rapid move) moves all the axes at a muxed feed rate until it reaches the stated position. The advantage of this is that you can keep a constant feed rate without being a mathematician. This means that it's somewhat easier to control the rate at which a cutter is removing material, and thus spindle rates don't have to be adjusted and your finish is predictable. The disadvantage is that you can't easily control the feed rates of an individual axis within a single command...

Anyways, one of many things that could be improved.

However, this can be addressed in multiple ways already... Either you have a generator which outputs your desired gcode within the current constraints (granted, none exist for this particular function yet... that I know of..), or a python script can be made to do the same (same problem.).

Speaking of which... At least within EMC, Gcode is not the end-all be-all, and motion control can be performed directly by routing of modules within the Hardware Abstraction Layer from a source of your making to the motion controller (EMCMOT) and/or the trajectory planner (EMCTRAJ).. There exists, because of this, the potential for some truly amazing, easy, and intuitive machine control interfaces that may or may not use Gcode at all. I think that using Python scripts as g-code generators is nice... But not as revolutionary as a real alternative.. I keep mentioning Python BTW, not because I'm particularly dedicated to the language, but because it's a relatively easy to use language that is well supported by EMC, and the world in general. In fact, EMC allows for modules (parts that control basic functionality) to be directly written in python.

On the other hand, Gcode, as we both agree, has some great attributes, and will be the primary method of Computer Numeric Control programming for at least another decade or two. At the very least Gcode will probably serve for some time as a container for what is generated in more intuitive environments.
It'll be interesting to see how this all plays out though... This is the first time that home and hobby users have access to what is essentially an industrial manufacturing standard- I suspect that the demands of the hobby users will actually fuel the capabilities of the industrial users, and vice versa, until there is a robust alternative to gcode.

So... My argument against OpenSBP wasn't really for Gcode (except in comparison.. And I can't stress how much I really do respect Gcode) so much as it was for a better method of interface and programming altogether...

By the sounds of it, you seem to have a pretty good grasp of programming/gcode/etc.... If my explainations seem a little "over-explained", it's for those who are still dipping their feet into this for the first time..