High Level langages

[Dark]

hi guys.. im a new comer in the cnc world.

ive made some research about high level langages for gcode and couldnt find much of informations..

i found a discution on some forum that was interesting as they were talking about some high level langage for gcode but it was all related to linux. since im not into linux stuff my interest quickly faded away.

seem like there are not much support for these high level langages.. and really wonder why it is actualy like that?

ive read often here of poeple using VB to do macro stuff to quicken up the programmation process of gcode.

ive seen poeple looking for a "good gcode editor" and wanot..

also.. another thing that ive noticed with the GCode, and its porbaly the most important aspect.

seem there are no code sharing in the machinist community!?!

and yes.. i certainly do understand why there is no sharing.. after all, these codes are the bread and butter of the machinists for most of the parts, or the code made by a machinist is owned by a business and therefor not sharable.

but also the gcode by itself is not really portable.. most of the codes are machine specific and wouldnt be much of use for other machines.

i guess these factors are enough to keep poeple from sharing codes.

you will see some poeple that give advises on how to proceed with this or that, or some poeple that will share some procedure(chunk of code) on how to acomplish this.. but we dont see any real code sharing...

im starting to see the gcode more like of an executable file for machinery than a langage to code with.. ie. would you open a exe file in edit to modify the program? or more appropriatly, open an .exe file in a hex editor and mod the program directly in hex? you would usualy open up a high level langage editor, modify the code and recompile the new exe.. that pretty much how i see how the gcode should be processed.

sometime i feel like a code would be faster to do with programation instead of the cad to cam to gcode produre, but due to the lack of good environment and high level langage... the cad to cam to gcode procedure seem to remain the best option most of the time.

also i would like to point out that the gcode is not the most pleasant code to edit/browse through. it feel kinda like programming assembler but much more simpler.. and browsing through several hundred lines of gcode give me headache in about 2 mins.

the OP-CODE style of the GCode langage is getting pretty old too and we should not forget that when the lanage as been made in the ??(70's , 80's?) the datas requierment was probaly not the same? as we may have now? and the gcode seem to become totally unmanagable after couple of hunded of lines.. (for me anyways) lets alone the 500k to 1meg + files..

ive started to look into loops and variables and all that stuff.. and its just a real PITA. not only that.. but it seem that a code that will work in an environment X, may or may not work in another environment due to the lack of standards and support by the different software and hardware.

why does in 2010 the machinist community havent yet adopted a standard high level langage to work with gcode?

ive been into this for only about 5 months now and clearly see a need for such high level langage.

this may have to do with the tools im using right now.. but i dont think all the solution is into good cam softwares either.. even with cam softwares i always end up editing the code to fit my needs/specs.

seem to me that what take me hours to do would take couple of mins in a well organisated environment with high level langage support.

i can already see huge libraries of functions, yes.. functions.. not sub routine
that would extend the gcode to no end...
extended libraries with deep functionality for drill cycles, circle cycles, rectangle cycles, rect with rouded corner, oval shape.. etc etc at the simple call of a function with couple parameters.. i saw and use the cycles system in the gcode, but its pretty limited.. an higher level langage that could manage huge environment would remove any limits to the posiblities

machine specific routine could be coded into libraries and be accessed by function calls or the like... which mean i would not have to recode or copy from file to file my little routines that i do here and there to init the machine and store it, etc.. for each part/code.

how about a high level langage that could actualy give access to the system's API functions or any other standard library code(.dll)?
this would give total access to the I/O of the computer to play with all while compiling gcode, seem like this would open up the posiblities to me

in a very complete high level langage environment we would be able to generate HUGE gcode from very few lines of code!

maybe ive missed the boat somewhere and such software/langage is already out?

what are the solution(s) out there to go around that? posibly something thats not linux related?

what do you guys think about high level langages for gcode?

sincerely sorry for the long post.

edit:

humm ok, so no one as a sugestion or good solution(s) for high level langage(s)?

actualy since ivent found what i was looking for(about 1 month ago) i started to code my own langage
and i call it the G++, yes just like the C++, the G++ uses C/C++ syntax but is specificaly targeted at outputing GCode rather than exe files.

the compiler is heavily under construction at the moment.. but should be functional soon.
not sure if someone would have interest in such langage/software but ill maybe eventualy put it out here if there is enough interest?

[Dark]

here a screen shot of the G++ langage, basically its the same as the c/c++ but it also handle pure gcode as well.

ive worked out a first compiler that i put 2 week of development on it, it was hardcoded and was a recursive scanline based compiler, it was very limited. but this as put eveything into context for the contruction of the real compiler.

