On Mon, 17 May 2010 02:50:44 -0400, you 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? >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. >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. >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. >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. 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. >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. "I think it's surely doable, but there are a lot of things missing before someone can start coding on this. Fist a complete spec how things should work/shouldn't work. - what is allowed during a pause? everything? only jogging? some MDI? all g-codes? running subprograms? - what happens when the user wants to resume? how does the resume work? are there special cases (arcs, threading, cycles, etc)? I'd start by creating a wiki page (surely this is a community effort where everybody can jump in with ideas, inspirations, etc), and when something starts to form concept-wise I'm sure someone might/will actually implement it. Regards, Alex " >> No new features get "developed" unless one of them >> (the developers) wants it for himself. > >There is a lot of truth to this. You seem to have a problem >with the idea, but it is fundamental to free software. Not a problem now you have confirmed this is so. It has been denied in the past. A clear Mission Statement may help with any confusion in the future? >So yes - most features get developed when a developer wants >that feature for himself. Such is life. > >> Where do these features come from, who is tasked to >> write them > >This is not a business, where programmers are paid to do >whatever the boss wants done. You don't "task" free >software developers, you ask them. Perhaps the following needs re wording. This lead me to believe that suggested features are prioritised, then "tasked". The official feature request tracker is found at https://sourceforge.net/projects/emc/ under the menu item RFE. This listing shows requested features, the priority assigned to each, and the person assigned the task of coordination of effort toward implementing the feature. Steve Blackmore -- ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
