CNC Crankshaft Machining

[Stuart]

if its ok with you I will mod your code for Mach4 to see if I have missed anything

Stuart

[Vixen]

Hello Kvom

I loaded and machined your latest code. The new comments will certainly make it a lot easier to follow. And the continuous rotation will save a lot of time. Need to remember to reset A to zero before the next run otherwise it unwinds before stating to machine

The machined part was identical to that in my reply #39 ie. a 120 degree half moon sector approx 2.5 mm at the deepest point. The toolpath plot was identical to that in reply#41. The debug shows that each of the 18 passes has a depth increment of approx 0.14 mm, same as before.

I then ran the program again with #4 set to 2 passes. The result was the same half moon as previously. The debug showed z= 13.73 for the first pass, z= 12.5 for the second (final) pass and the z increment as 1.25. So a total depth of cut change of 2.5mm in both the 2 pass and 18 pass tests.

The time for each pass was about 36 seconds.

Isn't this frustrating?   

Could there be some difference between LinuxCNC v2.7 and Pathpilot?

Mike

[Stuart]

Something is fishy with the maths , it’s one step forward two back

Here is what I am finding the shape of the path varies with the number of passes , I mean the add kinks, out of round . The kink moves around the circle depending on the passes

Even had it do a double toe loop at one point

I think (long shot) that it’s rounding errors in the cos and sin look up tables


My plan for Sunday load up mach3 and see if there is any alteration ,as this was done for mach3 it may have been ok on that but not on others


it seems that KVOM and myself take a step forwards but other ones then rear up to bite you in the bum

[Jasonb]

The guy who is going to let me have a copy along with some notes from John S says there were some issues with it.

Also said someone did some articles in EiM a year or two back, I'll see if I can get more details

[kvom]

WRT the depths, the maximum cutter depth is -pcd_radius + pin_radius at 180 degrees.

I ran the program on my machine using a 2" diameter piece of machinable wax, and got what I expected.  Picture attached.

As for as the "half moon shape", it looks to me as if you didn't modify the bar/pcd/pin diameters to match the bar.  Basically it looks like the pin it's machining is larger than the bar.

[Vixen]

Hello Kvom.

There is something very strange here.

I loaded and machined your latest code from reply #59 as soon as it arrived this morning. Hope it has not changed since then.

I have a 30mm diameter bar in the chuck

I used these variables
#<_bar_diameter> =[30]
#<_pcd_diameter> =[15]
#<_pin_diameter> =[10]
#<_passes> = [2]
#<_feedrate>=[500]
#<_mode> = [21] (21=metric, 20= inch

I set the Z zero at top of bar, Y on the bar centre line, and X where I wanted the pin.

I ran the program with it set to 2 passes and also set to 18 passes. The result was the same half moon as previously. The debug showed z= 13.73 for the first pass, z= 12.5 for the second (final) pass and the z increment as 1.25. So a total depth of cut change of 2.5mm in both the 2 pass and 18 pass tests.

I also tried inch mode [20] with inch dimensions. It produced the same half moon as with metric settings.

I am at a loss to understand whats happening. You get a 10 mm dia pin and I get a half moon.

That's it for tonight.

Thanks for your support and patience.

Mike

[kvom]

I set the Z zero at top of bar

Z0 is center of the axis, not top of bar

[Vixen]

Yes, I tried Z0 at the centre of the bar yesterday and again today (just now)

The cutter sweeps the whole face of the bar with a 15mm DOC and follows a strange heart shaped path. I ended up breaking the cutter and ripping up the end of the bar.

I give up, where is the fourjaw.

Thanks for your help and support

Mike

[kvom]

One issue I see is that the clearance provided by extra passes may well be insufficient.  Given the 30/15/10 used in Mike's test, the space between the bottom of the pin and the bar perimeter is 17.5mm.  Even with the max clearance of 2.5, the first pass will cut 15mm deep at full width.  There's certainly opportunity to break an endmill if the feedrate is too large, and one needs an endmill whose flute length is at least 15mm.

One easy solution is to run the program once with a large pin size, and again with a smaller.  But a better approach may be to add a <_max_DOC> parameter that the per-pass removal is calculated from.

[Jasonb]

Kvom are you saying that your blue bit of plastic was cut with one deep pass and then the remainder with a lot of small cuts

The maths should make the cutter 17.5 above the finished pin edge on the first rotation, 16.5mm on the next, then 15mm etc. So the cuts start as a shallow arc and as the cutter gets lower you get a wider arc until the last couple of passes are a full circle. Not sure what you did for clearance and roughing as that was not something in JS's original code just a tool that got 1mm lower per revolution and cut it like a lathe tool would if it were set in te h4-jaw

I won't spend any more time on it until I get a copy from ARC or the guy on ME.

[Stuart]

Mike

That’s the odd path I am seeing bit like a pac man but curvy   
As I am between projects the triple is done and runs on air (reeves version ) lots of altered parts and drawing corrections , plus a lot of cnc work there are a fair number of parts in the valve gear
I will give it some time today cross reference to the work KVOM has done

Jason

When you get any more info please let us know what you have found out and the code will be very much appreciated not only by me but a lot of others


Last comment I was under the misguided opinion that gcode in its raw state was portable like pdf but alas it seems that the machines translators ( in the controllers) handle things in different ways , ok I can understand the likes of hermle and Tornos haveing unique coding systems ,but I would hazard a quest that most of our readers in there own shed/shops have mach3/4 ,Linux cnc inc path pilot on there cnc equipment ( mills and lathes not 3D printers )

Here is hoping that this can be sorted out

Stuart

[Jasonb]

Will do Stuart, Ketan's source may be slowed as he is a man down. Should be mid week before the other source is back from holidays.

Should add that the maths seems to be based on Z zero being middle of the bar.

A bit more food for thought, the chap on ME mentioned that the problem may be with direction of the fourth axis, the Sieg rotary tables that JS used mount to the right of the mill where as a lot of others mount to the left so sounds plausible.

[Stuart]

thanks for the info Jason

that may make sense the direction of rotation should not matter but early fixed in motion controller config , X movement can be looked at but as it does not move after the first movement may not be an issue


I mount the A axis on the left end and its been used for a few projects KX! mill son of yours but retrofitted with ESS and mach4 ( leafboy controller when US )

looking forward to any info if we can sort it out I will remember John when I use it ( well Adam did the grunt work )

Stuart

[Stuart]

Quick update

It’s very very dependant on how you set the WCS when it’s set off the part in z the part looks ok se pics


I am still not convinced about the maths


IMHO it seem to have had the maths tweaked to perform at a very specific size


Back to the WCS

If the z is in the normal position for a axis work rotational centre it will not work in Mach4 I believe that there was a config setting for mach3 to alter this

But place the z off the work by 5 mm it gives a good pattern not run in anger but with some adjustments it may work but it’s very finicky to get it all in tune to give the good tool path
As for the maths I did calculus but that was when I was 17 now 72  some not as good as I was
Stuart

[kvom]

That path looks more like what would be reasonable for this job, and while my code worked it would break the endmill in many cases.  Obviously i misinterpreted the pass generation in the original code.  It shouldn't be too hard to implement now that I see what it should be doing.

The direction of the 4th axis shouldn't matter as the path would be symmetric.