John Kasunich wrote: >> Never assume :) Stopping at the end of the current line or arc is better >> than the current behaviour. > > If swarf starts wrapping around the tool 1 inch into a 10 inch long > slot, waiting until the end of the move is not going to work.
So what do YOU do in that situation John? I end up with a wooden or plastic dowel handy to intervene since an uncontrolled 'stop' is likely to loose position how ever it is done :( Yes ... a controlled pause is a complicated problem and may be something that requires a hardware motion control processor. **** >> Surely a design flaw that needs addressing. > > Not really. Spindle speed is not the proper way to control a > laser. EMC already has "motion synchronized I/O", both analog > and digital. Those commands go into the queue along with the > motion commands, and are executed at the proper time - right > in the middle of the blend between consecutive moves, without > causing any motion disruption. "motion synchronized I/O" was not part of the original design? It was added much later, so why can't THAT design change simply be completed properly? **** > I probably agree that if you are writing a program once that will > be used to run 1000 or 10000 parts, simple is the way to go. The > time spent writing all those lines of code is no big deal. But > what about the guy who is making 1 or 2 or 5 parts? In the hands > of someone who proficient with them, subroutines can dramatically > reduce the time needed to write a program. How many people actually hand write gCode? Yes there is a need for linux versions of some of the good packages, but the majority of people will be starting from CAD drawings, and their gCode will be structured by the post processor routines. In reality it is the high volume Code which MAY be hand tweaked simply to get a few more parts per hour? The low volume builder is going to be FAR more concerned about recovering a part when something goes wrong while the high volume process just scraps the part and starts again? **** > You have admitted you know nothing about programming. To be blunt: > You have no clue how difficult it is to do what you want. So of > course you are optimistic. People who give orders are usually more > optimistic than those who have to carry them out. I like to think that I know something about programming. I started back in the days of ICL190x computers when we were still writing the loaders, let alone the compilers. Steve B. and I have our runins from time to time, but in this particular area I tend to agree with him. EMC is not the only package that has trouble with the problem of 'pause', and some of the USB modules will never be able to address it, but EMC DOES have the core elements needed to address it. What seems to be missing is communication between some elements of the system to allow backtracking. Given the vast increase in processor speed since the mid 1990's, some of the 'rules' set then really no longer apply, and "motion synchronized I/O" would at least allow the spindle to be run down when finally lifted out of the job, rather than when reaching home :( That said ... I break my gCode down into manageable chunks using a single tool at a time, so I can stop and start when I need to ... *I* am just as likely to cock things up as the Mill :) -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
