. .
  1. #1
    Wal's Avatar
    Lives in Stockport, United Kingdom. Last Activity: 30-03-2023 Has been a member for 9-10 years. Has a total post count of 491. Received thanks 71 times, giving thanks to others 29 times.
    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.

  2. #2
    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.
    ..Clive
    The more you know, The better you know, How little you know

  3. #3
    Wal's Avatar
    Lives in Stockport, United Kingdom. Last Activity: 30-03-2023 Has been a member for 9-10 years. Has a total post count of 491. Received thanks 71 times, giving thanks to others 29 times.
    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.
    Last edited by Wal; 11-10-2017 at 11:42 PM.

  4. #4
    Wal's Avatar
    Lives in Stockport, United Kingdom. Last Activity: 30-03-2023 Has been a member for 9-10 years. Has a total post count of 491. Received thanks 71 times, giving thanks to others 29 times.
    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.
    Last edited by Wal; 12-10-2017 at 12:27 AM.

  5. #5
    Wal's Avatar
    Lives in Stockport, United Kingdom. Last Activity: 30-03-2023 Has been a member for 9-10 years. Has a total post count of 491. Received thanks 71 times, giving thanks to others 29 times.
    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?

  6. #6
    m_c's Avatar
    Lives in East Lothian, United Kingdom. Last Activity: 3 Days Ago Forum Superstar, has done so much to help others, they deserve a medal. Has been a member for 9-10 years. Has a total post count of 2,908. Received thanks 360 times, giving thanks to others 8 times.
    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
    Avoiding the rubbish customer service from AluminiumWarehouse since July '13.

  7. The Following User Says Thank You to m_c For This Useful Post:


  8. #7
    Wal's Avatar
    Lives in Stockport, United Kingdom. Last Activity: 30-03-2023 Has been a member for 9-10 years. Has a total post count of 491. Received thanks 71 times, giving thanks to others 29 times.
    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

  9. #8
    Wal's Avatar
    Lives in Stockport, United Kingdom. Last Activity: 30-03-2023 Has been a member for 9-10 years. Has a total post count of 491. Received thanks 71 times, giving thanks to others 29 times.
    Found this too:

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

    Posting link for reference.

  10. #9
    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)

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Torque / Speed curves for different Spindle Types
    By Chaz in forum Spindles & Drive Motors
    Replies: 11
    Last Post: 26-09-2016, 08:06 PM
  2. eBay: cnc controller for mach3 or linux
    By rrossetti in forum Items On eBay UK
    Replies: 1
    Last Post: 27-02-2016, 01:33 PM
  3. linux
    By universally in forum LinuxCNC (EMC)
    Replies: 9
    Last Post: 31-01-2015, 05:12 PM
  4. Machine Slow on Curves
    By swisscheese in forum Computer Software
    Replies: 31
    Last Post: 12-04-2014, 12:49 AM
  5. Best software for Linux users?
    By birchy in forum CAD & CAM Software
    Replies: 10
    Last Post: 07-05-2011, 02:04 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •