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. >> 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. Please do some reading up on Gcode - a good place to start is Peter Smid's CNC programming handbook. ISBN 978-083113347-4 An excellent book that everybody who thinks they know, or wants to know about CNC should read. >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. 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.... >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 -- ------------------------------------------------------------------------------ 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
