Strange Speed Discrepancy on Curves - LINUX CNC

[Wal]

Hi all,

Bit of a weird one, this - I noticed it a while back, but using mainly smaller tools and cutting at pretty slow feeds it hasn't really bothered/affected me. I quite fancy getting to the bottom of it though...

The issue:

If I generate a tool path using straight lines at at a feed of 1800mm/min the machine runs at 1800mm/min - this is true regardless of whether those straight lines are horizontal/vertical (using only one of the motors) or diagonal (using both the X&Y motors).

If I generate a tool path where there are radii present the machine slows to around 1000-1100mm/min (it fluctuates) when it hits the corners.

Here's an illustration using three distinct shapes. Each shape has an identical path length and the CAD software reported that each scenario would take the same time to cut, but check out how everything slows down when cutting the circle.



Weird, huh? Machine is pretty beefy and happy at 2400mm/min rapids (well beyond that even, but I don't..)

Here's a real world example where you can clearly see the speed discrepancy between the 'straight' and 'curvy' bits of the cut:



Probably a simple solution to a dumb question - anyone..?

Wal.

[Clive S]

Wal I am going to stick my neck out Have you looked at the gcode ie is the circle using g3 and g2 or is it segmented short lines.

[Wal]

Hi Clive,

Shapes came in from illustrator so the circle (and just about all of my radii) are calculated as a series of short lines...

If I generate the curves from within the Vectric software then it uses G2 (not tested it, but I imagine it'll cut one of these circles at the correct speed...)

Wal.

[Wal]

Aha,

I'll test it properly tomorrow but it looks like if you export to the .svg format (from Illustrator) the Vectric software is happy to use G2 arcs when generating the g-code... Hopefully that should do it.

Wal.

[Wal]

After a few more tests...

If you save a perfect circle as a .pdf from Illustrator then Vectric will use G1 in the G-Code (a series of short lines which won't cut at the correct speed in Linux CNC)
If you save a perfect circle as an .svg from Illustrator then Vectric will use G2 in the G-Code (a proper arc that does cut at the correct full speed)

Generating circles and arcs from within the Vectric software uses G2's and G3's in the G-Code that cut at the correct speed, but curves and ellipses from within the Vectric software use G1's.

Anything other than a perfect circle from Illustrator (in .svg) results in G1's being written in the code - for me that's a problem as most of my work originates in Illustrator and doesn't necessarily involve perfect circles.

It would be nice if the software could write the more complicated contours/arcs as G2's and G3's but in theory it shouldn't be a problem - the feed is still set at 1800mm/min, right?

In practice, however, is this a case of my machine acceleration not being set up quick enough (in the LinuxCNC .ini file) to accommodate that quick succession of commands where the machine transitions from moving from one set of coordinates to another, effectively only allowing it to get up to a fraction of its intended speed before having to change direction..?

The video below (apologies for poor quality) shows the machine following another two paths. In the first you'll see (if not hear) a spike in speed where the path straightens out. In the second you'll see a gradual slowing down as the arcs of the spiral get tighter.



I guess that the more sophisticated commercial CAD/CAM software is clever enough to write contours in G2's and G3's, in the meantime maybe I ought to revisit my .ini file...

Any thoughts?

[m_c]

If the correct speed is maintained during G2/3s, and not using G1s, then the problem is likely to do with lookahead/smoothing settings, or even lack of processing power.

Lookahead would could cause the problem by the motion buffer simply not being kept full enough, so you end up with speed being restricted by the buffer not having enough stored motion to keep speed up. Simple test is to increase the lookahead setting. Lack of processing power would also cause similar symptoms, as motion is slowed to allow the buffer to be filled.

Smoothing/Corner settings would cause the problem due to the trajectory planner restricting speed to remain within the smoothing/cornering settings, at each corner between g1 line segments. It could be the amount of allowed deviation is too low, so the trajectory planner has to run at a slower speed to remain within the permitted deviation from the specified G-code path, while meeting acceleration settings.
Rather than me explain it poorly, have a read of this article in the dynomotion wiki that explains the problem far better, and how to solve it while using KMotionCNC. I'm sure LinuxCNC will have similar settings (KMotion uses the old EMC interpreter, however I've got no idea how much it's been modified and now varies between KMotion and LCNC) - http://www.dynomotion.com/wiki/index...ng_Noisy_GCode

[Wal]

Cheers m_c - I wasn't even aware of this side of LinuxCNC. Good shout.

Funnily enough, there was a link off the link you posted (http://wiki.linuxcnc.org/cgi-bin/wik...jectoryControl) where in the first paragraph the acceleration/deceleration I suspected is also referred to.

A few things to investigate there then - thanks again for the pointer..!

Wal.

Sent from my HTC One M9 using Tapatalk

[Wal]

Found this too:

http://linuxcnc.org/docs/html/config...#_traj_section

Posting link for reference.

[skunkworks]

You really want G64
http://linuxcnc.org/docs/html/gcode/...html#gcode:g64

The default behavior of G64 is go as fast as you can (up to the specified feedrate) while touching every gcode segment. If the lines are so short that they cannot be processed through 1 servo cycle - you start to get slow downs.

You really should get in the habit of specifying a G64 tolerance. If you don't you will get some pretty rounded corners as the default setting is go as fast as you can.

P - motion blending tolerance (how far away from the programmed path you deviate. P.005 says - go as fast as you can but stay within .005 of programmed path.

Q - naive cam tolerance - combine segments that are colinear with the Q amount. <- this will help your problem - it will combine segments that deviate within the Q amount.

G64 - best possible speed.

G64 P- <Q- > blending with tolerance.

On your programs I would try just a little Q - say G64P.005Q.001 (these are in inches - sorry)