What's new
What's new

a more powerful g-code

rimcanyon

Diamond
Joined
Sep 28, 2002
Location
Salinas, CA USA
I use g-code for all my projects (specifically Deckel Dialog 2). But I am frustrated at its lack of parameters. There is no support for parameters other than cutter comp, so I cannot write a program that is in any way general and reusable. Some things I like a lot about g-code: ability to use polar coordinates and rotate any axis. But what I am really looking for is a milling machine that has g-code that has parameters and all the common features you find in a programming language like C or Perl or Lisp or Ada or ...

Does such a machine exist (other than a PC running CAD/CAM)?
 
Dialog 4 does parameters. I have not used them much. If you look in the Stickies up top, there is a thread on macro programming that talks a lot about parameters.
 
Planet controls can run off a modified python/g-code? You can also run a c or vb program thru an api. Might be a little hobby market for some on this site; I went with them over centroid for my mill because their development is much more advanced and continues to evolve.
 
You need to read the sticky about macro programming. Using logic and variables, you can write all sorts of generic programs that just need some inputs to create any code you want.
 
Dialog 4 does parameters. I have not used them much. If you look in the Stickies up top, there is a thread on macro programming that talks a lot about parameters.


OK, I will look at the macro programming. But I have one caveat: I am looking for a machine that has an embedded language, if one exists. Not a PC running a code generator. So if the macro expansion occurs directly on the machine, I would be interested.
 
Hmmm. Just about every control I know uses parametric programming. For those of you that are not aware: parametric programming is "Macro B" on a Fanuc. Macro programming is "Macro A" on a fanuc.
The difference is parametric programming is writing a program that contains parameters. #500=#500+1. Pretty simple, eh? That is not the definition of a macro.
A macro is a single line of code that passes arguments to a parametric program. G999 X1. Y2. Z3. F30.
 
I wrote a Fanuc Macro B program that would engrave time, date, and incrementing serial number, user scalable, in a line at a specified angle or on an arc of a specified radius starting at a specified angle, optionally projected onto a cylinder aligned to the X or Y axis of a specified radius. I don't know how much more general you'd want to get.

Family of parts programs are pretty common.
 
You're about forty years behind the times ....

http://vintagemachinery.org/pubs/2098/17060.pdf

I ran a K&T 180 with the "D" control on occasion. People (including me) got into trouble with it at least once because unlike the 200/A control that read the code rings all the time or the EB's that didn't have code rings, the 180 only read them once, so if you checked several tools at once, and didn't return them to the proper pocket, things got ...interesting- leading to the dreaded Manual Recovery Mode.
 
Hmmm. Just about every control I know uses parametric programming. For those of you that are not aware: parametric programming is "Macro B" on a Fanuc. Macro programming is "Macro A" on a fanuc.
The difference is parametric programming is writing a program that contains parameters. #500=#500+1. Pretty simple, eh? That is not the definition of a macro.
A macro is a single line of code that passes arguments to a parametric program. G999 X1. Y2. Z3. F30.

ok, I would have called those variables and the program a subroutine with parameters. But I'm a software engineer, what do I know.

However, that is part of what I was hoping to find. Still looking for conditionals, e.g. repeat until X >= 1.0
 
If you're looking for something closer to a modern programming language, the Siemens control is probably the closest match of the mainstream controllers. Fanuc Macro B is very, very, limited compared to a "real" language. Siemens is too, but it's a lot closer to a C language.

I'd bet good money that if you explored some of the more niche European controls like maybe Roeders or Fidia - somebody has a more accessible (possibly less robust) way of implementing parameters.

In all honesty though, for most of what we actually need to do on a machine, just a handful of variables, some GOTO and WHILE statements are pretty much all you need.
 
Thanks for the suggestions re: Fanuc and Siemens. Siemens sounds like the right direction. Thanks for the suggestion to look at other European controls.

I'm not ready to buy a book yet, still looking for information about controls. The examples in the MACRO thread are a bit like early Fortran or something cruder. Would like to find a control that uses scoped variables, nested subroutines, named subroutines (e.g. DrillHoles, not O8000), named variables (not variables like #601), strong typing (integer/ floating/ boolean), matrix variables, a good set of predefined variables that can be used in conditionals that cover machine state (spindle speed, position, feed rate, tool in use, elapsed time, is coolant on,), ability to throw an exception with a message, etc.).
 
In all honesty though, for most of what we actually need to do on a machine, just a handful of variables, some GOTO and WHILE statements are pretty much all you need.

