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.
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.
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.
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.
"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.
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?
Having my own machine shop exposes me to software like this. I like it mostly for the conversion to G-code. It has proven to be quite reliable. I have tried other programs like Solidworks/SolidCAM and Alibre with plugins, they are good, but you pay heavily for it. CADFusion is priced right for what you get. The company focuses on making the most accurate G-code translation, where all the others feature it as an add-on.
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.
Simply put, "Hey, machinists. Check out this program, it works great."
So, basically this entire article is nonsense. It's premise is an outline leading up to the last three paragraphs touting the capabilities and benfits of the "CADFusion" software. The sentence "That is where Aerotech's state-of-the-art CADFusion software comes in" is particularly ridiculous in that this "software" is hardly state-of-the-art. I'm not going to go sentence by sentence, but with statements such as "The key here is that CADFusion is a platform built around the idea of motion control, not simply a plug-in like most other programs" indicates that the author is out of touch with the industry and simply does not know what he's talking about.
Given that, according to "ronrek" this software is "normally" provided as part of a "package" makes the last statements "So if you're an automation design and manufacturing aficionado, try this program out, and bring the true engineer out of you. Since I have my own home machine shop, the software will soon be put through its paces" makes no sense at all, unless of course the author has a shop built around Aerotech's motion controllers and equipment. Other than as a advertisement for Aerotech, what exactly was the point of this article?
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.
You are correct. It is targeted at laser and water jet cutting applications. Tool offset based on diameter is supported along with lead on/off moves and advanced laser power control based on veloicty and/or position.
As I mentioned in an earlier post it is designed to create tool paths for Aerotech motion controllers.
In an age of globalization and rapid changes through scientific progress, two of our societies' (and economies') main concerns are to satisfy the needs and wishes of the individual and to save precious resources. Cloud computing caters to both of these.
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.