Incorrect Arc Movement

Home › Forums › TinyG › TinyG Support › Incorrect Arc Movement

Tagged: 

Viewing 15 posts - 1 through 15 (of 23 total)
1 2
  • Author
    Posts
  • April 16, 2015 at 11:10 pm #7640
    Hcamp
    Member

    I have had an issue a few different times with arcs not moving correctly.
    From what I can tell it seems to happen on fairly small arcs and rather than moving along the intended arc segment the machine will travel on the rest of the circle that the intended arc would be apart of. It’s as if it takes the opposite of either CW or CCW arc that it should be. This has most of the time resulted in a move that goes crashing through and ruining the work piece or running into clamps.

    It believe it will consistently do it if the same program is re run, but if the same geometry is used and the program regenerate with slightly different tool paths then it will sometimes not have issues in the same spot as before.

    I know I can set CamBam, or other CAM software to convert arcs to line segments but this can produce very large files with many more lines than are needed, making it more difficult to load and smoothly run in ChilliPepper.

    I have a Shapeoko 2 and have been using CamBam with either default or Mach3 post processor, using ChilliPepper for control, and have the latest firmware (440.14) installed.

    Just wondering if there is a setting(s) that I should adjust or a different post processing format for arcs that would help to avoid this.

    April 17, 2015 at 6:47 am #7641
    cmcgrath5035
    Moderator

    A settings issue does not seem likely as you describe the behavior, but anything is possible. As described, it would seem to indicate a bug or geometry induced math error.
    Most efficient would be for you to post your Parameter set and a Gcode file known to have triggered this. Using dropbox or similar cloud resource is easiest to deal with. See

    If you run the Gcode via the CP simulator, does the plot follow the correct path?
    If you know what line number (even approximately) in the Gcode file triggers that that would speed analysis.

    April 20, 2015 at 11:26 pm #7644
    jlauer
    Member

    Small arc movements were fixed in newer firmware. Are you sure you have the latest firmware? I too have seen issues in the past with small arcs, but my understanding is those got fixed. I have not personally tested that though.

    April 21, 2015 at 9:29 pm #7646
    Hcamp
    Member

    I initially had the issues a while ago and didn’t connect the issues to an error with arcs, as I had been having some other problems with noise in some wiring that have since been fixed.

    Here are my current parameters: https://docs.google.com/document/d/1Y4reacwPXAMGouWnDZT8aphNCHDIjnWjSMberLFEIbs/pub

    I am running 440.14, I believe this is the newest?

    Unfortunately both previous times I had the issue I just ended up running the job again with different gcode file, and didn’t save the one that didn’t work.

    The most recent time that this just happened I again wasn’t thinking of having others debug and over wrote the file to complete the job I was working on.

    I just went back to try and reproduce it and I have yet to get it to. I will keep trying to see if I can get it to show up again.

    • This reply was modified 9 years, 5 months ago by Hcamp.
    • This reply was modified 9 years, 5 months ago by Hcamp. Reason: linky no worky
    April 22, 2015 at 2:13 pm #7651
    cmcgrath5035
    Moderator

    Hcamp
    Two parmeters

    [ja]  junction acceleration50800000 mm
[ct]  chordal tolerance           0.0000 mm

    Look to be way off, here are the default values

    [ja]  junction acceleration  100000 mm
[ct]  chordal tolerance           0.0100 mm

    $ct=0 could be causing havoc.

    You might try just changing these.

    But to be honest, a number of other parameters look strange, such as 

    [xtm] x travel maximum          300.228 mm
