On Mon, 17 May 2010 23:14 +0100, "Steve Blackmore" <[email protected]> wrote: > On Mon, 17 May 2010 02:50:44 -0400, John Kasunich wrote: > > > >The motion controller pulls lines and arcs out of the queue and > >makes the tool move along that path. A particular line or arc > >might sit in the queue for a couple tenths of a second, if you > >have a program that consists of many short moves. It also might > >be in the queue for minutes or even hours, if the program has > >very long, very slow moves. A short program can be completely > >interpreted and in the queue before the tool ever touches metal. > > Shorten the queue maybe?
No. I already explained why the queue is there. Suppose you are running a contouring program with lots of 0.01 inch moves, feeding at 60 ipm. That works out to 100 moves per seconds flowing through the motion queue. User space programs like the interpreter often get suspended for a tenth of a second, and can get suspended for longer - a second is not impossible. That requires a queue of 100 entries (or more). > >So, how can we do that? I assume he doesn't want to wait till > >the end of a line or arc to stop. > > 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. > >Already said jogs can probably be done. > > Good. > > >Next is spindle and > >coolant. Normally, when the interpreter encounters a spindle > >state change (on/off/speed) or a coolant change (on/off), it > >stops queuing movement commands. > > Why? - the fact that the spindle or coolant is toggled on or off > should not stop the motion queue. You can say something should or should not work a particular way all you want. The fact is, it does work that way, and it has since the core of EMC was originally written by NIST back in the mid 1990s. In the original architecture of EMC, motion was the only thing the motion controller did, and the only thing that went through the motion queue. Spindle, coolant, and all other I/O functions went through a separate I/O controller, and were not queued. (At the time, the I/O controller was a semi-custom program that handled many of the machine specific functions that are now done using HAL and ClassicLadder.) Since motion is queued, and things like spindle and coolant are not, it is critical that the queue be allowed to empty before the interpreter issues spindle commands - otherwise the spindle would stop as soon as the interpreter sees the M5, while the cutter still has many queued moves to make. Dragging the tool through the work with the spindle off is not good. You could argue, with some validity, that spindle commands (and coolant, and virtually everything else) should be queued along with motion. But now you are talking about significant architectural changes. This is no longer a matter of adding a new feature like bolting an accessory onto a car. You are talking about replacing the engine (or at least radically changing it). > >When the motion controller > >finishes processing all the moves in the queue, the interpreter > >see that, sends the spindle or coolant command, and starts > >queuing motions again. We refer to such events as "queue > >busters". (And as an aside, the fact that spindle speed > >changes are queue busters might explain why the guy who is > >trying to change laser intensity on the fly with S words sees > >motion pause briefly for each change.) > > 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. > >You can't just hand-wave away the complexity of canned cycles, > >subroutines, etc. for this problem. > > Why not? - Commercial controls don't feed hold in canned cycles, > macro's or loops. You didn't read my first message. Imagine this bit of lathe code: N100 G0 Z1.10 (position beyond end of part) N101 G0 X0.25 (position at major diameter) N102 G1 Z0.00 (turn major diameter) N103 G0 X0.50 (get clear) N104 G0 Z1.20 (position beyond end) N105 G0 X0.30 (major diameter) N106 G76 blah blah blah (thread the part) N107 G0 Z1.00 (position at end) N108 G0 X0.20 (prepare for chamfer) N109 G1 X0.25 Z0.95 (cut 45 degree chamfer) I'm using the tip of the threading tool to turn the major diameter of the part and to chamfer the end of the thread. It would be nicer to use a tool changer to switch between threading and turning tools, but not everyone has one of those. Now suppose the user hits pause while turning the major diameter. No canned cycle is in effect. But the interpreter has already read, processed, and queued all of the motion for the threading cycle and the chamfer. All those moves have been calculated, offseted, etc. All of those moves need to be discarded if you change offsets, which will happen if you touch off. > The penchant for code programmers writing G code as macros is certainly > not encouraged in any CNC companies I've dealt with. Program length is > not a problem these days, simplicity of individual lined code is more > important than file length, it's easier to understand and edit if > required by a non programmer operator, and allows feed holds if > required. I can see this as an objectionable idea for programmers, > certainly not so for the poor op who has to try and decipher overly > complex Gcode. The practical advantages of simple code far outweigh any > programming kudos. 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. About 95% of my lathe programming is done by copying one file and editing it. It starts with a bunch of subroutines, for things like facing, boring, turning, etc. I never have to touch those. The actual part program follows the subroutine definitions, and consists almost entirely of calls to the subroutines. I can program a new part very quickly that way. I don't have to figure out roughing and finish passes, etc - the subroutines do all that for me. You write g-code your way, I'll write it my way. Nobody forces you to use subroutines, loops, and the other advanced features of EMC2's g-code. But we're not going to implement "pause" in a way that makes it useless to people who do want to use those features. > >The above is simple facts about how EMC works, and some of the > >reasons why what you want is somewhere between "very hard" and > >"impossible". > > This encouraged me to be more optimistic than you seem to be. 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. > A clear Mission Statement may help with any confusion in the future? You still seem to think that EMC2 is a business, complete with a top-down heirarchy, where bosses write "Mission Statements" and tell the peons what to do. You say you are an engineer - then you should be accustomed to dealing with technical issues, and cooperating with engineers and experts in fields other than your own. You don't need to be a programmer to understand the issues that I've described. If you make good faith suggestions that actually address the issues, you will get good faith answers. The answer might be "that looks promising", or "that won't work, because of this detail that was skipped over in the simplified description", or "that won't work, but it gives me an idea for something else that might". In any case, the result will be discussion and progress. But if you simply keep telling us how things "should be", we will simply tell you how they are, and then ignore you. Regards, John Kasunich -- John Kasunich [email protected] ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