Here is why I think we need (or at least why I want) a more powerful control.

- code generated by CAD/CAM is incredibly bloated.
- code generated by CAD/CAM does not make use of the processing power of the machine.
- most machines have a lot of processing power.
- writing good software (including machining code) requires readability, type checking, clear program structure, an interpreter that can detect many kinds of errors,
- goto's should not be allowed

So I would like to be able to run programs on the machine in real time that do the calcs, and that handle lots of cases, and are genuinely reusable.
 
I ran a K&T 180 with the "D" control on occasion. People (including me) got into trouble with it at least once because unlike the 200/A control that read the code rings all the time or the EB's that didn't have code rings, the 180 only read them once, so if you checked several tools at once, and didn't return them to the proper pocket, things got ...interesting- leading to the dreaded Manual Recovery Mode.
Ha, a K&T guy. Are we extinct yet ? My 180 had a C and the 50 taper toolchanger, so no code rings, ran just like a normal mill. But the 200's had D's and code rings ... as I remember, stick the tools in anywhere then drive the chain around once, it read all the tools, then kept track ? Tools didn't have to go back in the same place, the only thing you had to watch was if you ran oversizes, to be careful they didn't go right next to another tool.

Luckily, we didn't have those laser labels, cuz I heard they had a problem with coolant munging up the reading.

I loved the D. Have you run anything since you liked better ?
 
O commands can be used as conditionals in g-code. Not sure what you mean by not thru pc. Using a pc/c-more/rasberry is an effective solution to hmi. Using the power of it to check syntax and m-codes before data block #1 is sent to controller. Controllers should be focused on movement (including look ahead) and I/0 only.
Cad does not generate code. Cad is a program to draw pictures. Cad has no care of physical overlaps, open solids, or what machine/printer email address you use is.
Cam assists in converting drawing/model from cad into a machine commands. Two very different pieces of software.

my controller takes c+, vb, python, mint, hpl, dxf, and g code. I am pretty sure I will not use most of these options.
 
Here is why I think we need (or at least why I want) a more powerful control.

- code generated by CAD/CAM is incredibly bloated.
- code generated by CAD/CAM does not make use of the processing power of the machine.
- most machines have a lot of processing power.
- writing good software (including machining code) requires readability, type checking, clear program structure, an interpreter that can detect many kinds of errors,
- goto's should not be allowed

So I would like to be able to run programs on the machine in real time that do the calcs, and that handle lots of cases, and are genuinely reusable.

Seems like you have some fundamental misunderstandings. How much CNC experience do you actually have? How much CAD/CAM? How much software development using which languages?

I ask, because in general, people who post these kind of assertive claims have no idea how any of this really works.

I am also not a fan of gcode, but there are reasons why it hasn't been superceded by something better.

Gcode is a very simple language used to describe a path through Cartesian space. That's really ALL it does. EVERYTHING that comes after is done using the "processing power of the machine".

In the control, after the interpreter has parsed the gcode, the trajectory planner determines the motion sequence of the axis required to follow that path. It does so using it's preprogrammed data of the physical machines kinematics and dynamics.

These things do not lend themselves well to human readability or quick understanding under dynamic conditions, which is why they have not been successfully developed into a lower level programming language for CNC control, and why every parametric extension to gcode acts only on the gcode and not to any closer-to-the-metal functionality of the machine.

There have been some attempts at crossover over the years with varying degrees of success. STEPNC was one that disappeared. Delcam, prior to their acquisition by Autodesk, were developing a new type of post processor for powermill that learned some of the machines dynamics to tailor the toolpath for it when doing high speed machining.
 
Here is why I think we need (or at least why I want) a more powerful control.

- code generated by CAD/CAM is incredibly bloated.
- code generated by CAD/CAM does not make use of the processing power of the machine.
- most machines have a lot of processing power.
- writing good software (including machining code) requires readability, type checking, clear program structure, an interpreter that can detect many kinds of errors,
- goto's should not be allowed

So I would like to be able to run programs on the machine in real time that do the calcs, and that handle lots of cases, and are genuinely reusable.

I'm confused as to what you want.

Sounds like you want what most people actually think a CNC machine does.
You want to hold the print up to the screen and yell "MAKE THIS" and it
just does it. After you push the green button of course.

If you have a print, what do you want to tell the control so it makes your part?

There are conversational controls out there, you still have to tell it stuff, and it
still generates G-code in the back ground. Very similar to cad/cam, just boiled down
and stuffed into the control.. Kind of like the old text games vs having actual graphics.
 








 
Back
Top