TinyG Inch MM

Home › Forums › TinyG › TinyG Support › TinyG Inch MM

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • January 10, 2016 at 9:14 am #9253
    leversole
    Member

    Some of you may know the struggles I have been thru the past few months…I have an Ox type router with TinyG as the controller…any file with much more than some simple text, will randomly screw up the work piece thru an uncommanded move…I have documented, for example, a straight Y move after an arc will randomly result in an XY angled move (even though the code is for an Y only)! On this file, it is usually after a thirty minute cut, on the cutout part! Very frustrating! I found that I can run this file with a clockwise cut and the problem goes away (same arc on the other side!)! I have other examples where the cutter will decide after three or four depth increments to shortcut and cut across the work! Anyway, I was experimenting yesterday and decided to convert the file to MM. The file in question cut from start to finish?!? What? Anyway, long story short I converted some of the other files that I could never finish without a screw up to MM and so far they have all cut like they should…My advice is, if you are using inches and having random issues, give MM a try…

    Inch MM

    January 10, 2016 at 9:51 am #9254
    cmcgrath5035
    Moderator

    Converting problematic Gcode file to mm is a good experiment to run.
    If stuff runs better when coded in mm, keep running in mm.

    TinyG follows a prescribed set of conformance rules for Arcs that are rather complex, arcs that violate those rules are skipped but execution not halted, which may/may not be the best strategy. TinyG does its real work(converting Gcode to stepper commands)in mm, so inch mode directives need to be converted to mm.

    There is no “iso-like” standard for Gcode compliance, either for generators or interpreters, rather there are several ‘defining documents’ that are often, but not universally implemented.

    It would be helpful to make available to the devs Gcode files that misbehave in inch but work OK in mm as test cases.
    If possible, put your Gcodes in a cloud drive and post a link here.

    March 1, 2016 at 2:51 pm #9384
    Evan F
    Member

    I am having the same issue with a new Tinyg v.8 running build 440.20 fw 0.97.

    see the picture below running the sample gcode files in ChiliPeppr. When running in inches, the inside loop of the “e” and the “p”‘s are deformed. It works fine when i load the mm file. (There is also some backlash in my pen mount consistent across both.)

    logo

    • This reply was modified 8 years, 8 months ago by Evan F.
    March 1, 2016 at 2:59 pm #9386
    Evan F
    Member

    you might need to right click the image to view…

    March 1, 2016 at 10:28 pm #9387
    cmcgrath5035
    Moderator

    To me, I see issues in your mm plots as well.
    Copy your parameters ($$ dump) and Gcode to a cloud drive, post links.

    What sort of machine?

    What OS you run?

    March 2, 2016 at 10:28 am #9388
    Evan F
    Member

    What issues other than backlash do you see in the mm plots?

    The machine is an OX. I am running JSON server on Windows10. I have tested with ChiliPeppr on both windows10 and MacOS with the same result. Browser is Chrome on both.

    Here is a cloud drive with the following:
    tinyg config.txt – ($$dump)
    chilipeppr inch gcode.csv – (chilipeppr logo gcode in inches)
    chilipeppr mm gcode.csv – (chilipeppr logo gcode in mm)
    IMG_0860.JPG – (another picture showing test of inch & mm from Win10 and MacOS)

    Thank you for your help!

    March 3, 2016 at 6:36 am #9389
    cmcgrath5035
    Moderator

    My mm comment – probably what you are attributing to pen mount backlash.

    Very helpful dataset, I like your backlash test line.
    I’m not sure how/why Gcode files are Gcode.csv.
    Did Chilipeppr output them that way?
    Gdrive viewer put .csv into a spreadsheet column, sort of hard to read

    Parameters look OK.
    Vmax on X and Y rather fast (50000, vs 16000) .
    If you had a heavy spindle attached, GO moves could slip if belts were not real tight, but you observations are with very slow G1 or G2 moves, so I don’t think Vmax in play here.

    We have seen, off and on, inch mode Gcode having this issue with fw 440.20 (and earlier).
    Your are the first I have seen someone actually output the CP inch logo to the machine in quite a while, I am a little surprised this basic test tool is failing and it hasn’t appeared frequently. It could be somewhat Ox related – Ox uses larger GT3 pulleys, resulting in $xtr=60mm.
    Most test beds have been using SO2 parameters, where $xtr=40mm.

    So, for now, treat inch mode as buggy.
    Use mm mode.

    Please keep your Gdrive dataset up, I will pass it on to the devs as a test case for getting this resolved.

    March 3, 2016 at 1:09 pm #9390
    Evan F
    Member

    Yes, Chilipeppr downloaded the files as .csv. I’ll convert them to plain text and add them to the cloud drive. I’ll keep the drive up for a few months.

    I do have Vmax set high for now. Just testing to see how fast the machine will move. It is very fast at 50000!

    Thanks for your help. I’ll stick to mm for now.

    March 4, 2016 at 5:12 am #9391
    cmcgrath5035
    Moderator

    I tried reproducing your Gcode as .csv results.

    I run Linux and Chrome.
    When I use the Download/Save G Code option in the TinyGWorkspace widget, it downloads the Gcode to a file named ‘download’ with no extension to my default Chrome downloads directory.

    Were you using Windows or Mac when you downloaded the Gcode file?

    Seems odd that an OS would see Gcode as csv. There are not many “,” in Gcode files.

    Or did you use some other method to extract the Gcode files?

    March 4, 2016 at 10:10 am #9392
    Evan F
    Member

    Chrome on the Mac saves as “download.csv” and Chrome on Windows is saving as “download” with no extension.

    March 4, 2016 at 4:57 pm #9393
    cmcgrath5035
    Moderator

    Good to know.
    We don’t hear from many MAC users.

    March 8, 2016 at 5:36 pm #9416
    mort
    Member

    Hi Leversole,

    Once upon a time I had issues very similair to what you describe, with the cnc sometimes operating properly, and other times the cnc would randomly depart from the g-code, sometimes driving the bit through the work piece, spoil board and into the body, other times cutting through hold downs (throwing the work piece about). destroyed work pieces happened a lot. the g-code would run sometimes, but it would fail approx 50% of the time.

    Anyway, the issue turned out to be electric noise which was appearing on the usb data lines, and on the stepper wiring. the source was the spindle’s VFD controller. My steps to fix the issue were:
    1) change the usb cable for one with good shielding. I had to cut open a few to find one with decent shielding.
    2) change the stepper wiring over to 4 core with good shielding, grounded the shielding at the cotnroller end.
    3) Add mains power filters one the controller power supply, water cooler pump power supply (was also noisy), and VFD.
    4) change the spindle wiring over to very high quality well shielded cable (this had the greatest effect).

    I still have issues with noise appearing on homing switch lines, which randomly triggers them if I have them connected, but I’m planning re-wiring those with shielded cable and adding a filter.

    If you’ve got access to an oscilloscope you might want to set it up on some of your lines and have a look at whats going on.

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