Machsupport Forum
Mach Discussion => General Mach Discussion => Topic started by: wyama on July 24, 2008, 06:43:20 PM
-
I can't seem to get constant velocity when doing spirals or thread milling. I've reduced a facing operation to test the CV mode and when I change the init at the top from G61 to G64 I see the CV light on the Mach screen turn on/off accordingly.
The G1 code cuts a straight line and it seems to "bounce" or turn around without really ramping down and then back up. That's seems very harsh as far as direction change worst case yet G2 code or G3 coding seems to ramp down and stop for each line.
I can't seem to get it to be continuous. I've tried all the settings on the general config page in Mach and on the settings screen for CV feedrate.
Nothing seems to make a difference.
(magc_shave 7-13-2008)
G90 G64
M6 T1 (TOOL CHANGE endmill0500:reg) (MSG, LOAD TOOL # 1) G43 H1
G0 G54 X0.075 Y0.05
S1909
M01
Z-0.1
G1 Z-0.19 F2.9
Y-0.05 Z-0.21
Y0. F5.7
G3 X0. Y0.075 R0.075 F2.9
G3 X-0.075 Y0. R0.075
G0 Z0.10
M05 M09
M30
Any thoughts?
Wayne
-
I can't seem to get it to be continuous. I've tried all the settings on the general config page in Mach and on the settings screen for CV feedrate.
Turn all the CV options OFF.
-
I seem to have tried every combination. I just double checked and turned off all CV options in the general configuration and still nothing.
It would be nice to resolve as thread milling takes forever with all the starts and stops.
Wayne
-
HI WAYNE, DOes it happen all the time or just sometimes. WHat version of Mach are you running?
If it does it again try two things
1 Try a Regen toolpath to see IF it stops doing it.
2 Try a total COLD rebooting of windows and restart MACH to see IF it stops doing it.
IF you have a complete piece of code that shows it it will help.
Please let us know, (;-) TP
-
You need to turn off both options on the settings page as well as all the settings on the General Config page.
-
HI WAYNE, DOes it happen all the time or just sometimes. WHat version of Mach are you running?
If it does it again try two things
1 Try a Regen toolpath to see IF it stops doing it.
2 Try a total COLD rebooting of windows and restart MACH to see IF it stops doing it.
IF you have a complete piece of code that shows it it will help.
Please let us know, (;-) TP
The machine has been doing this since since I acquired it a couple months ago. I have a Syril SX3. The code posted was stripped down from a finishing operation I had run on some heat sinks.
It appears on all jobs small or large do the same thing. I have turned off all CV setting in the general config and on the settings page and it still ramps down and then back up.
I do notice that the when it ramps down and stops or nearly stops it has overshot into the next command. ie. Coming back to 0,0 before the first arc it comes to rest part way onto the arc.
If I single step line for line each line ends as specified in the Gcode.
Before posting I have basically spent all day playing with all the different settings, finding threads associated or related here, on CNCzone and the mach yahoo forum.
Today I also downloaded and installed the latest mach locked version 2.62. I believe I was running 2.4xx. Both versions behave the same.
If I change G64 in the 2nd line to G61 the CV light in Mach goes out, but, the behavior is very similar.
I tried creating a sample thread milling from within Mach and resulting code also start/stopped for every G2 command. Just wanted to check if it was something FeatureCam is generating vs other code. I even tried changing the G2/G3 config from X, y, radius to X,Y I,J format.
The feed rate is slow. I would expect issues with high feed rates. ??? :o
I had to reboot the machine after installing the latest version. I have rebooted the laptop many times previous and for good or bad it's very stable and repeatable. The more I use the machine the more annoying it gets and I believe it's the start/stopping that is causing burrs in the thread mill operation and of course takes 3X longer than it should due to the large quantities of stops. It's like going 50MPH starting and stopping every 10 feet.
Maybe, something here that will lead to a clue or resolution. ;)
Wayne
-
Now I have read the post, I'm not sure what you are after - whether you want Constant Velocity on or off.
With Constant Velocity ON as a line is coming to the end of a move, the next line is calculated, and is started before the old line is finished - and the net output combined to give a position that suits both (or suits neither). This leads to rounding of corners etc. I tried this on my lathe/mill and on an acute angle, the table was stopping nearly 30thou short of the line end.
Exact Stop is, as described, an exact stop, where the line is completed and the axis stops BEFORE starting the next line. In many applications, particularly complicated patterns where arcs are made up from many, many little lines, this gives a jerky movement. It is, however, exactly accurate.
There are several moves where constant velocity does not function - and G2 and G3 is one - becasue the axis co-ordinates for these moves are continually generated in Mach3 as the move progresses. I could see also where having constant velocity on would ruin a cut, and I would have thought that threading is one of them, since accuracy is called for.
If you want to make your lathe/mill smoother, then ramp down the acceleration on the motors. You can keep the max speed, but cut back on the gas - and make for a smoother run.
I have not adjusted my CV - I have left it at the default values. You may have adjusted it so that it is almost like exact stop.
I think the problam is with your basic motor acceleration.
-
In two cases it would be preferable if the head continued in a constant fashion.
The partial code above is a spiral cut. Each G2 command cuts 90 degrees or a partial circle. The next command continues the circle so it would seem if CV is working there would be a smooth transition from one to the next since it is cutting a circle to begin with.
Thread milling does the same thing. The commands are broken up into partial radius command each approximately 90 degrees or 1/4 of the circle/spiral.
If there are 20 threads with 4 gcode lines per turn then there are some 20 X 4 or 80 Gcode lines. At the feed rate I'm going at the machine is spending 60% of the time either stopped, slowing down or speeding up. What a real waste of time.
Since each command is a partial circle there should be no angle break or difference from one line to the next as it is part of a drawn circle. It's not like it's making a 90 degree corner turn. i can't see why there would be any rounding or distortion caused by two adjacent lines of code. It's not like traveling in the Y direction and then traveling in the X direction on the next command.
It's frustrating to know there is CV to account for this and not being able to get to it. Not only is it doubling or tripling the machine time it's not very efficient.
I have CV enabled, but, it's not working as expected.
Wayne
-
CV stays on when I run your code here, could you attach your xml and I will run with that and see what happens.
Hood
-
Here's my mach3 xml file.
Wayne
-
Well using your xml and your snippet of cde CV stays on. If you just use the snippet that you posted does CV turn off? Do you actually see the CV LED turning off or is there another reason you believe it is turning off?
Hood
-
Yes, using the code supplied the CV light is on. That's not the issue. Changing the code from G64 to G61 will turn CV off which the CV light goes out on the Mach screen as well.
Either way, the code as is when it run on my machine will "whine" down to a stop and then whine back up when starting the next line of code. "Whine" is the sound of both the X,Y steppers making music.
I made a simple straight line with two segments. Just moving X on the X,Y plane the CV on or off changes the machine behaviour. Changing it to add Z as well also behaves correctly with and without CV mode.
These are G1 linear move commands. G2, G3 are circular move commands and based on what I'm seeing it appears CV is not implemented on circular moves.
Wayne
-
CV in a G2/G3 move will sound like its winding down to a stop because one axis has to come to a stop as it reaches the cardinal point, it then reverses and goes the other way. Same when you get to the next cardinal point, the other axis will wind down and stop then reverse. With constant velocity the axis should not have a significant delay but it will stop as it is impossible for an axis to reverse without stopping. Your motor tuning will make a big difference to what you see/hear. A machine with fast acelleration you wil hardly notice the slow down, one with a slower acelleration will be quite noticeable.
If you put G61 in you will, or should notice a more significat slow down/stop.
Hood
-
Cool, that makes a lot of sense.
Still, It doesn't seem correct why it whines down off cardinal. Where it ends up stopping is say 20 degrees off top dead center. Also, the initial transition into the circle from the straight line it whines down and ends up stopping way past the start point of the circle. Maybe, there is an offset from where it transitioned into the start of the circle and now is shifted.
It's not in CV mode if the head slows down and stops is it? that's what is happening.
It seems to behave the same on this particular code with CV on or off.
Wayne
-
Can you take a video of it and put it on the Mach group You Tube page, that will give us a better idea of what you are meaning.
Hood
-
Ha!!! Just what I was thinking. Give me a second. Uploading.
-
Hope this links works.
http://www.youtube.com/watch?v=8ycgGgxrCsk
Wayne
-
Here's a longer video of a section of code for threadmilling.
I've loaded a drill into the spindle to help visually see the head move. The CV light was on in the Mach screen.
http://www.youtube.com/watch?v=p_9rU5cmEf8
The associated code:
M6 T5 (TOOL CHANGE TM-1875) (MSG, LOAD TOOL # 5)
S2500
M01
G0 G54 X0.4737 Y0.4156
Z1.0
M01
Z0.1
G1 Z0.0391 F9.0
X0.4909 Y0.3984 F4.5
G2 X0.4972 Y0.375 Z0.037 R0.0469
X0.385 Y0.2628 Z0.0277 R0.1122 F9.0
X0.2728 Y0.375 Z0.0185 R0.1122
X0.385 Y0.4872 Z0.0092 R0.1122
X0.4972 Y0.375 Z0. R0.1122
X0.385 Y0.2628 Z-0.0092 R0.1122
X0.2728 Y0.375 Z-0.0185 R0.1122
X0.385 Y0.4872 Z-0.0277 R0.1122
X0.4972 Y0.375 Z-0.037 R0.1122
X0.385 Y0.2628 Z-0.0462 R0.1122
X0.2728 Y0.375 Z-0.0555 R0.1122
X0.385 Y0.4872 Z-0.0648 R0.1122
X0.4972 Y0.375 Z-0.074 R0.1122
X0.385 Y0.2628 Z-0.0832 R0.1122
X0.2728 Y0.375 Z-0.0925 R0.1122
X0.385 Y0.4872 Z-0.1017 R0.1122
X0.4972 Y0.375 Z-0.111 R0.1122
X0.385 Y0.2628 Z-0.1203 R0.1122
X0.2728 Y0.375 Z-0.1295 R0.1122
X0.385 Y0.4872 Z-0.1387 R0.1122
X0.4972 Y0.375 Z-0.148 R0.1122
X0.385 Y0.2628 Z-0.1573 R0.1122
X0.2728 Y0.375 Z-0.1665 R0.1122
X0.385 Y0.4872 Z-0.1758 R0.1122
X0.4972 Y0.375 Z-0.185 R0.1122
X0.385 Y0.2628 Z-0.1943 R0.1122
X0.2728 Y0.375 Z-0.2035 R0.1122
X0.385 Y0.4872 Z-0.2127 R0.1122
X0.4972 Y0.375 Z-0.222 R0.1122
X0.385 Y0.2628 Z-0.2313 R0.1122
X0.2728 Y0.375 Z-0.2405 R0.1122
X0.385 Y0.4872 Z-0.2498 R0.1122
X0.4972 Y0.375 Z-0.259 R0.1122
X0.385 Y0.2628 Z-0.2682 R0.1122
X0.2728 Y0.375 Z-0.2775 R0.1122
-
Thats certainly not looking very good, can you post the full code as a file and I will see what my mill runs like with it.
Hood
-
Hood, Thanks for replying.
I was beginning to believe pilot error.
I started running at tool change 5. That's the bottom section of the file.
Wayne
-
just looking at your xml, it has 2000 steps per unit, what hardware do you have as that seems rather low for being set up in imperial units.
Is it steppers? Do your drives have micro stepping? what gearing? whats the ballscrew pitch or TPI?
Hood
-
Oh O... I'm not sure I posted the correct xml file. I'm using the SyilSX3.xml configuration file that Syil created. Is that the xml file I need to post and not the mach3 file.
Just in case, here's the Syil xml mach3 config file.
-
yes thats correct, if you are using the syil then thats the profile you will want, will go load that and see :)
Hood
-
Sorry took so long but I had to modify your xml to reflect my pin asignment.
OK first thing I noticed is you have the kernel set to 35KHz and your motors are tuned faster than that so try setting to 45KHz and see if that helps. Also you have ES set in the General Config page, you want to change that to CV. For this file it shouldnt really matter as you have a G64 in it but just for future.
Also might be good to set Persistent DROs on the General config page and maybe even persistant tools but that will depend on how you do the tool changes etc.
I tried your file and your xml and it runs fine for me, certainly none of the jerky movements you are seeing, think maybe the Kernel speed change may help you out.
Hood
-
Oh another thing you might want to change is the Auto Limits OverRide on the settings page but you would have to enable your limits and that depends how your switches are set up. Usually if your switches are activated at either end of the axis travel you can use them as both Home and Limit switches.
Hood
-
Sorry took so long but I had to modify your xml to reflect my pin asignment.
OK first thing I noticed is you have the kernel set to 35KHz and your motors are tuned faster than that so try setting to 45KHz and see if that helps. Also you have ES set in the General Config page, you want to change that to CV. For this file it shouldnt really matter as you have a G64 in it but just for future.
Also might be good to set Persistent DROs on the General config page and maybe even persistant tools but that will depend on how you do the tool changes etc.
I tried your file and your xml and it runs fine for me, certainly none of the jerky movements you are seeing, think maybe the Kernel speed change may help you out.
Hood
Maybe, it's the laptop I'm using is not fast enough. The interrupt value seems to hover around 10 ish. I saw a Mach video tutorial or doc somewhere that described typical numbers. I don't recall what was good numbers or not. I seem to recall values around 2-3 being good. Maybe, the laptop is not up to the task.
Well, that could just push me over the edge to get a real PC and not use the laptop. I have a MPG that I can't hook up to the laptop since I can't seem to get a 2nd parallel port adaptor to work on the laptop. USB to parallel doesn't work and I haven't tried a PCMCIA adaptor to parallel yet.
On the debug screen there is a blend box. When I run the code I see values changing in this box. Maybe, this is a value relating to CV when it's combining one line to the next possibly the blend value shows the amount of stitching is being performed.
I modified the feed rate to 1.9 on the G1 and G2 commands in the sample test file and it still comes to a complete stop between each command. It's almost like there is a delay value execution number that is appied between each Gcode line.
Are there other tests that I can perform to isolate this more?
I've learned quite a few things from this. I have a better handle on G61, G64 commands and how to create G2 commands in two formats.
I am only guessing that the non smooth threadmilling is the cause for rough threads. Since I can't make it run continuously smooth I can't verify if that is indeed the culprit or it's just the way it is.
The other thing I learned is that when pressing the stop on Mach you can lose a few steps. Now I know when I crash my tool into my part I should go back and verify my X and Y zeros.
I have checked persistant DROs. Doesn't seem to work. I exit the program and restart it and find the DROs have new numbers. Bummer!
Thanks for the help. Going to bed now. It's 3am in the morning.
Wayne
-
Ahhhhhhhh laptop, now thats a bad word LOL
ok do the drive test and see what that looks like, also try the optimisation steps and look to see if there are any power saving options set up in device manager.
Did you try with the Kernel set to 45KHz?
One thing you might want to look at is the SmoothStepper, its still Beta but works well and the few things that are still to be implemented should be done shortly.
Hood
-
Another thing to check is make sure your xml is not read only (can be if you copy from a CD) Also when you make a setting change you could try using the save Config option, think its under the config menu.
Hood
-
I don't want to compromise anything on this machine. The laptop came configured when I bought the machine. Since I can't hook up the MPG to the laptop it's time to dump it and get a real PC.
I've ordered a PC to be configured with two parallel ports so I can run the machine and have the MPG hooked up. I'll get the PC on Tues and will report back if it has resolved the CV problem. Hopefully, the answer will be yes.
No matter... Hopefully, I'll be able to use the MPG I have.
Thanks everyone for all the help. I'll let you know what happens with the new PC when it arrives.
Wayne
-
Just a follow up and a FYI for someone else that may have this sympton.
After getting the new PC hooked up and configured I was totally bummed as the new PC did exactly the same thing.
What I discovered was that if I raised the kernel from 25K to 45K on the laptop it would time out. The laptop can't run that fast. I finally found the setting in the ports/pins configuration. Not sure why it's there an not in the general configuration section. :o
When I upped the kernel rate on the PC there was no issues. Still the program paused or ramped down and up at each line.
I finally found that disabling the backlash solved this. Enabling backlash again confirms the start/stop and disabling backlashed it runs continuous from line to line.
So, the PC was not all in vain. One issue down... Now to go play with the MPG. ;D
Wayne