the new compiler have huge fundation.
a full word processor and is a recursive word/expression type of compiler.

[neilw20]

Re-usable code.
We have that. Drill cycles, circles, etc.
Scaling. Yep.
Subroutines. Yep. Multiple calls to a sub. Yep.
Portability. Each job is very machine/tooling/job dependent, so there is not a lot of scope to re-use stuff.
The stuff we re-use are already done, like tool change cycles unique to a given machine.
Why complicate things. It will be like trying to write a windows program.
There are good gcode editors and simulators out there now.
for instance see http://NCplot.com

If you want to do fancy stuff, and it is almost always 3D, along with the complex geometry environment, and tool use rules, you use a CAM program.
Plenty out there. Lots bad, some good, some excellent, some too complicated to contemplate, and quite a few that only big corporations can afford. $200K for a $2M machine.
Most here only would only wish for a $20K machine.
Machine manufacturers all want their customers to use their unique systems, so they are tied to it for life. What's new? Connectivity has improved.
It is only fairly recent that things like Mach3 can be run on a PC or a MAC.
Machines. There are many, but Seagate make 1 million HD drives a day to keep the PC / MAC happy.
Isn't it a much smaller customer base for the CNC machines?

Go ahead and create a nice standard, or just another unique way to do what has been done since 1970.
We still machine stuff, just a bit faster now, and the $HAPE I$ still related to the co$t.

Variables. There's an area that could be more readable.
The Bosch Controller went a little way towards this with variables with 1 letter and 2 numbers. Wow!

Write gcode with variables, and have a utility that turns the symbols into comments, so you get 'standard' gcode, and when you edit it the symbols are restored.

Dark,
You seem to want to do obscure stuff but don't like linux. ????

You've been doing this for 5 months? What machine do you have?
There are a whole heap of people doing this for up to 40 years and you must balance productivity and utility.

If it ain't broke, why fix it? Improve it sure, but run machines for 5 years, and see how the world ticks.
Best of luck and I hope your machining is more concise than your grammar and spelling.
Accurate work, means attention to the finest details. Just look at what can be produced in China, where the attention to details is just starting to sink in.

[Dark]

Hi Neilw, thanks for the reply.

yes, the gcode as some functionality as is, but the drill, circle and other cycles that are supported by the gcode are VERY limited.
which mean you need alot of aditional code around to fill up a complete cycle or to do some fancy cycles.

the sub routines and variables in the gcode are ugly and way too basic to make anything clear and readable imo
and im not sure to understand how we can reuse gcode, other than coping a chunck of code in another file?
i heard that some software can read external files? but thats only some softwares that seem to support that

portability, yes there are no portability right now because just like you said, each job is machine/tool dependent,
however IF we would use a high level langage we could then code base functions/libraries that would be sharable and portable to be used into any other codes.

i understand that there are already alot of gcode editor, sim, cam software etc..

but seem that none of them are either in my budget.. or they are some obscure stuff on linux. or not exactly what im looking for.
and about linux, havent said that i didnt like linux. but rather that im not much into linux stuff
ive 10-12 computers around the house and in the shop, and they all run either xp or dos

as a game coder, ive not much to do with linux which as a really poor support for games..
you will see some titles here and there. but really linux is not a OS of choice for gamers or to work in the game industry...

when i said 5 months... this is more like 3 months to build the machine and controller
and 2 months of use.. its a small mill 3 axes made of wood/teflon?/acrylic and some NEMA 17 sized motors.
well.. the machine **** ... it flex like paper and wanot... but still.. does work good enough that i can cut carbon fiber parts

and to answer your main question as to what im trying to acheive?
basicaly a high level langage for gcode derived from the C/C++ syntax since its the most universal/portable langage.
i though it would be a good base for a standard high level langage for machinery and robotic.
the main goal here is only about fasten up the production of gcode via programmation.
also make the code more managable, easier to read, easy to modify/add code or base functions/libraries

like i said in the first post, browsing through gcode is a real PITA... specialy when the files get a little fat.

as for the screen shot ive posted this may not be the best example here, this is only some code that i use to build/debug the compiler
but with such high level langage we will be able to make very complex and huge gcode from very little high level code w/o actualy toutching one things related to pure gcode in the main file.
considering we already had the libraries to back off the front code.

lets take the assembler as a good example for gcode,
if we had to code eveything in asm today, our softwares would still be at the age of stone..
it would be unpraticable to manage all the datas we process now a day in our software in such low level langage..
but this doesnt mean asm is forgotten or not used anymore, infact its more used then ever.. just buried into the base stuff

sorry bout the grammar and spelling, english isnt my first lang.

