I am trying to install pycam on a Windows XP computer. I've installed all of the files listed on the wiki starting with the .2 version of pycam. All seemed to install fine.
When I run pycam.py through the python GUI, i get the message;
Failed to load GTK bindings for python. Please install the package 'python-gtk2'
I'm guessing that something is not being found?? I don't end up with the same directories that the install doc talks about. I dont have C:\Programs\GtkGLExt\". Any help would be appreciated.
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks. That installed a lot more. Now it runs past the previous problems. Now I end up with the following errors;
Warning (from warnings module):
File "C:\Documents and Settings\bambam\My Documents\Downloads\PYCAM\pycam-0.2\pycam\Gui\Project.py", line 331
self.gui.add_from_file(GTKBUILD_FILE)
GtkWarning: GtkSpinButton: setting an adjustment with non-zero page size is deprecated
Warning (from warnings module):
File "C:\Documents and Settings\bambam\My Documents\Downloads\PYCAM\pycam-0.2\pycam\Gui\Project.py", line 427
obj.set_color(gtk.gdk.Color(red, green, blue))
DeprecationWarning: integer argument expected, got float
Traceback (most recent call last):
File "C:\Documents and Settings\bambam\My Documents\Downloads\PYCAM\pycam-0.2\pycam.py", line 71, in <module>
gui = gui_class()
File "C:\Documents and Settings\bambam\My Documents\Downloads\PYCAM\pycam-0.2\pycam\Gui\Project.py", line 537, in __init__
uimanager.insert_action_group(actiongroup)
TypeError: GtkUIManager.insert_action_group() takes exactly 2 arguments (1 given)
Not sure what to do with this one.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The above problems were caused by broken compatibility of the code with GTK (before v2.16).
The new release v0.2.1 should fix these issues.
Please report back, if everything is working now. Thanks for your report!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ran pycam.py from Python GUI
Running the module results in the “PyCAM” window with all the settings and the “PyCAM Visualization” window being displayed. The Python GUI lists the following errors;
Warning (from warnings module):
File "C:\Documents and Settings\bambam\My Documents\Downloads\PYCAM\pycam-0.2.1\pycam\Gui\Project.py", line 360
self.gui.add_from_file(GTKBUILD_FILE)
GtkWarning: GtkSpinButton: setting an adjustment with non-zero page size is deprecated
Loaded a .stl file that I’ve loaded in FreeMill and Cut3d and get line after line of the following type of error; (File was generated from MoI)
ERROR: skipping invalid triangle: Point5460<0.108643,-0.318249,0> / Point5460<0.108643,-0.318249,0> / Point5455<0.108643,-0.318249,0.15>
ERROR: skipping invalid triangle: Point5460<0.108643,-0.318249,0> / Point5455<0.108643,-0.318249,0.15> / Point5455<0.108643,-0.318249,0.15>
And at the end it says
Warning (from warnings module):
File "C:\Documents and Settings\bambam\My Documents\Downloads\PYCAM\pycam-0.2.1\pycam\Gui\Project.py", line 262
self.area.set_events(gtk.gdk.MOUSE | gtk.gdk.BUTTON_PRESS_MASK)
GtkWarning: gtk_widget_set_events: assertion `!GTK_WIDGET_REALIZED (widget)' failed
File does show up in the visualization window but it is difficult to tell if it is all there. Color seems to be just one color with no differences in the detail. Switched off polygon file and in wire frame it looks like it is all there.
Setup what I thought are reasonable values for tool path and pressed generate. Program goes in to never-never land. Waited about an hour and nothing. Any action in the window results in a program not responding message in the title bar.
Notes:
1. Will only let me enter 3 decimal places for a tool radius. It is not enough. When using an 1/8” cutter, we need to enter a radius of .0625”.
2. In visualization window. When I press one of the view buttons, the entire menu bar disappears and none of the buttons are visible. When I pass the mouse over the area, the buttons come back but the menu bar doesn’t.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just tried one of the sample files in pycam, sled.stl. Same results. It loaded fine with no errors. When I generated the tool path the lower portion of the settings box said generating 1/14 and a progress bar got to about 10% and stopped. That was the end of it. No response from the program after that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) GTK warnings: you can safely ignore them. They are hard to avoid, if the code should run under different versions of GTK.
2) Drill size: I increased the number of digits to allow finer control. Anyway you can enter as many digits as you like - they are there, but only the first three digits are visible.
3) Regarding the problem with the menubar: could you take a screenshot of this and post it here?
4) Path generation hangs: I tried the "sled.stl" sample file. It worked for me with the three pre-configured processing templates ("Rogh", "Semi-finish", "Finish"). Could you try these as well? Please tell me, which settings you configured so I can reproduce your setup here.
Thanks for your feedback!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I tried to do a screen shot for you but it looks like I can only post a link, not a pic. I don't have a place to post one right now, but I'm not sure you will need it from what I found. I was going to post a screen of the locked up program but when I do a screen dump and save it the pycam windows just show up as a white box. Also, if I switch to another program and come back to the pycam windows when they are locked up they don't update, just stay white.
As far as the buttons disappearing. If I click any one of them, they all disappear along with the gray bar they are on. I'm left with the black background color in that area. When the mouse passes over where a button should be, it reappears. Each one when the mouse passes over. The gray menu bar never reappears. Another click on any one of them starts the process all over again.
I tried using the rough, semi-finish,and finish templates on sled.stl. Rough will lock up the program. I gave up after about 30 minutes of waiting for something to happen. Semi-finish will do nothing for about 3 minutes then jump to 50% on the progress bar (with no other sign of anything happening). Then nothing up to 30 minutes (gave up at that point). Finish generates a nice tool path in about 5 seconds and returns control just fine. I tried to generate a tool path with the rough right after the finish completed successfully and the program locked up just like before. All of these results are repeatable. I did each one of them about 3 times with the same results each time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did a few more checks. The finish template uses the drop cutter. If I load either of the other two templates, and change to the drop cutter with either allowable pattern, they will run fine. If I change from the drop cutter to the push cut on the finish template, the program will lock up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Regarding the visibility of the buttons: I assume, that this is a problem related to your installed version of GTK and Windows. I can't reproduce it here, so I would tend to ignore this problem since it is not a real show-stopper.
Regarding the non-working path generation:
I guess, you installed the Open Dynamics Engine (ODE) as it is suggested in the installation instructions?
If so, then please try to disable it (see "Edit -> Preferences") and run the path generation again.
Which version of ODE did you install?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Disabled ODE and everything seems to work. Was able to generate a path with all of the settings I tried. I can't say that I understand what some of the paths are doing but they do generate.
In my Add/Remove Programs window I show that I have "Python 2.5 PyODE01.2.0" installed. I assume that's what you wanted?
It seems that I am at the point of being able to generate a few tool paths so I'm off to try it out. Thanks for your help.
B
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I see the new version out there but I'm not sure what to do with it. There is a zip file and a windows .exe file. Should I unpack the zip file an run it like before or should I run the exe file. Does the exe file just unpack or does it do an install of some sort?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi bamoore01,
thanks for asking :)
The fancy new windows installer (exe) puts the PyCAM files into the directory tree of the choosen python version. Additionally a start menu entry is added containing the "run" link, some doc files and project-related web links.
Use the zip file, if you want a simple directory layout (for playing with the code) and if you can live with running PyCAM manually via the commandline.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I ran the windows installer. ODE worked on this one.
I think I'm past the install for now and into the trying it our. I loaded one of my files generated in MOI 3d. Got the same bunch of errors I mentioned before but it loaded OK and. I generated a tool path with the drop cutter and zigzag over the surface. It worked will except for one little thing.
I sized the surrounding box with no margins. All of the outside edges are at the top surface of my shape. The cut path keeps dropping off the edge of the shape on each pass. Hope that makes sence. I can post more info later when I get a little more time if you need.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This was the first report of a successful installation with the new Windows installer - thanks!
Regarding your issue with the edges:
I am not sure what you mean with "dropping off the edge". Could you clarify this? Or just send me the STL file via mail (devel@sumpfralle.de).
Is the output correct, when you disable ODE or after increasing the upper z limit of the bounding box slightly?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With the bounding box margins set to zero the cutter travels in the negative z direction at the outer edges of the shape where the shape meets the bounding box. At all of the outer edges the z of the shape is at the max z of the shape. The amount of negative z travel varies and is most pronounced in the corners when it goes negative at the edges.
As far as the +z of the bounding box. I have to set the bounding box in the +z direction to greater than the cutter +z travel. If I don't, I get a log of random +z "bounces" of the cutter along the top surface of the shape.
Bruce
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 model. It is quite detailed :)
The toolpath goes up to safety height (configured via the GUI) where the cutter hits the model at maximum z level. This emits a warning to the terminal output (something along: "please increase maximum z").
I agree, that this behaviour is a little bit surprising, since the cutter should not really hit the model, when the upper limit of z is equal to the highest point of the model. As far as I can see, this is caused by slight inaccuracies due to floating number calculations. You will notice that a slight change of the tool radius will "fix" this (usually). Thus it is just a problem of accuracy at a border case (model height == bounding box height).
Practically the upper limit of z represents the height of the raw material block. Usually this should be higher than the target model, I guess.
Do you have any suggestions, how this (intended) behaviour could be communicated better?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure what you are asking for so I'll just start blabing.
Yes, detailed. I probably went a little overboard on the # of facets setting. I understand the floating point accuracy problems. My coding experience is in data analysis and process control. Always a problem.
It's easy to live with the +z excursions on the top of the model when the cutter hits the max z of the bounding box after I set zero margins on the bounding box. I simply raised the z of the bounding box up enough so that it won't hit. Then I never see the +z excursions.
And here is where I lost you. I'm not sure what you are asking for in the last paragraph. If you are asking for me to better explaing the problem or if you are asking for help on how to tell the cutter to stop doing that. I don't speak fluent CNC. Its a second language so you have to be patient with my explanations.
From what I read, you are associating the +z excursions and zero z margin with what I call the -z drop offs at the edge of the model. They may be related in code but operationaly they seem like two different issues. The -z drop offs at the edge of the model still happen when if the bounding box z is set up high enough so that the cutter does not hit the bounding box on top. For this model, not such a big deal. I don't use the edges. For my next project it's a killer. I will be cutting a releif carving into the center of a larger panel.
Done with my rambling for now. By the way. Great project. Thanks for your work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Let me explain the relevant part of the algorithm:
The minx/minyy/maxx/maxy boundaries are automatically expanded by the tool radius. Thus the toolpath starts at "minx - tool_radius" and ends at "maxx + tool_radius". This "expansion" of the work area is maybe arguable, since it makes it harder to explicitely control the toolpath limits. Tell me your opinion about this!
This "expansion" (combined with the spherical cutter shape that you probably selected), leads to a slight -z drop (due to the sphere tool shape) at the edges of the model.
The weird behaviour (z dropping down to the bottom of the model) at the corners is a problem of the ODE library, that I already noticed. Sadly the ODE people did not yet reply to my mail regarding this issue. (http://groups.google.com/group/ode-users/browse_thread/thread/82460d2422e7e3fe)
After disabling "ODE" in the preferences window, these glitches disappeared for me.
Another workaround would be to reduce the x/y boundaries slightly (e.g. minus tool radius), since the ODE bug only occours at the outmost corners or the STL model.
Regarding the last question of my previous post: I just wanted to ask you, if you would see a better way of communicating the reason for the "+z excursion" at zero height margin to the user. But this was obviously not your point, so you can forget about this question …
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I got home this evening and tried making the bounding box smaller than the model to see how that works. It works but I notice something that relates to what you were asking about. I have to make the bounding box about one tool radius smaller than zero margins on the x and y to make the edge drop offs stop.
You mentioned that the bounding box is expanded by one tool radius in each direction on the x and y. I assume that this is to account for the extra space needed by the diameter of the tool. But, and this is difficult to tell because of screen resolution limits, it appears that the center of the tool is traveling to the edge of the bounding box. Wouldn't you still want to limit the center of the tool to the edge of the model? This probably relates back to the real purpose of the bounding box. Is it to contain the cutting tool or the finish cut. I don't know. I'm going to mess with this some more after my laptop charges back up.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your visual assumption is correct: the expanded bounding box limits the _center_ of the drill. Thus this expansion is quite confusing, I guess.
As far as I can tell, the expansion was supposed to allow the cutter to process the outer sides of the model.
I will discuss with Lode (the author of this specific code), whether we should simplify the bounding box (e.g. no expansion) or not.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The new release (v0.2.3) includes a new setting "boundary mode", that allows you to choose between "move inside/along/around limits". I guess, that's what you need?
Additionally the "material allowance" is now supported for the non-ODE mode, as well. Thus ODE is disabled by default to avoid the bug in ODE that caused the droppings at the corner of your model.
Do you have any other wishes? :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am trying to install pycam on a Windows XP computer. I've installed all of the files listed on the wiki starting with the .2 version of pycam. All seemed to install fine.
When I run pycam.py through the python GUI, i get the message;
Failed to load GTK bindings for python. Please install the package 'python-gtk2'
I'm guessing that something is not being found?? I don't end up with the same directories that the install doc talks about. I dont have C:\Programs\GtkGLExt\". Any help would be appreciated.
Thanks
try this one: http://www.bonifazi.eu/appunti/pygtk_windows_installer.exe
Thanks. That installed a lot more. Now it runs past the previous problems. Now I end up with the following errors;
Warning (from warnings module):
File "C:\Documents and Settings\bambam\My Documents\Downloads\PYCAM\pycam-0.2\pycam\Gui\Project.py", line 331
self.gui.add_from_file(GTKBUILD_FILE)
GtkWarning: GtkSpinButton: setting an adjustment with non-zero page size is deprecated
Warning (from warnings module):
File "C:\Documents and Settings\bambam\My Documents\Downloads\PYCAM\pycam-0.2\pycam\Gui\Project.py", line 427
obj.set_color(gtk.gdk.Color(red, green, blue))
DeprecationWarning: integer argument expected, got float
Traceback (most recent call last):
File "C:\Documents and Settings\bambam\My Documents\Downloads\PYCAM\pycam-0.2\pycam.py", line 71, in <module>
gui = gui_class()
File "C:\Documents and Settings\bambam\My Documents\Downloads\PYCAM\pycam-0.2\pycam\Gui\Project.py", line 537, in __init__
uimanager.insert_action_group(actiongroup)
TypeError: GtkUIManager.insert_action_group() takes exactly 2 arguments (1 given)
Not sure what to do with this one.
The above problems were caused by broken compatibility of the code with GTK (before v2.16).
The new release v0.2.1 should fix these issues.
Please report back, if everything is working now. Thanks for your report!
Getting closer.
Ran pycam.py from Python GUI
Running the module results in the “PyCAM” window with all the settings and the “PyCAM Visualization” window being displayed. The Python GUI lists the following errors;
Warning (from warnings module):
File "C:\Documents and Settings\bambam\My Documents\Downloads\PYCAM\pycam-0.2.1\pycam\Gui\Project.py", line 360
self.gui.add_from_file(GTKBUILD_FILE)
GtkWarning: GtkSpinButton: setting an adjustment with non-zero page size is deprecated
Loaded a .stl file that I’ve loaded in FreeMill and Cut3d and get line after line of the following type of error; (File was generated from MoI)
ERROR: skipping invalid triangle: Point5460<0.108643,-0.318249,0> / Point5460<0.108643,-0.318249,0> / Point5455<0.108643,-0.318249,0.15>
ERROR: skipping invalid triangle: Point5460<0.108643,-0.318249,0> / Point5455<0.108643,-0.318249,0.15> / Point5455<0.108643,-0.318249,0.15>
And at the end it says
Warning (from warnings module):
File "C:\Documents and Settings\bambam\My Documents\Downloads\PYCAM\pycam-0.2.1\pycam\Gui\Project.py", line 262
self.area.set_events(gtk.gdk.MOUSE | gtk.gdk.BUTTON_PRESS_MASK)
GtkWarning: gtk_widget_set_events: assertion `!GTK_WIDGET_REALIZED (widget)' failed
File does show up in the visualization window but it is difficult to tell if it is all there. Color seems to be just one color with no differences in the detail. Switched off polygon file and in wire frame it looks like it is all there.
Setup what I thought are reasonable values for tool path and pressed generate. Program goes in to never-never land. Waited about an hour and nothing. Any action in the window results in a program not responding message in the title bar.
Notes:
1. Will only let me enter 3 decimal places for a tool radius. It is not enough. When using an 1/8” cutter, we need to enter a radius of .0625”.
2. In visualization window. When I press one of the view buttons, the entire menu bar disappears and none of the buttons are visible. When I pass the mouse over the area, the buttons come back but the menu bar doesn’t.
I just tried one of the sample files in pycam, sled.stl. Same results. It loaded fine with no errors. When I generated the tool path the lower portion of the settings box said generating 1/14 and a progress bar got to about 10% and stopped. That was the end of it. No response from the program after that.
Hi bamoore01,
1) GTK warnings: you can safely ignore them. They are hard to avoid, if the code should run under different versions of GTK.
2) Drill size: I increased the number of digits to allow finer control. Anyway you can enter as many digits as you like - they are there, but only the first three digits are visible.
3) Regarding the problem with the menubar: could you take a screenshot of this and post it here?
4) Path generation hangs: I tried the "sled.stl" sample file. It worked for me with the three pre-configured processing templates ("Rogh", "Semi-finish", "Finish"). Could you try these as well? Please tell me, which settings you configured so I can reproduce your setup here.
Thanks for your feedback!
I tried to do a screen shot for you but it looks like I can only post a link, not a pic. I don't have a place to post one right now, but I'm not sure you will need it from what I found. I was going to post a screen of the locked up program but when I do a screen dump and save it the pycam windows just show up as a white box. Also, if I switch to another program and come back to the pycam windows when they are locked up they don't update, just stay white.
As far as the buttons disappearing. If I click any one of them, they all disappear along with the gray bar they are on. I'm left with the black background color in that area. When the mouse passes over where a button should be, it reappears. Each one when the mouse passes over. The gray menu bar never reappears. Another click on any one of them starts the process all over again.
I tried using the rough, semi-finish,and finish templates on sled.stl. Rough will lock up the program. I gave up after about 30 minutes of waiting for something to happen. Semi-finish will do nothing for about 3 minutes then jump to 50% on the progress bar (with no other sign of anything happening). Then nothing up to 30 minutes (gave up at that point). Finish generates a nice tool path in about 5 seconds and returns control just fine. I tried to generate a tool path with the rough right after the finish completed successfully and the program locked up just like before. All of these results are repeatable. I did each one of them about 3 times with the same results each time.
I did a few more checks. The finish template uses the drop cutter. If I load either of the other two templates, and change to the drop cutter with either allowable pattern, they will run fine. If I change from the drop cutter to the push cut on the finish template, the program will lock up.
Regarding the visibility of the buttons: I assume, that this is a problem related to your installed version of GTK and Windows. I can't reproduce it here, so I would tend to ignore this problem since it is not a real show-stopper.
Regarding the non-working path generation:
I guess, you installed the Open Dynamics Engine (ODE) as it is suggested in the installation instructions?
If so, then please try to disable it (see "Edit -> Preferences") and run the path generation again.
Which version of ODE did you install?
No problem on the buttons.
Disabled ODE and everything seems to work. Was able to generate a path with all of the settings I tried. I can't say that I understand what some of the paths are doing but they do generate.
In my Add/Remove Programs window I show that I have "Python 2.5 PyODE01.2.0" installed. I assume that's what you wanted?
It seems that I am at the point of being able to generate a few tool paths so I'm off to try it out. Thanks for your help.
B
Hi bamoore01,
I recently fixed the problem with the ODE code that caused the hang.
Please stay tuned for the next release in a couple of days …
I see the new version out there but I'm not sure what to do with it. There is a zip file and a windows .exe file. Should I unpack the zip file an run it like before or should I run the exe file. Does the exe file just unpack or does it do an install of some sort?
Thanks
Hi bamoore01,
thanks for asking :)
The fancy new windows installer (exe) puts the PyCAM files into the directory tree of the choosen python version. Additionally a start menu entry is added containing the "run" link, some doc files and project-related web links.
Use the zip file, if you want a simple directory layout (for playing with the code) and if you can live with running PyCAM manually via the commandline.
I ran the windows installer. ODE worked on this one.
I think I'm past the install for now and into the trying it our. I loaded one of my files generated in MOI 3d. Got the same bunch of errors I mentioned before but it loaded OK and. I generated a tool path with the drop cutter and zigzag over the surface. It worked will except for one little thing.
I sized the surrounding box with no margins. All of the outside edges are at the top surface of my shape. The cut path keeps dropping off the edge of the shape on each pass. Hope that makes sence. I can post more info later when I get a little more time if you need.
This was the first report of a successful installation with the new Windows installer - thanks!
Regarding your issue with the edges:
I am not sure what you mean with "dropping off the edge". Could you clarify this? Or just send me the STL file via mail (devel@sumpfralle.de).
Is the output correct, when you disable ODE or after increasing the upper z limit of the bounding box slightly?
File sent.
With the bounding box margins set to zero the cutter travels in the negative z direction at the outer edges of the shape where the shape meets the bounding box. At all of the outer edges the z of the shape is at the max z of the shape. The amount of negative z travel varies and is most pronounced in the corners when it goes negative at the edges.
As far as the +z of the bounding box. I have to set the bounding box in the +z direction to greater than the cutter +z travel. If I don't, I get a log of random +z "bounces" of the cutter along the top surface of the shape.
Bruce
I took a look at the model. It is quite detailed :)
The toolpath goes up to safety height (configured via the GUI) where the cutter hits the model at maximum z level. This emits a warning to the terminal output (something along: "please increase maximum z").
I agree, that this behaviour is a little bit surprising, since the cutter should not really hit the model, when the upper limit of z is equal to the highest point of the model. As far as I can see, this is caused by slight inaccuracies due to floating number calculations. You will notice that a slight change of the tool radius will "fix" this (usually). Thus it is just a problem of accuracy at a border case (model height == bounding box height).
Practically the upper limit of z represents the height of the raw material block. Usually this should be higher than the target model, I guess.
Do you have any suggestions, how this (intended) behaviour could be communicated better?
I'm not sure what you are asking for so I'll just start blabing.
Yes, detailed. I probably went a little overboard on the # of facets setting. I understand the floating point accuracy problems. My coding experience is in data analysis and process control. Always a problem.
It's easy to live with the +z excursions on the top of the model when the cutter hits the max z of the bounding box after I set zero margins on the bounding box. I simply raised the z of the bounding box up enough so that it won't hit. Then I never see the +z excursions.
And here is where I lost you. I'm not sure what you are asking for in the last paragraph. If you are asking for me to better explaing the problem or if you are asking for help on how to tell the cutter to stop doing that. I don't speak fluent CNC. Its a second language so you have to be patient with my explanations.
From what I read, you are associating the +z excursions and zero z margin with what I call the -z drop offs at the edge of the model. They may be related in code but operationaly they seem like two different issues. The -z drop offs at the edge of the model still happen when if the bounding box z is set up high enough so that the cutter does not hit the bounding box on top. For this model, not such a big deal. I don't use the edges. For my next project it's a killer. I will be cutting a releif carving into the center of a larger panel.
Done with my rambling for now. By the way. Great project. Thanks for your work.
I guess, I understand your problem now.
Let me explain the relevant part of the algorithm:
The minx/minyy/maxx/maxy boundaries are automatically expanded by the tool radius. Thus the toolpath starts at "minx - tool_radius" and ends at "maxx + tool_radius". This "expansion" of the work area is maybe arguable, since it makes it harder to explicitely control the toolpath limits. Tell me your opinion about this!
This "expansion" (combined with the spherical cutter shape that you probably selected), leads to a slight -z drop (due to the sphere tool shape) at the edges of the model.
The weird behaviour (z dropping down to the bottom of the model) at the corners is a problem of the ODE library, that I already noticed. Sadly the ODE people did not yet reply to my mail regarding this issue. (http://groups.google.com/group/ode-users/browse_thread/thread/82460d2422e7e3fe)
After disabling "ODE" in the preferences window, these glitches disappeared for me.
Another workaround would be to reduce the x/y boundaries slightly (e.g. minus tool radius), since the ODE bug only occours at the outmost corners or the STL model.
Regarding the last question of my previous post: I just wanted to ask you, if you would see a better way of communicating the reason for the "+z excursion" at zero height margin to the user. But this was obviously not your point, so you can forget about this question …
I got home this evening and tried making the bounding box smaller than the model to see how that works. It works but I notice something that relates to what you were asking about. I have to make the bounding box about one tool radius smaller than zero margins on the x and y to make the edge drop offs stop.
You mentioned that the bounding box is expanded by one tool radius in each direction on the x and y. I assume that this is to account for the extra space needed by the diameter of the tool. But, and this is difficult to tell because of screen resolution limits, it appears that the center of the tool is traveling to the edge of the bounding box. Wouldn't you still want to limit the center of the tool to the edge of the model? This probably relates back to the real purpose of the bounding box. Is it to contain the cutting tool or the finish cut. I don't know. I'm going to mess with this some more after my laptop charges back up.
Your visual assumption is correct: the expanded bounding box limits the _center_ of the drill. Thus this expansion is quite confusing, I guess.
As far as I can tell, the expansion was supposed to allow the cutter to process the outer sides of the model.
I will discuss with Lode (the author of this specific code), whether we should simplify the bounding box (e.g. no expansion) or not.
The new release (v0.2.3) includes a new setting "boundary mode", that allows you to choose between "move inside/along/around limits". I guess, that's what you need?
Additionally the "material allowance" is now supported for the non-ODE mode, as well. Thus ODE is disabled by default to avoid the bug in ODE that caused the droppings at the corner of your model.
Do you have any other wishes? :)