Trochoidal Pocket & Profile MOPs plugin (HSM)

[dave benson]

Hi qwerty

Hi, is the following a bug or a feature?

--> Neither.

Trying to understand this behaviour / inconsistency. -->

  It’s normal behaviour.

The Troc mops are not ordinary mops (where a 0.5 stepover gives you a 0.5 stepover)
they are fitting routines, (fitting crescent shaped) toolpaths to the available area.
So they fiddle with the stepover to do so, if you look at the side bar info panel you’ll
see there are a lot of extra parameters to twiddle. Just above the stepover parameter
is another parameter called minimum stepover. With these two parameters you can
modify the stepover value. In practice I’ve never had to do this though.

If you have an already existing job where you are using a pocket mop and it’s taking
too long then start a new thread and post the CB file, and I’ll walk you through the
process of converting a pocket mop to a Troc mop.

Dave

[qwerty]

Dave, thanks for explanation. I use troc mops on regular basis and I am aware of minimum stepover / stepover parameters effect. I was just wondering what is going on. After generating toolpaths I will measure actual stepover and adjust parameters to get actual stepover I want...

[dave benson]

I like the Troc mops as they have speed and utility and I use them where
I can, for my purposes pocketing HRS and Al plate and some plastics I set
up some styles to make it quick and most of the time just have to enter
the target depth.
Mostly I use the Troc rougher along with a standard CB profile finisher at full depth.
This ensures that the final dimensions and finish are good and a profile mop at full depth
to clean up the pocket walls is fast.

Dave

[qwerty]

Yes, trocho pocket rough MOP + profile finish MOP is also my best practice...

[dh42]

Hello

On a French forum, a guy falls on a strange behavior with trocho pocket when using roughing clearance ...

The problem is not present for all values of roughing clearance ... and on my tests it appears only on the "8" shape, no problem with the others.

With a value of -0.2, the problem is present but it go away for -0.19 ...

The problem can appears with both negative and positive values.

the problem is also depending of the step over value and tool diameter ...

Changing the start point location, don't solve the problem ; it just appears at another location.

The "8" polyline structure seems OK

++
David

[dave benson]

David
I'm not seeing the issue with CB ver1 32 bit win10.

[dh42]

Strange ... I still have CB 0.98 installed and the problem is not present on it.

After checking, the plugin used on the V1.0 is V2.4.0.0, the one on 0.98 is V2.1.2.0 ..

If I use the V2.1.2.0 on CB V1.0, the bug go away ... so seems it is a problem with V2.4.0.0 ...

.... and ... I tested with the V 2.3.0.0 and the bug is also present.

There was major changes in V2.3.0.0 ... maybe the guilty ...

v2.3.0
* using the triangle.net Voronoi partitioning code - should be much more robust ! this version is CB1.0+ only

Can you have a look on the version number you're using ?

++
David

[dave benson]

This one David, it works well for me.

[Bubba]

Tried this plugin and all is well. The toolpath in '8' looks good. Converted the shapes to an inch and used .187 tool dia to simulate.
Trohomops plugin version 2.4.0.0, CB v: 1.0 x64, Framework v:1.4.30319.42000, on Win 11   

[dh42]

This one David, it works well for me.

Ok, but seems there is a mismatch with versions number ! ... the 2.2.0.0 is older than the 2.1.2.0  (have a look on the GIT)