[neilw20]

Dark,

Thanks for the reply.
I'm just a programmer with 3 commercial packages, 2 of which are still in use by the big end of town, still going strong at 22 years life.

Drill cycles. What can be improved?
In absolute mode:
G83 X0 R10 Q6 Z-5 F150 (peck drilling)
X10
X20 Z-12 ( a little deeper)
X30 R20 Z15 F95 (up on top of a step)
(drills 4 holes 10mm apart without moving Y, changing feed rates too.)
how do you do this more easily?
G80 (finished)
In incremental mode, even simpler for rows of holes at the same depth , albeit a bit cryptic.
after preamble from starting point
X10 L3 (4 holes X0 X10 X20 X30)
and it is just as easy to a diagonal line.

Stuff is reusable only if you make the same part.
At least with gcode simulators you can visualize and debug stuff readily without breaking cutters.

Sorry my French is limited to 2 words. Our grammar sucks.

As I said, a nice tool to make symbolic gcode transparent to machine/human environment would be a good step forward.

I will write one one day - in C, with a VB interface.

Attached zip has password 'john' to extract, so that anti virus programs, don't filter it to the garbage bin.
By all means, scan it for viruses after after you extract it.

[stevespo]

Originally Posted by Dark lets take the assembler as a good example for gcode, if we had to code eveything in asm today, our softwares would still be at the age of stone.. it would be unpraticable to manage all the datas we process now a day in our software in such low level langage.. but this doesnt mean asm is forgotten or not used anymore, infact its more used then ever.. just buried into the base stuff

I think you've raised some good points and that is a reasonable analogy. However, our high level representations are already in the form of vector based drawings (CAD), parametric modeling, etc. The compiler is the CAM program, which takes the high level models, parameters and then produces gcode for a target interpreter.

There is value in a higher level programming language that abstracts some of the complex gcode instructions into a simple, human readable, syntax. There are parts and operations that may lend themselves to this more readily than taking the time to do a drawing, etc.

I assume that whatever tool you've envisioning will ultimately produce gcode (machine code) and not some new low level language. For it's faults, gcode is the universal language produced by CAM and understood by the many thousands (millions?) of controllers out there.

It may not be common practice today, but there was a time when we would run multiple C compilers, instrument the code, run benchmarks and then take the best results as our base. We would then look for bottlenecks and hand code optimized routines in assembler that we would patch into the executable binary.

This is fairly analogous to what people are doing today with their CAD/CAM/gcode. The tools are doing 99.9% of the work, and you occasionally come in and tweak a program to make an improvement that the high level tool isn't capable of. At least that is the way that I'm using them. A production shop may have a different methodology or needs.

Steve

[BobWarfield]

Dark, these guys are right. The g-code does enough, and it is universal enough, that you don't want to try to replace it with a higher level language. It's too hard, it won't work everywhere, and it doesn't add enough value.

Part of the issue is just sitting down and learning g-code until you can read it and be comfortable with it. It look so cryptic when you first start seeing it. Eventually, it clicks, and you realize its pretty decent, and is streamlined to do the job it needs to do.

There are some opportunities for improvements. Neil's idea of a way to make some of variables and identifiers more symbolic is a good one, for example. BTW, some of what you envision as more canned cycles are available as Wizards. And there is actually a pretty vibrant community of folks writing and exchanging macros. They're out there, you just have to go dig for them.

On the subject of improvements, I'm in the midst of building a G-Code Editor/Simulator companion to my G-Wizard Machinist's Calculator. It will have a lot of these capabilities baked in. I won't say more because it is a little ways out. If you want to follow it, sign up for the G-Wizard beta test (it's free):

http://www.cnccookbook.com/CCGWizard.html

I will be sure to let you know how to get onto the Editor beta when it's ready. Meanwhile, you can see just a little of what the editor will do here:

http://www.cnccookbook.com/CCGWizardE.html

Check out features like the "Hints", which help beginners come up to speed fast on how to read g-code, and help experts remember what all the obscure parameters do on the canned cycles.

Cheers,

BW

[Khalid]

Agree with Neil and Bob..Both are the great men at CNCZone with immense knowledge and wisdom... You know, I was stucked in Embroidery Gcode generator.. My software is the First one that can generate Gcode for embroidery work...

This is only because we have no embroidery gcode generator available..so we made one..and if you follow the whole thread from start, you will see how much brain storming has been done by the community....I made it free for alll.. You can download it from here

The download links for this free software is
http://www.cnczone.com/forums/showth...=57404&page=33
Feel the interface, You have to download some DST (Embroidery files) from internet and open in my software...IT IS FREE...It can spit Gcode with Indexer or simple Z... You can see the sample of embroidery work here
www.my-woodcarving.blogspot.com

