On 05/12/2013 02:16 AM, Steve Blackmore wrote: > On Sat, 11 May 2013 21:40:55 -0700 (PDT), you wrote: > >> Re: Correct use of subroutines >> >> My old school answer is that most subs should be written in (G91) >> Incremental mode. >> >> My more modern method can be either G90 or G91 depending on the >> application but I use variables for D, F, Z and loop to run Z level >> roughing and finishing often using several tools. >> >> RE: G84 >> >> BTW it is the programmers job to lie to the machine - the machine >> should NEVER lie to the operator. >> >> The value you use for your F should be exactly what the machine >> feeds at. No IF's ands or buts... 100% F This is also a key safety >> point - The operator needs to be able to read the G-code and KNOW >> exactly what the machine will do when it tries to execute that >> code. > > Which is the reason that many commercial shops never use subs now. > >> Now if you are using a using a specific tool which needs to run at >> a reduced feed then you as the programmer should alter the >> programed feed rate. In this case if you wanted to use a Osub to do >> your tapping and you wanted it to feed at 95% thats fine - its all >> man readable in the Osub - Fixed cycles don't display the inner >> workings so others would not know of your 95% mod. >> >> While I started out on a Bandit CNC way back and subs were critical >> with controls that could only handle like 99 command lines. > > 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? > 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. 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. 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. 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. One silliest example is seeing their email address embedded in scripts, multiple times in some cases. That only becomes known when all of a sudden there is a major failure somewhere and nobody got any warnings prior to that because some user account was disabled. > > If you are hand coding they can save some typing and cut 'n' paste > but in the CAD/CAM world they are pretty worthless. I do not agree. The problem is (very) awkward UI in CNC consoles from what I've seen on older systems. It's very archaic going all the way back to paper tape days. Can't say the same for newer ones. > One of the big shops I work with don't even use canned cycles unless > they really have to! They run a prize scheme where if an operator > saves time or tooling cost on code they are rewarded. One operation > they do is a deep drilling op in a nasty cast steel. They use a > through coolant drill but it still clogs up with chips. It was soon > realised that it was pointless withdrawing the drill until it had > reached a certain depth to clear it. The deeper it gets, the more it > needs clearing etc. The drilling operation is done with G1 and G0 > moves, easy to adjust to get the optimum without unnecessary machine > moves. It's ended up as hybrid drill, peck, deep hole operation and > saves several seconds. That saved time is more profit. > > Steve Blackmore 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. -- Rafael Skodlar ------------------------------------------------------------------------------ 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
