I donh't have much experience with G codes, which is because I do have some experience using G codes for single axis motion control. That was quite a challenge to write even a faily simple back-and-forth motion program, with a "return home after jam" function added. At that point I decided that I would use alternative control methods in future machines, and I never touched G codes again. Many servoc system suppliers have been eager to provide programming languages and hardware that has been much simpler and more effective.
Is it possible that the G coding process has become that much simpler and user friendly? Or is it that the interfacing programs have removed the grief and pain?
"G code" was really developed for "Numerical Controls" (NC), which evolved into "Computer Numerical Contros" (CNC's). It is reasonably well suited for that environment (machine tools), but is not really so well suited for general purpose motion control (in my opinion). I believe the history of "G code" is related to the simplistic nature of the first numerical controls, and the use of paper tape readers to transfer data directly to registers in the control. Each data element had a single character prefix (Address) to route the data from the tape to the appropriate register in the control. The "G" address referred to "General" codes, I think. Typically "F" was feedrate, "S" was spindle speed, "M" was "Misc" code (usually used to turn some on/off device on or off - coolant, spindle, etc.), and "T" was Tool code. "G" was used to toggle motion related settings, such as feed or rapid, linear or circular interpolation, select cutter diameter compensation direction, and things like that.
Modern "Computer Aided Machining" (CAM) packages take cad data in, and output cutter path data. Usually CAM software generates the cutterpath in a "neutral" language first. Then that data is "Post Processed" to generate "G code" that is suitable for some specific machine tool. Most CAM packages include a large number of "Post Processors" (Posts) that will translate the neutral language output to formats suitable for many common controls.
As such, a programmer doesn't need to know much about "G code" any more. An analogy might be that web programmers can use tools that don't require an in-depth knowledge of HTML anymore. The tools hide the details. Similarly, once the "Post" is configured in a CAM package, the programmer can focus on creating machining operations without really caring much about the output language.
There is some effort to blur the lines between CAD and CAM packages, but under the hood there are standard interface points that are worth maintaining. For example, many CAD programs use the "Parasolid" engine as the underlying geometry description engine. CAM programs know how to read common native data formats, as well as formats that are designed for data interchange, such as IGES. I consider it a good thing that many vendors can participate due to the somewhat standard interface points between CAD, CAM, and controllers.
G code, the ISO 6983/RS274D programming standard, was created as a common programming syntax for CNC controllers. This is why most of the CAD to Toolpath applications support this format. But as another person on this thread has mentioned if you are using tools like CADFusion you don't have to be an expert at G Code syntax as the application creates the output. You do need familiarity however if you want to edit the resulting code on the machine.
Most newer controllers will offer alternatives to programming in G code for user that don't have exposure to this language. These languages can have basic-like syntax. The following two sets of program lines provide a comparison between a G code program and a more transparent syntax:
RS274 G Code:
G21 ;Metric programming units
G1 X10 Y20 ;Linear Interpolation
G0 X0 Y15 ;Rapid Move
The same 3 commands in Aerotech's basic syntax:
LINEAR X10 Y20
RAPID X0 Y15
There are other methods of transferring CAD data to machine tools besides G code. StepNC was developed as a replacement for the RS274 standard and NURBS is used for 3D surfaces.
Simply put, "Hey, machinists. Check out this program, it works great."
Check what out?
No advertised price.
Small screen shots that are not readable.
Looks like the only way to get any info is to fill out the "Request Quote" form.
Stated by "ronrek": "It is CAM for 2D laser processing with output to support Aerotech CNC control platforms. It does not support milling and turning applications. Entry/exit paths, tool diameter, process speeds are all settable within the application". So really this is proprietary software to run on a dedicated system.
"State of the art, might be an over statement, but you would feel strongly when it is accurately creating a part from a solid model".
What is it creating a part of? A 2D outline? This statement is a bit misleading, is it not? It has been stated, this is software to run a proprietary laser. It is not a "general tool" for creating actual 3D parts. This entire article smacks of nothing more than "bait and switch" for drawing people to Aerotechs website, not as an actual, usable tool. This wouldn't be so bad if it was stated as such, but to imply that it is a free-standing software package (like those from Vectric) is a bit hard to swallow.
So another terse layer of code interpretation on top of a relatively simple text file. Replacing the "G code" G1 with the word "LINEAR". Adding another level of abstraction is hardly helpful.
Anyone that is working on a machine should have at least a passing familiarity with G and M code. At its core, there are only three "G" codes needed to do anything on a simple XY system. If understanding these three codes eludes one, they should perhaps find something else to do, perhaps something in the fast food industry.
The "G" code that I commented about was for a "sort of simple" linear motion system that was part of an industrial testing machine. I did make it work in a reasonably short time, but I found it inconvenient. The next hundred industrial testing machines did not need that sort of motion control system, so as long as I recorded what was done and what was programmed all correctly, why become an expert on a language that I never used again.
Robots that walk have come a long way from simple barebones walking machines or pairs of legs without an upper body and head. Much of the research these days focuses on making more humanoid robots. But they are not all created equal.
The IEEE Computer Society has named the top 10 trends for 2014. You can expect the convergence of cloud computing and mobile devices, advances in health care data and devices, as well as privacy issues in social media to make the headlines. And 3D printing came out of nowhere to make a big splash.
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.