I really wish to see the outcome of your software...Keep posting..

[Dark]

i hear ya about the sim and cam and the other converters softwares guys.

a high level langage will not replace these softwares
but i think Stevespo pretty much put the nail right on

Originally Posted by stevespo There is value in a higher level programming language that abstracts some of the complex gcode instructions into a simple, human readable, syntax. There are parts and operations that may lend themselves to this more readily than taking the time to do a drawing, etc.

Neilw, instead of telling you what could be improuved in the drill cycle because i really dont know and to tell you the truth i dont even fully understand your code
ill show you what could be the result in a HLL environment.

#include "drill.h"

float ReleasePlane = -2.0;
float HoleDept = 0.5;

void Main()
{

	Drill(-10, 0, 2, 0, 10, HoleDept, ReleasePlane);

}

this would output the gcode to make 10 holes, starting at x -10 y 0, and would increament x of 2 and y of 0 each pass.

how about a drill cycle in a circle patern?

DrillCircleCycle(0, 0, 25.0, 16, HoleDept, ReleasePlane);

this could be a function added to the dill library and every one could have access to the fucntion with a simple call
which would generate a good bunch of gcode from a simple single clear call.

now think about the gcode generated by this

for(int i=0;i<10;i++)
	DrillCircleCycle(0, 0, (i*10.0)+25.0, 16, HoleDept, ReleasePlane);

of course this is not limited to drill and circle cycles, just imagine all the base functions/libraries that could be made

as far as i can tell, 40 years later people still code GCode programs. even if there are powerfull cam software and converters out there
i think a HLL would greatly enchance the gcode capibility, functionality, and fasten up the production of codes at the programation level in an extendable enviroment

for complex geometry.. a cam/coverter will remain the best option.. no doubt

[dpuch]

The reason there isn't much change in the language of machine controls (G-code) is there isn't a market for it. It works.

Commercially you will spend $50,000 to $500,000 USD on a machine. Plus probably $5,000 to $15,000 on tools, holder s and fixtures. Another $3,000 to even $20,000 for CAM software to make programing it easy is an easy choice. CAM software is the graphical IDE of the machining world. For small run stuff some builders have basically included a CAM package on the control (mazatrol might be one example).

Besides the vast majority of parts produced commercially are impractical to even try and program g-code directly. Think of it this way, would you design a window from scratch via code, or use an IDE to place fields, buttons text ect?

So the answer is CAM software IS the high level language. It is 90% 3d coordinate points anyhow. Check out featurecam, I think they have a free demo you can play with. At some point looking at G-code is just to check that everything is working fine when you "compile" g-code with your CAM package's post processor. Having good code format, spacing, some comments form the post-processor as well as a good g-code editor makes this a lot easier. No it will not ever be as readable as a modern computer programming language, get over it.

That said there is still a lot the hobby level cnc user can do for cheap. For g-code functions, do some searches for canned cycles. There are usually the standard drill/bore/tap cycles but some machine builders include others. Like a drill hole pattern (rectangular or circular) boss or pocket milling (rectangular or circular) facing routines ect. Do a google search on "drill cycle macro" and read some of the pages. Specifically look around on http://www.cncci.com/resources/tips.htm

There are a few free tools for producing g-code like DXF to g-code converters as well as one or two early attempts at CAM software. Another option that is limited for general CNC use is the phlatscript but it is still an impressive start if someone wanted to extend it to general CNC use.

[sinha_nsit]

G-code was designed to make its use as simple as possible, so that people not having enough experience with a high-level programming language could use it. Yes, there is macro programming feature now available which can do a lot more than what conventional programming can do. Those who have learnt it, simply love it.

[bernster]

Hi Dark,
I see your last post was some time ago, but hope you see this.
I am a cnc programmer and I am very interested in what you are saying. I have a Gcode translator built at the moment, It translates various Gcode flavors from different cad output. You can create many cfg files that suits machine sizes and shapes. You can import raw code with or without any config parameters at all, like G0 Z up, Z depth, clearance heights, feeds, speeds etc., and the translator will apply all of your chosen config settings into the output file. I designed this as a bridge for people who want to retro-fit their machine or build a new one. The translator targets the Mach3 PC based cnc controller and is suitable for 3 axis engraving and routing.
I would like to take this a long way.
I would like to build a complete package as I find Mach3 is not always good for accurate engraving. I see you are using C++, I am use python, but the languages are very similar and also python has good features for picking Gcode from strings, and is portable.