On 05/12/2013 01:48 PM, Steve Blackmore wrote: > On Sun, 12 May 2013 10:08:10 -0700, you wrote: > > >>>> code. >>>> On 05/12/2013 02:16 AM, Steve Blackmore wrote: > >>> These days unlimited code length is the norm and subs are frowned >>> upon commercially in my experience. The operator can't easily alter >>> the code, if required, on the fly. Some of the subs I've seen here >> >> But they can make changes somewhere in te middle of thousands lines of code? > > Of course they can - they have to understand Gcode, but not some obtuse > programming language or complex math. They often simply pause the > machine, alter the code and restart.
Of course, if they spend the same amount of time to learn some advanced code but still simple code instead of G-code they could do much better. Using your analogy we should pause faulty applications in the "middle somewhere", change assembly code, or registers in the CPU, and memory locations, and proceed from there. I only see that being done on PDP-1 and similar machines in computer museum. Where did I mention need for complex math? Knowing basic geometry is needed even in non CNC machining. No? > >>> and elsewhere are so complex that they could only be written to show >>> how clever the author is, not for ease of machine control. A typical >>> op has no chance of understanding them. >> >> That might be unfair to the programmer. > > But often true. > >> If the operator does not understand complex operation, that's precisely >> why a subroutine should be used IMO. Granted, I do not know much about G >> code and machining in general as my work mostly revolved around >> computers and connections to "other stuff", sometimes CNC. However, code >> is code, it automates processes and minimizes redundancy if written >> properly. That goes for CNC machine operations or OS administrative tasks. > > Your key statement " I do not know much about Gcode and machining in > general as my work mostly revolved around computers and connections to > "other stuff" - You then go on to assume that applies to CNC operations. Machines behave predictably based on what the code says. There is no magic there. Bad code, bad results in my real life experience. Who would want machines that do not behave predictably??? > Please do some reading up on Gcode - a good place to start is Peter > Smid's CNC programming handbook. ISBN 978-083113347-4 I have a book on CNC programing and a floppy disk that came with it. I used to run programs from that book under OS I left behind 19 years ago. However, code is code, including ~50 years old G-code that never evolved much. I know, old industry doesn't die fast but some parts of it just should. A number of attempts have been made over the years but no solution has emerged. > An excellent book that everybody who thinks they know, or wants to know > about CNC should read. Of course, the more you know the better you are. However, knowing G-code is irrelevant for this discussion. The fact is that G-code was outdated long time ago, proved by the fact that manufacturers started to use different implementations to accommodate new functionality. Perhaps you should check what's going on around the world http://reprap.org/wiki/G-code http://www.ghielectronics.com/community/forum/topic?id=11023 to understand the limitations that G-code is imposing on end users. > >> Drawing an analogy from the sysadmin world, I can say that well >> defined, understood, and tested functions (subroutines) are the best way >> to develop, maintain, and use code efficiently and consistently in any >> environment. > > You also know that is the holy grail in most environments. Getting > programmers to document their code is the bane of computer ops. We have an agreement here. > > BTW - I've been there, done that and threw away the tee shirt. I was a > Senior Ops Analyst for British Gas for some years in an ICL VME > environment and wrote and controlled SCL, but gave up that boring world, > moved up to designing and managing installations of Distributed > Mainframe Systems, their HVAC environments and CHP plant development. > Finally went back to my roots with Industrial Engineering and CAD/CAM > solutions when British Gas was devolved. > >> I hate to see "systems administrators" write more or less same >> functionality, sometimes (?) with hardcoded IP numbers, hostnames etc. >> into their scripts which make it extremely hard to read or maintain >> because some variable with no name like "i" or "j" is defined deep into >> the code, line 315 or whatever. > > The same could be said for Gcode as when it fails on line 315 the answer > is on something defined in line 20.... Of course, the issue is "understand the code". It would be easier to read/enter one line like "selecttool 3; position 11, 22; drill 5mm", than using whatever equivalent number of obscure G-code. At least for occasional CNC users and emerging personal 3D printing. > >> When the issue is known, a well defined subroutine would account for >> that and drill/peck depending on depth and perhaps drill bit size. >> Program once, reuse tested code countless times. I would give the >> operator double brownie points for modifying, documenting the >> subroutine, and send feedback to the programmer. Why? Because other >> operator on the line could use the same subroutine when >> "Joe" is not there or caches in on his last check from that company. > > In this case the code is centrally kept and accessed via the network. > There is a master copy and working copies. They would NEVER write as a > subroutine as the next operator wouldn't understand it. He would however > understand any change made in Gcode. Any changes are supposed to be > documented on the work order, often, like programmers, they forget. To > circumvent that the code is checked against the centrally held working > copy and any changes flagged for investigation. BTW - if they don't > document it - no bonus :) > > When you know what Gcode is, and how it works, perhaps you'll > understand. > > Steve Blackmore That sounds like G-code is as complicated as Linux kernel I compiled a few hundred times before generic drivers became modularized and more stable. Without being a C++ programmer, I should not be able to do that, right? -- Rafael ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
