CNC Crankshaft Machining

[Jasonb]

With the tool effectively stationary above the ctr of the crank pin would there need to be any feed rate, the rotation of the 4th axis sets how fast the work moves against the tool

[Vixen]

With the tool effectively stationary above the ctr of the crank pin would there need to be any feed rate, the rotation of the 4th axis sets how fast the work moves against the tool

That's correct; there is no F word to control feed rate. The virtual feed rate is controlled only by the reaction time of the 4 th axis.

Jo must be laughing at us now. She completed her manual roughing in a fraction of the time it has taken  (or will take us) to sort out the G-code.

So far we have discovered that John's code will run on Mach 3 but not on Mach 4. We also know that KVOM's modified code will run on his Tormach Pathpilot but not on the native LinuxCNC Ver 2.7.

But thats CNC all over. 

Mike

[Jasonb]

I also wonder how fast you could cut, as the middle of the cutter is over the pin it will be a bit like using the end of a ball nose cutter where the ctr is turning at zero speed so does not do a lot of cutting. Could almost do with roughing cuts that offset the cutter a few mm to one side before coming back on ctr for the finish cut but then as per Andrew's post in my link the cutter is concave on the end not flat so may not produce parallel pins.

[Vixen]

You are correct, the cutter will be plunge cutting on the end face all the time, with all the problems of zero cutting speed on the tool centre line as well as a concave face etc.

The software makes for a brilliant demonstration at an exhibition but a lot more work would be required to grind/ turn the journal to a finished condition in the lathe, using traditional model engineering methods. I see this software only as an alternative roughing process or perhaps only as a mechanical/CNC curiosity.

Another way would be to mount a horizontal grinding spindle on the z axis in place of the vertical milling spindle. But when and where do you stop, we only do a crankshaft once every blue moon

Mike

[kvom]

G1 requires a feedrate.  I suspect John's machine could set that in the control.

The move to X5 seems hinky too, unless John just set the center of each as X5.  It appears also that the machining of each must start at A0, so the initial param set is unneeded.

Since X doesn't move during the machining, either the desired width equals the tool diameter or else one would run the program with different values of X to make it wider.

The code is O003 can be simplified as at the start of each pass A=0 so Y will be 0, and the cos(0)=1 in the Z calc.

[Stuart]

Re F command

When John delivered my mill ( which has been converted to ESS and mach4 by me ) he set the F100 in the init string in the mach3 set up page note mm machine

So could that be the reason for the lack of a feed setting in the program

The A would need a feed

He gave me a simple gcode block for a 90deg helix on a shaft something like g1 x5 a90 f50 , this gives a coordinated XA move both finishing at the same time as was John’s slant on things he gave you the idea for you to flesh out for your own use

this thread shown how compact gcode can be when the CAM is the human brain not a silicon one , that being said 99.9% of the time I use fusion 360 well it is free 

Stuart    Yes I do look like that but hair is longer shoulder length and crutches

[Vixen]

I attempted to run your LinuxCNC modified code on my LinuxCNC ver 2.7 machine. I am also getting a divide by 0 error message when it attempts to enter the O003 subroutine. I don't understand enough to mess with " adding a couple of extra [] pairs that looked like they might be needed."     Can you advise please.

Mike   

