Facebook pixel
to DeskProto home page
looking glass icon
to DeskProto Facebook page
to DeskProto Youtube page
to DeskProto Instagram page

Forum menu:

DeskProto user forum

Forum: communicate with other users

Forum home page main
router drum brushing stock
You’re logged in as:guest
Online users:0
Online guests:68

page 1 of 5

16:02 CEST

I am performing a finishing pass using a rather short bit.
I think with your previous help I have eliminated collet strikes, but now I am seeing that the router drum is brushing/intersecting the figure.
I have placed a video of this at https://youtu.be/kcTEA6xLYdM so you can see what is happening.
Any advice on how to configure the operation to avoid this would be appreciated.

Thanks as always for your help.


16:23 CEST
actual strike here. this is a real problem...

09:27 CEST
Hi Malcolm,

Thanks for the clear video, as the "router drum" that you wrote about was not immediately clear to me. Basically the problem is that the spindle motor (or any other part of the Z-axis) collides with the part.

The only real solution for this problem is to use a longer cutter, as for all other solutions the part will not be completely machined.

Two other ideas:
- make the Area to be machined (in V6 the Operation sub-segment) smaller by entering a higher value for the minimum Z
- in the machine definition enter the size of the spindle motor diameter as collet size (this will make toolpath calculation much slower).

However, as said these are not real solutions as much of the part will be left un-machined.


14:13 CEST
Hi Lex, thanks for the quick reply.

the cutter I used for the roughing pass is longer and it was brushing the part as well.

it seems, and I am thinking out loud here:
- if I use a much longer cutter then I lose z-capacity as I am at the top of the z-axis when starting the cut: I am very close to the limit, and a longer cutter will reduce my available travel.
- if I make the motor diameter size the collet size then I lose the height of the collet for vertical faces. in this item the collet was in fact very close to the vertical face and the effect would be to have a significant area that could not be machined, even with the longer tool.

Also, the issue with using a longer cutter is that the geometry is still not quaranteed not to strike unless the cutter is as long as the z-max, which is not practical on large pieces.

is it possible to make the collet check more complex by adding a collet height and then spindle motor width above it, so the keep out area is more properly defined?
I know this could not happen instantly, but I would like to make a feature request for this if possible...

here is a link to some photos of the work piece, so you can see how it ended up: https://twitter.com/amstanley/status/1050707477724061696

17:15 CEST
Hi Malcolm

Thanks for the suggestion.
I will put it on our list of improvement ideas. Though to be honest I have some doubt as that would make the current toolpath calculation very slow -- it will be needed to improve the algorithm to make this any useful.

Nice photos on twitter !
We are now working on a wooden Abraham Lincoln, for a next tutorial video.

In this case I think that setting a minimum Z-value for the area to be machined in the finishing operation will be a good solution: the result will be almost the same as when protecting against spindle motor collisions.
The top of the head then not will be detailed, which later can be done by hand.


23:46 CEST
In this case, maybe, but then what about the next model?
it seems easy to set the correct z-limit after the fact but hard to guess in advance what setting will maximize the machined area while avoiding collisions if you are carving a wide variety of 'found' models you have never seen before, and for which there is no adequate simulation which will provide warning a problem will occur.

I think I prefer the idea of setting the collett width to the motor width, as at least that way I am certain no collisions will occur; the required additional processing time is a workflow issue; getting this collision challenge solved seems very much worth having to plan ahead a little more when preparing the cut.

if you can add the more complex boundary checking, perhaps when adding the requested feature, it could be enabled with a checkbox so it does not impact users for whom the feature is not relevant... that way the speed decrease would only apply to those of use who are working in tight spaces with very complex shapes...

15:56 CEST
Hi Malcolm,

You are of course right: adding such option will not impact users that do not check it.
You also already found a workaround: enter the motor diameter as collet size. Though that check will not be accurate.

The issue is on our list of ideas, and it won't b every difficult to implement, so I hope that it will make in in V7.1


09:34 CEST
I really want to appreciate both of you for helping me out in this :)

23:34 CET
Hi Lex...

so when you say 'Though that check will not be accurate.' may I ask what you mean?

I ran another carve today. Different carving target, source is https://www.thingiverse.com/thing:1568115 .

I have placed the project files and some pictures of the outcome at https://1drv.ms/f/s!Ajqd8czMvuVgidkOd5ag1byeboi3Pw in case you wish to see them.

As discussed above I did set the collet width to be the width of the router motor, and saw what appeared to be strike avoidance behaviour as it was cutting.

Unfortunately the carve experienced a strike somewhere close to line 75524 of the g-code file, You will see the damage in the close up photo I took immediately after. It appeared that the cutter was trying to reach an area under an overhang maybe? The cutter was taking a path around the A axis, with rotation at that moment toward the front of the table (from the top), and teh cutter was forced into the previously carved material, burning the workpiece from friction and losing steps. It seemed significant to me that the collision apparently occurred between the collet and the cutting surface of the bit. I don't know if that is a useful clue or not.

It made me sad as I recently upgraded to your latest version and the meander on the spiral around the A-axis seems much more efficient than before, which made me very happy to watch for a very long period of time.

Anyway, seems we still have a collision challenge, and I wonder if you have any other suggestion?
- why do you think the wider area collet check will not be accurate?
- would turning on vertical surface checking help?

Please let me know if any other information would be helpful.

Thanks as always for your help.


15:56 CET

Hi Malcolm,

First my remark about the check not being accurate. What I meant to say was that when you use the collet check to check for the motor diameter, then DeskProto will no longer be able to check for collisions with the collet. The check with the motor will be accurate though. I should have phrased that a bit more clearly.

The vertical surface check will not help to solve this issue. it is meant to make vertical surfaces really vertical instead of slightly sloped.

I am not sure what is happening here. My guess is that when machining the fourth layer the cutter needs to machine at the full 20 mm layer thickness: the toolpath marked yellow in the above screenshot.
Though of course I have not seen what is happening: did the cutter at the error location "drill" deeper than 20 mm? You mention that the collision occurred 'between the collet and the cutting surface of the bit' - do you mean that the shaft of the cutter tried to remove wood - which suggests more than 20 mm... ?


page 1 of 5