2.1.2 > April 5, 2017
2.2.0 > March 28, 2017 ... but on your picture it is dated 9 December 2017  (and on the first post, there is no 2.2.0 ... 

https://github.com/jkmnt/matmill/releases

Tried this plugin and all is well. The toolpath in '8' looks good. Converted the shapes to an inch and used .187 tool dia to simulate.

Yes, but any change in the tool diam or the step over may change the behavior, in the mm version, changing the value about 0.01mm and the bug disappears. On your picture, we can see that the step over is not the same as I used, it is larger.

++
David

[Bubba]

Yes, but any change in the tool diam or the step over may change the behavior, in the mm version, changing the value about 0.01mm and the bug disappears. On your picture, we can see that the step over is not the same as I used, it is larger.

++
David
[/quote]

Sorry, I only use inch units. As for the stepover I use .5, its works for me..

[dave benson]

Ok, but seems there is a mismatch with versions number ! ... the 2.2.0.0 is older than the 2.1.2.0  (have a look on the GIT)

2.1.2 > April 5, 2017
2.2.0 > March 28, 2017 ... but on your picture it is dated 9 December 2017  (and on the first post, there is no 2.2.0 ... 

I ran your file on both of them (my PC and laptop) and the tool paths are ok.
I then downloaded the latest version 2.4 and got the same result as you.

Yes I don't know what's going on there, I checked the version on my laptop 32 bit
and when you hover the the .dll, the info say's it's 2.2 but the release date is for 2.3.

I left 2.4 installed and regenerated the Gcode from the tool turret production files
and had no issues.
Something to know is with troch mops, CB's default stepover of 0.4 should be considered
the minimum stepover, as except for the spiral part of the toolpath, the stepover is continuously changing during the course of the
cusp shaped toolpath, from almost zero to a maximum value set by the mop. Setting the stepover much lower than the default will
cause tool wear and local heating by rubbing. Nearly all the production files were 0.4 with some using the feed rate adjuster to 0.65.

Dave

[dh42]

Hello,

Not sure to understand for the step over of 0.4, I retry with V2.4 and if I use the same file with a step over (SO) = 0.4 instead 0.2 and roughing clearance (RG) = -0.2, no problem ... but step over = 0.4 and roughing clearance = -0.4 .. give the same bad toolpaths. In both case min step over is = 0.9 (MSO)

other tests

MSO = 0.90   SO = 0.2   RG = -0.2 > BAD

MSO = 0.89   SO = 0.2   RG = -0.2 > OK

MSO = 0.90   SO = 0.4   RG = -0.4 > BAD

MSO = 0.89   SO = 0.4   RG = -0.4 > BAD

MSO = 0.88   SO = 0.4   RG = -0.4 > OK

MSO = 0.88   SO = 0.4   RG = -0.5 > BAD

MSO = 0.85   SO = 0.4   RG = -0.5 > OK

 

Seems there is a relationship between MSO and RG ...

seems also that only this 8 shape cause problems .. but why ?? ..

++
David

[dave benson]

I don't know, what the issue is with the plugin.

I tried out your posted settings with my production files and they all worked, with 2.3.
I tried your bad settings and 2.3 gives no errors at all, so that would be a fallback.
I did go to github and compare 2.3 and 2.4 versions and the difference was 2.4
enabled the transformation of tool paths which is a facility I've never used so
I'm going to leave 2.3 installed as it worked with all the production files.
 

Not sure to understand for the step over of 0.4, I retry with V2.4 and if I use the same file with a step over (SO) = 0.4 instead 0.2 and roughing clearance (RG) = -0.2, no problem ... but step over = 0.4 and roughing clearance = -0.4 .. give the same bad toolpaths. In both case min step over is = 0.9 (MSO)

David the 0.4 default stepover is the minimum stepover you should set to use the mop as intended.
It's a MMRR mop in other words a roughing mop intended to remove vast acres of real estate quickly, it does this by using cusp shaped
tool paths where the stepover is constantly changing from almost nothing (0 and 180)  to the value you have set in the mop (at 90 deg mid point)
of the tool path, so if you set the stepover any less than 0.4 then the tool will spend more time in the part of the tool path where it's not cutting at
the mop set stepover but at a far smaller value and if this value is smaller than the end mills minimum cut value then the tool will rub on the surface
heating it up and dulling it.
So while you can set the step over value to less than the default it defeats the purpose of the mop.
I ran 2.4 in the debugger and there is code to generate the tool paths and then crop them for things like 'min length' ect, and it seems that in some
cases with various mop settings and geometry that those two extra polyline\toolpaths we see sometimes haven't been removed from the list.

Dave

[Bubba]

So while you can set the step over value to less than the default it defeats the purpose of the mop.
********************************
Totally agree, that's why my default is set at.5