Re: [Emc-users] Tool change question
On 20.03.12 22:21, Kirk Wallace wrote: I've got my brain sore thinking about this, so I'm a little foggy, but it seems the safest way to do this is to break the g-code program into a separate program for each tool change. If doing that, then we might keep the files for a job in a directory named according to the job. If there [were] a way to make this look like one run, that would be better. It is easy to have a filter program process a #nextfile somefile last command in an input file, to achieve file sequencing. However, it is just as easy to keep the entire part program in a single file, and synthesise separate files of gcode on the output of the filter. Do you visualise an M2 separating the tool runs, on the output of the filter? How much jogging do we really want to do, though? Isn't it a bit more convenient to program rapids to a fixed probing station, where we also do the toolchanges? (Or toolchange nearby, to avoid dropping things on the probing sensor.) Perhaps I haven't understood all the variables in your following paragraph?: Also, it would be nice to be able to use the same original part file for machines with repeatable tool holders or machines or tool holders that need a touch off for each change. If touch off isn't needed, then we just go to the toolchange position, omitting the touch off position? A machine-specific toolchange subroutine could conveniently wrap up all of that customisation, couldn't it? (And with #include functionality in the filter program, such a subroutine could be in a file of its own, or several could be included in the one file, if they are always used together.) The key to which type of change would be needed could be a setting in a configuration file or a special code in the tool table. Rather than spreading this stuff all over the system, would it be more convenient to just let the toolchange subroutine do the customisation in the part program? A preprocessor could scan the g-code file for tool changes and create sub files of the commands between tools of the touch off variety. Then call the subfiles in sequence with a touch off macro between sub-runs. Ah, that sounds very much like the understanding of your idea that I'm ploughing through, above. If you're happy to use a more human-readable dialect of LinuxCNC gcode, then we can add a toolchange command, conforming to your specifications, and syntax which we find most readable, to infrastructure which is already coming together. Checks would be needed to make sure the contexts don't change or are correct. If it's all one file, then what sort of checks do we need to perform? Even if it is something that gcode can't intrinsically do, such as reading back the current state of a modality, the translator can do that with its input. (It's doing that now on distance mode, so that a G81 ... L3 can be given a fleeting G91, with automatic restoration to G90 before proceeding to the next line, _if_ that is the setting current in that section of the program.) Basically, automating what an operator would currently need to do by hand. And that is what we're all here for. ;-) If we need to tell the filter something about what we've done during the toolchange, then that could be written to a temporary file or named pipe, for the filter to inspect before proceeding with the next code segment. That also would not necessitate splitting the part program into subfiles, because switching a filter's input stream between input files is trivial. An Await Signal command is easily added to the translator/filter currently in the works. It could alternatively respond to a unix signal, or check a semaphore, or whatever we find most convenient. Your ideas look like a lot of fun to implement. To make it more seamless, it ought to be manageable to make the filter respond to unix signals (thus obviating the need for a communications file, just to give a resumption go ahead), and it may be possible to add an AXIS button to send such a signal. If we can clarify exactly what is required, then I'd enjoy adding to the translator the parts it can do. (i.e. pretty much all of it, barring a button or two in AXIS, AIUI.) Even if we start with something basic, it can be tweaked as we go along. Erik -- Gcode needs bringing up to date. We no longer need cater for paper tape. - Dave Caroline, on emc-users ML. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Tool change question and enhancement request
On Wednesday, March 21, 2012 09:39:56 AM Kirk Wallace did opine: On Tue, 2012-03-20 at 21:15 -0700, Karl Cunningham wrote: On 03/20/2012 04:47 PM, Kirk Wallace wrote: it has the the M00 pauses and when I hit Esc, it exits the current program run, so I would need to do a run from line (as I see you mentioned above) on a new program run in order to resume. If I had several tool changes to do, this could get tricky, especially after working twelve hour shifts, six days a week for three months (been there) or after doing nothing on any CNC for several months and getting a rush job (done that). Your method seems reasonable, but I'll need to play with it some more to get a better understanding of how well it works with different situations such as with conditional codes and other run from line problems. Thanks for the tip Terry. One could include the message to operator construct: (MSG, bla bla bla) in the g-code to prompt the operator to do the right thing. Karl I've got my brain sore thinking about this, so I'm a little foggy, but it seems the safest way to do this is to break the g-code program into a separate program for each tool change. If there where a way to make this look like one run, that would be better. Also, it would be nice to be able to use the same original part file for machines with repeatable tool holders or machines or tool holders that need a touch off for each change. The key to which type of change would be needed could be a setting in a configuration file or a special code in the tool table. A preprocessor could scan the g-code file for tool changes and create sub files of the commands between tools of the touch off variety. Then call the subfiles in sequence with a touch off macro between sub-runs. Checks would be needed to make sure the contexts don't change or are correct. Basically, automating what an operator would currently need to do by hand. Kirk; this ignores the fact that the oword call file sub programs aren't shown in the axis display. They seem to execute in their own little world, so that would leave the operator flying essentially blind while the main code that could be 10k+ LOC was executing. This is, at least to me, a complete non-starter even if it did work. I had trouble keeping track of what was going on when I wrote my autoz functions for the pcb-gcode output. In fact, the only redeeming reason to leave those as callable subroutine files was that it was then a single place where I could control the depth of cut by editing a single value in a single file. In fact, I am hoping that at some point before 2.6.0 final, LinuxCNC grows the ability to insert the contents of an oword called subroutine file, into the lower window displayed code as they are encountered in the main file. Hint, hint, pretty please? Just the two drill files for that simple board I made, have a dozen tool changes between them. Because of exit burrs, I chose to drill halfway thru from each side let the holes meet in the middle of the board thickness. It worked better than I dreamed. I was not able to determine that there was a miss-registration anywhere in the finished board. With a 100k rpms spindle it would have been cleaner I am sure because I would then have drilled all the way though, damaging the pallet too. There are reasons not to do that of course because that damage could also swell the pallet material locally, resulting in an unwanted elevation change of the board while the machining was in progress. In fact, I found that due to the burrs thrown up while etching at only 2500 rpms that I wasn't able to fully remove on a sheet of 600 w-r-d on my surface stone, that I had to relieve the pallet another 10 thou, leaving the original pocket elevation only for about 1/8 around the outside edge. You can see the extra relief in the pix of it on my web page, under Genes- os9-stf/eagle. What is not shown in that pix is the bottom of that pallet which has a 50 thou high 'fin' that exactly fits the T nut slots in the mills table. I found that trying to remount it and get the x axis aligned wasn't something a dial indicator could do 100% reliably, so this last pallet was made from scratch, from the bottom up with that alignment in mind. Cheers, Gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) My web page: http://coyoteden.dyndns-free.com:85/gene The heaviest object in the world is the body of the woman you have ceased to love. -- Marquis de Lac de Clapiers Vauvenargues -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net
Re: [Emc-users] Tool change question
On Wednesday, March 21, 2012 10:35:09 AM Erik Christiansen did opine: On 20.03.12 22:21, Kirk Wallace wrote: I've got my brain sore thinking about this, so I'm a little foggy, but it seems the safest way to do this is to break the g-code program into a separate program for each tool change. If doing that, then we might keep the files for a job in a directory named according to the job. Humm, not something that can be done currently as an oword named file must be in the NC_FILES defined path. HOWEVER, I didn't try to use the oeagle/tedautoz call format when I was doing the pcb's. I assumed that it would not work but would be happy to learn there is a way. If there [were] a way to make this look like one run, that would be better. It is easy to have a filter program process a #nextfile somefile last command in an input file, to achieve file sequencing. However, it is just as easy to keep the entire part program in a single file, and synthesise separate files of gcode on the output of the filter. Do you visualise an M2 separating the tool runs, on the output of the filter? How much jogging do we really want to do, though? Isn't it a bit more convenient to program rapids to a fixed probing station, where we also do the toolchanges? (Or toolchange nearby, to avoid dropping things on the probing sensor.) Perhaps I haven't understood all the variables in This was the problem I encountered. I at first made a probing location, a pillar with the probe surface on top of it that stood alongside the pcb pallet, but after breaking several bits and crushing the probe surface 2 times because I forgot to move and reconnect the probing clip, I gave up and now probe the corner of the pcb itself, removing all those variables from the equation. I do it slow enough there is no mark left on the pcb. your following paragraph?: Also, it would be nice to be able to use the same original part file for machines with repeatable tool holders or machines or tool holders that need a touch off for each change. If touch off isn't needed, then we just go to the toolchange position, omitting the touch off position? A machine-specific toolchange subroutine could conveniently wrap up all of that customisation, couldn't it? (And with #include functionality in the filter program, such a subroutine could be in a file of its own, or several could be included in the one file, if they are always used together.) The key to which type of change would be needed could be a setting in a configuration file or a special code in the tool table. Rather than spreading this stuff all over the system, would it be more convenient to just let the toolchange subroutine do the customisation in the part program? This was my final solution, with any xy compensations being done in the G55 world for the top of the board, and the G56 world for the bottom of the board. z offsets from the probing were applied in real time after canceling any that existed prior to the probe. That stuff can build up and eat your lunch. A preprocessor could scan the g-code file for tool changes and create sub files of the commands between tools of the touch off variety. Then call the subfiles in sequence with a touch off macro between sub-runs. Ah, that sounds very much like the understanding of your idea that I'm ploughing through, above. If you're happy to use a more human-readable dialect of LinuxCNC gcode, then we can add a toolchange command, conforming to your specifications, and syntax which we find most readable, to infrastructure which is already coming together. Checks would be needed to make sure the contexts don't change or are correct. If it's all one file, then what sort of checks do we need to perform? Even if it is something that gcode can't intrinsically do, such as reading back the current state of a modality, the translator can do that with its input. (It's doing that now on distance mode, so that a G81 ... L3 can be given a fleeting G91, with automatic restoration to G90 before proceeding to the next line, _if_ that is the setting current in that section of the program.) Basically, automating what an operator would currently need to do by hand. And that is what we're all here for. ;-) If we need to tell the filter something about what we've done during the toolchange, then that could be written to a temporary file or named pipe, for the filter to inspect before proceeding with the next code segment. That also would not necessitate splitting the part program into subfiles, because switching a filter's input stream between input files is trivial. An Await Signal command is easily added to the translator/filter currently in the works. It could alternatively respond to a unix signal, or check a semaphore, or whatever we find most convenient. Your ideas look like a lot of fun to implement. To make it more seamless, it ought to be manageable
[Emc-users] Tool change question
Kirk, Thanks for your insight into the problem as per your recent message You could just do this: Put a M00 on the line right before the TxM6 line. When the machine stops at the M00 hit the esc key Now jog around,change tools and touch off. reload the tool table. I will assume that you are using AXIS so now right click on the TxM6 line and it will start from there. I have tried your suggestion and found that by pressing escape after clicking the TxM6 line and then right clicking, a message flag appears that says Start From Here or something similar -- Alwyn McLeod Cell 073 500 6992 Fax 086 510 8765 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Tool change question
On Wed, 21 Mar 2012 19:24:52 +1100 Erik Christiansen dva...@internode.on.net wrote: On 20.03.12 22:21, Kirk Wallace wrote: I've got my brain sore thinking about this, so I'm a little foggy, but it seems the safest way to do this is to break the g-code program into a separate program for each tool change. If doing that, then we might keep the files for a job in a directory named according to the job. If there [were] a way to make this look like one run, that would be better. It is easy to have a filter program process a #nextfile somefile last command in an input file, to achieve file sequencing. However, it is just as easy to keep the entire part program in a single file, and synthesise separate files of gcode on the output of the filter. Do you visualise an M2 separating the tool runs, on the output of the filter? How much jogging do we really want to do, though? Isn't it a bit more convenient to program rapids to a fixed probing station, where we also do the toolchanges? (Or toolchange nearby, to avoid dropping things on the probing sensor.) Perhaps I haven't understood all the variables in your following paragraph?: Also, it would be nice to be able to use the same original part file for machines with repeatable tool holders or machines or tool holders that need a touch off for each change. If touch off isn't needed, then we just go to the toolchange position, omitting the touch off position? A machine-specific toolchange subroutine could conveniently wrap up all of that customisation, couldn't it? (And with #include functionality in the filter program, such a subroutine could be in a file of its own, or several could be included in the one file, if they are always used together.) The key to which type of change would be needed could be a setting in a configuration file or a special code in the tool table. Rather than spreading this stuff all over the system, would it be more convenient to just let the toolchange subroutine do the customisation in the part program? A preprocessor could scan the g-code file for tool changes and create sub files of the commands between tools of the touch off variety. Then call the subfiles in sequence with a touch off macro between sub-runs. Ah, that sounds very much like the understanding of your idea that I'm ploughing through, above. If you're happy to use a more human-readable dialect of LinuxCNC gcode, then we can add a toolchange command, conforming to your specifications, and syntax which we find most readable, to infrastructure which is already coming together. Checks would be needed to make sure the contexts don't change or are correct. If it's all one file, then what sort of checks do we need to perform? Even if it is something that gcode can't intrinsically do, such as reading back the current state of a modality, the translator can do that with its input. (It's doing that now on distance mode, so that a G81 ... L3 can be given a fleeting G91, with automatic restoration to G90 before proceeding to the next line, _if_ that is the setting current in that section of the program.) Basically, automating what an operator would currently need to do by hand. And that is what we're all here for. ;-) If we need to tell the filter something about what we've done during the toolchange, then that could be written to a temporary file or named pipe, for the filter to inspect before proceeding with the next code segment. That also would not necessitate splitting the part program into subfiles, because switching a filter's input stream between input files is trivial. An Await Signal command is easily added to the translator/filter currently in the works. It could alternatively respond to a unix signal, or check a semaphore, or whatever we find most convenient. Your ideas look like a lot of fun to implement. To make it more seamless, it ought to be manageable to make the filter respond to unix signals (thus obviating the need for a communications file, just to give a resumption go ahead), and it may be possible to add an AXIS button to send such a signal. If we can clarify exactly what is required, then I'd enjoy adding to the translator the parts it can do. (i.e. pretty much all of it, barring a button or two in AXIS, AIUI.) Even if we start with something basic, it can be tweaked as we go along. Erik Hi all, It is obvious that, oh, what a way to start a statement. ;-) Anyway, I think we need a way to queue up a series of programs; in other words a facility to do open and run from a sequential list. Dave -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net
Re: [Emc-users] Tool change question
2012/3/21 Alwyn McLeod mcleod.al...@gmail.com: Kirk, Thanks for your insight into the problem as per your recent message You could just do this: Put a M00 on the line right before the TxM6 line. When the machine stops at the M00 hit the esc key Now jog around,change tools and touch off. reload the tool table. I will assume that you are using AXIS so now right click on the TxM6 line and it will start from there. I have tried your suggestion and found that by pressing escape after clicking the TxM6 line and then right clicking, a message flag appears that says Start From Here Exactly! And that is what You have to select to resume running the code from that particular place. Viesturs -- Alwyn McLeod Cell 073 500 6992 Fax 086 510 8765 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Tool change question
On Wed, 2012-03-21 at 19:24 +1100, Erik Christiansen wrote: On 20.03.12 22:21, Kirk Wallace wrote: I've got my brain sore thinking about this, so I'm a little foggy, but it seems the safest way to do this is to break the g-code program into a separate program for each tool change. If doing that, then we might keep the files for a job in a directory named according to the job. If there [were] where might have been a left over accent from Saint Patrick's Day. a way to make this look like one run, that would be better. It is easy to have a filter program process a #nextfile somefile last command in an input file, to achieve file sequencing. However, it is just as easy to keep the entire part program in a single file, and synthesise separate files of gcode on the output of the filter. Do you visualise an M2 separating the tool runs, on the output of the filter? Whatever is needed to make a full file that could stand on its own if needed. How much jogging do we really want to do, though? Isn't it a bit more convenient to program rapids to a fixed probing station, where we also do the toolchanges? (Or toolchange nearby, to avoid dropping things on the probing sensor.) Perhaps I haven't understood all the variables in your following paragraph?: Since, at touch off tool change periods, we are between separate part files, the operator can do whatever is normally done to set up a job, such as jog to the workpiece, pull out a favorite dowel pin and finely jog for a proper slip fit between the bit and workpiece, enter in the proper offset, repeat for each axis and finish with clicking Resume but actually starting a new run. Also, it would be nice to be able to use the same original part file for machines with repeatable tool holders or machines or tool holders that need a touch off for each change. I think it would be better to have the g-code remain portable between different machines and have the tool change variations handled in the local application rather than having a different g-code file for each machine even though the part is the same. In the real world, it seems that there is always something about a machine that requires a change in the g-code, but I'd like to avoid it if we can. If touch off isn't needed, then we just go to the toolchange position, omitting the touch off position? Yes, I think so. A machine-specific toolchange subroutine could conveniently wrap up all of that customisation, couldn't it? (And with #include functionality in the filter program, such a subroutine could be in a file of its own, or several could be included in the one file, if they are always used together.) The key to which type of change would be needed could be a setting in a configuration file or a special code in the tool table. Rather than spreading this stuff all over the system, would it be more convenient to just let the toolchange subroutine do the customisation in the part program? The more I think about this, the preprocessor could check the g-code for all of the tools called, then check to see if any tool parameters are missing for those tool entries and flag the tools with missing information for special handling. The tool table has totally changed (for the better, at first glance) since the last time I looked at it, so I'll need to get up to speed on tool tables. A preprocessor could scan the g-code file for tool changes and create sub files of the commands between tools of the touch off variety. Then call the subfiles in sequence with a touch off macro between sub-runs. Ah, that sounds very much like the understanding of your idea that I'm ploughing through, above. If you're happy to use a more human-readable dialect of LinuxCNC gcode, then we can add a toolchange command, conforming to your specifications, and syntax which we find most readable, to infrastructure which is already coming together. Checks would be needed to make sure the contexts don't change or are correct. If it's all one file, then what sort of checks do we need to perform? Even if it is something that gcode can't intrinsically do, such as reading back the current state of a modality, the translator can do that with its input. (It's doing that now on distance mode, so that a G81 ... L3 can be given a fleeting G91, with automatic restoration to G90 before proceeding to the next line, _if_ that is the setting current in that section of the program.) The above is new to me, but my concern is to start the new run (subfile) with the proper header, with the new header derived from the context that the previous subfile ended with. Sort of like saving and restoring the stack and other registers to handle an interrupt. Basically, automating what an operator would currently need to do by hand. And that is what we're all here for. ;-) If we need to tell the filter something about what we've done during the toolchange, then that could be
Re: [Emc-users] Tool change question
On Wed, 2012-03-21 at 18:19 +0200, Viesturs Lācis wrote: 2012/3/21 Alwyn McLeod mcleod.al...@gmail.com: ... snip I have tried your suggestion and found that by pressing escape after clicking the TxM6 line and then right clicking, a message flag appears that says Start From Here Exactly! And that is what You have to select to resume running the code from that particular place. Viesturs My problem with the 'right click / run from this line' feature is that I don't know what the present context is or should be. I can work it out by carefully keeping a record of the header context and any changes while the program runs, or ahead of time, create stop points and sub headers in the g-code. It may be convenient to have the computer do this automatically. Having HALscope stream the context would be interesting. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/index.html California, USA -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] CAM / G-code Generation
Greetings, I have been trying to find a decent open source CAD and CAM solution. FreeCAD looks very promising and it appears that Dan Falck got opencamlib at least crudely working with it. Is any one using FreeCAD/opencamlib to make any actual cuts? Other than that, can anyone recommend a simple open source solution for generating G-code? If not open source, how about it at least run on Ubuntu 10.04? I appreciate all comments and suggestions! Thanks, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] CAM / G-code Generation
Have you looked at HeeksCAD/CAM? heeks.net Ray On Wed, Mar 21, 2012 at 10:50 AM, Jeshua Lacock jes...@3dtopo.com wrote: Greetings, I have been trying to find a decent open source CAD and CAM solution. FreeCAD looks very promising and it appears that Dan Falck got opencamlib at least crudely working with it. Is any one using FreeCAD/opencamlib to make any actual cuts? Other than that, can anyone recommend a simple open source solution for generating G-code? If not open source, how about it at least run on Ubuntu 10.04? I appreciate all comments and suggestions! Thanks, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] CAM / G-code Generation
On Mar 21, 2012, at 11:50 , Jeshua Lacock wrote: Greetings, I have been trying to find a decent open source CAD and CAM solution. FreeCAD looks very promising and it appears that Dan Falck got opencamlib at least crudely working with it. Is any one using FreeCAD/opencamlib to make any actual cuts? Other than that, can anyone recommend a simple open source solution for generating G-code? If not open source, how about it at least run on Ubuntu 10.04? I appreciate all comments and suggestions! I've made parts with FreeCAD and PyCAM. FreeCAD is pretty great, PyCAM still has a ways to go. If you are going to use PyCAM, clone their git repo on Sourceforge, don't use their latest published deb, it's out of date. I feel sanguine about Dan Falck's FreeCAD + OpenCamLib. -- Sebastian Kuzminsky -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Z-probing derived kinematics
Today i wrote a little program which calculates the absolute z distance between a distorted plane (stl file) at a given xy location and zero. I used simple triangles and no higher order interpolation. The result was calculated very fast because of the simple maths used (only + - * /) and always correct compared to a cad program. So i think the problems lay beyond the z-depth calculation from the stl file. I wonder how you process a simple move over a distance which may span over 3 triangles. Do you separate this move into three single moves with different start and end z-depths? Or do you check before each step the z-depth of the stl file and correct the commanded z-depth (would be very cpu intensive if done for each single step)? Ciao, Rainer Am 20.03.2012 00:00, schrieb Michael Haberler: I ran into a problem with following errors if a move is exactly along a triangle edge I havent investigated it further but I guess it could be a discontinuity/numerical accuracy/stability problem along the edges If that is the case, the approach using discrete-triangle based correction could be fundamentally flawed one way I guess would work is to create a continuous surface correction function, like a cubic spline - Michael Am 19.03.2012 um 21:03 schrieb Fox Mulder: Since the last mail from december it has gotten really quite about this very handy feature. But i can see in the git logs that it was further developed. So what is the state of it right now and how could it be used? Sadly i can't find any info at all on the linuxcnc website. I want to do some pcb etching tests in the next few weeks and i think this feature would be a great benefit for this purpose. :) Ciao, Rainer Am 21.12.2011 08:31, schrieb Michael Haberler: I found the idea quite intriguing, and thought about integrating the surface correction idea better. After bouncing a few ideas with Andy, this is what I have so far: probekins: a kinematics module which be default behaves like trivkins it accepts a mesh of triangles which define Z correction values (actually an approximation of the workpiece surface, or machine surface for that matter) this mesh might eventually generated by probing, but also used as a general machine Z correction this isnt finished or polished, but I'm posting it anyway to see what folks think about it. see http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/probekins - Michael v0.1 README: Z correction by triangular mesh --- The probekins kins module is a trivial kinematics module unless loaded with a Z correction mesh. It helps dealing with warped workpiece surfaces (or machines), and was inspired by a recent thread on emc-users about PCB milling. the correction mesh is a set of triangles specified by an STL file. This file might eventually be generated by probing a few points, and creating a triangular mesh from it, for instance by a Delauney triangulation, If a point (x,y) lies within the one of the triangles, it's z value is adjusted by the interpolated value on the enclosing triangle. Points outside any triangle are not corrected for. This means the correction value currently 'falls off the cliff' at the convex hull of the triangles (the enclosing polygon if you will). The triangles are applied in the order specified in the file, so there could be a 'later' larger triangle enclosing or overlapping an earlier one. The algorithm currently is based on a brute-force test of all triangles until first match. The ray/triangle intersection test is very fast, nevertheless this is an O(number of triangles) implementation. There are numerous ways to optimize this which are left as an exercise for the reader;). To load an STL Z correction file: - python stlcorr.py file,stl To inspect the current correction: -- python stlcorr.py To clear the correction: python stlcorr.py -c Example STL file containing two triangles: solid facet normal 0 1 1 outer loop vertex 0 0 0 vertex 0 5 0 vertex 5 0 2 endloop endfacet facet normal 2 3 4 outer loop vertex 1 1 1 vertex -1 -1 1 vertex 1 -1 2 endloop endfacet endsolid - The normal vectors are ignored and can be left out for the purpose of describing a correction mesh. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] CAM / G-code Generation
On Wed, 21 Mar 2012 11:50:34 -0600 Jeshua Lacock jes...@3dtopo.com wrote: Greetings, I have been trying to find a decent open source CAD and CAM solution. FreeCAD looks very promising and it appears that Dan Falck got opencamlib at least crudely working with it. Is any one using FreeCAD/opencamlib to make any actual cuts? Other than that, can anyone recommend a simple open source solution for generating G-code? If not open source, how about it at least run on Ubuntu 10.04? I appreciate all comments and suggestions! I think Dan is off using HeeksCAD as the easiest free solution. On the $$ side I use synergy from weber systems. The drafting is free, cam for 2.5 D is $250. IIRC, wireframe is $750 and full solids (parasolids) is $1250. The learning curve is interesting but possible even for a dummy like me. Google 'synergy cad' to get a web site. They have a 30 day trial of the full meal deal. On the non-$$ side I'm trying to learn APT; both for mental exercise and as a practical tool. Dave Thanks, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] CAM / G-code Generation
On Mar 21, 2012, at 12:40 PM, Ray Mitchell wrote: Have you looked at HeeksCAD/CAM? heeks.net Hi Ray, I haven't had time to run my machine in quite sometime, but, HeeksCAD is was what I used last time I needed to make some simple tool paths. When I looked at the current state of Heeks yesterday, it seemed like the author was recommending FreeCAD: I don't have time to administer HeeksCAD properly and I suggest for a more active project you look at FreeCAD. http://code.google.com/p/heekscad/ Apparently, Dan Falck got opencamlib running in FreeCAD. I understand that opencamlib is essentially what powers G-code creation in Heeks: http://opensourcedesigntools.blogspot.com/ Best, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] CAM / G-code Generation
On Mar 21, 2012, at 12:44 PM, Sebastian Kuzminsky wrote: On Mar 21, 2012, at 11:50 , Jeshua Lacock wrote: Greetings, I have been trying to find a decent open source CAD and CAM solution. FreeCAD looks very promising and it appears that Dan Falck got opencamlib at least crudely working with it. Is any one using FreeCAD/opencamlib to make any actual cuts? Other than that, can anyone recommend a simple open source solution for generating G-code? If not open source, how about it at least run on Ubuntu 10.04? I appreciate all comments and suggestions! I've made parts with FreeCAD and PyCAM. FreeCAD is pretty great, PyCAM still has a ways to go. If you are going to use PyCAM, clone their git repo on Sourceforge, don't use their latest published deb, it's out of date. I feel sanguine about Dan Falck's FreeCAD + OpenCamLib. Thanks Sebastian. I had forgot about PyCAM - it looked promising last time I gave it a shot, but IIRC it was crashing last time I tried it. Will give her a whirl. Best, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] CAM / G-code Generation
On Mar 21, 2012, at 1:24 PM, dave wrote: I have been trying to find a decent open source CAD and CAM solution. FreeCAD looks very promising and it appears that Dan Falck got opencamlib at least crudely working with it. Is any one using FreeCAD/opencamlib to make any actual cuts? Other than that, can anyone recommend a simple open source solution for generating G-code? If not open source, how about it at least run on Ubuntu 10.04? I appreciate all comments and suggestions! I think Dan is off using HeeksCAD as the easiest free solution. On the $$ side I use synergy from weber systems. The drafting is free, cam for 2.5 D is $250. IIRC, wireframe is $750 and full solids (parasolids) is $1250. The learning curve is interesting but possible even for a dummy like me. Google 'synergy cad' to get a web site. They have a 30 day trial of the full meal deal. On the non-$$ side I'm trying to learn APT; both for mental exercise and as a practical tool. Thanks for the suggestions Dave. I could live with $250 but I ultimately need some solids. So PyCAM, HeeksCAD and opencamlib that is pretty much all the open source CAM? Seems surprising. Is there any decent 3D CAM on Windows for a few hundred then? Best, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] CAM / G-code Generation
On Mar 21, 2012, at 13:59 , Jeshua Lacock wrote: Is there any decent 3D CAM on Windows for a few hundred then? A friend speaks highly of Cam Bam (which is closed source, costs money, and runs on Windows). I've never used it, but I've run its gcode on LinuxCNC and that worked well. -- Sebastian Kuzminsky -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] CAM / G-code Generation
Have you looked at HeeksCAD/CAM? heeks.net Hi Ray, I haven't had time to run my machine in quite sometime, but, HeeksCAD is was what I used last time I needed to make some simple tool paths. When I looked at the current state of Heeks yesterday, it seemed like the author was recommending FreeCAD: I don't have time to administer HeeksCAD properly and I suggest for a more active project you look at FreeCAD. http://code.google.com/p/heekscad/ My understanding is that Dan Heeks wanted to work on the google-code version himself, whenever he has time - he may be busy with other projects. The version of HeeksCAD/CNC on github was forkeddeveloped by a number of users, but that momentum seems to have been lost now. Apparently, Dan Falck got opencamlib running in FreeCAD. I understand that opencamlib is essentially what powers G-code creation in Heeks: http://opensourcedesigntools.blogspot.com/ I think Dan Falck ran some python-scripts on STL-files offline, and then just imported the original STL file together with the toolpath into FreeCAD. There are no 2D operations in opencamlib, so any 2/2.5D operations in HeeksCNC use something else. Libarea is used for 2D offsets. I've been tinkering with a 2D voronoi-diagram implementation called OpenVoronoi which can eventually be used for a number of 2D operations. It would be great if someone would work out how to export triangles (3D) and/or lines/polylines/arcs (2D) from FreeCAD into python (where opencalib, openvoronoi, and libarea can be used), and then how toolpaths produced by the libraries can be pushed back into FreeCAD as new geometry. Dan F seems to have made some progress in this direction. Anders -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] CAM / G-code Generation
Just to throw my two cents in, in addition to there being very few cam solutions, there are even fewer that do lathe profiling. The ones that do, it's listed as experimental or seems thrown in. Ian On Mar 21, 2012, at 4:46 PM, Greg Bernard wrote: What sort of work are you planning to do? In the Windoze world there is CamBam (about $150 for the latest version, free for the old but still usable version) I could not get it to run under Wine. I just recently bought Vectric V-carve Pro which runs well on Wine. It will do any 2.5 D work and is excellent for artistic type stuff. I am VERY pleased with it. Price is $599. They also have Aspire which does full 3d but is out of my price range at $2000. It is a very nice piece of software however. From: Jeshua Lacock jes...@3dtopo.com To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Sent: Wednesday, March 21, 2012 2:59 PM Subject: Re: [Emc-users] CAM / G-code Generation On Mar 21, 2012, at 1:24 PM, dave wrote: I have been trying to find a decent open source CAD and CAM solution. FreeCAD looks very promising and it appears that Dan Falck got opencamlib at least crudely working with it. Is any one using FreeCAD/opencamlib to make any actual cuts? Other than that, can anyone recommend a simple open source solution for generating G-code? If not open source, how about it at least run on Ubuntu 10.04? I appreciate all comments and suggestions! I think Dan is off using HeeksCAD as the easiest free solution. On the $$ side I use synergy from weber systems. The drafting is free, cam for 2.5 D is $250. IIRC, wireframe is $750 and full solids (parasolids) is $1250. The learning curve is interesting but possible even for a dummy like me. Google 'synergy cad' to get a web site. They have a 30 day trial of the full meal deal. On the non-$$ side I'm trying to learn APT; both for mental exercise and as a practical tool. Thanks for the suggestions Dave. I could live with $250 but I ultimately need some solids. So PyCAM, HeeksCAD and opencamlib that is pretty much all the open source CAM? Seems surprising. Is there any decent 3D CAM on Windows for a few hundred then? Best, Jeshua Lacock Founder/Engineer 3DTOPO Incorporated http://3DTOPO.com Phone: 208.462.4171 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Z-probing derived kinematics
Rainer, I'm not sure if I fully understand your question. The way this works is through forward and reverse kinematics (see http://wiki.linuxcnc.org/uploads/EMC_Control_LG.gif) when the trajectory planner outputs a new target position it passes it through reverse kins to determine the corresponding axis positions. So thats where the z correction happens - tp runs about 1000 times a sec, so the correction is applied at the same rate the probekins module currently searches sequentially through the list of triangles searching for a hit. On a hit, the z value is used to correct the output to the axis control. The problem: Assume you have two triangles which share an edge. Now program a move which in x,y follows this shared edge. I *think* this border case is responsible for the following error. if you move across triangles in an arbitrary fashion (not tracking edges) it works just fine. Maybe somebody else can dig deeper into this, it might be just a trivial thing. The ray/triangle intersection test itself is very fast - its a favorite CG/raytracing community problem. Sequentially testing many triangles might become an issue, but there are standard ways to deal with this, like KD trees. -m Am 21.03.2012 um 20:06 schrieb Fox Mulder: Today i wrote a little program which calculates the absolute z distance between a distorted plane (stl file) at a given xy location and zero. I used simple triangles and no higher order interpolation. The result was calculated very fast because of the simple maths used (only + - * /) and always correct compared to a cad program. So i think the problems lay beyond the z-depth calculation from the stl file. I wonder how you process a simple move over a distance which may span over 3 triangles. Do you separate this move into three single moves with different start and end z-depths? Or do you check before each step the z-depth of the stl file and correct the commanded z-depth (would be very cpu intensive if done for each single step)? Ciao, Rainer Am 20.03.2012 00:00, schrieb Michael Haberler: I ran into a problem with following errors if a move is exactly along a triangle edge I havent investigated it further but I guess it could be a discontinuity/numerical accuracy/stability problem along the edges If that is the case, the approach using discrete-triangle based correction could be fundamentally flawed one way I guess would work is to create a continuous surface correction function, like a cubic spline - Michael Am 19.03.2012 um 21:03 schrieb Fox Mulder: Since the last mail from december it has gotten really quite about this very handy feature. But i can see in the git logs that it was further developed. So what is the state of it right now and how could it be used? Sadly i can't find any info at all on the linuxcnc website. I want to do some pcb etching tests in the next few weeks and i think this feature would be a great benefit for this purpose. :) Ciao, Rainer Am 21.12.2011 08:31, schrieb Michael Haberler: I found the idea quite intriguing, and thought about integrating the surface correction idea better. After bouncing a few ideas with Andy, this is what I have so far: probekins: a kinematics module which be default behaves like trivkins it accepts a mesh of triangles which define Z correction values (actually an approximation of the workpiece surface, or machine surface for that matter) this mesh might eventually generated by probing, but also used as a general machine Z correction this isnt finished or polished, but I'm posting it anyway to see what folks think about it. see http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/probekins - Michael v0.1 README: Z correction by triangular mesh --- The probekins kins module is a trivial kinematics module unless loaded with a Z correction mesh. It helps dealing with warped workpiece surfaces (or machines), and was inspired by a recent thread on emc-users about PCB milling. the correction mesh is a set of triangles specified by an STL file. This file might eventually be generated by probing a few points, and creating a triangular mesh from it, for instance by a Delauney triangulation, If a point (x,y) lies within the one of the triangles, it's z value is adjusted by the interpolated value on the enclosing triangle. Points outside any triangle are not corrected for. This means the correction value currently 'falls off the cliff' at the convex hull of the triangles (the enclosing polygon if you will). The triangles are applied in the order specified in the file, so there could be a 'later' larger triangle enclosing or overlapping an earlier one. The algorithm currently is based on a brute-force test of all triangles until first match. The ray/triangle intersection test is very fast, nevertheless
