Bravo John! That was not only the best description I've read of EMC's workings but also one of the more thoughtful and well constructed rants I've heard on this or any other forums. As my own rant I have to say that I've shaken my head several times after reading some of the demanding posts lately. I am a "noobie" at this but I'm astounded at the functionality of this free software as well as the level of support available from its developers and users. The biggest limitations I've encountered thus far are my own. It's my hope to continue to learn and become a contributor to this wonderful software myself.
________________________________ From: John Kasunich <jmkasun...@fastmail.fm> To: Enhanced Machine Controller (EMC) <emc-users@lists.sourceforge.net> Sent: Mon, May 17, 2010 1:50:44 AM Subject: Re: [Emc-users] Jog under PAUSE / tool cnange 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 -- John Kasunich jmkasun...@fastmail.fm ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
