[Moondog]

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]

You need to enable CV (constant velocity mode) and give it a try. Are you using Mach 3 or 2?

[Moondog]

Thanks Dennis

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

Using Mach2

[bgolash]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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) 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]

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]

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]

Gerry,

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

Moondog

[derekj308]

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