Hi Kvom
The divide by 0 error message appears to be due to the second part of this program line, from Z[[[ to the end.

G01 Y[[#2/2]*SIN[#5]] Z[[[#1/2]-[[#2/2]*COS[#5]+[#3/2]]]*[#6/#4]*-1]

Could you please check that what I have is the same as the code which actually works on your machine. I fear I have too many or too few [] or they are in the wrong place.

I also find I need an F number at the end of that GO1 command line.

Many thanks

Mike

[kvom]

After a few experiments plus reading the LinuxCNC manual, I got the code to both load and execute without any error messages.  That's not to say it would mill a crankshaft correctly.  The main issue is that in LinuxCNC, variables #1-#30 are local to subroutines, so any values for these variables set outside would be 0 within the sub.  The G1 moves do require a feedrate.

One issue with my machine is that once it's at A359, a return to A0 requires that the axis reverse.  This will slow each pass down a good deal; a machine that has a setting or g-code to advance to A0 by moving forward would be faster.

Here's my code:

#1=[30] (;BAR)
#2=[15] (;PCD)
#3=[10] (;PIN)
#4=[18] (;Passes)
#5=[0] (;A)
#60=[1] (;Pass)
#80=[1/#4]
#31=[#1/2]
#32=[#2/2]
#33=[#3/2]

O004 sub
#50=[#50 + 1]
#51=[[#32] * SIN[#50]]
#52=[[#32] * COS[#50]]
G01 F500 A[#50] Y[#51] Z[[[#31]-[#52]+[#33]]]*[#70]]
O004 endsub

O003 sub
#50=[0]
#70=[[[#60]*[#80]]*-1]
G00 Z2.0
G00 A[0]
G01 F500 Y0 Z[[[#31]-[#32]+[#33]]*[#70]]
O104 repeat [358]
O004 call
O104 endrepeat
#60=[#60+1]
G00 Z2.0
O003 endsub

G0 G21 G49 G40 G17 G64 G80 G90 G98
M6 T1
(M03 S4000)
G00 Z10.0
G00 A0.0 Y0.0 X5
O103 repeat [#4]
O003 call
O103 endrepeat
A0.00
M5 M9
M30

[Vixen]

After a few experiments plus reading the LinuxCNC manual, I got the code to both load and execute without any error messages.  That's not to say it would mill a crankshaft correctly.  The main issue is that in LinuxCNC, variables #1-#30 are local to subroutines, so any values for these variables set outside would be 0 within the sub.  The G1 moves do require a feedrate.

One issue with my machine is that once it's at A359, a return to A0 requires that the axis reverse.  This will slow each pass down a good deal; a machine that has a setting or g-code to advance to A0 by moving forward would be faster.

Thanks for the update Kvom. Your revised code will now load and execute and displays some sort of toolpath on the simulation screen.

I can see you have done a lot of work sorting out the subroutine calls; like adding additional variables to cater for the different way LinuxCNC handles subroutines and then to amend the code to point to these new variables.

Most machines are too dumb to know the A360 and A0 are the same place, so will unwind back to A0. Need a way to reset A360 to A0 without actually moving

I stuck some 30 diameter alloy bar in the 4 axis chuck. Zeroed the Y and Z axes at TDC of the bar and pressed go. Not a success. The Y axis went back and fore as you would expect but the Z axis did not move up and down in anti phase. Most of the movement was towards the centre. As a result, the pin was not being turned eccentrically but a somewhat concentrically. My initial guess is a sign change is required in the Z axis, but here may be more.

I will experiment a bit more after I  study the new code and attempt to understand the tool paths.

Thanks for your help and support. I don't actually need to turn a crankshaft but this bit of code has got me excited and has become a bit of a quest.

Cheers

Mike

[Roger B]

Dave (Steamer) needs a flat 12 crankshaft     

[Vixen]

Not with this software.      Dave may need to do it the traditional way.

Actually, I believe it will be a Schilling style, built-up crankshaft, not a one piece job

Mike

[Roger B]

Hirth couplings? (stretching my memory) 

[Vixen]

We though the Shilling couplings would be easier to achieve than a row of Hirth couplings

Mike

[kvom]

See attached file

I believe I have shaken the bugs out of the LinuxCNC version.  When I run it with debug statements the Z values at A=0,90,and 180 look correct.

The program assumes Z0 is the centerline of the bar and that Y0 is the top of the bar at A0.  I don't know why there is a move in X, so I'd just remove it, and position the X axis along the bar where a pin will be located.  No other X moves are generated.

The starting value of Z should be the radius of the bar.  The first Z move will thus be a plunge to the value needed for A0, and the rest of the Z moves are coordinated with A and Y axes.

Program logic is fairly easy to follow if you you visualize a circle representing the Pin turning around the A axis with a constant radius equal to the PCD.  Then the position of the top of the PIN is the position of its center with its Z value incremented by its radius.

Using the example values, the top of the pin at A0 is the sum of the pin and PCD radii or 12.5.  At A180 it's the PCD radius minus the pin radius or 2.5.  At A90 and A270 its the pin radius or 5.

The program allows specification of passes; each pass increases the DOC.  In the example the excess material at A0 is 2.5mm, so 18 passes means removal of .139mm, probably an excessive pass count.

[Jasonb]

I don't know why there is a move in X, so I'd just remove it,

If you setup with X=0 as the end of the blank you can just change the X value for each crankpin to how far the middle of the pin is from the end of the blank.