Model Engine Maker
Supporting => Tooling & Machines => Topic started by: Vixen on August 28, 2019, 06:29:41 PM
-
It's always a good idea to use the mill for roughing out the crankshaft as lots of metal has to be removed.
Before he passed away, John Stevens, gave me this copy of a CNC program for "turning" a crank journal completely on a 4 axis CNC mill. I know this probably belongs in Jason's "dark side" topic but I have placed it here as it seems more relevant. And NO, I have not tried it myself.......yet.
The program consists of two mathematical formulae that work together, one for Y and one for Z, then repeat every pass until the required journal diameter is reached.
In operation X once set doesn't move, Y goes in and out at the same time that Z moves up and down so the centre of the cutter is always over the centre of the journal.
Here is John's original code:- parameter #1 specifies the bar stock diameter, #2 specifies the PCD (throw)of the journal and #3 the journal diameter
#1=[30] ;BAR
#2=[15] ;PCD
#3=[10] ;PIN
#4=[18] ;Passes
#5=[0] ;A
#6=[1] ;Pass
G0 G21 G49 G40.1 G17 G64 G80 G50 G90 G98
M6 T1
M03 S4000
G43 Z10.0
G00 A0.0 Y0.0 X5
M98 P003 Q#4
A0.00
M5 M9
M30
%
O003
#5=[0]
G00 Z2.0
G00 A#5
G01 Y[[#2/2]*SIN[#5]] Z[[[#1/2]-[#2/2*COS[#5]+#3/2]]*[#6/#4]*-1]
M98 P004 Q358
#6=[#6+1]
G00 Z2.0
M99
O004
#5=[#5+1]
G01 A#5 Y[[#2/2]*SIN[#5]] Z[[[#1/2]-[#2/2*COS[#5]+#3/2]]*[#6/#4]*-1]
M99
-
That look a bit tricky subroutine calling a subroutine , sounds a bit recursive
I think I read that this was done for a exhibition to show off a cnc mill for arc euro ( who now do not sell cnc mill ) and was written by Johns son
It’s very interesting just goes to show that hand raised gcode it more efficient than that done by cam software
If you done mind I will run it on my demo machine ( computer only no mech bits attached )
Stuart
-
Hi Stuart,
Give it a run and report back. As I said, I have not tried it myself.
Basically the y and z axes moves are coordinated and follow a sine and cosine linear relationship. The stock bar rotates about it's axis and the throw is machined eccentrically. After each pass (rotation) the depth of cut is incremented until the final pin diameter is reached. This is ideal work for a big mill just as Jo did.
However clever, this is still only roughing out, I expect the journals will still need to be finished in the traditional way on the lathe.
Mike
-
I have just been outside to test the John Stephens code on my LinuxCNC setup. It does not run.
LinuxCNC has a problem with the M98 subroutine call. LinuxCNC does not use M98 for subroutines, it does it a different way.
So I declare the John Stephens code to be a bit of a "red herring".
:embarassed: :embarassed: :embarassed:
Mike
-
My machine also runs a version of LinuxCNC, and I modified the code to use the LinuxCNC calling conventions. I was getting a divide by 0 error code on program load, but could single step into O003, but then I got a jump back to the beginning of the main program. After I shut my machine down I added a couple of extra [] pairs that looked like they might be needed. Code is posted below if you want to try it.
Note that it assume metric values, so for an inch crankshaft the values would need to be inchese and G21 changed to G20.
#1=[30] ;BAR
#2=[15] ;PCD
#3=[10] ;PIN
#4=[18] ;Passes
#5=[0] ;A
#6=[1] ;Pass
O004 sub
#5=[#5+1]
G01 A[#5] Y[[#2/2]*SIN[#5]] Z[[[#1/2]-[[#2/2]*COS[#5]+[#3/2]]]*[#6/#4]*-1]
O004 endsub
O003 sub
#5=[0]
G00 Z2.0
G00 A[#5]
G01 Y[[#2/2]*SIN[#5]] Z[[[#1/2]-[[#2/2]*COS[#5]+[#3/2]]]*[#6/#4]*-1]
O104 repeat [358]
O004 call
O104 endrepeat
#6=[#6+1]
G00 Z2.0
O003 endsub
G0 G21 G49 G40 G17 G64 G80 G90 G98
M6 T1
M03 S4000
G43 Z10.0
G00 A0.0 Y0.0 X5
O103 repeat [#4]
O003 call
O103 endrepeat
A0.00
M5 M9
M30
-
Mike, could you post it somewhere else then? I would like to try it on my mach3 machine!
thanks
Mark
-
Could be it runs on the Sieg version of Mack3 rather than Linux
At teh time I doubt John had a suitable CAM package and even if he did probably would not have been able to draw the cam in 3D CAD, I used to draw up stuff for him that he wanted to 3D print.
-
I just ran the program on my mill with mach3 and it seems to run fine , was just air cutting. Let it run for 14 minutes and then estopped it as it was dinner time. Wonder how long it runs for? Or meant to run for?
Cheers
Mark
-
That confirms my thoughts that Johns son wrote it for Mach3
My mach4 him no likey and sicks up on the first line
Any way I have the code saved and will give it a good looking at
Stuart
-
John S posted about it on ME forum, read it and see the pics here (https://www.model-engineer.co.uk/forums/postings.asp?th=57015) also does cams
-
My machine also runs a version of LinuxCNC, and I modified the code to use the LinuxCNC calling conventions. I was getting a divide by 0 error code on program load, but could single step into O003, but then I got a jump back to the beginning of the main program. After I shut my machine down I added a couple of extra [] pairs that looked like they might be needed. Code is posted below if you want to try it.
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.
Is your machine a Tormach? which uses a derived variation of LinuxCNC
Mike :killcomputer:
-
given it a seen to for mach4
it did not like the var refs put in () to comment out the descriptions
removed the Q xxx from the sub call ins now
Caveat emptor I have NOT run it for real with a tool in place
#1=[30] (BAR)
#2=[15] (;PCD)
#3=[10] (;PIN)
#4=[18] (;Passes)
#5=[0] (;A)
#6=[1] (;Pass)
G0 G21 G49 G40.1 G17 G64 G80 G50 G90 G98
M6 T1
M03 S4000
G43 Z10.0
G00 A0.0 Y0.0 X5
M98 P003
A0.00
M5 M9
M30
%
O003
#5=[0]
G00 Z2.0
G00 A#5
G01 Y[[#2/2]*SIN[#5]] Z[[[#1/2]-[#2/2*COS[#5]+#3/2]]*[#6/#4]*-1]
M98 P004
#6=[#6+1]
G00 Z2.0
M99
O004
#5=[#5+1]
G01 A#5 Y[[#2/2]*SIN[#5]] Z[[[#1/2]-[#2/2*COS[#5]+#3/2]]*[#6/#4]*-1]
M99
Stuart
-
I thought the Q358 in subroutine O003 was there to get it to index the A axis through 360 degrees.
Mike
-
It need a lot more testing but with the Q in place it throws sub not found error
Q is a parameter used in pec drilling and others
I think in this case it was tiring to pass the var
All I can say at this time is with the Q in place it won’t run
a past 360 is a config parameter in the control as roll over
Stuart
-
My machine is not a Tormach but is running Tormach's PathPilot version.
I noticed there is no F word, so feed rate must be set elsewhere.
-
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
-
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. :killcomputer: :killcomputer: :killcomputer:
Mike
-
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.
-
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
-
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.
-
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 :cheers:
Stuart :old: Yes I do look like that but hair is longer shoulder length and crutches
-
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
-
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
-
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
-
Dave (Steamer) needs a flat 12 crankshaft :stir: :) :wine1:
-
Not with this software. :LittleDevil: :LittleDevil: 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
-
Hirth couplings? (stretching my memory) :old:
-
We though the Shilling couplings would be easier to achieve than a row of Hirth couplings
Mike
-
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.
-
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.
-
I think the excessive pass tally is what it was done for an exhibition , I remember John saying they slowed it down so the great unwashed could follow the movement and therefore the material would last longer less cost :stir:
at least it’s given a starting point for a more rounded gcode to do the job for what it’s intended
Good work guys
-
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
No way to use a Modulo function for the angular variable in this G code programming ? sort of MOD((alpha+increment);360))
-
I ran it again this afternoon on Mach3 while I was doing something else and it ran for 38 minutes before I estopped it, so maybe it's not quite right??
Mark
-
I'm with Stuart's comments on the speed, Talking with Ketan from ARC he has said before that Adam always wanted to push the mill to run as fast as possible but it was not good for showing punters what was going on and he did not have an endless supply of materials or cutters to break when he pushed things a bit too far!
looking at the Code Mike originally posted it looks like it should go round 18times as #4 the passes is set to 18. That sounds about right for 1mm off per pass as the inner edge of a pin will be 17.5mm from the furthest edge of the web
-
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.
Hello Kvom
I loaded the attached file from reply #28.
It loaded successfully without error messages
It will execute
It produces a toolpath plot in the Y,Z axes. see below
(http://lister-engine.com/coppermine/albums/userpics/10013/P1070502.JPG)
I set the program to run 4 passes. You can see the y,z toolaths are now circular and correct. The four tool paths for the four passes are all 15 mm diameter and do not diminish in diameter as I would expect. You can see the Z axis incrementing the depth of cut but the corresponding tool paths do not decrease in diameter. There does not appear to be a sin, cos function (#51,#52) in the O003 subroutine to recalculate the new toolpath diameter
Here is my 4 axis machine setup. The piece of metal is from a previous iteration of this program.
(http://lister-engine.com/coppermine/albums/userpics/10013/P1070503.JPG)
Regarding depth of cut and number of passes. We need to remember that at the A180 position, 20mm of material needs to be removed. Therefore 20 passes, each removing 1 mm of material is not unreasonable. I would expect the toolpath to show an outer circle of 30 mm less the depth of cut, followed by 19 more concentric circles of deminishing diameter until the final 10 mm diameter is achieved.
Setting the Z axis to zero on the material centre line is an interesting challenge. It's easy to set the Y axis, simple touch off both sides and divide by two. Without a centre line reference block, the Z axis is not so easy, as you can only touch off the top surface. So I touch off the top surface, zero Z, move down by half the material diameter and zero Z again. Not as accurate as a reference block but it will do for these initial experiments.
Hope this feed back will help you refine your LinixCNC version of this interesting program
Regards and Respects
Mike
-
With M99 at the end will it keep running in a loop? As that's what it seems to be doing for me
Mark
-
Regarding depth of cut and number of passes. We need to remember that at the A180 position, 20mm of material needs to be removed. Therefore 20 passes, each removing 1 mm of material is not unreasonable. I would expect the toolpath to show an outer circle of 30 mm less the depth of cut, followed by 19 more concentric circles of deminishing diameter until the final 10 mm diameter is achieved.
Mike with the PCD of 15mm eg 15mm stroke the pin will not be so far over, 17.5mm at the most as per my previous post. John's photo shows the pins are not flush with the edge.
(http://www.stevenson-engineers.co.uk/files/crank2.jpg)
-
With the default params there is 2.5mm difference between the edge of the bar and the pin.
-
Mike, I think your simulation is showing the correct movement.
The idea of the program is that the cutter stays vertical above the ctr of the crank pin during the full 360mm rotation. As the throw of the crank is constant at 15mm PCD the Y axis should not need to move more than 15mm. Likewise the rise and fall over 360deg will also be the same 15mm PCD.
Think of it like an eccentric, you can make it whatever diameter you like but the follower will always only move by twice the offset or the total throw.
All your simulator is showing is the tool following the ctr of the pin and gradually working it's way down, the first pass will just kiss the opposite side of the stock to the pin then you will gradually get a larger arc of engagement until the last 3 passes where you are cutting on the full 360deg.
Attached sketch shows that Z movement is only 15mm (95-80) for both the finished pin and another pass (red circle) of 20mm dia, turn it on it's side and Y will also stay at 15mm movement
EDIT
I've asked Ketan if he has a copy of the program, a video of it in action or can remember how long it took to cut each pin.
-
Hello Jason,
We need to be careful about what we are comparing and commenting on.
I have no doubt the John Stephens program runs perfectly on an Arc Mach3 machine. It's been well demonstrated as working. And that program was the subject of my initial post. Since then, we have discovered it will not work on LinuxCNC because that operating system handles subroutines in a entirely different way. Kvom is working hard to convert the original program for LinuxCNC ( and Pathpilot) use
Therefore please remember, I am only commenting on the much modified LinuxCNC version that Kvom is working on. It has become so modified, it bares little resemblance to the original.
The LinuxCNC defaults were: bar diameter 30, PCD 15 and pin 10 which may be different to Sir Johns defaults, and would account for the different depth to be cut numbers.
I have completed a machine run of Kvoms Reply #28 version, from the beginning through to the end on my LinuxCNC 4 axis machine and this is the result of 18 passes.
(http://lister-engine.com/coppermine/albums/userpics/10013/P1070504.JPG)
You can see that only a small segment (about 120*) was machined away to a depth of about 2.7mm and located either side of A180. The curved segment appears to be centred on the required pin position but is oversize Clearly, the modified program is not behaving as we would wish and still needs some more development work.
My feed back to Kvom is intended to allow more trouble shooting of his LinuxCNC changes and should not be taken out of context as comments on the original John Stephens work.
Mike
-
My comments were based on the same perameters of a 15mm PCD used by both John and Kvom which would not leave 20mm to come off, as confirmed in post #37 by Kvom. If you are looking for an incorrect finished item then it is hard to comment whether the program is giving the right results. And that the path would not be a diminishing circle unless the revised program does not follow the same principal as JS's original.
On your test cut did the first or second of the 18 passes start removing metal or was it just the last few?
-
Hello Jason
Ok it's 17.5mm not 20 mm, but still enough to need multiple passes. I have not seen John's program in operation only a modified one, which gives strange results, so I am guessing how it should work.
All 18 passes appeared to take a small amount off the A180 sector.
Mike
-
That makes it more complicated as it may have been a simple Z height issue as your 2.7mm could be 2.5 and add that to 15mm half (dia of bar) would give the 17.5.
It would seem that the second half of the code is not feeding down far enough, the first part gives the movement about the pin which as you say seems to be correct, will have a look to see if I can spot anything obvious but I probably know the least about G-code but whatever machine it is running on the basic maths and geometry would be the same.
What do the 18 passes look like on your screen, I would expect a stack of circles 18 high like you posted for the 4 passes with 1mm drop between each, last may be 0.5 or first cutting 0.5mm above the bar.
-
Here is a screen-shot showing (in red) the first pass of the 18 passes while running Kvoms Reply #28 version of the LinuxCNC modified program.
(http://lister-engine.com/coppermine/albums/userpics/10013/P1070506.JPG)
On pressing GO the tool does a rapid (G00) plunge to Z 2mm (just clear of the workpiece). It then moves (G01) to Z 15 mm. then the A axis rotates 360* while the Y and Z axes move +/- 7.5mm. When A 360 is achieved, the tool plunges (G00) back down to Z 2mm (just clear of workpiece) and the A axis unwinds to A0, then everything repeats. The Z increments are each approximately 0.14 mm. All measurements are taken from the screen while everything is in motion, so there may be some small errors in the numbers.
Mike
-
I have just done a full cutting run on Mach3 using the original code, each pass took 3 minutes but I ended up with a quarter moon segment not a crank pin, so it appears something is amiss
Mark
-
I was otherwise occupied today, but can look further at it tomorrow. I believe that the sin and cos functions act mod 360 so there will be no need to return the A axis to 0 for each pass. The abbreviated test I ran yesterday gave the correct Y values for 90 and 180 for both a single pass and a double pass where I stopped it after pass 1.
I broke up all the long expressions in order that I can output debug values.
My A axis is just lying on its back next to the mill. If I get what looks like reasonable outputs and can get the strength to lift the rotary onto the mill table, I may attempt a run using some machinable wax rods.
-
I was going to post this last night but now having seen Mikes post it confirms what I found thouugh would be grateful if my maths could be checked.
As it seemed the Z & Y movement was correct producing the 15mm circular movement I looked at John's (bear with me Mike) formula for the Z feed per rev.
Z[[[#1/2]-[#2/2*COS[#5]+#3/2]]*[#6/#4]*-1]
Filling in the numbers we get, I will use 0 deg for A
Z [[[30/2] - [15/2 x cosA + 10/2]] x [1/18] x-1]
Z [[15 - 7.5 x 1 + 5] x 0.055 x -1]
Z 2.5 x 0.055 x -1
z 0.1375
Next time around #6 will have increased to 2 so you get 2/18 which gives the total downfeed for Z as 0.275 etc
So by the time we have dropped 18 times the total downfeed will only be -2.475
Both these figures tie in with what Mike has got 0.1375 is his approx 0.14mm and the total cut is similar too.
Looks like there may have been an error in Johns early code and that kvom has carried this into his.
Need to work out a cure now but suspect instead of x[#4/#6] it needs to be + [#4-#6] this would give us an additional height above the pin of +17 on the first pass (the half depth cut I mentioned earlier) then +16 the next time round as 18-2 = 16 and so on.
-
Good work there Jason
I have to concur with you this code snippet that was originally posted may be the preamble to the working code that was used to demo the sieg mill at a exhibition
It was the use of ; instead of () for comments that made me think it was work in progress
I will have another look during the week
Stuart
-
Ketan came back to me and said he did not know if they have it, Ian is not in until Tuesday and he should know though they may have given away the computer that had it on! Adam won't be able to help at the moment.
-
Jason,
Smart bit of detective work, well done.
I think I am beginning to understand how it works :facepalm: but who knows. So please bear with me.
#4 specifies the number of passes
#6 is the pass count and is incremented after every pass (see #6=[#6+1] in subroutine O003 in JS's program)
Maybe the depth of cut should be 1/18 ( of something?) subtracted from the 7.5mm on the first pass; 2/18 on the second, 3/18 on the third and to on until 18/18 is subtracted on the final pass
Should the *[#6/#4] in JS's equation actually be -[#6/#4]??? Again i'm guessing, it's a long time since my school maths lessons.
Mike
-
Mike see the last line in my post above to see what I think the #6/#4 should be.
It almost wants a calculation to work out the 17.5mm and then to add that onto the angular height and then subtract the increasing #6 from that. or subtract 1/18, 2/18, etc.
I have asked on the ME forum and a member there says he has the code for Mack3 and will send it to me when he gets back from holiday.
-
said it would be next week but I think I have it sorted the back plot in nc plotter look ok
in mach4 M98 P100 Q.... L.... is the format
Q is jump to index no. in the sub and L is the number the sub is run ( note can be a integer or a #4 var call )
I now get nice diminishing circular tool path centred on the crank pin
note there is no F xxxx in the code that's up to you but bear in mind it will be the coordinated speed from the slowest of the A XYZ hope that makes sense
code below
#1=[30] (BAR)
#2=[15] (;PCD)
#3=[10] (;PIN)
#4=[18] (;Passes)
#5=[0] (;A)
#6=[1] (;Pass)
G0 G21 G49 G40.1 G17 G64 G80 G50 G90 G98
M6 T1
M03 S4000
G43 Z10.0
G00 A0.0 Y0.0 X5
M98 P003 L#4 ( pass nuber of passes from var 4)
A0.00
M5 M9
M30
%
O003
#5=[0]
G00 Z2.0
G00 A#5
G01 Y[[#2/2]*SIN[#5]] Z[[[#1/2]-[#2/2*COS[#5]+#3/2]]*[#6/#4]*-1]
M98 P004 L358 (number of repeats of subprogram)
#6=[#6+1]
G00 Z2.0
M99
O004
#5=[#5+1]
G01 A#5 Y[[#2/2]*SIN[#5]] Z[[[#1/2]-[#2/2*COS[#5]+#3/2]]*[#6/#4]*-1]
M99
Stuart
-
Good work Stuart. Now we have a Mach 4 version to compare.
Have you made any other changes other than the Mach4 subroutine calls?
Have you machined this program yet? Did it create a round crank pin or a just remove a half moon.?
Any chance you can post a photo of the back plot showing the diminishing circular tool paths so we can compare them with the ones I posted using the LinuxCNC version
Cheers
MIke
-
Mike only the brackets around the var description and the two comments fro the m98 calls I though I had better comment them up
-
Stuart,
Thanks for that. Your backplot with the concentric circles (based on the JR program) looks completely different to the vertical column of Audi rings I posted from the LinuxCNC version.
Is there any way you can rotate the backplot so that the Z and Y axis are flat to the screen, and then to take another photo?
Thanks again
Mike
-
Best I can do but there may still be more work just noticed the over run
-
Mmmmm yes :thinking: :thinking:
Thanks Stuart and Snoopy
Mike
-
As i said earlier the tool should not move in diminishing circles just the vertical row like mike showed but spaced by the cut eg 1mm, simple geometry and eccentric movement as it is just a diminishing distance above a point moving 15mm in Y and Z.
-
Jason what you are seeing is because I have show rotary about x in the control config under tool path
The rings are the rotary table rotating not the tool
Stuart
-
I spent the morning messing with this, and in the end converted the #nn codes to named variables. Plots look ok (should be descending circles) since each is displaced by the amount of roughing clearance for that pass. I think the named variables will make the logic a lot clearer. g-code attached.
The angle is not reset to 0 for each pass, but continues to increment. The sin and cos functions work mod(360), so no rewind of rotary is needed.
There is no X motion. Operator is responsible to position X appropriately. Each pin starts at the top of the bar at A=0, and the initial Z move is to +bar_radius before moving to Y0.
-
if its ok with you I will mod your code for Mach4 to see if I have missed anything
Stuart
-
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? :wallbang:
Could there be some difference between LinuxCNC v2.7 and Pathpilot?
Mike
-
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
-
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
-
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.
-
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
-
I set the Z zero at top of bar
Z0 is center of the axis, not top of bar
-
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
-
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.
-
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.
-
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
-
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.
-
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
-
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 :old: some not as good as I was
Stuart
-
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.
-
Hello Kvom
Did you notice the original JS code for O003 and O004 (when simplified ) was as follows
Z + [ bar rad minus pcd rad plus pin rad * passes/count}
whereas your code appear so have
Z + [ bar rad minus pcd rad minus pin rad * passes/count}
With the plus, the overall depth of cut becomes 12.5 mm not 2.5mm
Hope this helps
Mike
-
Stuarts latest screen shots would also work assuming the wide gap between the circles on the left is 1mm and diminishes to about 0.06mm on the right.
This would give a full 1mm depth cut on the wide side of the crank reducing to a very shallow depth on the side nearest the pin. What we don't know is when John said "1mm per pass" is whether that was a maximum or a fixed depth. Fixed depth would be better as you would almost be rubbing the corner off as the DOC got to the shallowest part.
-
I reworked the linux program so that now rather than specifying the number of passes you specify the maximum depth of cut, and the number of passes is calculated. This max DOC is attained only at the 180 degree point, and is pro-rated around the bar based on the position of the top of the pin. The attached photo of the PP screen shows the paths for each of the passes. These are not circular. I believe the program is quite easy to read and understand at this point.
Note that since all the A/Y/Z moves are coordinated, the actual cutting feedrate is quite small, so an appropriate doc can be larger than you might think. My A axis appears to turn at 300 degrees/minute. At this rate the SFM of a 2" diameter bar is ~5.2 ipm.
-
Nice work there KVOM
It took me a while visualise the paths required
Looks like your version is a better way to use for different jobs
The JS one seems to be critical in the setup
May I try to port your version over to a Mach/fanuc version
Stuart
-
You have been busy Kvom.
I downloaded your latest version into LinuxCNC ver 2.7
The toolpath plot showed an elliptical tool path opening to a full circle with each successive pass. We have seen a similar elliptical plot way back in your Reply #22 post. I will go back and revisit this version later.
(http://lister-engine.com/coppermine/albums/userpics/10013/P1070526.JPG)
I entered the standard 30 bar 15 pcd 10 pin parameters (converted to inches) and a 1 mm (0.04" pass depth.
This is a photo of what was produced. The pin, coloured black, is crescent shaped, the "machined" toolpath was a double loop. The narrow dimension of the crescent is 10mm
(http://lister-engine.com/coppermine/albums/userpics/10013/P1070523.JPG)
The most significant thing I noticed was the Y axis was moving to the opposite end rather than staying vertically above the pin. The Y axis is moving in ANTI PHASE to the pin
Can we assume a numerical Y axis sign change would sort this
Alternatively reversing the direction of rotation of the 4 th axis would sort it
Or by turning the 4th axis around through 180 degrees. I think Jason mentioned something about JS having his rotary on the right.
I will play around a bit more
Regards
Mike
-
BINGO It works.
What a difference it makes, just reversing the effective direction of rotation of the A axis.
I did this, by turning the 4 th axis head through 180 degrees on the table. The Y axis movement is now IN PHASE with the movement of the pin and always remains vertically above it. The "machined" tool path now produces a perfect circular pin of 10 mm diameter.
Compare this circular pin with the one in the previous post. The program is the same, only the direction of rotation of the A axis has changed.
(http://lister-engine.com/coppermine/albums/userpics/10013/P1070527.JPG)
Kvom, is it possible to offer the option of incrementing or decrementing the rotation count to offer two directions of rotation to match the users set-up?
This has been a long hard struggle by Kvom. Well done that man. It is not easy to visualise all three axes moving together particularly movements relative to a rotating axis.
Regards and Respect
Mike :cheers:
-
That looks like it. :cartwheel:
Mike, bit hard to tell from your tool marks but did the cutter start buy cutting a full circle be it of varying DOC or did it do increasing length arcs until the last few rotations here the tool is within the 2.5mm of the narrow side?
Now if only you would stop playing with those radials and make something that needs a long crankshaft ;)
-
Now if only you would stop playing with those radials and make something that needs a long crankshaft ;)
Oh! do you mean something like a Mercedes Benz W165 crankshaft or a Porsche 917 crankshaft? Why did you think I was paying so much attention :lolb:
In answer to your question. The narrow side has 2.5 mm removed and the wide side of the bar has 17.5 mm removed. The depth of cut is 2.5 / 18 at the narrow side and 17.5 /18 at the far side. The "machined" tool path (that's a new definition for the dictionary) describes a nearly circular orbit removing more material from the 17.5 side.
We have very little control of the actual feed rate, it is effectively controlled by the cycle time of the subroutine loops. The amount of material removed is much greater for the early cuts and reduces as the final small pin diameter is reached. A final spring cut at the final diameter would be nice.
The cutter is effectively 'conventional' milling on the right hand side and would be 'climb' milling on the opposite side of a slot. I had used up all my long series, end cutting mills during these experiments. I only had this one last, worn out, cutter left to play with, thence the poor surface finish.
Happy happy
Mike
-
The Y direction issue seems obvious once you see it. The easiest "fix" is just to reverse the sign of Y in line 30.
Change Y[#<Y>] to Y-[#<Y>]
-
The Y direction issue seems obvious once you see it. The easiest "fix" is just to reverse the sign of Y in line 30.
Hello Kvom
It is only obvious when you see it being machined, who would have guessed, if you only look at the YZ plot on the screen.
Two small points. A additional spring pass at the final pin diameter would be nice as would lifting the cutter clear at the end.
That is a brilliant piece of work from you. I admire your persistence. It is doubly difficult and frustrating when you cannot visualise the final "machined " tool path
Mike :praise2: :praise2:
-
The Y direction issue seems obvious once you see it. The easiest "fix" is just to reverse the sign of Y in line 30.
Hello again Kvom. Which is line 30? Is it the G01 F A Y Z line at the bottom of O004 sub?
Mike
-
Yes. Change Y[#<Y>] to Y-[#<Y>]
A parameter at the top (1 or -1) could work, but it would need to be documented in comments based on whether the top of the rotab move away or towards you.
Lifting the tool at the end would be a final line in the main: G0 Y[#<_bar_radius>]
Spring pass would just be:
#<_passcounter> = #<_passes>
O003 call
After the O103 endrepeat line
-
Yes. Change Y[#<Y>] to Y-[#<Y>]
A parameter at the top (1 or -1) could work, but it would need to be documented in comments based on whether the top of the rotab move away or towards you.
Thanks Kvom. If you edit your reply #77 with the above information, that should be enough.
Mike
-
Me again Kvom,
I think that if you were to reinstate all the sin and cos functions back into the two subroutines; then you can use variable #5 <angle> as the pin position angle ie. 90 degrees, 180 degrees, 270 degrees or whatever.
That said, it may be safer to set and re-zero the pin angle and the x axis offset manually, at the start of machining each throw.
Mike
-
Yes. Change Y[#<Y>] to Y-[#<Y>]
Na, Changing Y[#<Y>] to Y-[#<Y>] did not do it. The A axis still turns the same way with either.
Just found the new edits in Reply 86. Thanks
Mike
-
Looking at it I think you'd end up as Y--nn. Try
Y[#<Y> * -1.0]
-
. Try Y[#<Y> * -1.0]
Bingo, that fixed it, The Y motion is now in phase with the pins motion. Kvom you are a miracle worker. :praise2: :praise2:
Actually, Changing Y[#<Y>] to Y-[#<Y>] may have been working. I was expecting the A axis to change direction even though I had just edited the Y axis command :shrug:
of the two I think Y[#<Y> * -1.0] is the better, as it is more obvious to see which mode you are in.
Cheers
Mike
-
I managed to remove my 4th axis from the table without injury and replace it with the vise, also without injury. ;D
Since I needed to retram the vise, I decided afterwards to check the tram on the mills. CNC spindle was still within .001" over 6", but the Bridgeport had gotten off by a bit more. Adjusted back to flat; Next time I run the face mill I'll should see nicer finish.
-
Well double Bingo!! Just went and ran the original first listed by Vixen program on my Mach3 machine. Previously it cut a half moon shape but this time I reversed the a axis direction in the motor setup config as there wasn't room to switch the rotary table to the right hand side as the stepper motor fouled the column and now we have a perfect crank pin to size !! My machine I set to rollover to 0 and it doesn't rewind , just a z retract and then z to the new cut depth! :whoohoo:
Mark
-
:ThumbsUp:
Nice work there fellows, had a hard time understanding most :insane: of it, but am pretty impressed with how you all cooperated, de-bugged it, & got results.
Another reason why this site is such a gem.
Fine work!
John
-
Just went and ran the original first listed by Vixen program on my Mach3 machine. Previously it cut a half moon shape but this time I reversed the a axis direction in the motor setup config as there wasn't room to switch the rotary table to the right hand side as the stepper motor fouled the column and now we have a perfect crank pin to size !! My machine I set to rollover to 0 and it doesn't rewind , just a z retract and then z to the new cut depth!
Mark
Post video or it never happened!!! :lolb:
-
I wish I knew how Steve! Will see if I can post a picture of the end result, even that will challenge me!!