I've taken the liberty of memorializing John's post (without what he refers to as a rant that may be removed) at: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?WhyManualWhilePausedIsHard
I've also added a link to it from the page: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ManualWhilePaused [I've assumed that is OK with John -- if not, please delete it.] Regards, Ken On 5/17/2010 2:50 AM, John Kasunich wrote: > > On Mon, 17 May 2010 02:40 +0100, "Steve Blackmore"<st...@pilotltd.net> > wrote: > > >> look at the wiki page, nobody is asking that it works during >> macros, canned cycles, loops or any other excuse that can be >> made to not implement it. >> > How about this excuse: > > (Note: to understand this, you will have to think like a developer > for a while. That means you need to understand the basic internal > architecture of EMC2, and you need to think in detail about how to > implement what you want, not just what you want the machine to do.) > > First: Basic EMC2 architecture. EMC consists of several levels. From > the top down, it goes GUI, Interpreter, Motion Controller, HAL. (I'm > leaving out a lot, but this is still going to be too long, so forgive > any oversimplification.) The first two levels are normal "user space" > programs. Like all normal programs, they are at the mercy of the > operating system and any other programs that are running at the same > time. > > When the computer gets busy, regular programs temporarily stop or > slow down while the operating system or another program does something > else. Everybody has experienced that with everyday programs. You > click on something that normally happens instantly, but it takes a > half-second or a couple of seconds instead. That kind of thing > happens all the time, usually for a tenth of a second, or a hundredth, > and you never notice, but it is there. Not a big deal with normal > computer programs, and not even a big deal for the GUI of a machine > tool. But not acceptable for the low-level motion control. > > To avoid this problem, EMC runs the motion controller (and HAL) as > realtime processes. When a realtime process is configured to run > every 1000th of a second, that is exactly what you get, no matter > how busy the rest of the computer gets. (There is still a small > amount of variation, measured in microseconds, but we're ignoring > that). > > The motion controller runs 1000 times a second. Most of the time, > all it does is calculate a new position a little farther along the > line or arc described by the current line of g-code. But sooner > or later that line or arc ends, and a new one starts. When that > happens, the info about the next line of g-code MUST be available. > That info comes from the g-code interpreter. But what if the > interpreter happens to be right in the middle of a 1/10 second > delay? > > EMC solves this problem with the motion queue. The queue holds a > couple hundred motions (lines, arcs, etc). The interpreter runs > as fast as it can, turning g-code into simple motions and putting > them in the queue. The motion controller takes them out of the > queue and moves the tool. > > What this means is that the interpreter is usually many lines > ahead of the motion controller. The interpreter applies work > offsets to each move. It translates units from whatever the > program uses (inches or mm) to machine units. It applies cutter > compensation and tool length offset. It breaks canned cycles > down into individual lines and arcs. After doing all of that, > it puts the lines and arcs into the motion queue. > > 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. > > All of the above information is background - a very simplified > version of what happens as EMC runs a program, just enough to > explain what the motion queue is and why we have it. Now lets > think about implementing "pause/jog/run". > > Steve has put his thoughts into the wiki page at > http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ManualWhilePaused > He says "EMC need only remember the axis positions it stopped > at and on resume should always do a combined move back to that > position." > > So, how can we do that? I assume he doesn't want to wait till > the end of a line or arc to stop. If the tool breaks or swarf > wraps 1 inch into a 10 inch long cut, you need to stop now. So > that means we MUST do this in the motion controller, since the > interpreter simply queues up complete moves and doesn't know > anything about the middle of a move. > > It might be practical to implement pause/jog/resume entirely > in the motion controller. Jogging is currently done there, so > it isn't out of the question for the controller to remember > the current position, let you jog away, then do a move back to > the remembered position. There are plenty of messy details, > but no fundamental problems - as long as ALL you want to do > is jog. > > Steve also writes: "The only requirements are to jog, toggle > spindle and coolant on/off and touch off current tool. MDI may > be useful to allow accurate axis positioning." > > Already said jogs can probably be done. 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. 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.) > > So - here we are, with the motion controller paused in the > middle of an arc, and another 2 or 20 or 200 lines and/or > arcs sitting in the queue. We can't wait for the queue to > empty, because it won't. So we need another method to get > the spindle and coolant commands to the motion controller. > This is not impossible, but it adds complexity and might > introduce bugs - when you have two channels that can send > commands to the motion controller, you need to carefully > coordinate them to make sure the controller is listening > to the right one at the right time. Let's assume that we can > deal with all those nasty details - spindle and coolant control > is possible, just tricky. > > Next on the requirements list is touch-off. Here it gets very > nasty. Touch-off changes a coordinate system offset. But the > interpreter applies offsets before any line or arc goes into > the motion queue. When we stopped the motion controller, there > were still 2 or 20 or 200 lines and arcs in the queue using the > old offsets. Those motions will happen after we resume with > the new tool, so they will be wrong. We must throw away all > the queued motions, back the interpreter up, and re-queue with > the new offsets. This is NOT just a matter of nasty details. > There are fundamental problems with "backing up" the interpreter. > > You can't just hand-wave away the complexity of canned cycles, > subroutines, etc. for this problem. Just because you paused > in the middle of a very ordinary move doesn't mean that the > queue doesn't contain motions that were part of a canned cycle > that happens later in the program. You have absolutely no > control over what got discarded from the queue. > > After the touch-off requirement, Steve said that MDI "may be > useful". Consider that MDI uses the exact same interpreter as > normal program execution. If you've ever noticed that you can > type several lines of MDI while the first one is running, that > is because MDI lines are interpreted and stuffed into the motion > queue just like regular lines. > > So, to do MDI we not only have to throw away every programmed > motion that is in the queue, we also have to use the interpreter > to process the MDI commands. That means that any of the internal > data used by the interpreter might change as the operator uses > MDI. This makes it even harder to "back up" the interpreter > when it is time to resume the g-code program. > > 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". It took me over an hour to think it through and > write it up, and I've barely scratched the surface of the problem. > > Although I've contributed thousands of lines of code to EMC2, > I'm mostly focused on HAL and the motion controller, and I don't > know enough about the interpreter to understand all the issues > involved in this feature. It would take several more hours and > input from other programmers before I could even begin to estimate > the amount of work needed, or have any confidence that all > "show-stopper" issues have been identified. > > Now we get to the reason I spent the time writing the above. > Warning, this is a rant: > > >> 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. > > In a business, the customers wave money and say what they > want, the employees do the work, and the bosses hope that > they can get more from the customers than they have to pay > the employees. That is how they make a profit. > > In an open source project, there are no bosses and no profit. > The customers do not wave money and the "employees" don't get > paychecks. At first glance, there is no reason it should > work at all. Why should programmers spend thousands of hours > thinking through complex technical issues and writing and > debugging tens of thousands of lines of code, for nothing? > > But it does work. It works because programming can be fun. > It works because some programmers are craftsmen who get > satisfaction from creating something that they can be proud > of. It works because some programmers simply like to make > people happy. > > It works best when the programmers are also the customers. > > They don't have to wave money at themselves - they just write > the code to do what they need. Sometimes they know it will > be easy, and just do it. Sometimes they know it will be hard, > but they want it bad enough to do it anyway. Sometimes they > think it will be easy, but it winds up hard. In business, > those are the projects that get canceled due to cost overruns. > In free software, the boss is also the programmer is also the > customer, and if he wants it bad enough it happens in spite of > "overruns". > > 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. They will do the work > because they want to make you happy, or because they > consider the feature a technically "elegant" addition to > the program, or because it is fun, or for whatever other > reason motivates them to contribute to the project. > > In a business, nothing gets done unless it is expected to > be profitable, and that means having a good idea of exactly > what the job is going to cost. You wouldn't quote a > machining job until you sit down and estimate the cost > of doing it. > > Now imagine a customer who cannot do the work himself, does > not have a good understanding of exactly how much work is > needed, refers to the opinions of those are familiar with > the type of work as "excuses", and suggests that they don't > know much about the "real world". Would you as a business > owner want to serve this customer? > > >> Discussing would be a start! >> > Consider the first 2/3 of this message my contribution to > the discussion. > > The last third is a rant - I'll freely admit that. But I > don't think the discussion can be useful unless everyone > involved understands what motivates people to work on free > software. > > Feel free to chop the last part, and reply to the technical > issues - they are the issues that need to be solved if > this feature is ever going to happen. > > John Kasunich > -- Kenneth Lerman 55 Main Street Newtown, CT 06470 203-426-3769 ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
