Like the topic says, I made my first cuts today from a pycam generated file on Windows XP. Install as not so bad. Had lots of good help from here.
I generated three cut paths on a stl model generated from MOI3d. All three passes were using the drop cutter with a zigzag pattern. The first two passes were intended as roughing passes with a material allowance of .3 and .1 and an overlap of 50%. Worked mostly. The final pass was with 90% overlap and 0 material allowance. The material allowance worked fine but the overlap looked like it stayed at 50%.
I tried some different overlaps with the sled stl to see if that worked. I didn’t. Even with a 99% overlap, there are still only about 5 passes in one cutter diameter. I say about because I did it this morning and I’m doing this by memory. At any rate it was far from 99%. Maybe I’m not understanding the overlap parameter??? I’m assuming that with a 90% overlap the cutter will move over one tenth (0.1) of the cutter diameter.
Now for a few questions about material allowance. If I set a material allowance does it only apply to the Z axis or is it also applied to the X and Y too. Also, is it the proper way to do roughing passes when using the drop cutter. It’s the only way I could find that would allow me to make multiple passes.
I also had a problem with the model edges. I didn’t keep track of this very well so I don’t have too many details. I’ll try to detail this better when I get more time. I use a 0 margin bound box and decrease the box size the amount of the cutter radius to keep the cutter from traveling in the –z direction at the edges. There is some discussion on this in the Help section of this forum. Even though the display does not show any Z excursions, they definitely show up during the cut. On my second roughing pass, the cutter jumped in the +Z direction at the end of each line.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I took a look at the "overlap" code and it is indeed broken. You can easily fix it on your own by changing the following line of pycam/Gui/Project.py (around line 1367):
effective_toolradius = self.settings.get("tool_radius") * (1.0 - self.settings.get("overlap")/200.0)
to:
effective_toolradius = self.settings.get("tool_radius") * (1.0 - self.settings.get("overlap")/100.0)
(just the last number changes from "200" to "100").
The fix is already commited to svn.
Regarding the material allowance:
It applies to x, y and z distances. The radius of the drill and its length are virtually increased by the material allowance. This is the correct assumption for the spherical cutter. For the cylindrical cutter the calculation is not completely correct, since the perfect "expanded" drill shape would be a cylinder with a capped conus, but it is very close to reality so it should not hurt.
Did you try to use the "PushCutter" with an appropriate "Max. Step Down" setting? This should be the way to go for multiple pass layers.
Regarding your manual "fix" for the border limits at zero margin: I will add a configuration setting for the different interpretations of the bounding box:
- "the tool is always completely inside"
vs.
- "the tool travels around the bounding box"
This will be included in v0.2.3.
Regarding the -z excursion: just disable the "Model view" (in "Preferences") to visually check the model path. I guess, the glitches that you encountered later were visible in PyCAM as well, or?
Regarding the jump to +z at the end of each line:
This is just a "go to safety height" move after each cut. You can adjust it via the "Safety Height" parameter. Right now I can't think of an easy (and safe) way to skip these "safety moves" where they are obvisouly not necessary.
again: thanks for your feedback!
Lars
PS: I would be happy to see (or even publish) pictures of your cutted piece, if you don't mind :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried the push cutter. I guess I’m not understanding what it is supposed to do. With the drop down cutter and the zigzag pattern, I get a cut path that follows the upper surface of the model. Using the push cutter and a zigzag pattern with step down I get a series of cut paths that appear do nothing more than cut a series of xy planes starting at max z of the bound box down to the min z of the bound box in increments of the step down value. It looks like when the z cut is at the model level, it goes right through the model .
All of the above was done with ODE disabled. When I enable ODE, the push cutter stopeds working. I thought this was working in the earlier version in a test?? Mabybe didn't test enough. In the above test, I set the max z of the bound box high enough so that there were 5 xy plane cuts of nothing but air. On the 6th, the model was finally touched. When ODE was enabled, the program locked up when on that 6th pass. 30 minutes later, nothing so I gave up waiting and ended the program.
Also, and this is something I suspect and have not really verified. The more cut paths you generate, the slower the program gets. As I was trying different options on the same model, the path generation took longer and longer. Restarting pycam did not help. I had to reboot. Sounds like memory holes?
And yes, will be happy to post pics as soon as I cut something nice. What is the best way on the forum?
A few more things that don’t seem to work;
1. Load Recently Used Models shows a blank list.
2. Manage templates does not save a template. Type in a name, click save and they show up in the list. The next time I run pycam, the template is not there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
you should combine the push cutter with the polygon path processor…
it's supposed to clear the material from atound the model. (have a look atthe "screenshots" section https://sourceforge.net/project/screenshots.php?group_id=237831) to see what the paths are supposed to look like
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
did you experience this lockup with ODE under PyCAM v0.2.2? I thought, I this problem was fixed in that version.
Could you send me the STL file and your processing settings? I would like to reproduce the lockup …
Regarding the suspected memory holes: I never experienced this. I _could_ imagine, that the ODE library could expose leaks, but I doubt, that they would survive after the program was closed.
Sadly I can't really reproduce this issue here (I use Windows only in Virtualbox), thus it would be great, if you could provide more details.
It seems like you can't upload pictures directly to this forum. But you can upload them somewhere else and add a link here. You could also send pictures to my mail account, then I will upload them myself.
Your two issues:
1) I fixed this in r264 - thanks for your hint!
2) The template management works, but it is not intuitive :)
After "saving" the specific setting, you also need to save the new list of settings to a "processing settings" file (see the menu). You can load the file later again (or specify it on the commandline).
I am currently working on improving this part of the GUI, since it is really awkward …
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm going to back off of the comment about the tool paths not generating with ODE enabled. It maybe working. It's just slower than my attention span would allow. In my first attempt at generating a tool path as suggested, push cutter and polygon, I turned on the cutter in the display options. It was moving every once in a while so I think things were grinding along. It was going to take a looonnnng time so I stopped the program and reloaded a smaller file.
I loaded the sled.stl file and tried it. I figured out were to post pics so instead of writing down all of the settings, its in the screen dump;
Is this how it should look? There is a nice flat cut in the xy plane at the upper z limit and a few cuts around the bottom of the model. I was expecting some cuts that would follow the top surface of the model. I'm still not understanding what the differences are between the two cutter types but I'm working on it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I made another attempt at a tool path today. I loaded the sled, set the units to inches, and selected a zero margin bound box.
I started the cutting path with the settings in the link. The pic is where it ended. I did this twice with the same results. I used the sled because because it kind of worked before with a 50% overlap. I had the same results with my own model so I back stepped to this try.
I also have a question about the over lap. The way that the tool path seems to be generating it looks like there will be 290 steps in the 1.75" width of the sled. With the .125" dia cutter I've set, it seems that there should only be 140 steps with a .0125" step. It looks like the overlap is applied to the cutter radius?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Couple thoughts, I too just recently did my first cuts using pycam. It seems very promising, I even started going through the code and am starting to get my head around how things are layed out (unfortunately I am not a python programmer, only marginally familiar with python).
Here are my initial thoughts, and do feel free to correct me if you think I am misunderstanding something:
1) Jump to Safety Height: I agree with bamoore01, it would be nice if the bit didn't lift to safety height only to set down again on the same spot. If nothing else the gcode could be parsed to detect and eliminate the most absurd occurrences of this. This is really just a nuisance though.
2) Drop Speed: Would be nice to be able to set a drop speed different than the feedrate. Not sure how common it is but the mill/bits I am working with is supposed to have a slow drop rate compared to feedrate. Would be nice not to have to slow down everything. Would also be nice to set the speed of safe moves separately, ie make safe moves as fast as possible.
3) Contours: I have also been playing around with contours, as they make for faster cuts on simple shapes. The contour algorithm being used seems to result in jagged lines (especially if a side is made of many polygons). Just had a thought that it could also have to do with the size of the object/triangles, on a larger object the jagged edge was less noticeable, at least in the vizualization window. I really need to play around with different models to figure out what is causing this.
PS Any chance someone can give me a short explanation on the internal representation of the model and paths? Is it just a kdtree of triangles? And using ordinary differential equations to compute paths? What is the non-experimental method of computing paths?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just did some more tests on the contour path planning. It appears to be an issue with overshoot on corners. If you use Contour postprocessing with x path direction, the sides parallel to the x axis are clean and it is sides parallel to the y axis that are jagged from over shoot. This appears to be exacerbated by rounded corners.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@bamoore01:
regarding your push cutter toolpath:
you specified a "max step down" value of zero. This results in just two slices: one at the upper z limit and one at the lower z limit.
I will need to add some check to the GUI to prevent the user from specifying a value of zero for the step down.
You will get a better picture of the push cutter with a value of 0.3 or something similar.
regarding the memory error:
I am about to investigate this. Maybe it is caused by the slightly old version of ODE that comes bundled with PyODE. Currently there seem to be preparations for a new release ongoing, so I hope this problem will be solved then.
regarding the overlap:
another user also noticed this calculation mistake. It is fixed in trunk and will be released soon.
regarding your pictures:
I would be especially keen on any pictures of the real-world object, that you cutted. Could you post these?
regarding the speed of safe moves:
You are right - currently the rapid speed (GCode: "G0") is only used for the first move to the start location and for the last move to the final location. I added this to the TODO list (see above), as well.
regarding jagged lines for Contour Cutter:
Do the cuts get better, if you use a smaller drill?
Do you see a difference, if you increase the margin around the model slightly? (I assume, you are using a zero-margin)
Could you provide an example model file and a screenshot for these jagged contours? You could also send it to me via mail (devel@sumpfralle.de).
regarding the internal representation of the data:
Triangles are stored in a kdtree.
The experimental ("ODE") collision detection does the following: do binary splits of the requested drill movements (DropCutter: vertical; PushCutter: horizontal) until the longest movement without a collision is found (checked via ODE). Usually 20 iterations are used for the DropCutter. The PushCutter uses 4 .. 20 iterations (depending on the model size).
The manual collision detection checks all triangles, that would meet the drill and calculates the exact location of the contact. For most cases this is considerably slower than the ODE collision detection.
I hope, this clarified your questions …
Lars
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I will make another try using a different dropdown heights for the push cutter. I assumed that a zero dropdown would make a series of cuts along the top surface of the model.
I'm not sure what picture you would want. The only thing I have to take a picture of is a failed cut where the overlap did not work properly resulting in a really rough finics. I can post that if you want but it looks pretty bad. All of my other attempts at make a tool path have failed when trying to set something up with an overlap small enough to generate a good looking finish cut. (earlier post)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just sent an email with pictures of jagged tool paths to Lars along with the stl file used. Reducing the tool radius and increasing the margins helped a bit.
Hope to have some more time to work with pyCAM over the weekend.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@bamoore01:
if the picture looks pretty bad, then please don't send it :)
I will wait patiently for a nice one …
regarding the overlap:
sorry for mixing your report up - of course, it was _you_ who noticed this issue before.
Did you try to replace "200" in the code with "100" as described above?
Does it behave as expected?
regarding the zero drop-down value:
In the next release, it will not be possible anymore, to use the invalid value (zero) here.
regarding the memory error, that you reported earlier:
I reproduced this here and noticed, that the generated toolpaths consume quite a bit of memory. The situation will get slightly better with the next release, if you are using python 2.6 or above. On Windows you are probably using python 2.5 due to the comfortable GTK installer described in INSTALL.txt, thus you won't enjoy this improvement :(
other ways to reduce memory consumption:
- remove unused toolpaths (via the third tab in the main window)
- increase the tool radius or reduce the "overlap"
I hope, this helps …
@odemia:
thanks for the helpful screenshots!
I assume that the jagged tool paths are caused by the tool radius.
Maybe you could try to increase the "overlap"? This should fix the inaccuracy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been working on trying to make a useable tool path using the sled sample stl and any of the cutter combinattions. I really haven't had much success. If I us an overlap of any usable value (> 50%) it simply takes too long and usually ends with errors.
I understand what you are saying when you suggest reducing the overlap or increase the tool radius. That may make the program work but it doesn't do anything to make an final product on the cnc machine. So, I'll keep trying.
Looking forward to the next release to try out.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm going to have to be a little dense here. What am I supposed to do with the three .gc files in the zip. I can't find any .gc files anyplace to replace or add to in the Python or pycam directories.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Like the topic says, I made my first cuts today from a pycam generated file on Windows XP. Install as not so bad. Had lots of good help from here.
I generated three cut paths on a stl model generated from MOI3d. All three passes were using the drop cutter with a zigzag pattern. The first two passes were intended as roughing passes with a material allowance of .3 and .1 and an overlap of 50%. Worked mostly. The final pass was with 90% overlap and 0 material allowance. The material allowance worked fine but the overlap looked like it stayed at 50%.
I tried some different overlaps with the sled stl to see if that worked. I didn’t. Even with a 99% overlap, there are still only about 5 passes in one cutter diameter. I say about because I did it this morning and I’m doing this by memory. At any rate it was far from 99%. Maybe I’m not understanding the overlap parameter??? I’m assuming that with a 90% overlap the cutter will move over one tenth (0.1) of the cutter diameter.
Now for a few questions about material allowance. If I set a material allowance does it only apply to the Z axis or is it also applied to the X and Y too. Also, is it the proper way to do roughing passes when using the drop cutter. It’s the only way I could find that would allow me to make multiple passes.
I also had a problem with the model edges. I didn’t keep track of this very well so I don’t have too many details. I’ll try to detail this better when I get more time. I use a 0 margin bound box and decrease the box size the amount of the cutter radius to keep the cutter from traveling in the –z direction at the edges. There is some discussion on this in the Help section of this forum. Even though the display does not show any Z excursions, they definitely show up during the cut. On my second roughing pass, the cutter jumped in the +Z direction at the end of each line.
Hi bamoore01,
thanks for your feedback!
I took a look at the "overlap" code and it is indeed broken. You can easily fix it on your own by changing the following line of pycam/Gui/Project.py (around line 1367):
effective_toolradius = self.settings.get("tool_radius") * (1.0 - self.settings.get("overlap")/200.0)
to:
effective_toolradius = self.settings.get("tool_radius") * (1.0 - self.settings.get("overlap")/100.0)
(just the last number changes from "200" to "100").
The fix is already commited to svn.
Regarding the material allowance:
It applies to x, y and z distances. The radius of the drill and its length are virtually increased by the material allowance. This is the correct assumption for the spherical cutter. For the cylindrical cutter the calculation is not completely correct, since the perfect "expanded" drill shape would be a cylinder with a capped conus, but it is very close to reality so it should not hurt.
Did you try to use the "PushCutter" with an appropriate "Max. Step Down" setting? This should be the way to go for multiple pass layers.
Regarding your manual "fix" for the border limits at zero margin: I will add a configuration setting for the different interpretations of the bounding box:
- "the tool is always completely inside"
vs.
- "the tool travels around the bounding box"
This will be included in v0.2.3.
Regarding the -z excursion: just disable the "Model view" (in "Preferences") to visually check the model path. I guess, the glitches that you encountered later were visible in PyCAM as well, or?
Regarding the jump to +z at the end of each line:
This is just a "go to safety height" move after each cut. You can adjust it via the "Safety Height" parameter. Right now I can't think of an easy (and safe) way to skip these "safety moves" where they are obvisouly not necessary.
again: thanks for your feedback!
Lars
PS: I would be happy to see (or even publish) pictures of your cutted piece, if you don't mind :)
I tried the push cutter. I guess I’m not understanding what it is supposed to do. With the drop down cutter and the zigzag pattern, I get a cut path that follows the upper surface of the model. Using the push cutter and a zigzag pattern with step down I get a series of cut paths that appear do nothing more than cut a series of xy planes starting at max z of the bound box down to the min z of the bound box in increments of the step down value. It looks like when the z cut is at the model level, it goes right through the model .
All of the above was done with ODE disabled. When I enable ODE, the push cutter stopeds working. I thought this was working in the earlier version in a test?? Mabybe didn't test enough. In the above test, I set the max z of the bound box high enough so that there were 5 xy plane cuts of nothing but air. On the 6th, the model was finally touched. When ODE was enabled, the program locked up when on that 6th pass. 30 minutes later, nothing so I gave up waiting and ended the program.
Also, and this is something I suspect and have not really verified. The more cut paths you generate, the slower the program gets. As I was trying different options on the same model, the path generation took longer and longer. Restarting pycam did not help. I had to reboot. Sounds like memory holes?
And yes, will be happy to post pics as soon as I cut something nice. What is the best way on the forum?
A few more things that don’t seem to work;
1. Load Recently Used Models shows a blank list.
2. Manage templates does not save a template. Type in a name, click save and they show up in the list. The next time I run pycam, the template is not there.
you should combine the push cutter with the polygon path processor…
it's supposed to clear the material from atound the model. (have a look atthe "screenshots" section https://sourceforge.net/project/screenshots.php?group_id=237831) to see what the paths are supposed to look like
Hi bamoore01.
did you experience this lockup with ODE under PyCAM v0.2.2? I thought, I this problem was fixed in that version.
Could you send me the STL file and your processing settings? I would like to reproduce the lockup …
Regarding the suspected memory holes: I never experienced this. I _could_ imagine, that the ODE library could expose leaks, but I doubt, that they would survive after the program was closed.
Sadly I can't really reproduce this issue here (I use Windows only in Virtualbox), thus it would be great, if you could provide more details.
It seems like you can't upload pictures directly to this forum. But you can upload them somewhere else and add a link here. You could also send pictures to my mail account, then I will upload them myself.
Your two issues:
1) I fixed this in r264 - thanks for your hint!
2) The template management works, but it is not intuitive :)
After "saving" the specific setting, you also need to save the new list of settings to a "processing settings" file (see the menu). You can load the file later again (or specify it on the commandline).
I am currently working on improving this part of the GUI, since it is really awkward …
I'm going to back off of the comment about the tool paths not generating with ODE enabled. It maybe working. It's just slower than my attention span would allow. In my first attempt at generating a tool path as suggested, push cutter and polygon, I turned on the cutter in the display options. It was moving every once in a while so I think things were grinding along. It was going to take a looonnnng time so I stopped the program and reloaded a smaller file.
I loaded the sled.stl file and tried it. I figured out were to post pics so instead of writing down all of the settings, its in the screen dump;
Is this how it should look? There is a nice flat cut in the xy plane at the upper z limit and a few cuts around the bottom of the model. I was expecting some cuts that would follow the top surface of the model. I'm still not understanding what the differences are between the two cutter types but I'm working on it.
I made another attempt at a tool path today. I loaded the sled, set the units to inches, and selected a zero margin bound box.
I started the cutting path with the settings in the link. The pic is where it ended. I did this twice with the same results. I used the sled because because it kind of worked before with a 50% overlap. I had the same results with my own model so I back stepped to this try.
I also have a question about the over lap. The way that the tool path seems to be generating it looks like there will be 290 steps in the 1.75" width of the sled. With the .125" dia cutter I've set, it seems that there should only be 140 steps with a .0125" step. It looks like the overlap is applied to the cutter radius?
Couple thoughts, I too just recently did my first cuts using pycam. It seems very promising, I even started going through the code and am starting to get my head around how things are layed out (unfortunately I am not a python programmer, only marginally familiar with python).
Here are my initial thoughts, and do feel free to correct me if you think I am misunderstanding something:
1) Jump to Safety Height: I agree with bamoore01, it would be nice if the bit didn't lift to safety height only to set down again on the same spot. If nothing else the gcode could be parsed to detect and eliminate the most absurd occurrences of this. This is really just a nuisance though.
2) Drop Speed: Would be nice to be able to set a drop speed different than the feedrate. Not sure how common it is but the mill/bits I am working with is supposed to have a slow drop rate compared to feedrate. Would be nice not to have to slow down everything. Would also be nice to set the speed of safe moves separately, ie make safe moves as fast as possible.
3) Contours: I have also been playing around with contours, as they make for faster cuts on simple shapes. The contour algorithm being used seems to result in jagged lines (especially if a side is made of many polygons). Just had a thought that it could also have to do with the size of the object/triangles, on a larger object the jagged edge was less noticeable, at least in the vizualization window. I really need to play around with different models to figure out what is causing this.
PS Any chance someone can give me a short explanation on the internal representation of the model and paths? Is it just a kdtree of triangles? And using ordinary differential equations to compute paths? What is the non-experimental method of computing paths?
Just did some more tests on the contour path planning. It appears to be an issue with overshoot on corners. If you use Contour postprocessing with x path direction, the sides parallel to the x axis are clean and it is sides parallel to the y axis that are jagged from over shoot. This appears to be exacerbated by rounded corners.
@bamoore01:
regarding your push cutter toolpath:
you specified a "max step down" value of zero. This results in just two slices: one at the upper z limit and one at the lower z limit.
I will need to add some check to the GUI to prevent the user from specifying a value of zero for the step down.
You will get a better picture of the push cutter with a value of 0.3 or something similar.
regarding the memory error:
I am about to investigate this. Maybe it is caused by the slightly old version of ODE that comes bundled with PyODE. Currently there seem to be preparations for a new release ongoing, so I hope this problem will be solved then.
regarding the overlap:
another user also noticed this calculation mistake. It is fixed in trunk and will be released soon.
regarding your pictures:
I would be especially keen on any pictures of the real-world object, that you cutted. Could you post these?
@odemia:
regarding the move to safety height:
Good point! I added this as a TODO in the wiki:
https://sourceforge.net/apps/mediawiki/pycam/index.php?title=TODO
regarding the speed of safe moves:
You are right - currently the rapid speed (GCode: "G0") is only used for the first move to the start location and for the last move to the final location. I added this to the TODO list (see above), as well.
regarding jagged lines for Contour Cutter:
Do the cuts get better, if you use a smaller drill?
Do you see a difference, if you increase the margin around the model slightly? (I assume, you are using a zero-margin)
Could you provide an example model file and a screenshot for these jagged contours? You could also send it to me via mail (devel@sumpfralle.de).
regarding the internal representation of the data:
Triangles are stored in a kdtree.
The experimental ("ODE") collision detection does the following: do binary splits of the requested drill movements (DropCutter: vertical; PushCutter: horizontal) until the longest movement without a collision is found (checked via ODE). Usually 20 iterations are used for the DropCutter. The PushCutter uses 4 .. 20 iterations (depending on the model size).
The manual collision detection checks all triangles, that would meet the drill and calculates the exact location of the contact. For most cases this is considerably slower than the ODE collision detection.
I hope, this clarified your questions …
Lars
I will make another try using a different dropdown heights for the push cutter. I assumed that a zero dropdown would make a series of cuts along the top surface of the model.
I'm not sure what picture you would want. The only thing I have to take a picture of is a failed cut where the overlap did not work properly resulting in a really rough finics. I can post that if you want but it looks pretty bad. All of my other attempts at make a tool path have failed when trying to set something up with an overlap small enough to generate a good looking finish cut. (earlier post)
Just sent an email with pictures of jagged tool paths to Lars along with the stl file used. Reducing the tool radius and increasing the margins helped a bit.
Hope to have some more time to work with pyCAM over the weekend.
@bamoore01:
if the picture looks pretty bad, then please don't send it :)
I will wait patiently for a nice one …
regarding the overlap:
sorry for mixing your report up - of course, it was _you_ who noticed this issue before.
Did you try to replace "200" in the code with "100" as described above?
Does it behave as expected?
regarding the zero drop-down value:
In the next release, it will not be possible anymore, to use the invalid value (zero) here.
regarding the memory error, that you reported earlier:
I reproduced this here and noticed, that the generated toolpaths consume quite a bit of memory. The situation will get slightly better with the next release, if you are using python 2.6 or above. On Windows you are probably using python 2.5 due to the comfortable GTK installer described in INSTALL.txt, thus you won't enjoy this improvement :(
other ways to reduce memory consumption:
- remove unused toolpaths (via the third tab in the main window)
- increase the tool radius or reduce the "overlap"
I hope, this helps …
@odemia:
thanks for the helpful screenshots!
I assume that the jagged tool paths are caused by the tool radius.
Maybe you could try to increase the "overlap"? This should fix the inaccuracy.
I've been working on trying to make a useable tool path using the sled sample stl and any of the cutter combinattions. I really haven't had much success. If I us an overlap of any usable value (> 50%) it simply takes too long and usually ends with errors.
I understand what you are saying when you suggest reducing the overlap or increase the tool radius. That may make the program work but it doesn't do anything to make an final product on the cnc machine. So, I'll keep trying.
Looking forward to the next release to try out.
bamoore01: have a look at the linked-to file for a sample of how to use the (old) tk gui with some parameters and timing:
https://sourceforge.net/projects/pycam/files/pycam/0.2.2/samplerun-sled.zip/download
I'm going to have to be a little dense here. What am I supposed to do with the three .gc files in the zip. I can't find any .gc files anyplace to replace or add to in the Python or pycam directories.
preview them in emc2 AXIS or NCSim?
http://www.linuxcnc.org/
http://www.cs.technion.ac.il/~gershon/NCSim/