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
Re: [Emc-users] Jog under PAUSE / tool cnange
On Sun, 16 May 2010 21:08:40 -0500, you wrote: As soon as a use presses ok, I don't want it go linear line to the stopped point, but I want to put a option to align in order. For example first X and Y, then Z. This way I will have less chance to crash the tool in the part. I think this will work good for lathe's and XYZ type routers. I've used both methods and the sequential axis method is more prone to operator error. It's easy to see where a straight line move will actually go and it's very easy to position a tool where it wont hit clamps or stock. Not so with sequential axis moves, there is no ideal order that will work in all circumstances. Steve Blackmore -- -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
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
[Emc-users] connect with port com
Hi, I have a question, i hope to help by. I want to use pyserial in EMC in order to accept data from peripheral device, for example control panel. How is way? thank you! Name: Hoang Van Binh Mobile: 01656110660 Michatronics_ Hà Nội university of technology * -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
I like that description John. I'm myself are aware of problems of realtime programming as I do that daily with microcontrollers but other user's doesn't know that problems. I know that editing/modifiing realtime software is pain. You make new function and other one stops work as should. It's nasty. And my program's are up to about 40 kilobyte of machine code and EMC2 is hughe. But! Yes there is But. It can be done! And it should be done! Why? Beacouse all workaround are so messy and dangerous that we should minimise risk! Is someone milling plastic and swarf catch the tool the user want to pause and cleanup the tool as they know that this mees will burn part. And how he can do that? It can pause machine and can stop spindle(not in emc but there should be some external controll too) Now the plastic can be wraped around tool and the only way to get it out is to cut that from spindle as we can't jog in out of the work. And cutting with sharp knife in sharp tool isn't good idea. another one: The user drill printed circuit board. They broke drill bit and pause machine. How to replace it? In software as is there are no way to do that. But has some messy workaround. as stop program jog machine and resume last line and forgot that pisece of broken bit is in that hole and restart just to broke another one. But if we PAUSE machine the motion queue can be cleaned! For resumming we only need the last (paused) position and line where it happens to resume on just right spot and fill up the motion queue with new data. It can be done. And the last. The people (developers) makes great program for free. So we can only to have wish what we want and they wil decide if thing wil be done. That's true. If they don't need that stuff then this will be done latter.(if at all) Is someone of developer come to Slovenia then just drop the mail and I wil fillup the fridge with beer. There this is the only payment method with opensource and free program as EMC2 is. Slavko. p.s. Just one thing. What software (or machine) doesn't alow jog under pause? -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Sorry, I did not read the complete thread. Maybe there is an easier solution to this problems: How about if emc would store the gcode position after a stop/emergency shutdown,i.e. the last completely finished move. And if there would be a continue button, where emc will replay the complete gcode in fast mode, without actually sending any moves. Only if the stored line is reached it will continue to send. Its a bit complex, with loops and stuff... It would be necessary to assume a save path to reach the position initial to the last complete move. If the user knows this, he can manually jog to a safe continue position where a direct move from will do no harm. Additional Idea: having enabled/disabled breakpoints in the gcode-view. Users can create/activate/disable/delete breakpoints in given lines (ignoring multiple moves per line). A stop of any kind automatically creates one disabled breakpoint, maybe with a additional label of the current date/time. This breakpoints settings are lost if a new gcode file is loaded by open, if reload is pressed, the line breakpoints numbers are conserved (potentially usafe, if lines shift, but mostly usefull). greetings, bernhard.. On 5/17/2010 11:01 AM, Slavko Kocjancic wrote: I like that description John. I'm myself are aware of problems of realtime programming as I do that daily with microcontrollers but other user's doesn't know that problems. I know that editing/modifiing realtime software is pain. You make new function and other one stops work as should. It's nasty. And my program's are up to about 40 kilobyte of machine code and EMC2 is hughe. But! Yes there is But. It can be done! And it should be done! Why? Beacouse all workaround are so messy and dangerous that we should minimise risk! Is someone milling plastic and swarf catch the tool the user want to pause and cleanup the tool as they know that this mees will burn part. And how he can do that? It can pause machine and can stop spindle(not in emc but there should be some external controll too) Now the plastic can be wraped around tool and the only way to get it out is to cut that from spindle as we can't jog in out of the work. And cutting with sharp knife in sharp tool isn't good idea. another one: The user drill printed circuit board. They broke drill bit and pause machine. How to replace it? In software as is there are no way to do that. But has some messy workaround. as stop program jog machine and resume last line and forgot that pisece of broken bit is in that hole and restart just to broke another one. But if we PAUSE machine the motion queue can be cleaned! For resumming we only need the last (paused) position and line where it happens to resume on just right spot and fill up the motion queue with new data. It can be done. And the last. The people (developers) makes great program for free. So we can only to have wish what we want and they wil decide if thing wil be done. That's true. If they don't need that stuff then this will be done latter.(if at all) Is someone of developer come to Slovenia then just drop the mail and I wil fillup the fridge with beer. There this is the only payment method with opensource and free program as EMC2 is. Slavko. p.s. Just one thing. What software (or machine) doesn't alow jog under pause? -- ___ 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
Re: [Emc-users] Jog under PAUSE / tool cnange
Slavko Kocjancic pravi: p.s. Just one thing. What software (or machine) doesn't alow jog under pause? Uff I forgot that one. EMC2 -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
On 17 May 2010 09:12, Ian W. Wright watchma...@talktalk.net wrote: As my initial suggestions - I can't see why the program would have to return to exactly the same place in the script as it was when it was paused before the jog surely it could return to the start of the 'block' or line it was cutting at the pause.. This would be simpler (I think). You basically throw away the queue when pause is pressed and run from line but if you imagine needing to unclog a cutter near the end of a very long slot, you could have been in that same G-code line for 20 minutes. Assuming that the trajectory planner works in machine coordinates; my initial idea of dry running through the code until you reach the coordinates where pause was pressed then going live is a non-starter as a change in work or tool offsets means that you won't reach the same machine coordinates. it seems that the reason that jog-on-tool-change is possible is that the motion controller stops there anyway (and expects to stop there). I guess this means that jog-on-tool-change is relatively easy, though perhaps it needs to refuse to restart unless it is at it's safe retract position to save the risk of wiping out clamps and work on the way back from the touch-off fixture. How does the Axis Preview work? Does that use the same command interpreter or a cut-down version? I can't seem to get away from needing to do a dry run of the G-code up to the point where the relative coordinates and G-code program line match and then start loading the motion queue. -- atp -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
On 05/17/2010 04:12 AM, Ian W. Wright wrote: Well said John. I, for one, am extremely grateful for all the work that the 'developers' have put into EMC over the years. While I have never used EMC in a commercial sense, I have followed its development almost from its inception and have always been really impressed by the commitment of its developers and their willingness to try to solve the most obscure of problems for its many users. I can't think of another single program which can cope with the sheer variety of different machines and strategies that different people use. I would also like the facility to pause and jog but I can well understand the difficulties involved in implementing it - just getting 'run from line' to work well took ages and, at least on my installation which is the last of the 2.3 versions, still doesn't restart the spindle reliably. As with so many problems in life, getting this request to work is probably more a question of thinking out a strategy rather than actually coding and it may be that even those with no coding abilities, like myself, can help in this respect. Discussions and suggestions, however far fetched, may just spark an idea which hasn't been considered before and this may lead to a solution to the problem. If other, commercial, programs have this feature, then it must be possible and so it will just be a matter of figuring out the correct strategy. As my initial suggestions - I can't see why the program would have to return to exactly the same place in the script as it was when it was paused before the jog surely it could return to the start of the 'block' or line it was cutting at the pause.. Since one of the biggest stumbling blocks seems to be canned cycles and subroutines, maybe these could be separated out from the rest of the script by the interpreter and stored in a different place to the main script, being then called by the main script as separate 'programs' as required. Then, when the program restarts after a pause and jog, just the main script could be scanned and reloaded - - I'm probably talking rubbish here - it just shows how limited my programming skills are!! Ian I've got no dog in the Jog under PAUSE/tool change discussion, other than to give my thanks and praise to the folks that make all this possible by writing, compiling, testing and using the code that underlies this awesome piece(s) of software. Sheer variety of machines? Whooo boy. Which developer ever figured that EMC2 would be used on a machine of my design, that would cut extremely finely tapered bamboo strips that would be glued up into a bamboo fly fishing rod... ;-) And the help I got from the folks that seem to live, eat, sleep, and breathe on the IRC? (Special thanks go out to Michal G(I'm not gonna try and spell your last name cuz I know I'll screw up it... ;-}) who got me going in the right direction with a quick re-write of my hal and ini files.) I'm now trying to understand the complexities of G Code. You guys that have been using it for a while can giggle, that's okay. I was a noob ADA, C, Java and Lisp coder once too, and I can remember the initial uphill learning curve to picking up a new language and then understanding and using it on a daily basis. That's part of the fun though. Once that part is overcome, it becomes old hat. I think once I get up to speed on this stuff, I'd like to volunteer my time in the development stuff. My coding skills are a little rusy, but I still know all those languages above, some shell programming, and a sysadmin level of Perl usage. If any of those skills can be useful to the program, please let me know and I'll be happy to participate. Mark -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
On 17 May 2010 10:01, Slavko Kocjancic esla...@gmail.com wrote: Is someone of developer come to Slovenia then just drop the mail and I wil fillup the fridge with beer. I have always promised myself I would go back to Slovenia (we blasted through without stopping on the way to Romania in 1999 having read that there was nowhere to buy fuel on a sunday. This proved to be untrue, and what little we saw of Slovenia was lovely. Of course, I would need to become a Dev first, now where did I put that copy of Kernighan and Ritchie? -- atp -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Servo stepper mix
Hello! You can use any kind of motor for any joint on the machine. You can also use more than one type of hardware, so for instance you could have a Pico Systems card on one parallel port, use a second parallel port directly, and use a PCI plug-in Mesa card, all at once. I am confused and I would like to know, where can I find more detailed information on this matter. I am concerned, how do I configure EMC to work with Mesa card for servo control on 2 axis and use parallel port to output step/dir signals time for remaining 3 axis at the same. Has anyone ever attempted (and succeeded) with this approach? with best regards, Viesturs Lācis -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Andy Pugh pravi: On 17 May 2010 09:12, Ian W. Wright watchma...@talktalk.net wrote: As my initial suggestions - I can't see why the program would have to return to exactly the same place in the script as it was when it was paused before the jog surely it could return to the start of the 'block' or line it was cutting at the pause.. This would be simpler (I think). You basically throw away the queue when pause is pressed and run from line but if you imagine needing to unclog a cutter near the end of a very long slot, you could have been in that same G-code line for 20 minutes. Assume program: N1 G01 X100 Y100 N2 G01 X300 Y-10 N3 G01 X0 Y0 If you stop/pause that progran let's say in N2 just before they end and save coordinate like G30.1 and do jog or whatever... And if you restore coordinate like G30 the machine wil go to the point where is paused (linear line) and if you rerun line N2 it wil do just smal move to the end at X300 Y-10 not the whole thing from X100 Y100 to X300 Y-10 It should work at least with G0/1/2/3 (G2/3 with radius can be problematic but not with I,J) In case of canned cycle the restore of Z axis can be problematic. I think to restore from backoff Z is much safer. (and to decide retry last canned cycle or skip to next) For my knowledge the only stop point and line is needed and queue can be cleaned. The stop point can be probably saved (we must wait to machine do real stop with deceleration) and line is already known. (or axys lye where program is) Slavko. -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Spirograph Curves
Hmm, well my webstats say there have been over 200 unique visits to the spirograph page, but as yet not a single comment Can anybody give me some feedback, good or bad :) Cheers, Andy. -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Andy Pugh wrote: it seems that the reason that jog-on-tool-change is possible is that the motion controller stops there anyway (and expects to stop there). I guess this means that jog-on-tool-change is relatively easy, though perhaps it needs to refuse to restart unless it is at it's safe retract position to save the risk of wiping out clamps and work on the way back from the touch-off fixture. This is, I think, the crux of the problem. It is not so much the 'current position', but that the trajectory planner simply does not have enough information to work on when stopped 'mid flow'? It should be possible to tag 'safe' points, but as has been pointed out, these could be some time or distance from the actual current cutting point. Even dry running will not necessarily get to the same point, and invariably there will be a 'mark' of some sort where the cutter picks up again in the work simply because it is not now cutting up until that point. Steve ... I think the main problem here is not so much that nobody wants to do it, but rather nobody can get their head around the mathematics to work out HOW to do it ;) Perhaps we need to flag possible 'stop points' through the code where the trajectory planner can work from? Virtual tool change points ;) -- 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
Re: [Emc-users] Servo stepper mix
2010/5/17 Viesturs Lācis viesturs.la...@gmail.com: I am concerned, how do I configure EMC to work with Mesa card for servo control on 2 axis and use parallel port to output step/dir signals time for remaining 3 axis at the same. Effectively you just combine all the elements from the typical HAL files (either in one HAL file, or declare more than one HAL file in the INI) It will take some fiddling, but the easiest way is probably to create a Mesa config with PNCconf, and a stepper config with stepconf, then combine them. You will need to combine any duplicated loadrt and addf statements, and there will be some duplication of spindle speeds and e-stops etc that will need to be resolved. -- atp -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Thanks for both providing a framework to context requests and teaching me something about how EMC works. Save a copy. I'm sure it will be useful again in the future to context another request. Unless one has dealt with the details of complex systems is easy to assume that if it seems like it should be simple it is, or that if it is simple for a person it is easy to instruct a machine to do it. Craig On 5/16/2010 11:50 PM, John Kasunich wrote: On Mon, 17 May 2010 02:40 +0100, Steve Blackmorest...@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,
[Emc-users] G76 thread depth
I have noticed that I need a lot more thread depth in G76 than the tables say I should need. For instance an M12 thread should have a thread depth of 1.08mm, but I needed 1.55mm before the nut would fit on. I was using a 29.5 degree compound slide angle (Q), do I need to allow for this like you would manually machining? Is it possible that things are getting confused by being in diameter mode? (I have already realised that the first cut is I inside the start position, though it took a while) -- atp -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] G76 thread depth
On a side note, G76 on our Fanuc, using thread depth out of the machinist handbook/threadmaker app, we finish OD threads at a good -.010 to -.030 ( varies by diameter and pitch) wear offset before the gages show the thread in tolerance. Seems like a common problem in other words. On Mon, May 17, 2010 at 6:27 AM, Andy Pugh a...@andypugh.fsnet.co.uk wrote: I have noticed that I need a lot more thread depth in G76 than the tables say I should need. For instance an M12 thread should have a thread depth of 1.08mm, but I needed 1.55mm before the nut would fit on. I was using a 29.5 degree compound slide angle (Q), do I need to allow for this like you would manually machining? Is it possible that things are getting confused by being in diameter mode? (I have already realised that the first cut is I inside the start position, though it took a while) -- atp -- ___ 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
Re: [Emc-users] Jog under PAUSE / tool cnange
Jog on tool change (or on pause) should be straight forward. At the pause, simply remember each of the jogs. Then when resume is executed, play them back in reverse order. I believe that all of this can be done with HAL components. This would NOT solve the touch off problem. One could, of course, use an offset HAL component that could be used as part of a touch off. Ken On 5/17/2010 6:12 AM, Lester Caine wrote: Andy Pugh wrote: it seems that the reason that jog-on-tool-change is possible is that the motion controller stops there anyway (and expects to stop there). I guess this means that jog-on-tool-change is relatively easy, though perhaps it needs to refuse to restart unless it is at it's safe retract position to save the risk of wiping out clamps and work on the way back from the touch-off fixture. This is, I think, the crux of the problem. It is not so much the 'current position', but that the trajectory planner simply does not have enough information to work on when stopped 'mid flow'? It should be possible to tag 'safe' points, but as has been pointed out, these could be some time or distance from the actual current cutting point. Even dry running will not necessarily get to the same point, and invariably there will be a 'mark' of some sort where the cutter picks up again in the work simply because it is not now cutting up until that point. Steve ... I think the main problem here is not so much that nobody wants to do it, but rather nobody can get their head around the mathematics to work out HOW to do it ;) Perhaps we need to flag possible 'stop points' through the code where the trajectory planner can work from? Virtual tool change points ;) -- 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
Re: [Emc-users] Jog under PAUSE / tool cnange
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 Blackmorest...@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
Re: [Emc-users] G76 thread depth
On 17 May 2010 13:08, Daniel Goller mor...@gmail.com wrote: On a side note, G76 on our Fanuc, using thread depth out of the machinist handbook/threadmaker app, we finish OD threads at a good -.010 to -.030 ( varies by diameter and pitch) wear offset before the gages show the thread in tolerance. Seems like a common problem in other words. I have been looking at http://www.tribology-abc.com/calculators/metric-iso.htm And see plenty of scope for confusion, but I am not sure that the diagram is actually right. It seems to indicate that the nominal diameter is to the centre of the crest-rounding, so the actual OD is bigger than the nominal size, whereas every bolt I have ever measured is less than the nominal diameter. -- atp -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Slavko, On Mon, May 17, 2010 at 4:15 AM, Slavko Kocjancic esla...@gmail.com wrote: Slavko Kocjancic pravi: p.s. Just one thing. What software (or machine) doesn't alow jog under pause? Uff I forgot that one. EMC2 Forgive me if I did not understand the tone of this post. I speak English and a little Spanish so I understand the difficulties of expressing an idea with complete clarity in a second language. Hell, I understand the difficulty of expressing an idea in my native language. :) It seems many times my employees have heard me say 'Just do whatever the hell you want to do' when in reality that is NOT what I said. My first experience with a retrofit was with MDSI's OpenCNC software. purchase software for 5 axis mill - $12,500.00 purchase hardware to MDSI spec - $6,000.00 purchase training at MDSI facility- $2,500.00 + travel and expenses purchase help for machine start in my shop - $3,000.00 + travel and expenses Up to now this does not include having the machine wiring designed and installed. That was another $25,000.00. This does not count my time to learn and install and configure the software and hardware. My guess is if you would offer someone this kind of compensation you would be able to dictate the project. With EMC2, you can do each of these projects yourself, ask questions and receive answers and help for free. I may be wrong but if the feature you want is valuable enough then I think you could fund the development and then sell the feature to interested people. I don't know all the requirements of this endeavor. You would have to research that also. I am sure everyone would be happy if you would fund this project and then release it to EMC2 for everyone to enjoy. The 'developers' have done this. Is there another FREE software package that has the features you want? I understand the desire for needed capability. I need some capability for two of my machines. They each have Fanuc controls. To add the capability my options are as follows: Fanuc 16i control 4 axis dynamic fixture offsets - $6000.00 + installation install EMC2 my choice of these options- I could choose to keep the Fanuc control and pay for the feature. Probably not as I want all my machines to have EMC2. Fanuc 15MB options not available retrofit new Fanuc control- did not price as I know this is way more than I would want to spend install EMC2 my choice of these options- EMC2 is my only option Just like me you have options. thanks Stuart -- dos centavos -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
I can't belive that we are talking so much how hard is to implement this. And nobody implementing this just beacouse is hard. http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?EmcFeatures There are features that at least 90% of user's doesn't need. But will be added just beacouse they are simple to implement. :-( -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Stuart Stevenson pravi: Slavko, On Mon, May 17, 2010 at 4:15 AM, Slavko Kocjancic esla...@gmail.com wrote: Slavko Kocjancic pravi: p.s. Just one thing. What software (or machine) doesn't alow jog under pause? Uff I forgot that one. EMC2 Forgive me if I did not understand the tone of this post. I speak English and a little Spanish so I understand the difficulties of expressing an idea with complete clarity in a second language. Hell, I understand the difficulty of expressing an idea in my native language. :) It seems many times my employees have heard me say 'Just do whatever the hell you want to do' when in reality that is NOT what I said. Well I didn't speak english very well. So if my post hurt somebody thet is not my intention! I just want to say that some common and needed feature (i found it in a other software and machines) doesn't implemented in EMC2 and should be! Now I have some small pcb drilling CNC with my own software controller and one biger CNC with EMC2. And I install EMC2 instead something else (or write by myself) I didn't do that beacouse I know that this is not easy task. EMC2 is good. But We Want to be better. And that jogging definetly will make EMC2 better - more user friendly. Slavko. p.s. I want to say: We need that feature Please. not to say: stupid developers why this isn't already there. :-D -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Re-starting from the beginning of the line of g-code that was PAUSED would work for most applications. Consider this as a possible and useful partial solution. This still might be messy with loops and other complications like coolant pump state but could prove easier to program. What would be the problems with cutting some air as part of restarting?? There probably are problems in some applications and some of these problems might also apply to starting mid-move. Comment from people who know more about machining than I do? Craig -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Salvko, i think it would be a good idea to seperate item 15 into two items: 15) JOG under PAUSE - Alow users to jog machine when program is paused. 16) JOG under ToolChange - Alow users to jog machine when program M6 executed. The TouchOff? should be enabled too and maybe even MDI Although they look the same, the problem domain is in both cases somewhere else. As noticed before, item 16) is possible easer to solve then item 15) because of various internals With 15 it would be just fine if you can jog out, stop the spindle clean the workpiece, clean the bit and the machine and continue. For me personally it would already be awesome if when I press pause the tool will just move up and spindle stop (not need for jogging) The problem with 15) is that you can pause in the middle if a running line, and it's hard to re-start in the middle of an operation. With 16) The machine stops at a distinct line and already can continue from there, we just need to have a way to touch off (can that be done with the modified manual hal toolchange??) If they are broken into two piece, it will be easer to solve because a programmer can just concentrate on a easer task. Ries PS: I am going to modified the hal:manualtoolchange a bit so it will find the start point of 3 axis routers better, my little project for EMC :) On May 17, 2010, at 8:22 AM, Slavko Kocjancic wrote: Stuart Stevenson pravi: Slavko, On Mon, May 17, 2010 at 4:15 AM, Slavko Kocjancic esla...@gmail.com wrote: Slavko Kocjancic pravi: p.s. Just one thing. What software (or machine) doesn't alow jog under pause? Uff I forgot that one. EMC2 Forgive me if I did not understand the tone of this post. I speak English and a little Spanish so I understand the difficulties of expressing an idea with complete clarity in a second language. Hell, I understand the difficulty of expressing an idea in my native language. :) It seems many times my employees have heard me say 'Just do whatever the hell you want to do' when in reality that is NOT what I said. Well I didn't speak english very well. So if my post hurt somebody thet is not my intention! I just want to say that some common and needed feature (i found it in a other software and machines) doesn't implemented in EMC2 and should be! Now I have some small pcb drilling CNC with my own software controller and one biger CNC with EMC2. And I install EMC2 instead something else (or write by myself) I didn't do that beacouse I know that this is not easy task. EMC2 is good. But We Want to be better. And that jogging definetly will make EMC2 better - more user friendly. Slavko. p.s. I want to say: We need that feature Please. not to say: stupid developers why this isn't already there. :-D -- ___ 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
Re: [Emc-users] Jog under PAUSE / tool cnange
One of the many problems with Jog under Pause is that a pause can interrupt a partial move. Run From Here can get you back to the beginning of the interrupted move. How hard would it be to have EMC figure out how to break the interrupted move into two pieces so that it could bring you back to the splice point? Could this be successfully managed even if the interrupted move was in a subroutine? If it could be done, it should be a way to allow tool offsets to be altered during the pause. Regards, Steve Stallings -Original Message- From: Kenneth Lerman [mailto:kenneth.ler...@se-ltd.com] Sent: Monday, May 17, 2010 7:39 AM To: emc-users@lists.sourceforge.net Subject: Re: [Emc-users] Jog under PAUSE / tool cnange 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 -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
While i would be thrilled to stop mid cycle, change insert, move back and continue, (we do it all the time on long (roughing) passes on our Fanucs, we note the position, move away, index turret, change insert, index back to current tool, move back to point we stopped cutting at and back in auto, hit cycle start, to complete the (G71) cycle) I would think the automation of moving tools up is already adding more complexity than necessary, the control then would need to know what kind of tool you have to see if it is safe to pull up. A jog on pause could be left to the operator. The DRO could store the position when program was paused, displaying the Last Auto position, and the operator uses the current position DRO to know he/she went back to the place where the program was paused. From this point the program should be possible to be continued. Since the program was never stopped, all parameters like speed, feed, offsets should all be in the state as they were when the program was paused. The safety aspect lies with the operator, as it does when setting tool length offsets and checking clearances to chucks and workholding in general. This way 15) sounds simple and useful (to me). On Mon, May 17, 2010 at 8:51 AM, Ries van Twisk e...@rvt.dds.nl wrote: Salvko, i think it would be a good idea to seperate item 15 into two items: 15) JOG under PAUSE - Alow users to jog machine when program is paused. 16) JOG under ToolChange - Alow users to jog machine when program M6 executed. The TouchOff? should be enabled too and maybe even MDI Although they look the same, the problem domain is in both cases somewhere else. As noticed before, item 16) is possible easer to solve then item 15) because of various internals With 15 it would be just fine if you can jog out, stop the spindle clean the workpiece, clean the bit and the machine and continue. For me personally it would already be awesome if when I press pause the tool will just move up and spindle stop (not need for jogging) The problem with 15) is that you can pause in the middle if a running line, and it's hard to re-start in the middle of an operation. With 16) The machine stops at a distinct line and already can continue from there, we just need to have a way to touch off (can that be done with the modified manual hal toolchange??) If they are broken into two piece, it will be easer to solve because a programmer can just concentrate on a easer task. Ries PS: I am going to modified the hal:manualtoolchange a bit so it will find the start point of 3 axis routers better, my little project for EMC :) On May 17, 2010, at 8:22 AM, Slavko Kocjancic wrote: Stuart Stevenson pravi: Slavko, On Mon, May 17, 2010 at 4:15 AM, Slavko Kocjancic esla...@gmail.com wrote: Slavko Kocjancic pravi: p.s. Just one thing. What software (or machine) doesn't alow jog under pause? Uff I forgot that one. EMC2 Forgive me if I did not understand the tone of this post. I speak English and a little Spanish so I understand the difficulties of expressing an idea with complete clarity in a second language. Hell, I understand the difficulty of expressing an idea in my native language. :) It seems many times my employees have heard me say 'Just do whatever the hell you want to do' when in reality that is NOT what I said. Well I didn't speak english very well. So if my post hurt somebody thet is not my intention! I just want to say that some common and needed feature (i found it in a other software and machines) doesn't implemented in EMC2 and should be! Now I have some small pcb drilling CNC with my own software controller and one biger CNC with EMC2. And I install EMC2 instead something else (or write by myself) I didn't do that beacouse I know that this is not easy task. EMC2 is good. But We Want to be better. And that jogging definetly will make EMC2 better - more user friendly. Slavko. p.s. I want to say: We need that feature Please. not to say: stupid developers why this isn't already there. :-D -- ___ 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 -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Servo stepper mix
On Mon, 2010-05-17 at 13:04 +0300, Viesturs Lācis wrote: Hello! You can use any kind of motor for any joint on the machine. You can also use more than one type of hardware, so for instance you could have a Pico Systems card on one parallel port, use a second parallel port directly, and use a PCI plug-in Mesa card, all at once. I am confused and I would like to know, where can I find more detailed information on this matter. I am concerned, how do I configure EMC to work with Mesa card for servo control on 2 axis and use parallel port to output step/dir signals time for remaining 3 axis at the same. Has anyone ever attempted (and succeeded) with this approach? with best regards, Viesturs Lācis It looks like a m5i20 will do this nicely. Of course it needs the pwm to analog card also unless you use a pwm servo amp but still it is a pretty simple setup. Check the wiki under HostMot2. Good luck. Dave -- ___ 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
Re: [Emc-users] Jog under PAUSE / tool cnange
Steve Stallings wrote: One of the many problems with Jog under Pause is that a pause can interrupt a partial move. Neglecting specially-shaped cutters (keyway, T-slot), and also neglecting niceties like tangent arc entries to arc moves (probably impossible since EMC doesn't know what the part is), this isn't a huge issue. Linear moves are trivial to continue from where they were left off, and arc moves aren't terribly hard (simply save the center point and radius, and you can figure out where in the arc the program was stopped. It's not necessary to go to exactly that spot, and in fact it would be nice to have an option of backtracking along the move a little anyway) Run From Here can get you back to the beginning of the interrupted move. This is probably the best thing to do in most cases anyway, the notable exceptions being loong moves (boring!) or canned cycles. How hard would it be to have EMC figure out how to break the interrupted move into two pieces so that it could bring you back to the splice point? Or close to the splice point - easy. In fact, I think there's a variable in the motion controller that goes from 0 to 1 as a move is executed - it lets the motion controller know how far it has to go in this move. (I don't know the specifics, I just recall that there's a variable for that) Could this be successfully managed even if the interrupted move was in a subroutine? Depends on where you do the interrupting. The motion controller sees a bunch of motions in the queue, not a loop or subroutine. It does arcs and lines, and manages blending between them (as well as accel/vel constraints and such). A subroutine or loop just results in more than one motion being put in the queue. Note that variable values, loop conditions, etc. are all irrelevant at the motion controller level - all the motion parameters are just numbers at this level. If it could be done, it should be a way to allow tool offsets to be altered during the pause. It seems a lot of people either didn't fully read John's email, or didn't fully understand the implications of it. (I'm just responding to Steve because this happens to be the last email I read - nothing personal :) ) Offsets are applied in the interpreter, and the already-offset motions are queued for the motion controller to execute. If you change the tool offset, the queue has to be discarded and re-filled with a new set of offset motions. Executing G-code can change the interpreter state, e.g. by changing variable values (or coordinate offsets, G90/91 motion modes ...). This increases the complexity of re-running code quite a lot, since we would need a way of returning the interpreter to the state it was in when the executing motion was queued. That's not an easy problem. - Steve -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Hello... Not bad idea to be separate item as jog under toolchange can be resolved quicker. I changed wiki and I think all command M0 M1 and M6 can behave similar. For example if someone mill plastic then can issue few M1 in program and has optional stop on M1 dissabled. If swarf come up then just enable M1 pause and have nice workaround. Maybe there is not bad idea to have another one pause button that pause program like inserting M1 after just current line?!? Easyer to implement. Beaware of one nasty thing with manualtoolchange.py! When window popup the keyboard control is on that window! If someone uses Estop in keyboard and something goes wrong during toolchange dialog then Estop button wont work! Slavko Ries van Twisk pravi: Salvko, i think it would be a good idea to seperate item 15 into two items: 15) JOG under PAUSE - Alow users to jog machine when program is paused. 16) JOG under ToolChange - Alow users to jog machine when program M6 executed. The TouchOff? should be enabled too and maybe even MDI Although they look the same, the problem domain is in both cases somewhere else. As noticed before, item 16) is possible easer to solve then item 15) because of various internals With 15 it would be just fine if you can jog out, stop the spindle clean the workpiece, clean the bit and the machine and continue. For me personally it would already be awesome if when I press pause the tool will just move up and spindle stop (not need for jogging) The problem with 15) is that you can pause in the middle if a running line, and it's hard to re-start in the middle of an operation. With 16) The machine stops at a distinct line and already can continue from there, we just need to have a way to touch off (can that be done with the modified manual hal toolchange??) If they are broken into two piece, it will be easer to solve because a programmer can just concentrate on a easer task. Ries PS: I am going to modified the hal:manualtoolchange a bit so it will find the start point of 3 axis routers better, my little project for EMC :) -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Slavko Kocjancic wrote: [snip] Beaware of one nasty thing with manualtoolchange.py! When window popup the keyboard control is on that window! If someone uses Estop in keyboard and something goes wrong during toolchange dialog then Estop button wont work! This is one reason why you never ever ever ever use a keyboard or mouse action as an emergency stop. Ever. It's not just hal_manualtoolchage either, the OS can pop up a window or change focus for any reason, at any time. The only stop button that can legitimately be called an emergency stop button, is one that physically, in hardware, will stop the machine, regardless of what the PC or the machine are doing. - Steve -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Normally I am a top poster, but I will try to insert my replies below as Stephen did. -Original Message- From: Stephen Wille Padnos [mailto:spad...@sover.net] Sent: Monday, May 17, 2010 10:15 AM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] Jog under PAUSE / tool cnange Steve Stallings wrote: One of the many problems with Jog under Pause is that a pause can interrupt a partial move. Neglecting specially-shaped cutters (keyway, T-slot), and also neglecting niceties like tangent arc entries to arc moves (probably impossible since EMC doesn't know what the part is), this isn't a huge issue. Linear moves are trivial to continue from where they were left off, and arc moves aren't terribly hard (simply save the center point and radius, and you can figure out where in the arc the program was stopped. It's not necessary to go to exactly that spot, and in fact it would be nice to have an option of backtracking along the move a little anyway) Backtracking would be nice, but I figure it is best to keep the problem and proposed solution as simple as possible at first. Run From Here can get you back to the beginning of the interrupted move. This is probably the best thing to do in most cases anyway, the notable exceptions being loong moves (boring!) or canned cycles. In this case, I am only considering Run From Here as that seems to me to be the only way to reliably restore the machine state. How hard would it be to have EMC figure out how to break the interrupted move into two pieces so that it could bring you back to the splice point? Or close to the splice point - easy. In fact, I think there's a variable in the motion controller that goes from 0 to 1 as a move is executed - it lets the motion controller know how far it has to go in this move. (I don't know the specifics, I just recall that there's a variable for that) Yes, I was hoping that after Pause brought the machine to rest, that there would be information available about exactly where along the cut path the machine stopped. Reversing the math of offsets etc. to determine the proper values in G code to represent the location where the machine Paused will be tough because (I assume) that this information is only available in absolute machine coordinates. Could this be successfully managed even if the interrupted move was in a subroutine? Depends on where you do the interrupting. The motion controller sees a bunch of motions in the queue, not a loop or subroutine. It does arcs and lines, and manages blending between them (as well as accel/vel constraints and such). A subroutine or loop just results in more than one motion being put in the queue. Note that variable values, loop conditions, etc. are all irrelevant at the motion controller level - all the motion parameters are just numbers at this level. Hopefully using the Run From Here approach would recreate the current machine state accurately. The only place I expected to get down to the motion control level was in extracting the information needed to break the motion command into two parts. If it could be done, it should be a way to allow tool offsets to be altered during the pause. It seems a lot of people either didn't fully read John's email, or didn't fully understand the implications of it. (I'm just responding to Steve because this happens to be the last email I read - nothing personal :) ) Offsets are applied in the interpreter, and the already-offset motions are queued for the motion controller to execute. If you change the tool offset, the queue has to be discarded and re-filled with a new set of offset motions. Executing G-code can change the interpreter state, e.g. by changing variable values (or coordinate offsets, G90/91 motion modes ...). This increases the complexity of re-running code quite a lot, since we would need a way of returning the interpreter to the state it was in when the executing motion was queued. That's not an easy problem. No offense taken about understanding John's comment. I acknowledge that I am trying to fiddle with the design of something that I have not taken the time to fully understand. In my defense, I did say that I only expect the proposed approach to work if you are willing to use Run From Here to re-read and process the file to re-establish the valid machine state. One thing I now see that I overlooked is the effect of blending on the data available for constructing the splice point. Steve Stallings -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Offsets are applied in the interpreter, and the already-offset motions are queued for the motion controller to execute. If you change the tool offset, the queue has to be discarded and re-filled with a new set of offset motions. Executing G-code can change the interpreter state, e.g. by changing variable values (or coordinate offsets, G90/91 motion modes ...). This increases the complexity of re-running code quite a lot, since we would need a way of returning the interpreter to the state it was in when the executing motion was queued. That's not an easy problem. - Steve There is one (nasty) thing when run from line is applied. The queue is cleaned and program resume from selected line but not with correct modal parameters! For example: I run the program and somewhere hit stop. I do whatever I want and after that resume from selected line. Or example 2: I just finish very long roughting part and decide to turnoff machine beacouse is time to go to sleep. In next day just turn on machine select proper point on program (eg finishing pass) and start from selected line. ... and got error like F parameter not set or similar nonsense As run from selected line just do RUN FROM SELECTED LINE! and if machine is metric and in 1'st line you have G20 then part come out realy big. and if somwhere within program some variables are set after Run from selected line they have big chance to be wrong. So be aware from STOP / JOG(go to take beauty sleep) / Run from selected Line sequence. Can be very unpredictable. The solution is that when Run from selected line is executed the parser run program from start without motion til got selected line. Of course this is not easy too. Just imagine probe move here :D Slavko. -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
- tags: Freelance TYPO3 Glassfish JasperReports JasperETL Flex Blaze-DS WebORB PostgreSQL DB-Architect email: r...@vantwisk.nlweb: http://www.rvantwisk.nl/ skype: callto://r.vantwisk Phone: +1 (803) 426-3350 On May 17, 2010, at 10:36 AM, Slavko Kocjancic wrote: Hello... Not bad idea to be separate item as jog under toolchange can be resolved quicker. I changed wiki and I think all command M0 M1 and M6 can behave similar. For example if someone mill plastic then can issue few M1 in program and has optional stop on M1 dissabled. Thanks.. If swarf come up then just enable M1 pause and have nice workaround. Maybe there is not bad idea to have another one pause button that pause program like inserting M1 after just current line?!? Easyer to implement. As mentioned before, you cannot easily insert a command on each line once they are in the queue unless the M1's are inserted when a program is loaded, you could do this using a filter I think... The suggestion you make to introduce a other pause method that stop after the line was processed might be easer to implement then trying to modify the current pause method. Then at least EMC is at a clear point ( I assume) where to resume from and not in the middle of something. Beaware of one nasty thing with manualtoolchange.py! When window popup the keyboard control is on that window! If someone uses Estop in keyboard and something goes wrong during toolchange dialog then Estop button wont work! The proper way to solve e-Stop is to have a external button connected to your machine, next to a emergency stop. I think every decent size machine (that can seriously hurt a human) should have external buttons for that I do have, but luckly never used them :) Ries Slavko Ries van Twisk pravi: Salvko, i think it would be a good idea to seperate item 15 into two items: 15) JOG under PAUSE - Alow users to jog machine when program is paused. 16) JOG under ToolChange - Alow users to jog machine when program M6 executed. The TouchOff? should be enabled too and maybe even MDI Although they look the same, the problem domain is in both cases somewhere else. As noticed before, item 16) is possible easer to solve then item 15) because of various internals With 15 it would be just fine if you can jog out, stop the spindle clean the workpiece, clean the bit and the machine and continue. For me personally it would already be awesome if when I press pause the tool will just move up and spindle stop (not need for jogging) The problem with 15) is that you can pause in the middle if a running line, and it's hard to re-start in the middle of an operation. With 16) The machine stops at a distinct line and already can continue from there, we just need to have a way to touch off (can that be done with the modified manual hal toolchange??) If they are broken into two piece, it will be easer to solve because a programmer can just concentrate on a easer task. Ries PS: I am going to modified the hal:manualtoolchange a bit so it will find the start point of 3 axis routers better, my little project for EMC :) -- ___ 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
Re: [Emc-users] Jog under PAUSE / tool cnange
Kenneth Lerman wrote: Jog on tool change (or on pause) should be straight forward. At the pause, simply remember each of the jogs. Then when resume is executed, play them back in reverse order. Allen-Bradley controls apparently use this technique. I believe that all of this can be done with HAL components. This would NOT solve the touch off problem. One could, of course, use an offset HAL component that could be used as part of a touch off. I think for that, you have to purge the queue and start off clean. Jon -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Stephen Wille Padnos pravi: This is one reason why you never ever ever ever use a keyboard or mouse action as an emergency stop. Ever. It's not just hal_manualtoolchage either, the OS can pop up a window or change focus for any reason, at any time. The only stop button that can legitimately be called an emergency stop button, is one that physically, in hardware, will stop the machine, regardless of what the PC or the machine are doing. - Steve I'm aware of that. And I have Hardware ESTOP even in smalest machine. But sadly I see machines that rely only on keyboard key as estop. The best thing is to remove that button from AXIS GUI. Let's force users to be safer. Slavko. -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
How about tagging each move? Each move has a unique number. If you stop to change tool halfway through the system knows exactly what move it is on and how far through that move it is. For instance you may be 50% through move 5227. When you restart, the interpreter dry runs the code using the new tool offsets until it hits move 5227. This could be in the middle of a subroutine, or canned cycle. It doesn't matter where it is. You now need to set the coolant/spindle outputs to the result of the dry run then restart from half way through that move. This is pretty much a variation of the existing 'run from here' code that my tool change hack takes advantage of. The current code already tags moves with the current line number so this would just be extending that function. If you are part way through a CV blended move you won't be able to start in exactly the same point you stopped but it should be close enough to make no real difference. Pausing and restarting with the existing code probably results in slightly different blended tool paths. I suppose in theory you could tag the output of the TP and dry run it as well. This should end you up in exactly the same place you started. The only time I can see that this would fall over is if you use incremental code from the start or if you use clever subroutines that generate different code for every run. I don't think any system is going to be totally fool proof. However the current 'run from here' code has the same limitations and has been in use for some time now. Les Stephen Wille Padnos wrote: It seems a lot of people either didn't fully read John's email, or didn't fully understand the implications of it. (I'm just responding to Steve because this happens to be the last email I read - nothing personal :) ) Offsets are applied in the interpreter, and the already-offset motions are queued for the motion controller to execute. If you change the tool offset, the queue has to be discarded and re-filled with a new set of offset motions. Executing G-code can change the interpreter state, e.g. by changing variable values (or coordinate offsets, G90/91 motion modes ...). This increases the complexity of re-running code quite a lot, since we would need a way of returning the interpreter to the state it was in when the executing motion was queued. That's not an easy problem. - Steve -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Ries van Twisk pravi: The proper way to solve e-Stop is to have a external button connected to your machine, next to a emergency stop. I think every decent size machine (that can seriously hurt a human) should have external buttons for that I do have, but luckly never used them :) Ries The smalest CNC can hurt people. And All machines should have Latching ESTOP button. The Estop button in AXIS GUI should be deleted for safety issues! As many operator's of small machines think that this is safe! Slavko. -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
As run from selected line just do RUN FROM SELECTED LINE! and if machine is metric and in 1'st line you have G20 then part come out realy big. and if somwhere within program some variables are set after Run from selected line they have big chance to be wrong. I thought it re-ran the whole code. My mistake. I probably got confused by Mach which does re-run the whole code. -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
I agree. There is no need for an estop button in the GUI. In fact the start button is of dubious value. On any machine I build you have to physically press a button to enable the drives. Trying to do it in the GUI will do nothing. Les Slavko Kocjancic wrote: I'm aware of that. And I have Hardware ESTOP even in smalest machine. But sadly I see machines that rely only on keyboard key as estop. The best thing is to remove that button from AXIS GUI. Let's force users to be safer. -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Jon Elson pravi: Kenneth Lerman wrote: Jog on tool change (or on pause) should be straight forward. At the pause, simply remember each of the jogs. Then when resume is executed, play them back in reverse order. Allen-Bradley controls apparently use this technique. I believe that all of this can be done with HAL components. This would NOT solve the touch off problem. One could, of course, use an offset HAL component that could be used as part of a touch off. I think for that, you have to purge the queue and start off clean. Jon I think here is the problem. Se this. User hit PAUSE/STOP User does jog, touchoff, maybe even MDI Now user hit RESUME (Or start from here) Parser is forced to cleanup queue as there are no other way to do that. .. and start filling queue from selected line. This from selected line is wrong. As that does't restore all modal parameters and variables. So machine should remember more thing to safe restore position. Or to have very restricted options enabled when paused. Slavko. -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Big misunderstanding on my part here. I thought that Run From Here would re-read and reprocess the entire program up to the point that you wanted to start cutting. Steve Stallings -Original Message- From: Slavko Kocjancic [mailto:esla...@gmail.com] Sent: Monday, May 17, 2010 10:52 AM To: Enhanced Machine Controller (EMC) Subject: Re: [Emc-users] Jog under PAUSE / tool cnange Offsets are applied in the interpreter, and the already-offset motions are queued for the motion controller to execute. If you change the tool offset, the queue has to be discarded and re-filled with a new set of offset motions. Executing G-code can change the interpreter state, e.g. by changing variable values (or coordinate offsets, G90/91 motion modes ...). This increases the complexity of re-running code quite a lot, since we would need a way of returning the interpreter to the state it was in when the executing motion was queued. That's not an easy problem. - Steve There is one (nasty) thing when run from line is applied. The queue is cleaned and program resume from selected line but not with correct modal parameters! For example: I run the program and somewhere hit stop. I do whatever I want and after that resume from selected line. Or example 2: I just finish very long roughting part and decide to turnoff machine beacouse is time to go to sleep. In next day just turn on machine select proper point on program (eg finishing pass) and start from selected line. ... and got error like F parameter not set or similar nonsense As run from selected line just do RUN FROM SELECTED LINE! and if machine is metric and in 1'st line you have G20 then part come out realy big. and if somwhere within program some variables are set after Run from selected line they have big chance to be wrong. So be aware from STOP / JOG(go to take beauty sleep) / Run from selected Line sequence. Can be very unpredictable. The solution is that when Run from selected line is executed the parser run program from start without motion til got selected line. Of course this is not easy too. Just imagine probe move here :D Slavko. -- ___ 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
Re: [Emc-users] Jog under PAUSE / tool cnange
I think, that following solution might be easy to implement: 1) press pause 2) press button, which stores coordinates of current position 3) jog away, do what ever... 4) press button, which returns to saved coordinates. here is important, that first move is in XY plane, Z move is last 5) hit resume 6) machine should remember all the variables, feed rates etc. during this pause (i do not know, if EMC already does it. if so, please ignore) So actually 2 buttons with IMHO simple functions have to be implemented About the safety of such solution: i agree that it is operator's responsibility to make sure, that machine is jogged to place, from which it can safely return to the saved point. I believe (but am not sure) that this way machine can be paused and resumed in the middle of the line... 2010/5/17 Ries van Twisk e...@rvt.dds.nl: - tags: Freelance TYPO3 Glassfish JasperReports JasperETL Flex Blaze-DS WebORB PostgreSQL DB-Architect email: r...@vantwisk.nl web: http://www.rvantwisk.nl/ skype: callto://r.vantwisk Phone: +1 (803) 426-3350 On May 17, 2010, at 10:36 AM, Slavko Kocjancic wrote: Hello... Not bad idea to be separate item as jog under toolchange can be resolved quicker. I changed wiki and I think all command M0 M1 and M6 can behave similar. For example if someone mill plastic then can issue few M1 in program and has optional stop on M1 dissabled. Thanks.. If swarf come up then just enable M1 pause and have nice workaround. Maybe there is not bad idea to have another one pause button that pause program like inserting M1 after just current line?!? Easyer to implement. As mentioned before, you cannot easily insert a command on each line once they are in the queue unless the M1's are inserted when a program is loaded, you could do this using a filter I think... The suggestion you make to introduce a other pause method that stop after the line was processed might be easer to implement then trying to modify the current pause method. Then at least EMC is at a clear point ( I assume) where to resume from and not in the middle of something. Beaware of one nasty thing with manualtoolchange.py! When window popup the keyboard control is on that window! If someone uses Estop in keyboard and something goes wrong during toolchange dialog then Estop button wont work! The proper way to solve e-Stop is to have a external button connected to your machine, next to a emergency stop. I think every decent size machine (that can seriously hurt a human) should have external buttons for that I do have, but luckly never used them :) Ries Slavko Ries van Twisk pravi: Salvko, i think it would be a good idea to seperate item 15 into two items: 15) JOG under PAUSE - Alow users to jog machine when program is paused. 16) JOG under ToolChange - Alow users to jog machine when program M6 executed. The TouchOff? should be enabled too and maybe even MDI Although they look the same, the problem domain is in both cases somewhere else. As noticed before, item 16) is possible easer to solve then item 15) because of various internals With 15 it would be just fine if you can jog out, stop the spindle clean the workpiece, clean the bit and the machine and continue. For me personally it would already be awesome if when I press pause the tool will just move up and spindle stop (not need for jogging) The problem with 15) is that you can pause in the middle if a running line, and it's hard to re-start in the middle of an operation. With 16) The machine stops at a distinct line and already can continue from there, we just need to have a way to touch off (can that be done with the modified manual hal toolchange??) If they are broken into two piece, it will be easer to solve because a programmer can just concentrate on a easer task. Ries PS: I am going to modified the hal:manualtoolchange a bit so it will find the start point of 3 axis routers better, my little project for EMC :) -- ___ 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 -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Leslie Newell pravi: As run from selected line just do RUN FROM SELECTED LINE! and if machine is metric and in 1'st line you have G20 then part come out realy big. and if somwhere within program some variables are set after Run from selected line they have big chance to be wrong. I thought it re-ran the whole code. My mistake. I probably got confused by Mach which does re-run the whole code. I think not. But maybe I'm wrong G0 x0 y100 G1 x100 (stopped here) G1 x200 y200 if code is stopped im midle line and axis joged in y direction then resume from 2'nd or 3'rd line doesn have similar (right one) path. If code is reread from start then should know to have set right Y Slavko. -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Viesturs Lācis pravi: I think, that following solution might be easy to implement: 1) press pause 2) press button, which stores coordinates of current position That G30.1 does 3) jog away, do what ever... 4) press button, which returns to saved coordinates. here is important, that first move is in XY plane, Z move is last That's G30 (axis) 5) hit resume 6) machine should remember all the variables, feed rates etc. during this pause (i do not know, if EMC already does it. if so, please ignore) So actually 2 buttons with IMHO simple functions have to be implemented About the safety of such solution: i agree that it is operator's responsibility to make sure, that machine is jogged to place, from which it can safely return to the saved point. I believe (but am not sure) that this way machine can be paused and resumed in the middle of the line... But how to touch off? Queue has wrong data I use that as have no other chance (of course using STOP instead pause) Slavko. -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Leslie Newell pravi: I agree. There is no need for an estop button in the GUI. In fact the start button is of dubious value. On any machine I build you have to physically press a button to enable the drives. Trying to do it in the GUI will do nothing. Les I found that some chargepump output from EMC is good. So the (hardware) machine can't be turned on if EMC isnt live. Or some strange output from printer port came while PC is in bootup process. .. but that's other topic. Slavko. -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
On Monday 17 May 2010, Viesturs Lācis wrote: I think, that following solution might be easy to implement: 1) press pause Pressing pause should store all modal info in addition to current line being executed. 2) press button, which stores coordinates of current position One button, the pause button, should do it all. 3) jog away, do what ever... 4) press button, which returns to saved coordinates. here is important, that first move is in XY plane, Z move is last Except this needs to not be the case if the tool is a dovetail or keyhole cutter. In that event, the return move must start at that tools entry into the metal else the part is wrecked. 5) hit resume 6) machine should remember all the variables, feed rates etc. during this pause (i do not know, if EMC already does it. if so, please ignore) So actually 2 buttons with IMHO simple functions have to be implemented About the safety of such solution: i agree that it is operator's responsibility to make sure, that machine is jogged to place, from which it can safely return to the saved point. I believe (but am not sure) that this way machine can be paused and resumed in the middle of the line... Except in the above cases, then it really should be a run from the top restart. Or at the very least, from the tool change that installed such a cutting tool. That one had to re-enter the metal from where ever the tool was inserted, so that may well be quite some time into the job, thus saving a large amount of retrace time. 2010/5/17 Ries van Twisk e...@rvt.dds.nl: - tags: Freelance TYPO3 Glassfish JasperReports JasperETL Flex Blaze-DS WebORB PostgreSQL DB-Architect email: r...@vantwisk.nlweb: http://www.rvantwisk.nl/ skype: callto://r.vantwisk Phone: +1 (803) 426-3350 On May 17, 2010, at 10:36 AM, Slavko Kocjancic wrote: Hello... Not bad idea to be separate item as jog under toolchange can be resolved quicker. I changed wiki and I think all command M0 M1 and M6 can behave similar. For example if someone mill plastic then can issue few M1 in program and has optional stop on M1 dissabled. Thanks.. If swarf come up then just enable M1 pause and have nice workaround. Maybe there is not bad idea to have another one pause button that pause program like inserting M1 after just current line?!? Easyer to implement. As mentioned before, you cannot easily insert a command on each line once they are in the queue unless the M1's are inserted when a program is loaded, you could do this using a filter I think... The suggestion you make to introduce a other pause method that stop after the line was processed might be easer to implement then trying to modify the current pause method. Then at least EMC is at a clear point ( I assume) where to resume from and not in the middle of something. Beaware of one nasty thing with manualtoolchange.py! When window popup the keyboard control is on that window! If someone uses Estop in keyboard and something goes wrong during toolchange dialog then Estop button wont work! The proper way to solve e-Stop is to have a external button connected to your machine, next to a emergency stop. I think every decent size machine (that can seriously hurt a human) should have external buttons for that I do have, but luckly never used them :) Ries Slavko Ries van Twisk pravi: Salvko, i think it would be a good idea to seperate item 15 into two items: 15) JOG under PAUSE - Alow users to jog machine when program is paused. 16) JOG under ToolChange - Alow users to jog machine when program M6 executed. The TouchOff? should be enabled too and maybe even MDI Although they look the same, the problem domain is in both cases somewhere else. As noticed before, item 16) is possible easer to solve then item 15) because of various internals With 15 it would be just fine if you can jog out, stop the spindle clean the workpiece, clean the bit and the machine and continue. For me personally it would already be awesome if when I press pause the tool will just move up and spindle stop (not need for jogging) The problem with 15) is that you can pause in the middle if a running line, and it's hard to re-start in the middle of an operation. With 16) The machine stops at a distinct line and already can continue from there, we just need to have a way to touch off (can that be done with the modified manual hal toolchange??) If they are broken into two piece, it will be easer to solve because a programmer can just concentrate on a easer task. Ries PS: I am going to modified the hal:manualtoolchange a bit so it will find the start point of 3 axis routers better, my little project for EMC :) -- ___ Emc-users mailing list
Re: [Emc-users] Jog under PAUSE / tool cnange
On 17 May 2010 17:11, Viesturs Lācis viesturs.la...@gmail.com wrote: 4) press button, which returns to saved coordinates. here is important, that first move is in XY plane, Z move is last That might not work for a lathe, or a hot-wire cutter, or a fly-fishing rod maker or. One of the strengths of EMC is its flexibility, which has led to it being used on a vast range of machines. Unfortunately that means that any changes have to (as far as possible) retain that generality. The last time this was discussed I thought that replaying the jogs in reverse would work as long as it recorded the position each time the machine stopped. That was because I was using the keyboard to jog. Now I can jog with my analogue joysticks, and it is nothing like as simple to record the path. I have been wondering if it would suffice to allow retraction in one direction only (the first direction you choose) under pause. That would cover about 75% of situations and makes the return move easy for the code. It would allow touch-off to the top of the work and to movable touch-sensors. it wouldn't work for fixed touch-off plates. No good for milling T-slots or turning internal grooves though. -- atp -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Spirograph Curves
On Mon, 2010-05-17 at 11:11 +0100, Andrew wrote: Hmm, well my webstats say there have been over 200 unique visits to the spirograph page, but as yet not a single comment Can anybody give me some feedback, good or bad :) Cheers, Andy. I certainly don't want to discourage your effort, but I suppose no one has found the need for your application, yet. I know when I have a need for your application, I will be making a pest of myself. In briefly considering how I might try to use your application, it seems that in its current form, one would be limited to engraving fine lines on a flat surface. What might be interesting would be to use the current path to come up with a three dimensional surface. Perhaps, use the original path as it is, then change Z with parallel paths. On the other hand, converting the path to an image, using GIMP to shade it, then using the image-to-g-code filter in the .ini file could be another way, but this would rasterize the surface. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Spirograph Curves
I loved Hilbert Curves... Regards, Fabio Gilii -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Spirograph Curves
There's something rather hypnotic about them :) On Monday 17 May 2010, Fabio Gilii wrote: I loved Hilbert Curves... Regards, Fabio Gilii --- --- ___ 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
Re: [Emc-users] Spirograph Curves
Hi Kirk, Yes, this is really just for providing surface decoration; screens, room dividers or box lids come to mind. Converting it to 3d could be an interesting challenge ! Cheers, Andy. On Monday 17 May 2010, Kirk Wallace wrote: On Mon, 2010-05-17 at 11:11 +0100, Andrew wrote: Hmm, well my webstats say there have been over 200 unique visits to the spirograph page, but as yet not a single comment Can anybody give me some feedback, good or bad :) Cheers, Andy. I certainly don't want to discourage your effort, but I suppose no one has found the need for your application, yet. I know when I have a need for your application, I will be making a pest of myself. In briefly considering how I might try to use your application, it seems that in its current form, one would be limited to engraving fine lines on a flat surface. What might be interesting would be to use the current path to come up with a three dimensional surface. Perhaps, use the original path as it is, then change Z with parallel paths. On the other hand, converting the path to an image, using GIMP to shade it, then using the image-to-g-code filter in the .ini file could be another way, but this would rasterize the surface. -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
On Mon, 17 May 2010 06:44:12 -0700, you wrote: Re-starting from the beginning of the line of g-code that was PAUSED would work for most applications. Consider this as a possible and useful partial solution. This still might be messy with loops and other complications like coolant pump state but could prove easier to program. What would be the problems with cutting some air as part of restarting?? There probably are problems in some applications and some of these problems might also apply to starting mid-move. Comment from people who know more about machining than I do? Commercially Feed Hold doesn't work within loops or canned cycles. Stopping at the end of the current line isn't a problem generally and certainly better than nothing. Steve Blackmore -- -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
In that case shouldn't a pause - stop - jog/mdi/touchoff - manually jog close to previous position - run from here work? I ran a bunch of cam generated code last night on a simulator setup and could not make the run from here (right click on gcode line etc) screw up - although I guess it gets confused on some modal changes according to others. Dave On 5/17/2010 5:07 PM, Steve Blackmore wrote: On Mon, 17 May 2010 06:44:12 -0700, you wrote: Re-starting from the beginning of the line of g-code that was PAUSED would work for most applications. Consider this as a possible and useful partial solution. This still might be messy with loops and other complications like coolant pump state but could prove easier to program. What would be the problems with cutting some air as part of restarting?? There probably are problems in some applications and some of these problems might also apply to starting mid-move. Comment from people who know more about machining than I do? Commercially Feed Hold doesn't work within loops or canned cycles. Stopping at the end of the current line isn't a problem generally and certainly better than nothing. Steve Blackmore -- -- ___ 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
[Emc-users] Suggestions for microcontroller
Hi everyone, I have built a simple ornamental turning (OT) lathe which I control with EMC. I generate the gcode to rotate and move the lathe head from side to side and in and out using gcode generated by some software I have written. However I want to investigate the possibility of controlling the lathes movements using a separate micro-controller board rather than the PC. I have used an Arduino to generate pulse trains to control the rotational stepper separately, but am not sure it is up to the job of controlling everything simultaneously although in ornamental turning everything happens very slowly compared to standard cnc machining (say rotations of head axis of up to 10 revs per minute at up to 0.1 degree resolution with correspondingly slow movements along the other two axes). I can write the code which I envisage will rotate the headstock and also move it traversely and horizontally synchronized to the headstock rotation). I was thinking of using the EMC core code functionality as a guide, so this is committing EMC without the UI onto separate hardware. I thought that perhaps I could generate and download tables of movements on the PC, download them onto the controller and run from there. So I think I need a controller plus simple keypad and small text display as one unit with ability to communicate with PC. I know that I could build a very small PC104 system that would run EMC directly but thought that would be a bit costly for what is a hobby project. So I am looking for suggestions for a suitable controller or development kit or alternative method. Thanks Alan -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Spirograph Curves
Hi Andy, I have downloaded your script and had a brief look at it but haven't yet had time to play with it properly. I can see a use for it in decorating surfaces - as a form of Engine Turning, but until I get time to look at it properly, I can't really say how useful it will be. There is another chap who is writing an engine turning program which is very flexible but I think your script may do some things that his won't and may therefore fill a gap. If you are interested, his website is at http://wood.dyadica.net/site/ . As you will see, his primary interest is in milling wood but, since I have been beta testing his program for him, he has incorporated into it a number of features that will be useful to me in engraving watch and clock dials, jewellery etc As soon as I get the chance, I'll let you know how your script measures up.. Ian -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Axis mods
Thanks: I have Idle working, I think, not sure what to expect in the way of debugging stuff, single step, break points, watch variables, etc.. Or how it fits in with the rest of EMC which Axis seems to need to run properly. Now need some time to play with stuff. On Sat, 2010-05-15 at 15:39 -0400, Dave wrote: Use the Synaptic package manager to get and install Idle which is a editor/debugger for Python. It is small, yet powerful for finding errors and testing code. It saves much head banging. There is also Eclipse, which is a full blown IDE. It has a Python add in that you can load off the Eclipse website. But to me, using Eclipse is like using a 10 lb sledge hammer to drive a tack - overkill. The Axis graphics are done in Tcl/TK which is a different language. There is a lot to learn. Dave On 5/15/2010 1:27 PM, Andre' B wrote: I have Emc from a Live-CD install now updated to 2.4.0 I would like to try a few modifications to Axis, dealing with the feed and spindle overrides. Want to toggle the number keys between feed override, spindle override, and both. Buy both I mean changing feed and speed to maintain the same feed per rev. I also have an idea for being able to change the overrides by a smaller increment then 10% without a bunch more keys. Have not done much programming in Linux, mostly just VB and C programming in Windows and DOS. Snooping around it looks like some of the stuff I want to mess with is in the Python script usr/bin/axis How to get started, what would be the best development tools to try first? -- ___ 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 -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
On Mon, 17 May 2010 17:02:23 +0100, you wrote: As run from selected line just do RUN FROM SELECTED LINE! and if machine is metric and in 1'st line you have G20 then part come out realy big. and if somwhere within program some variables are set after Run from selected line they have big chance to be wrong. I thought it re-ran the whole code. My mistake. I probably got confused by Mach which does re-run the whole code. So did I until I stuffed a tool into a job, it doesn't seem to apply offsets properly either :( The only information I can find says: Run From Selected Line - Select the line you want to start from first. Use with caution as this will move the tool to the expected position before the line first then it will execute the rest of the code. Nothing about what limitations it has or hasn't. Steve Blackmore -- -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
On Mon, 17 May 2010 23:14 +0100, Steve Blackmore st...@pilotltd.net 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
Re: [Emc-users] Jog under PAUSE / tool cnange
As run from selected line just do RUN FROM SELECTED LINE! and if machine is metric and in 1'st line you have G20 then part come out realy big. and if somwhere within program some variables are set after Run from selected line they have big chance to be wrong. I thought it re-ran the whole code. My mistake. I probably got confused by Mach which does re-run the whole code. It would be great if EMC could scan the code and apply the modal codes when you do a run from here. I have seen it reported as a bug in the archives. The developers stated that *not* scanning the program for modal codes was a *feature*. That is a nice way to say we don't want to do it! You could never make the control idiot proof. The operator needs to know not to restart in the middle of cutting a T-slot in incremental mode or something impossible. But I see no reason why the control could not select the right tool, start the spindle/coolant, select the offsets and plane, and then move to the correct location and get started. -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
I've been running emc2 all day today and every job has required a manual tool change. What I do is simply divide up my program and end each section with M00 so it doesn't continue past that point, then I just hit escape, jog, change tools, touch off, and then use run from here on the first line of the next section. Chris -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
there is always a spoil sport in every crowd - :) On Mon, May 17, 2010 at 8:02 PM, Chris Reynolds c_reynolds2...@yahoo.comwrote: I've been running emc2 all day today and every job has required a manual tool change. What I do is simply divide up my program and end each section with M00 so it doesn't continue past that point, then I just hit escape, jog, change tools, touch off, and then use run from here on the first line of the next section. Chris -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- dos centavos -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] ISO20 Tool Holders
I'm looking into mill tool holders that would work with a smallish DIY higher speed spindle. The HSK seems to be popular for routers. The HSK25 or HSK32 would be about the size I would like: http://www.tools-n-gizmos.com/specs/Tapers.html#HSK I also noticed that Haas uses an ISO20 on their office mill: http://www.schaublin.ch/catalogues/PO044-050.pdf Neither of these seem to be main stream, are the 30 taper CAT, BT, NMTB, etc. the smallest common holders? -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Jog under PAUSE / tool cnange
Steve Blackmore wrote: On Mon, 17 May 2010 17:02:23 +0100, you wrote: I thought it re-ran the whole code. My mistake. I probably got confused by Mach which does re-run the whole code. So did I until I stuffed a tool into a job, it doesn't seem to apply offsets properly either :( The only information I can find says: Run From Selected Line - Select the line you want to start from first. Use with caution as this will move the tool to the expected position before the line first then it will execute the rest of the code. Nothing about what limitations it has or hasn't. I just ran into this in a program that uses subroutines, and shifts to a G55 work offset in the subroutine. I put the program here : http://pastebin.com/embed_js.php?i=QyjpZUD9 if anyone wants to try it out. I tried to restart on line # 41, to skip over the first few pockets that were already done, and was amazed to see it skipped over the whole batch of 24 G01 moves and subroutine calls, and start to do the next pocket that wasn't in a subroutine. It didn't mess anything up, but was WAY different than the expected behavior. I ran this by the developer's list, and they basically said don't use run from line. Jon -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Suggestions for microcontroller
Hi Alan, I haven't any experience in doing this myself, but your post reminded me of something I saw a while back where micro controllers were used to run a machine. Perhaps there are some ideas you could use here even though your application is different? http://www.youtube.com/watch?v=ybEraG8FeP8 http://www.youtube.com/watch?v=PSuObtH2Tng http://www.youtube.com/watch?v=HF1Z9evXor0 There is a thread on CNCzone about this which begins here: http://www.cnczone.com/forums/showthread.php?t=99071 Hope that helps in some way? Regards, Martin Hi everyone, I have built a simple ornamental turning (OT) lathe which I control with EMC. I generate the gcode to rotate and move the lathe head from side to side and in and out using gcode generated by some software I have written. However I want to investigate the possibility of controlling the lathes movements using a separate micro-controller board rather than the PC. I have used an Arduino to generate pulse trains to control the rotational stepper separately, but am not sure it is up to the job of controlling everything simultaneously although in ornamental turning everything happens very slowly compared to standard cnc machining (say rotations of head axis of up to 10 revs per minute at up to 0.1 degree resolution with correspondingly slow movements along the other two axes). I can write the code which I envisage will rotate the headstock and also move it traversely and horizontally synchronized to the headstock rotation). I was thinking of using the EMC core code functionality as a guide, so this is committing EMC without the UI onto separate hardware. I thought that perhaps I could generate and download tables of movements on the PC, download them onto the controller and run from there. So I think I need a controller plus simple keypad and small text display as one unit with ability to communicate with PC. I know that I could build a very small PC104 system that would run EMC directly but thought that would be a bit costly for what is a hobby project. So I am looking for suggestions for a suitable controller or development kit or alternative method. Thanks Alan -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users _ Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1 -- ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Axis mods
I haven't used Idle extensively but it has saved me a bunch of time by finding syntax errors, correcting indentation, etc very quickly. A couple of simple print statements can oftentimes catch my logical errors. If you find yourself wanting, try Eclipse. It seems extensive and it is apparently used and supported to some extent by IBM. But similar to VS, it can be a big overkill for smaller changes or smaller projects. In either case the price is right.. ;-) Dave On 5/17/2010 6:29 PM, Andre' B wrote: Thanks: I have Idle working, I think, not sure what to expect in the way of debugging stuff, single step, break points, watch variables, etc.. Or how it fits in with the rest of EMC which Axis seems to need to run properly. Now need some time to play with stuff. On Sat, 2010-05-15 at 15:39 -0400, Dave wrote: Use the Synaptic package manager to get and install Idle which is a editor/debugger for Python. It is small, yet powerful for finding errors and testing code. It saves much head banging. There is also Eclipse, which is a full blown IDE. It has a Python add in that you can load off the Eclipse website. But to me, using Eclipse is like using a 10 lb sledge hammer to drive a tack - overkill. The Axis graphics are done in Tcl/TK which is a different language. There is a lot to learn. Dave On 5/15/2010 1:27 PM, Andre' B wrote: I have Emc from a Live-CD install now updated to 2.4.0 I would like to try a few modifications to Axis, dealing with the feed and spindle overrides. Want to toggle the number keys between feed override, spindle override, and both. Buy both I mean changing feed and speed to maintain the same feed per rev. I also have an idea for being able to change the overrides by a smaller increment then 10% without a bunch more keys. Have not done much programming in Linux, mostly just VB and C programming in Windows and DOS. Snooping around it looks like some of the stuff I want to mess with is in the Python script usr/bin/axis How to get started, what would be the best development tools to try first? -- ___ 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 -- ___ 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