[xjm] x jerk maximum           5004 mm/min^3 * 1 million
[xjh] x jerk homing           10008 mm/min^3 * 1 million

    I am not sure why you would have 5004 vs just 5000.
    Did you enter these manually? Do you recall how?

    April 23, 2015 at 9:46 pm #7657
    Hcamp
    Member

    I’ll try changing those parameters and see if that will solve the issue.

    I initially loaded the default parameters that were included as one of the presets in tgFX. I loaded those and did a basic tuning of distance movements. I still need to do a more complete fine tuning.

    I haven’t changed those, at least intentionally. I did mess a little bit with the Z axis speeds and jerk as I was having some issues with it stalling only on positive moves and only during running a program but not manually. They seem to be fine where they are now, I could probably clean and re tune alignment and get more speed out of it.

    When I upgraded the firmware I did a capture of all parameters, then used that to manually go back and put everything back to where I had it.

    I normally work on inches as I am much more familiar with it, I used the mm output on here as that’s what I have seen most others use when posting. Maybe there is some sore of rounding/converting error when manually entering between the in vs. mm that would cause the 5004 vs 5000?

    April 24, 2015 at 7:10 am #7658
    cmcgrath5035
    Moderator

    Hmmm. I am a bit suspicious that your parameters were borked a while ago by tgFX.
    I think I have to recommend a factory reset procedure to get a clean set of 440.14 parameters, after which you will need to reset your motor and axis parameters again.

    But first – what are you using on PC to run your machine:
    OS – Win__, Linux, MACOS ?
    Interface SW – Chilipeppr, CoolTerm, other? You can no longer use tgFX.

    April 25, 2015 at 12:11 pm #7660
    Hcamp
    Member

    Will just reloading the firmware reset everything to factory or are there additional steps that need to added?

    I am running Win Vista
    I have been using only Chilipeppr for a while now. I initially used tgFX, then used a mix of tgFX and Chilipeppr depending on which seemed to be working better at the time, and have since gone completely to Chilipeppr as it seems much more stable and reliable than when I first tried it.

    April 25, 2015 at 8:12 pm #7661
    cmcgrath5035
    Moderator

    To reset parameters, I would suggest you send a $defa=1 command from the CP Serial Port Console. This resets parameters in EEPROM to ‘factory setting’, a set of parameters compiled into the firmware

    Reflashing the tinyG with FW 440.14 would have the same effect.

    In both cases, the tinyG parameters will then need to be manually restored to match your machine. Use either the Serial Port Console command window or the configuretinyG widget.

    Running Windows, your could do the same process using CoolTerm, the choice is up to you.

    TinyG runs based on parameter values stored in EEPROM. The initial values in EEPROM are loaded as part of the FW install process. Subsequent changes to parameters make from the command line or by programs such as CP change values in EEPROM, not flash.

    The problem of corrupt parameters we are chasing are most likely with the values in EEPROM, not flash

    I highly recommend you NOT try tgFX anymore. While some basic functionality may still work properly, there are know issues between the final release of tgFX almost a year ago, and FW440.14. Work on tgFX has been terminated.

    Good luck – let us know how you make out.

    May 14, 2015 at 2:32 am #7705
    JulianRendell
    Member

    I’m seeing the same problems- really good description HCamp!

    Here’s a photo of the results (stopped as soon as I heard it cutting through the clamping wood): messed up arcs

    https://www.dropbox.com/s/uniruk76xcqhowx/Messed%20up%20arcs.jpeg?dl=0

    And the G-Code generated by CamBam that caused this:

    https://www.dropbox.com/s/sc31kq7v5tzy3vv/slingshot-middle.Part1%20%5B3DSurface1%5D.nc?dl=0

    To be clear- the circles carved are not supposed to be there!

    I’m on the latest firmware, and checked $CT; it’s set to the recommended default.

    I’m switching to use line segments and not arcs; fingers crossed that will work with ChilliPepper on a Raspberry Pi…

    Really hoping TinyG gets these bugs ironed out soon- I love the potential, but it’s driving me nuts!

    May 14, 2015 at 7:01 am #7708
    cmcgrath5035
    Moderator

    Julian
    We never heard back from HCamp, so have no update on if his resetting tinyG to defaults and entering correct parameter values helped.
    Note that the value of $ct in his parameter list was just an indicator of something very wrong. It might help if you added your full parameter dump to the Dropbox record.

    I downloaded your Gcode file. Way to big for any manual review and detection of issues, but will be useful to debug none the less.

    I first loaded your Gcode into the CAM generator/simulator I use, which is a backend to CAD program QCAD. That simulation displayed some bizarre results, including numerous large circles and small, including the one shown in your picture. Here is a screenshot :

    I then loaded the Gcode into my CP (Linux, Chrome) It took quite a while for the simulation to render, but it finally did and appears to be correct, no large circles. I will note that the CP browser seems seriously loaded down by the Gcode file – any attempt to zoom or make a 3D perspective change trashed the entire browser window. That might be a 3Dviewer issue, or ??

    So, nothing definitive in this so far. I could guess that tinyG is making the same error that my QCAD simulator is making, but have no idea why that would be.

    • This reply was modified 9 years, 4 months ago by cmcgrath5035.
    May 14, 2015 at 10:24 pm #7710
    alden
    Member

    Thank you for the report. We are still doing some work on arcs. Thank you for your patience – we should have this resolved soon.

    July 8, 2015 at 8:51 pm #7954
    matterest
    Member

    my tinyg has never worked right it starts to follow the gcode but then veers off and crashes. help would be appreciated.
    thanks,
    matt

    July 9, 2015 at 9:34 am #7960
    cmcgrath5035
    Moderator

    I suggest start a new thread, we have no context for what you issue might be.
    Start with a description of your machine and a parameter list

    July 9, 2015 at 10:23 am #7962
    djdaudio
    Member

    Not sure if a similar problem,

    But when I use Sheetcam to create my gcode, if I use outside or no contour, it works fine on the tinyg. The moment I use inside contour, it no longer follows arcs as normal and will instead use a series of very course straight lines, or skip circles all together.

    I will try to refine the problem, and start a new thread with it.

    This is with Vr8.

  • Author
    Posts
Viewing 15 posts - 1 through 15 (of 23 total)
1 2
  • You must be logged in to reply to this topic.