View Full Version : Bridges & jerky movements.


Moondog
06-14-2006, 06:40 AM
Another question hopefully you can answer.

I use 3D bridges in my toolpaths to hold parts whilst cutting. If the 3D bridge is on a straight cut it works fine, however if the bridge is on a curve the movement becomes jerky etc..

Is there a setting in Mach that may eliminate this?...

Normal cutting of curves and circles are no problem, perfect.

Any help appreciated.

cheers

Frans

DennisCNC
06-18-2006, 06:24 PM
You need to enable CV (constant velocity mode) and give it a try. Are you using Mach 3 or 2?

Moondog
06-18-2006, 08:21 PM
Thanks Dennis

CV mode is already set.. any other ideas? anyone..

Using Mach2

bgolash
06-18-2006, 08:36 PM
Hi
I can`t confirm this statement but I`ve heard something a while back.
Steppers can`t keep up to one another when the axes are moving
similtanously. I believe this is even more true when the speed is
high. I saw a video by Jeff Davies of homecnc using his servo machine
and didn`t notice any jerky movement. From what I saw the motion
was very smooth. I too have a stepper system and I see jerky motion
when two axes are moving at once. Maybe someone here can jump in
and clarify this condition.

Barry

Kiwi
06-18-2006, 08:39 PM
I had the same problem with my Machine Centre with a Fagor 8055 controller.
The fix is to put G51 E0.0001 at the beginning of the program.
G51 is the Look-Ahead mode which enables the CNC to look ahead up to 50 lines, analyze the tool path and calculate the max feedrate with an max error of 0.0001mm.
Don't know if Mach has the equivalant feature.

derekj308
06-18-2006, 11:08 PM
Hi Moondog
Are your pitches the same on X and Y? I have some vague memory about reading about issues when the pitches are different on X and Y. Something about circular interpolation.

Cheers
derekj308

Moondog
06-18-2006, 11:08 PM
Hello Kiwi..

Had a look at the G codes and settings.. couldn't see an equivilent for Mach 2. maybe someone esle will know.

I have a feeling it may be a Mach 2 resolution issue?...

Bgolash....

Steppers can keep up with Servos etc.. and co-ordinate all axis together.... it is the drivers and controllers that govern how well it works.....


cheers

Frans

Moondog
06-18-2006, 11:11 PM
Hi Moondog
Are your pitches the same on X and Y? I have some vague memory about reading about issues when the pitches are different on X and Y. Something about circular interpolation.

Cheers
derekj308

Derek... they aren't the same.. they very rarely are on most machines. Mach is supposed to compensate for drive/pitch differences as set up on Motor Tuning.... I'll have a look at circular interpolation (whatever that is).. is there a setting for it?

derekj308
06-18-2006, 11:20 PM
Hi Moondog
I agree with you that Mach does compensate for different pitches via the setup but whether the pulses out are synchronised is another story. I believe (and I could be very wrong) that when you use circular interpolation (just by using a G02 or G03) that the contoller (Mach) may not synchronise the two axes very well for whatever reason resulting in a 'jerky' movement. I'd fire off an email to Art for his opinion on this. I can't for the life of me remember where I read it. It may even be in the Mach manual.

Cheers
derekj308

Halfnutz
06-18-2006, 11:26 PM
If its just a matter of smoothing out those sections of code couldn't you just do a feed rate change to slow down for those sections?

Moondog
06-19-2006, 12:53 AM
If its just a matter of smoothing out those sections of code couldn't you just do a feed rate change to slow down for those sections?

To do that would take large amount of code changes and involve numerous different toolpaths....

I still think it is a Mach2 resolution problem...

Halfnutz
06-19-2006, 01:23 AM
I do it all the time with a simple F20 at the beginning of the problem and a F40 at the end of the block.

Just run the program, and wherever you hit a problem stop the program, open it in the editor, back up a line (or two) add a feed change to the first line of the block and one to the end of the block, and resume cutting at where you stopped. Once you run through the program once you have the problem fixed for good. If its a program you use more than a little, its not a big deal.

I use diferent feed rates throughout most of my programs. If Im at the beginning and doing the roughing with little or no Z movement and a simple raster scan I will crank the feed up to 70 or 80 IPM and then slow down to 30-40 for areas with lots of contouring and multi axis movements.

I geusse its a pain, but I only have to optimize the program once, and I can take a two hour program down to an hour sometimes. If its a design I like and plan on using over and over its well worth it.

I dont know exactly what your doing of course, maybe your talking about a six hour program with a tab every fifty lines, who knows, but its a something to consider.

Moondog
06-19-2006, 02:10 AM
I do it all the time with a simple F20 at the beginning of the problem and a F40 at the end of the block.

Just run the program, and wherever you hit a problem stop the program, open it in the editor, back up a line (or two) add a feed change to the first line of the block and one to the end of the block, and resume cutting at where you stopped. Once you run through the program once you have the problem fixed for good. If its a program you use more than a little, its not a big deal.

I use diferent feed rates throughout most of my programs. If Im at the beginning and doing the roughing with little or no Z movement and a simple raster scan I will crank the feed up to 70 or 80 IPM and then slow down to 30-40 for areas with lots of contouring and multi axis movements.

I geusse its a pain, but I only have to optimize the program once, and I can take a two hour program down to an hour sometimes. If its a design I like and plan on using over and over its well worth it.

I dont know exactly what your doing of course, maybe your talking about a six hour program with a tab every fifty lines, who knows, but its a something to consider.

Halfnut.

Thanks.. But I need a solution to the problem rather than a work around. There are too many tabs etc to even consider changing code.. it would be easier just to do Normal tabs instead of Ramp/3d tabs....

As I said above.. they work fine on straight sections, curves are the problem for the tabs. [

Kiwi
06-19-2006, 02:59 AM
Re #5.....Sounds like your problem is different to what I was having.
My machine was hesitating a the end of each block and not during G02/03 interpolation.

Halfnutz
06-19-2006, 11:15 AM
Moondog, I understand what your saying, you think you have a problem with the way Mach is interpolating those curves, I was thinking that maybe your just at your max speed, and Mach or your hardware wont crunch any faster. Thats basically why I do what I do, because if I run at an acceptable speed for all conditions I'm limited to less than 50ipm, whereas is I use diferent feed rates I can get much faster overall program runtimes. I HATE listening to that router screaming away for hours on end.

HayTay
06-19-2006, 07:56 PM
Moondog,

Maybe you can try adjusting the "Look Ahead xx Lines" value to something greater? I don't remember where the setting is in Mach 2. It's under Config -> State..... on the Mach 3 toolbar. The default for Mach 3 appears to be 25 lines.

Have you tried Mach 3? It amazes me how many Mach users are still using version 2. I know it takes some time to reconfigure Mach 3 and the screens are a little different, but, the latest Mach3 Dev. Version 1.90.051 (Click Here) (http://www.artofcnc.ca/Mach3Version%20D1.90.051.exe) just SCREAMS! Mach 3 runs much smoother than the previous version that I was using and I was able to adjust my feed rate from 33 ipm to ~60 ipm.

I had to run the previous version of Mach 3 at 33 ipm due to lost steps during multi-axis moves. Simultaneous X-Y-Z axis moves, 45 degree X-Y axis moves, and 90 degree radius curves went all haywire at any higher cutting speed. Sound familiar?

Just curious, what is your "displayed feed rate" versus your "programmed feed rate" when cutting the 3D bridges? I noticed that when I had a programmed F40 that the displayed feed rate was between 60 and 80 ipm on the cuts approaching 45 degrees, simultaneous 3-axis moves and 90 degree radius curves. This was well above the 50 ipm velocity setting I set up in the Motor Tuning screens, also. BTW, before anyone asks, the 50 ipm was ~80% of the velocity where my motors stalled or visibly lost steps.

The displayed feed rate in Mach 3 is also higher than the programmed feed rate for the types of cuts noted above but so far I haven't noticed any issues except for circles. I've got to slow down a bit to say 40 ipm on circular cuts but it is still faster than the original 33 ipm.

Why does/can the displayed feed rate be considerably higher than the programmed feed rate and/or the velocity setting in the motor tuning setup? Art? Someone? Anyone?


Curiosity killed the cat! Good thing I'm not a cat!!,

HayTay

Moondog
07-29-2006, 05:20 PM
Hello Hay Tay...

sorry for the delay in responding...

seems like the problem is that Mach cannot handle the amount of moves required. too many small moves.. I am cutting at 7000mm/min (around 300in/min). Also I am doing my NC code in Artcam and it looks loke Artcam creates too much code for these moves... Will look at doing the code in alphacam instead.

I also have noticed that the DRO's on Mach show much higher than the speed settings... for example... I have my machine set at 7200mm/min maximum. Sometimes during the rapids the DRO's show around the 10,000....???? strange.....

Mach does have its problems...

Also mach errors if you try and increase the feed rate over 100%... something that needs to be fixed ASAP...

Apart from Mach.. what are our other options?...


Moondog

ger21
07-29-2006, 06:40 PM
Hello Hay Tay...

sorry for the delay in responding...

seems like the problem is that Mach cannot handle the amount of moves required. too many small moves.. I am cutting at 7000mm/min (around 300in/min). Also I am doing my NC code in Artcam and it looks loke Artcam creates too much code for these moves... Will look at doing the code in alphacam instead.

I also have noticed that the DRO's on Mach show much higher than the speed settings... for example... I have my machine set at 7200mm/min maximum. Sometimes during the rapids the DRO's show around the 10,000....???? strange.....

Mach does have its problems...

Also mach errors if you try and increase the feed rate over 100%... something that needs to be fixed ASAP...

Apart from Mach.. what are our other options?...


Moondog

If using FRO over 100%, the rapids will increase as well.

When you say Mach errors at over 100%, what do you mean?

Moondog
07-29-2006, 07:44 PM
Gerry,

Apparently it is a well known issue.... above 100% it creates erratic moves...

Moondog

derekj308
07-29-2006, 08:25 PM
Hi Moondog

I believe the reason Mach shows a rapid greater than your maximum setting is when you are running two or more axis at once. For example in your case if your maximum single axis velocity is 7200mm/min on both axis then you could achieve a maximum rapid of 1.414 * 7200mm/min if you were running x and y ie 45 degree movement. The value shown for the feed/rapid rate on the DRO is the value of the velocity vector created between two points, not the maximum for one axis. When you rapid (G0) all axis involved are running at their maximum velocity set by you in Mach. When you feed (G1) each axis velocity is controlled to achieve the desired feed rate set in the program. In your example the maximum velocity you could achieve with a 7200mm/min setting per axis (x and y only) is 1.414 * 7200 = 10180mm/min. If you were to add in a Z move at the same time the DRO rapid value would increase again.

Cheers

ger21
07-29-2006, 11:28 PM
Program to the fastest speed you'll want to go, and use FRO to slow down only. That's how our commercial router works. Just start with the FRO at 50%, or whatever you want.

If you program at F100 and want to go up to 200, program at F200 and start with the FRO at 50%. Exactly the same, but you won't have any problems going faster.