On 05/13/2013 03:56 PM, RogerN wrote: > From: Steve Blackmore > .Sent: Monday, May 13, 2013 4:48 PM >> To: emc-users@lists.sourceforge.net >> Subject: Re: [Emc-users] Correct use of subroutines >> >> On Mon, 13 May 2013 22:50:51 +1000, you wrote: >> >> >>>> Given that it is now mainly a machine-to-machine data standard, the >>>> fact that it is archaic, antiquated and poor as a programming language >>>> is largely irrelevant. >> >> True. >> >>> True, and well expressed, but the LinuxCNC elves have added much needed >>> flow-control, looping, and subroutine language elements to LinuxCNC >>> gcode, so that it is nearly as good as assembler now. Named variables, >>> too, have done a lot for its utility as a hand-wrought language. >> >> Your LinuxCNC elves are working for a tiny niche market only. Nobody >> except programmers seem to think it's necessary. It certainly isn't to >> produce a part and all the loops and subroutines in the world don't >> machine that part any better or quicker. >> >> Your never going to persuade thousands of companies or the big players >> like Fanuc or Siemens to drop traditional Gcode. It's been tried before >> and then, as now, changes were as popular as pox in a brothel.
Never? One software company kept telling us in the mid 90's that Netscape, java, and Linux are not worth mentioning. There are plenty of similar examples of disruptive technologies coming from "little guys" that all of a sudden become something everyone wants to have. >> >> Commercially they have too much time, skill and money invested in >> something that already works and if it ain't broke there is no need to >> fix it. >> >> Steve Blackmore >> -- > > A program wouldn't have to give up it's ability to understand G code to > understand additional instructions. For example a canned routine for Finally somebody that understands what I tried to say in my earlier emails which veered far away from it's subject line. > drilling doesn't mean the control no longer understands milling exactly. > instructions. My Anilam control only had 1000 instructions program memory > but by using loops it could execute much more than 1000 instructions per > press of the start button. As an example, one part I made was cut out in a > sheet of Delrin, the size of piece that fit in my vise allowed me to machine > 3 rows and 7 columns, 21 pieces. By using nested loops I was able to > machine all 21 parts using the code for 1 part repeated in 3 rows and 7 > columns. > > So continuing the same idea, if the program understood it, I could define > one part, a turbine blade maybe, and repeat the part multiple times rotated > to different positions. When you have so much memory and hard drive space > it hardly seems worth writing efficient code, but if you can correct one > blade it could correct every blade, versus having to edit the same problem > for every different blade. > Exactly again. > I wish LinuxCNC understood G code plus something like C++ or Basic language. > > RogerN > HP developed a "specialized CNC language" HP-GL to drive NC (Numerically Controlled) machines, plotters. Because plotters use microcontrollers, they could handle higher level language with simple commands to select a pen, move it to starting position, put it down, and draw a line. http://en.wikipedia.org/wiki/HPGL Similarly could be done in CNC machines. One problem remains, standard. G-code remains in it's place precisely because we don't have such a standard. In "computer world" we have standards like XML, JASON, etc. which are interpreted in our browsers and other applications to interact with powerful server clusters in data centers. No such thing for CNC. If there was such a higher language like http://en.wikipedia.org/wiki/APT_programming_language but more advanced and object oriented, and XML perhaps, it would be possible to prevent CNC machines to do something stupid. For example, you enter the size and position of the raw material and tool size. The machine "could tell" of there was a possibility for tool collision if you manually entered bad command. With controllers that only handle G-code there is no such verification, or is it? Fact, systems that handle G-code are technically still on the same level as computers using paper tape for program input decades ago. It's easy to recognize the resistance from those who are afraid of (CNC) changes. However, we do not need to be scared into thinking that we need to know the G-code in order to understand CNC in general: http://en.wikipedia.org/wiki/Numerical_control Somebody did an excellent job on that page! -- Rafael ------------------------------------------------------------------------------ AlienVault Unified Security Management (USM) platform delivers complete security visibility with the essential security capabilities. Easily and efficiently configure, manage, and operate all of your security controls from a single console and one unified framework. Download a free trial. http://p.sf.net/sfu/alienvault_d2d _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
