Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: DaOne on September 24, 2010, 02:28:05 AM
-
Does mach 3 (lathe) have the ability to run a constant surface feet per minute? Basically as the tool moves closer to the center of the x axis the spindle speed increases to compensate for the diameter to keep an even sfm? My Haas has this ability. Wondering if I can give my retrofit the same ability.
-
Yes. G96 turns it on, G48S**** sets the max permissible speed whilst in CSS and G97 turns it off.
Hood
-
Thanks hood. So I just need to make sure its in my G code. Nothing else in mach setup that I need to turn on? You dont happen to know when I can locate a post for mastercam X4 turn? Thats what I use at work so would love to use that to program my retrofit too.
-
Yes G96 in the code and CSS should be active, G97 when you wish to turn it off and G48 with the max spindle speed you want, for example if you are facing a large dia you will likely not want it to spin too fast for safety reasons.
Regards the post processor, afraid I dont know.
Hood
-
hi
it is the first experiences with the lathe
I have also done me this test.
when I write G96 it tells me error,
it tells me that he wants G96S....
is it possible that mistake?
where G I can find the functions for the lathe?
thanks
regards
-
Here are the ingredients for spindle control...
G48 "Sets the max RPM the spindle will turn (so you don't over speed your work /chuck)
G96 "Sets the mode for constant surface speed (CSS)"
G97 "Sets the mode for constant spindle speed (RPM)"
S "This is the command to set the spindle speed. In CSS mode this is SFM. In RPM mode it is RPM (S after G48 is RPM)"
M3 "Turns the spindle on (clockwise rotation)"
M4 "Turns the spindle on (counterclockwise rotation)"
M5 "Turns the spindle off"
So lets say you want to use a front toolpost on a left hand spindle lathe for your code would look like this...
Variables for CSS mode: SFM=400, MaxRPM= 2000, Direction is clockwise.
G48 S2000
G96 S400 M3
M5
Or...
Variables for RPM mode: RPM= 2000, Direction is clockwise.
G97 S2000 M3
M5
Hope that helps.
Wes
-
ok thanks. :)
-
Related Turn question in Vn 40. with parallel port. Say I'm doing:
M3 S1500 (rpm)
G95 (constant feed per revolution)
F 0.2 (mm/rev)
G01 Z blah
and its cutting, the STrue is 1500 rpm (finally got that working) and its too fast so I turn down the spindle speed (via the VFD by hand), the STrue drops and the S speed stays the same as expected but the feed (mm/rev) goes up and the rate the Z axis moves does not change. So its not reducing the feed rate so mm/rev calculated goes up. Is this normal? Is there a setting I can adjust so it keeps a constant mm/rev when speed changes? Even if I try to change the "S" via override, makes no difference.
Do I need to be in G96 mode for this interaction or is the feedrate fixed once the command is running and actual spindle speed has no input? I have the box "Use Spindle Feedback in Sync modes" ticked.
Next, I've played with G96 and found it messed up the "STrue" number as soon as this command was reached. 0 to 1500 rpm would read 2035 to 2355 or something like that. I must be doing something wrong. Can someone post a successful G-Code snippet with G96 used please - would be really helpful. In the meantime, I'll experiment some more.
(G96 is not in the Turn documentation I have.)
Thanks,
Woody.
-
G21 G40 (metric and clear any comp.)
T0101 (select tool 1 offset 1)
G00 X100. Z10. (rapid to start point)
G48 S1000 (set max spindle speed)
G96 S50 M3 (select CSS)
G95 (set to feed/rev)
G01 X10. F.2 (feed to 10mm dia)
X100. (feed back to start point)
G97 S1000 M3 (set to rpm mode)
M30 (all done)
If you watch the speed it should range from 159 to 1591 rpm, this will not happen as the speed is capped at 1000 rpm, the G48 line can be changed to allow maximum if it is safe to do so.
Graham
-
When I use this code CSS works fine meaning as the diameter decreases spindle speed increases. What is not working is the G95 or constant mm/rev feed rate. If I assign F=.2mm/rev this feed rate only takes place at the start of the cut when the RPM is still 1000RPM. As the RPM increases the feed rate in mm/rev decreases. Has anyone had experience with this behavior? My observation is that RPM x F(mm/rev) remains a constant value which suggests to me that the feed is remaing constant in mm/min and not in mm/rev as it should having set G95.
-
When I use this code CSS works fine meaning as the diameter decreases spindle speed increases. What is not working is the G95 or constant mm/rev feed rate. If I assign F=.2mm/rev this feed rate only takes place at the start of the cut when the RPM is still 1000RPM. As the RPM increases the feed rate in mm/rev decreases. Has anyone had experience with this behavior? My observation is that RPM x F(mm/rev) remains a constant value which suggests to me that the feed is remaing constant in mm/min and not in mm/rev as it should having set G95.
I ran into this a couple of days back. It seams as if mach had a mind of its own. The feeds were almost rapids. CSS still worked but the feeds were way off. It required restarting to solve the issue and then it did it again after a few passes. Good thing for me I was cutting air. I feel there is a bug. I haven't had any more time to test if it occurs only with CSS and feed per rev on the same program. Something tells me its gonna be a long time before it gets fixed if there is actually a bug.
-
It is a known bug in Mach3 Turn. The combination of G95 and CSS doesn't work. G94 with CSS work fine.
Dan
-
It is a known bug in Mach3 Turn. The combination of G95 and CSS doesn't work. G94 with CSS work fine.
Dan
Seams like I keep uncovering these nice little easter eggs. Is there a thread listing all these bugs? If not maybe there should be.
-
I know it doesnt work with the SmoothStepper and I have had various people saying it does work,as well as others saying it doesnt work, with the PP. What you are describing is exactly what I see with the SS so I am thinking it is indeed a Mach issue but it could well be a combination of Mach and SS as I am not sure if the SS controls CSS internally or not.
Turn needs a lot of work done on it and this is one area that will be looked at but when that will be I dont have a clue.
Hood
-
I think this is a serious limitation especially when profiling with a good surface finish requirement. I would like to ask the VB script and Brain experts out there if they think it would be technically possible to get around this problem with a Brain or adding a few lines to a MacroPump that would constantly update F as a function of RPM.
-
I have had problems with G95 only (no CSS) with PP and Vn 40.
First run would be fine, second would be stepper commands outputted at max computer speed (no reference to feedrate or max velocity at all) (10 mins file executed in 5 seconds)! Steppers screaming and massive lost steps. Next would be fine, next same as above.
Went back to version 22 which works fine except for long, deep threads and finished my work.
However, I had some time and went back to version 40 AFTER changing my parallel port in BIOS from ECP or EPP mode to "Bidirectional Parallel" (for other reasons) and I've not had that problem with version 40 since. All G95 code I've tried so far is fine and ran same piece 6 times with no issues. (Was it a corruped install or does the parallel port make a difference, I don't know.)
With Vn40, I also found the MDI would not accept inputs until G-Code was run. I found this was due to the initialising strings in the Config page being empty after upgrade.
I did a quick check with G95 and G96 and it seems OK. So, at the moment, happy with Vn 40...
However, as per my previous post, G95 does not respond to spindle speed changes. I'm sure it used to in previous (very early) Mach3 versions as I remember being a little impressed with it... Seems that is broken now unless I remember badly.
Woody.
-
Regarding CCS
I'm using a SS and i think what is happening is when the X tool comes out to take a new cut, its only then that the spindle wants to slow down.
So it gets the timings wrong, as it starts a new cut with the spindle too fast. I put a G04 pause to slow the spindle and it seems to work OK cutting air
I am looking to getting a braking resister for my VFD to slow it down a bit quicker.
Maybe you guys could test the theory out.
Brian are you looking ;D ;D
Phil
-
Brian only looks when there is no mention of Turn ;0
I will just go and do another test on the lathe for CSS and I will write down what it does this time as I always forget exactly. I had a long chat with Greg about it a month or so ago and he knew got how it was meant to work and said he would work on it in the future but backlash comes first.
Hood
-
Brian only looks when there is no mention of Turn ;0
Hood
A pic of Brian
-
Yes that seems to be a good likeness ;D
Ok quick test, first thing was add a blended feed DRO to the screenset
MDI
G96S200
M48S1000
M3
Start at X10
G1X200F0.5
FPR starts at 0.5 and as spindle slows gets as high as 1.3
Blended starts at 490 and remains constant
Next
Start X200
G1X10F.5
FPR Starts at 0.5 and as spindle speeds up it goes as low as 0.16
Blended starts and maintains 155
In other words its well screwed up and would be good to know if others get the same results with the same inputs with SS and PP.
Hood
-
Hood, just to get a better understanding of the problem I think your results are consistant with the idea that the feed is constant in m/min. When you work outwards your feed in mm/rev goes up, not because the tool is traveling faster but because your RPM are lower so mm/rev becomes a higher number. The opposite occurs when the tool is traveling inwards towards the central axis. In other words, you program for a constant mm/rev, but what you are getting is a constant m/min behavior. And the value of the mm/min is the same at which you start the operation. That is why the tool moves much slower when you go inwards than when you go outwards.......... I use PP.
-
Hood, do you know if V4 of mach will address any of these issues in turn or is it basically updating mill / router only?
-
Mill is first priority. Once it works well Brian will move to lathe... I hope.
Dan
-
I hope that isn't the case since software is never finished. Its a ongoing endeavor. I see specific bugs that have been documented years back in my searches so I fear we might be waiting a long long time.
-
Turn users have been a very small number in relation to Mill/Router/Plasma guys so afraid it has basically been ignored. The only updates I know of to Turn are the recent changes to the driver for threading. Lathe users are now inceasing in numbers so our voice is getting a bit louder but afraid its still silenced by the racket from all of the other users.
I can say however that Brian is working very hard on the new Rev of Mach and as Daniel has said this will firstly be for the Mill guys. The work being done to Mill is also going to benefit Turn as it will make things much easier to get working properly. I know Brian has also been doing some work on Turn along side mill and hopefully will be able to crank things up once Mill is out for release.
Hood
-
Here is a table to give you some idea of the RPM required for a given CSS and cutting diameter.
The reason for this is that a lot of users do not realise just how fast 200m/min is at small diameters
Graham
-
Very handy Graham, will go get that printed out :)
Hood
-
Graham, that is handy, got an "English" version? ;)
Thanks,
Dave
-
Graham, that is handy, got an "English" version? ;)
Thanks,
Dave
I think the stone tablet that it was carved into got dropped and broke ;D
Hood
-
Dave,
got an "English" version?
yes I do, I will post it up tonight. Only problem is I think its white on pink ;D
Graham
-
:D
:D
;D
This was found in a cave written in ancient Hebrew on some old papyrus.
It has been translated. (most likely copied from the original stone tablets)
(rpm = sfm × 3.82 ÷ cutting diameter)
There was a Spread Sheet along with the Dead Sea scrolls but it was in an unsupported version.
Could make up a new one though. :)
-
Dave,
got an "English" version?
yes I do, I will post it up tonight. Only problem is I think its white on pink ;D
Graham
That's quite alright, beggers can't be choosers. :)
Thanks,
dave
-
Just for Dave
A table of the old fashioned way of working ;D
Graham
-
Thank you sir - 8)
Thanks,
Dave
-
a bit more math that may help some people...
IN -- MM Conversion...
MM = inch x 25.4
IN = mm / 25.4
SFM -- RPM Conversion...
SFM = ( RPM x DIA ) / 3.82
RPM = ( SFM x 3.82 ) / DIA
IPR - IPM Conversion...
IPM = ( # of teeth in the cutter x IPR ) x RPM
IPR = ( IPM / RPM ) / # of teeth in the cutter
Drill Point Length Calculation...
Depth = ( DIA / 2 ) / TAN ( ANGLE / 2 )
Thread Depth Calculation...
External Thread Depth = .61343 x ( 1 / # of threads per inch)
Internal Thread Depth = .54127 x ( 1 / # of threads per inch)
External Thread Depth ( SHARP V) = .86603 x ( 1 / # of threads per inch) MODIFIED POST: ADDED SHARP V 12/10/10 RICH
Cutter Comp Shift Calculation...
Compensation for an Angle...
Z Shift Amount at the End Point = TNR x ( 1 - TAN (ANGLE / 2))
X Shift Amount at the Start Point = ( TAN (ANGLE) x Z (above)) x 2
Compensation for a Radius...
Z Shift Amount at the End Point = TNR + Part Radius
X Shift Amount at the Start Point = 2 x (TNR + Part Radius)
-
Yes that seems to be a good likeness ;D
Ok quick test, first thing was add a blended feed DRO to the screenset
MDI
G96S200
M48S1000
M3
Start at X10
G1X200F0.5
FPR starts at 0.5 and as spindle slows gets as high as 1.3
Blended starts at 490 and remains constant
Next
Start X200
G1X10F.5
FPR Starts at 0.5 and as spindle speeds up it goes as low as 0.16
Blended starts and maintains 155
In other words its well screwed up and would be good to know if others get the same results with the same inputs with SS and PP.
Hood
Hood,
Just did a quick test. Seeing similar behaviour here as well. Mach3 always maintains same mm/min feed and adjusts the mm/rev accordingly. The mm/min feedrate at which it moves corresponds to the mm/rev feedrate at the beginning of the move. This is with a Smooth Stepper.
Dan
-
Thanks Dan, maybe someone that uses the PP can test to see if its the same, that way I will know who to moan at ;D
Hood
-
I did tests as described in my previous posts and mm/rev is adjusted so mm/min is kept constant. I do not use smoothstepper and the behaviour is the same as described by the guys with smoothstepper so nothing to do with it. Can anyone suggest a way of getting around this without having to wait for Mach to be fixed ??????????? Some Brains programming or something?
Jorge
-
Ah sorry, missed your post :(
Dont think really there is another way but I am not up on macros/plugins etc so maybe someone else who is can help, might be possible with formulas but again not got any experience of them.
I will be sure to let Brian know its screwed ;)
Hood
-
It is possible but not practical to do, the problem is you would have to split every move into small segments and recalculate the speed and feed, this would be a nightmare to do even on a simple part. I am sure the surface finish would suffer and the delays cause major jerkiness.
Best wait and see if Brian can fix it.
Graham
-
Just made up a quick spreadsheet to convert surface speed to RPM for a given dia and feed per tooth to feed per min.
Thought it might be of use to others if they are like me, ie paper gets lost in my workshop within 10 seconds ;D
Hood
-
Regards G96, I want to control the speed through the programme. I have an inverter powering a 2HP motor. can I use either the spare Y axis or A axis pin on the printer port to give the PWM. Is there another way of doing it
Regards Jason