Z axis problem

Home › Forums › TinyG › TinyG Support › Z axis problem

Tagged: 

Viewing 15 posts - 1 through 15 (of 36 total)
1 2 3
  • Author
    Posts
  • March 21, 2014 at 12:35 am #5649
    sparkcrafter
    Member

    I’m having a difficult time getting a firmware/settings combination that will work on my setup (a heavier duty shapeoko-type cnc router). The original firmware that shipped with the v8 TinyG (380.05?) was working ok, but then I made the mistake of trying the new tgfx feature to upgrade the firmware. It updated it to the current master of 380.08 and things haven’t worked right since. I would try going back to the original firmware, but I haven’t been able to locate it on the download site. After fighting multiple issues on 380.08, I decided to give the latest edge firmware a try. It solved several of the issues I was having, but I’m currently at a standstill trying to root cause an issue in which the z-axis will suddenly shift by several mm when routing a relief (no problems with simple cuts). It’s as if there is a buffer overflow issue when routing reliefs.

    I’ve tried using tgfx, jcnc, and coolterm with XON and with CTS (adjusting both TinyG and the SW accordingly).

    Any suggestions on what else I can try? Is there a way to get a firmware that’s more recent than 412.01 to test with?

    Here are some of the details:

    1) For a given relief, the problem occurs at the same spot in the gcode each time. But changing parameters such as $ct can change where the problem occurs. I changed $ct to 0.1 and it eliminated the problem on one relief, but the problem occurs in other reliefs.
    2) I’ve done all the recommendations to test for a z-axis mechanical problem, and the problem does not appear to be mechanical. (e.g. changing $mi, adjusting current, changed to NEMA23 for Z axis, changed velocities and jerk values)
    3) Here’s a snippet of gcode that was consistently failing until I changed the $ct value.

    (Test)
    (Material Size) (X=50.000, Y=80.000, Z=3.000)
    G90G80G21G49
    (Tool Number:1) (0.063 inches dia. ball nose)
    G0Z2.0000
    M3 S25000
    G0 X0.0000 Y0.0050 Z2.0000
    G1 Z0.0000 F508
    G1 X50.0000 F1270
    Y26.4150 Z0.0000
    X28.3145 Z-1.1291
    X27.6120 Z-1.2767
    X27.6101 Z-1.2771
    X27.3106 Z-1.2501
    X25.6332
    X25.4408 Z-1.2727
    X25.2279 Z-1.2502
    X23.2113 Z-1.2563
    X22.5751 Z-1.1268
    X21.5795 Z-0.9814
    X20.5580 Z-0.9099
    X19.2067 Z-0.9108
    X18.1675 Z-0.9569
    X17.1569 Z-1.0728
    X16.1800 Z-1.2774
    X15.2104 Z-1.5775
    X14.4949 Z-1.8794
    G0 Z2.0000
    G0 Y0.0000
    G0Z2.0000
    G0X0.0000Y0.0000
    M5
    M30

    5) Here are my current settings, although I’ve tried a wide variety of other settings:

    [ct] chordal tolerance 0.100 mm
    [fb] firmware build 412.01
    [fv] firmware version 0.97
    [hp] hardware platform 1.00
    [hv] hardware version 8.00
    [id] TinyG ID 1H4973-HYT
    [ja] junction acceleration 20000 mm
    [ct] chordal tolerance 0.100 mm
    [sl] soft limit enable 0
    [st] switch type 0 [0=NO,1=NC]
    [mt] motor idle timeout 1000.00 Sec
    [ej] enable json mode 0 [0=text,1=JSON]
    [jv] json verbosity 3 [0=silent,1=footer,2=messages,3=configs,4=linenum,5=verbose]
    [js] json serialize style 1 [0=relaxed,1=strict]
    [tv] text verbosity 0 [0=silent,1=verbose]
    [qv] queue report verbosity 0 [0=off,1=single,2=triple]
    [sv] status report verbosity 1 [0=off,1=filtered,2=verbose]
    [si] status interval 1000 ms
    [ec] expand LF to CRLF on TX 0 [0=off,1=on]
    [ee] enable echo 0 [0=off,1=on]
    [ex] enable flow control 1 [0=off,1=XON/XOFF, 2=RTS/CTS]
    [baud] USB baud rate 5 [1=9600,2=19200,3=38400,4=57600,5=115200,6=230400]
    [net] network mode 0 [0=master]
    [gpl] default gcode plane 0 [0=G17,1=G18,2=G19]
    [gun] default gcode units mode 1 [0=G20,1=G21]
    [gco] default gcode coord system 1 [1-6 (G54-G59)]
    [gpa] default gcode path control 2 [0=G61,1=G61.1,2=G64]
    [gdi] default gcode distance mode 0 [0=G90,1=G91]
    [1ma] m1 map to axis 0 [0=X,1=Y,2=Z…]
    [1sa] m1 step angle 1.800 deg
    [1tr] m1 travel per revolution 39.8500 mm
    [1mi] m1 microsteps 8 [1,2,4,8]
    [1po] m1 polarity 1 [0=normal,1=reverse]
    [1pm] m1 power management 0 [0=remain powered,1=power down when idle]
    [1mp] m1 motor power level 1.000 [0.000=minimum, 1.000=maximum]
    [2ma] m2 map to axis 1 [0=X,1=Y,2=Z…]
    [2sa] m2 step angle 1.800 deg
    [2tr] m2 travel per revolution 39.8500 mm
    [2mi] m2 microsteps 8 [1,2,4,8]
    [2po] m2 polarity 0 [0=normal,1=reverse]
    [2pm] m2 power management 0 [0=remain powered,1=power down when idle]
    [2mp] m2 motor power level 1.000 [0.000=minimum, 1.000=maximum]
    [3ma] m3 map to axis 1 [0=X,1=Y,2=Z…]
    [3sa] m3 step angle 1.800 deg
    [3tr] m3 travel per revolution 39.8500 mm
    [3mi] m3 microsteps 8 [1,2,4,8]
    [3po] m3 polarity 1 [0=normal,1=reverse]
    [3pm] m3 power management 0 [0=remain powered,1=power down when idle]
    [3mp] m3 motor power level 1.000 [0.000=minimum, 1.000=maximum]
    [4ma] m4 map to axis 2 [0=X,1=Y,2=Z…]
    [4sa] m4 step angle 1.800 deg
    [4tr] m4 travel per revolution 1.0000 mm
    [4mi] m4 microsteps 4 [1,2,4,8]
    [4po] m4 polarity 1 [0=normal,1=reverse]
    [4pm] m4 power management 0 [0=remain powered,1=power down when idle]
    [4mp] m4 motor power level 1.000 [0.000=minimum, 1.000=maximum]
    [xam] x axis mode 1 [standard]
    [xvm] x velocity maximum 2000.000 mm/min
    [xfr] x feedrate maximum 2000.000 mm/min
    [xtn] x travel minimum 0.000 mm
    [xtm] x travel maximum 450.000 mm
    [xjm] x jerk maximum 5000 mm/min^3 * 1 million
    [xjh] x jerk homing 20000 mm/min^3 * 1 million
    [xjd] x junction deviation 0.0500 mm (larger is faster)
    [xsn] x switch min 3 [0=off,1=homing,2=limit,3=limit+homing]
    [xsx] x switch max 2 [0=off,1=homing,2=limit,3=limit+homing]
    [xsv] x search velocity 3000.000 mm/min
    [xlv] x latch velocity 300.000 mm/min
    [xlb] x latch backoff 10.000 mm
    [xzb] x zero backoff 125.000 mm
    [yam] y axis mode 1 [standard]
    [yvm] y velocity maximum 2000.000 mm/min
    [yfr] y feedrate maximum 2000.000 mm/min
    [ytn] y travel minimum 0.000 mm
    [ytm] y travel maximum 800.000 mm
    [yjm] y jerk maximum 5000 mm/min^3 * 1 million
    [yjh] y jerk homing 20000 mm/min^3 * 1 million
    [yjd] y junction deviation 0.0500 mm (larger is faster)
    [ysn] y switch min 3 [0=off,1=homing,2=limit,3=limit+homing]
    [ysx] y switch max 2 [0=off,1=homing,2=limit,3=limit+homing]
    [ysv] y search velocity 3000.000 mm/min
    [ylv] y latch velocity 300.000 mm/min
    [ylb] y latch backoff 10.000 mm
    [yzb] y zero backoff 272.000 mm
    [zam] z axis mode 1 [standard]
    [zvm] z velocity maximum 200.000 mm/min
    [zfr] z feedrate maximum 200.000 mm/min
    [ztn] z travel minimum 0.000 mm
    [ztm] z travel maximum 75.000 mm
    [zjm] z jerk maximum 10 mm/min^3 * 1 million
    [zjh] z jerk homing 20 mm/min^3 * 1 million
    [zjd] z junction deviation 0.0500 mm (larger is faster)
    [zsn] z switch min 0 [0=off,1=homing,2=limit,3=limit+homing]
    [zsx] z switch max 1 [0=off,1=homing,2=limit,3=limit+homing]
    [zsv] z search velocity 75.000 mm/min
    [zlv] z latch velocity 75.000 mm/min
    [zlb] z latch backoff 2.000 mm
    [zzb] z zero backoff 2.000 mm

    March 21, 2014 at 10:51 pm #5650
    grim
    Member

    I was recently having a similar problem, but with fw380.08. When I flashed 412.01 it went away. I described what happened in this thread:
    https://www.synthetos.com/topics/new-beta-build/page/5/#post-5626
    That’s strange that you had the problem appear with 412.01 while that’s what fixed mine. What OS are you running?

    March 21, 2014 at 11:36 pm #5651
    sparkcrafter
    Member

    I’m using Windows 8 on a newer HP laptop with i5 processor. It seems like a buffer overflow or timing type issue to me. With the gcode I listed earlier I could get the problem to go away by deleting gcodes from early in the listing or toward the end of the listing. So, any change that altered the timing of that section of gcode would fix the problem. The gcode sequence I listed was cut down from a 10,000 line gcode sequence. This section started about 5,000 lines into the original listing. So there was something special about this particular gcode sequence that messed up the buffers or algorithms. Since I was able to fix the problem on some reliefs by changing tinyg settings, I’m not surprised you saw the problem go away when you changed firmware as that would change some of the timing variables. Until there is a firmware fix I think this issue will continue to pop up randomly depending on firmware version/settings and gcode stream.

    March 22, 2014 at 3:01 pm #5652
    Riley
    Keymaster

    Sparkcrafter,

    Thanks for reporting this issue. We are trying to reproduce your results with the gcode above. I am sorry this is happening. Please know we are working on it!

    Can you put your config in json? Meaning do this

    {“1″:””}
    {“2″:””}
    {“3″:””}
    {“4″:””}
    {“a”:””}
    {“b”:””}
    {“c”:””}
    {“x”:””}
    {“y”:””}
    {“z”:””}
    {“sys”:””}

    and paste all that back to me. I am going to create a config file and load it via tgfx so we are 100% sure we using the same config. Also just make sure that the config you send still causes the error to occur when sending the small snippet of gcode above.

    ril3y

    • This reply was modified 10 years, 6 months ago by Riley.
    March 22, 2014 at 3:41 pm #5654
    alden
    Member

    I’m taking a look at this as well. I’ve opened an issue on the github to track this: https://github.com/synthetos/TinyG/issues/76

    Q: When you say “the gcode was failing” what were the symptoms?

    Q: I’m also very suspicious of the root cause as you are not using arcs in the Gcode snippet yet $ct causes a change in behavior. CT is only used in arc generation. It sounds like there might be some problem in the flash or config integrity. Are there any other symptoms you have found?

    March 23, 2014 at 3:00 am #5664
    sparkcrafter
    Member

    Thanks for the quick responses Alden/Riley.

    Here are some updates on this issue:

    1) Alden: to answer your question, what I mean be “the gcode failing” is that the z-axis suddenly moves to a different offset so that what was 0,0,0 would now be 0,0,-2.5 The effect is that the spindle moves up about 2.5mm and continues on. So, after the gcode finishes and returns to 0,0,2 the spindle is about 4.5mm above the work surface instead of the expected 2mm safe clearance height.

    2) Riley: here’s the json output you requested. Some of these values are quite low or quite high compared to the wiki recommendations. The issue occurred using the recommended values and I’ve been tweaking every value I can in order to better understand if anything impacts the behavior. Now that I have a consistent failure, I’m capturing the current settings as-is just to keep things repeatable.

    {“r”:{“1”:{“ma”:0,”sa”:1.800,”tr”:39.8500,”mi”:8,”po”:1,”pm”:0,”mp”:1.000}},”f”:[1,0,9,1478]}
    {“r”:{“2”:{“ma”:1,”sa”:1.800,”tr”:39.8500,”mi”:8,”po”:0,”pm”:0,”mp”:1.000}},”f”:[1,0,9,5727]}
    {“r”:{“3”:{“ma”:1,”sa”:1.800,”tr”:39.8500,”mi”:8,”po”:1,”pm”:0,”mp”:1.000}},”f”:[1,0,9,2742]}
    {“r”:{“4”:{“ma”:2,”sa”:1.800,”tr”:1.0000,”mi”:1,”po”:1,”pm”:1,”mp”:1.000}},”f”:[1,0,9,9691]}
    {“r”:{“a”:{“am”:3,”vm”:172800,”fr”:172800,”tn”:-1,”tm”:-1,”jm”:5760,”jh”:5760,”jd”:0.0500,”ra”:0.199,”sn”:1,”sx”:0,”sv”:600,”lv”:100,”lb”:5.000,”zb”:2.000}},”f”:[1,0,9,1511]}
    {“r”:{“b”:{“am”:0,”vm”:3600,”fr”:3600,”tn”:-1,”tm”:-1,”jm”:20,”jd”:0,”ra”:1.000}},”f”:[1,0,9,8685]}
    {“r”:{“c”:{“am”:0,”vm”:3600,”fr”:3600,”tn”:-1,”tm”:-1,”jm”:20,”tn”:-1,”jd”:0,”ra”:1.000}},”f”:[1,0,9,382]}
    {“r”:{“x”:{“am”:1,”vm”:500,”fr”:2000,”tn”:0,”tm”:450,”jm”:5000,”jh”:20000,”jd”:0.0100,”sn”:3,”sx”:2,”sv”:3000,”lv”:300,”lb”:10.000,”zb”:323.000}},”f”:[1,0,9,6446]}
    {“r”:{“y”:{“am”:1,”vm”:500,”fr”:2000,”tn”:0,”tm”:800,”jm”:5000,”jh”:20000,”jd”:0.0100,”sn”:3,”sx”:2,”sv”:3000,”lv”:300,”lb”:10.000,”zb”:220.500}},”f”:[1,0,9,4139]}
    {“r”:{“z”:{“am”:1,”vm”:200,”fr”:200,”tn”:0,”tm”:75,”jm”:10,”jh”:20,”jd”:0.0100,”sn”:0,”sx”:1,”sv”:400,”lv”:100,”lb”:2.000,”zb”:1.000}},”f”:[1,0,9,7]}
    {“r”:{“sys”:{“fb”:412.01,”fv”:0.970,”hp”:1,”hv”:8,”id”:”1H4973-HYT”,”ja”:200000,”ct”:0.0010,”sl”:0,”st”:1,”mt”:1000.00,”ej”:1,”jv”:3,”js”:1,”tv”:0,”qv”:0,”sv”:1,”si”:1000,”ec”:0,”ee”:0,”ex”:1,”baud”:5,””:0,”gpl”:0,”gun”:1,”gco”:1,”gpa”:2,”gdi”:0}},”f”:[1,0,11,3302]}

    3) The snippet I originally listed no longer shows the problem because some setting I changed moved the problem. However, the full gcode listing still showed the problem, it was just shifted to a different part of the relief. So, this time I kept all settings the same as I cut down the full code to isolate the part that was failing. The new snippet is listed below. There doesn’t appear to be anything unique about this snippet, but I can repeatedly get the gcode to fail (offset z axis) by just running the snippet now. In fact I tried running the snippet from an old pentium XP laptop as well and the same failure occurred. Turning off power to the tinyg and restarting made no difference.

    4) Here’s what happens when the full gcode is run: The spindle starts at 0,0 and sweeps the X-axis back and forth from 0 to 50mm while it increments Y. For a given set of tinyg settings, the failure seems to always occur at the same Y value (which is why I’ve been able to isolate the snippet where the failure occurs), but if something changes in the configuration the Y location of the failure may change. For the X axis, the failure seems to always occur when X is decreasing and the value of X is about 15-20mm. As the X-axis moves toward 0, the spindle suddenly raises off of the work surface a few mm but otherwise continues on as normal.

    5) Because the location of the issue moves around, I don’t know if you’ll be able to re-create it with the snippet or not. If you need the full gcode listing, just let me know how to get it to you.

    Here’s the new snippet:

    (RABBIT)
    (Material Size) (X=50.000, Y=80.000, Z=3.000)
    G90G80G21G49
    (Tool Number:1) (0.063 inches dia. ball nose)
    G0Z2.0000
    M3 S25000
    G0 X0.0000 Y0.0050 Z2.0000
    G1 X50.0000 F1270

    X50.0000
    Y70.4950 Z-3.0001
    X41.4543
    X41.4445 Z-2.9630
    X41.3462 Z-2.7392
    X41.1538 Z-2.5192
    X40.8997 Z-2.3649
    X40.2524 Z-2.1448
    X39.5916 Z-1.9842
    X38.6410 Z-1.8305
    X37.7059 Z-1.7382
    X37.0685 Z-1.7099
    X35.7917 Z-1.7568
    X35.1233 Z-1.8064
    X33.8555 Z-2.0655
    X33.5304 Z-2.1475
    X33.3406 Z-2.1903
    X32.7767 Z-2.4060
    X32.7743 Z-2.4064
    X32.3565 Z-2.3703
    X32.0144 Z-2.3756
    X31.3308 Z-2.4528
    X30.9967 Z-2.5216
    X30.6646 Z-2.6242
    X30.3437 Z-2.8173
    X30.1884 Z-2.9967
    X30.1845 Z-3.0001
    X20.7875 Z-2.9995
    X20.7858 Z-2.9988
    X20.6700 Z-2.8529
    X20.4777 Z-2.7141
    X20.1713 Z-2.5987
    X19.8357 Z-2.5130
    X19.1605 Z-2.3967
    X18.3062 Z-2.3685
    X18.1502 Z-2.4033
    X18.1483 Z-2.4026
    X17.6741 Z-2.2195
    X16.8486 Z-1.9886
    X16.1831 Z-1.8643
    X14.8809 Z-1.7256
    X14.2701 Z-1.7060
    X13.5774 Z-1.7086
    X12.5567 Z-1.7910
    X11.2472 Z-1.9902
    X10.8224 Z-2.0914
    X10.3240 Z-2.2195
    X9.9958 Z-2.3447
    X9.6709 Z-2.5462
    X9.5459 Z-2.6918
    X9.4113 Z-2.9945
    X9.4079 Z-2.9967
    X0.0000 Z-3.0001

    G0 Z2.0000

    6) Let me know if you need me to try any experiments to help narrow down the problem. Since this is a new router setup, I keep expecting the issue to be mechanical such as the z-axis driver over-heating or the stepper motor missing steps, but when I watch the z-axis just raise off the work surface for no reason in a repeatable location I don’t know how this could be due to the mechanics. Thanks again for your help!

    March 23, 2014 at 9:58 am #5665
    alden
    Member

    When you say Z moves to a different offset is it actually observable as an offset – any of G92, G54 – G59, or is it an “apparent” offset (nonsense word. I just made it up). If I have this correct the observed behavior is that Z just raises up 2.5mm. Can you tell me where in the file this is? I have added line numbers to the 2 files and provided dropbox links here:

    https://www.dropbox.com/s/bxyqrah3lqc872m/sparkcrafter_Z_test_1_NUMBERED.gcode
    https://www.dropbox.com/s/uoct9sh7dhkwfhk/sparkcrafter_Z_test_2_NUMBERED.gcode

    You can ignore the semicolons in the first file – these are commented out lines. Semi is widely used in the 3DP community for comment lines, so TinyG supports it.

    Also, by looking at your settings should I assume the following:
    – You have modded the Z axis from the stock 1.25mm threaded rod?
    – Your X/Y wheels are different than mine (I use 36.54 travel per rev for X and Y)

    Lastly, your X jerk is extremely low. Can you try running the snippet with X set higher, perhaps 100 or 500 and see if you get the same results? I have a theory.

    • This reply was modified 10 years, 6 months ago by alden.
    March 23, 2014 at 10:57 am #5667
    alden
    Member

    I equipped the Shapeoko with a ghetto DRO:

    I am not able to reproduce the issue. Z starts at zero, goes to 2.00 on the first lift, then drops over he Y move. Goes up and down a little during the plunge, then returns to 2.00 at the end. (In reality the signs are reversed due to the caliper setup, and the DRO is not accurate to 0.01 mm, but it’s code and it’s repeatable).

    I am beginning to suspect a flash or eeprom problem. Particularly as you can change a value that has nothing to do with the Gcode being received ($ct) and it changes the behavior. A couple of things to try:

    – Can you re-flash the board with the latest edge build – build 412.02 and try again?

    – Also, if you can post the entire Gcode file somewhere I’ll run it maybe I’ll see the issue in some other part of the file.

    March 23, 2014 at 4:02 pm #5668
    sparkcrafter
    Member

    Alden, here’s some feedback on your questions:

    1) I don’t see any change to G92,G54-59. They are all zeroes except G55 x and y which are both 75. Every time I run the snippet I have to execute a g0z-2.5 followed by a g28.3 g0 to re-position the spindle at the correct height.

    2) The router is not a Shapeoko, I referred to it as a “heavier duty shapeoko-like cnc router” just to give you an idea of the type of machine it is. The machine is scratch built using v-slot aluminum extrusion and 1/4″ aluminum plates. I used 6mm diameter x 1mm TPI leadscrew for the z-axis.

    3) I tried changing $xjm from 5000x1million to 100x1million. That shifted the offset issue back to the original failing part of the relief. In other words the first snippet I sent would fail and the second snippet I sent would now work fine. So, adjusting xjm is certainly having an effect, but doesn’t fix the overall issue. I noticed that the “x1million” was added at some point and I had to go in and change some of the values to get the system working again. Could the issue be that there is an issue with the “x1million” change not being fully converted in all locations of the firmware or with the recommended settings?

    4) Don’t fixate on the $ct data point. It may be that something else was changed (e.g. $xjm) along with $ct.

    5) In your numbered gcode, the failure shows up as the spindle lifting off of the work surface sometime around line N55 (plus or minus). However, I can effect whether or not it will fail near N55 by deleting or adding back in gcode that is in the N20’s area. So, for instance, if I comment out the code in the N20-N30 area then the gcode runs fine. It’s as if a buffer is overflowing when trying to run the whole sequence.

    6) Where can I find 412.02? I only see 412.01 on your download page.

    7) Unrelated to this problem, $st always returns a “0” (NO). I use NC switches and they work when I set $st=1, however the report always shows $st=0.

    8) Here’s a link to the complete listing that I’m working on:

    https://www.dropbox.com/s/qjkr8a068gi1q5i/RABBIT%20test%204%20FINISH%20ONLY.TAP

    9) Here’s a second relief that also fails:

    https://www.dropbox.com/s/4iq6d3d32qmj086/obstacle%20course%20sign%20-%20FINE.TAP

    I’ve done a bunch more testing narrowing down what works and doesn’t work by commenting out lines of gcode, but don’t want to flood you with info if this is just an eeprom issue. Here are a few examples:

    =====================================
    This Snippet Fails Sporadically, and when it fails the offset is off by only about 1mm:

    (RABBIT)
    (Material Size) (X=50.000, Y=80.000, Z=3.000)
    G90G80G21G49
    (Tool Number:1) (0.063 inches dia. ball nose)
    G0Z2.0000
    M3 S25000
    G0 X0.0000 Y0.0050 Z2.0000
    G1 X50.0000 F1270

    X50.0000
    Y70.4950 Z-3.0001

    X35.7917 Z-1.7568
    X35.1233 Z-1.8064
    X33.8555 Z-2.0655
    X33.5304 Z-2.1475
    X33.3406 Z-2.1903
    X32.7767 Z-2.4060
    X32.7743 Z-2.4064
    X32.3565 Z-2.3703
    X32.0144 Z-2.3756
    X31.3308 Z-2.4528
    X30.9967 Z-2.5216
    X30.6646 Z-2.6242
    X30.3437 Z-2.8173
    X30.1884 Z-2.9967
    X30.1845 Z-3.0001
    X20.7875 Z-2.9995
    X20.7858 Z-2.9988
    X20.6700 Z-2.8529
    X20.4777 Z-2.7141
    X20.1713 Z-2.5987
    X19.8357 Z-2.5130
    X19.1605 Z-2.3967
    X18.3062 Z-2.3685
    X18.1502 Z-2.4033
    X18.1483 Z-2.4026
    X17.6741 Z-2.2195
    X16.8486 Z-1.9886
    X16.1831 Z-1.8643
    X14.8809 Z-1.7256
    X14.2701 Z-1.7060
    X13.5774 Z-1.7086
    X12.5567 Z-1.7910
    X11.2472 Z-1.9902

    X10.8224 Z-2.0914
    X10.3240 Z-2.2195
    ;X9.9958 Z-2.3447
    ;X9.6709 Z-2.5462

    ;X9.5459 Z-2.6918
    ;X9.4113 Z-2.9945
    ;X9.4079 Z-2.9967
    ;X0.0000 Z-3.0001

    G0 Z2.0000

    G0X0.0000Y0.0000
    M5
    M30

    ========================================

    This Snippet works:

    (RABBIT)
    (Material Size) (X=50.000, Y=80.000, Z=3.000)
    G90G80G21G49
    (Tool Number:1) (0.063 inches dia. ball nose)
    G0Z2.0000
    M3 S25000
    G0 X0.0000 Y0.0050 Z2.0000
    G1 X50.0000 F1270

    X50.0000
    Y70.4950 Z-3.0001

    X35.7917 Z-1.7568
    X35.1233 Z-1.8064
    X33.8555 Z-2.0655
    X33.5304 Z-2.1475
    X33.3406 Z-2.1903
    X32.7767 Z-2.4060
    X32.7743 Z-2.4064
    X32.3565 Z-2.3703
    X32.0144 Z-2.3756
    X31.3308 Z-2.4528
    X30.9967 Z-2.5216
    X30.6646 Z-2.6242
    X30.3437 Z-2.8173
    X30.1884 Z-2.9967
    X30.1845 Z-3.0001
    X20.7875 Z-2.9995
    X20.7858 Z-2.9988
    X20.6700 Z-2.8529
    X20.4777 Z-2.7141
    X20.1713 Z-2.5987
    X19.8357 Z-2.5130
    X19.1605 Z-2.3967
    X18.3062 Z-2.3685
    X18.1502 Z-2.4033
    X18.1483 Z-2.4026
    X17.6741 Z-2.2195
    X16.8486 Z-1.9886
    X16.1831 Z-1.8643
    X14.8809 Z-1.7256
    X14.2701 Z-1.7060
    X13.5774 Z-1.7086
    X12.5567 Z-1.7910
    X11.2472 Z-1.9902

    ;X10.8224 Z-2.0914
    ;X10.3240 Z-2.2195
    ;X9.9958 Z-2.3447
    ;X9.6709 Z-2.5462

    ;X9.5459 Z-2.6918
    ;X9.4113 Z-2.9945
    ;X9.4079 Z-2.9967
    ;X0.0000 Z-3.0001

    G0 Z2.0000

    G0X0.0000Y0.0000
    M5
    M30

    ==============================================

    This Snippet also works:

    (RABBIT)
    (Material Size) (X=50.000, Y=80.000, Z=3.000)
    G90G80G21G49
    (Tool Number:1) (0.063 inches dia. ball nose)
    G0Z2.0000
    M3 S25000
    G0 X0.0000 Y0.0050 Z2.0000
    G1 X50.0000 F1270

    X50.0000
    Y70.4950 Z-3.0001

    ;X35.7917 Z-1.7568
    ;X35.1233 Z-1.8064
    ;X33.8555 Z-2.0655
    ;X33.5304 Z-2.1475
    ;X33.3406 Z-2.1903
    ;X32.7767 Z-2.4060
    ;X32.7743 Z-2.4064
    ;X32.3565 Z-2.3703
    ;X32.0144 Z-2.3756
    ;X31.3308 Z-2.4528
    ;X30.9967 Z-2.5216
    ;X30.6646 Z-2.6242
    ;X30.3437 Z-2.8173
    ;X30.1884 Z-2.9967
    X30.1845 Z-3.0001
    X20.7875 Z-2.9995
    X20.7858 Z-2.9988
    X20.6700 Z-2.8529
    X20.4777 Z-2.7141
    X20.1713 Z-2.5987
    X19.8357 Z-2.5130
    X19.1605 Z-2.3967
    X18.3062 Z-2.3685
    X18.1502 Z-2.4033
    X18.1483 Z-2.4026
    X17.6741 Z-2.2195
    X16.8486 Z-1.9886
    X16.1831 Z-1.8643
    X14.8809 Z-1.7256
    X14.2701 Z-1.7060
    X13.5774 Z-1.7086
    X12.5567 Z-1.7910
    X11.2472 Z-1.9902
    X10.8224 Z-2.0914
    X10.3240 Z-2.2195
    X9.9958 Z-2.3447
    X9.6709 Z-2.5462
    X9.5459 Z-2.6918
    X9.4113 Z-2.9945
    X9.4079 Z-2.9967
    X0.0000 Z-3.0001

    G0 Z2.0000

    G0X0.0000Y0.0000
    M5
    M30

    March 24, 2014 at 7:55 pm #5669
    alden
    Member

    I ran the entire rabbit and the Z was off by 0.22 mm. You were seeing a sudden jump of 2.5mm?

    I also think some of the 0.22 might have been due to the lousy way I connected the “DRO” to the machine (silver tape). I am going to try to fashion a better anchor and see if I can get that number down – or confirm that it’s a legitimate error. I was using the settings you provided from the earlier post, not the JSON settings. I may try them as well. More later.

    March 24, 2014 at 9:59 pm #5670
    sparkcrafter
    Member

    Yes, 2.5mm. It is quite noticeable when it happens. However, i have also noticed smaller (eg 0.2mm offsets) on other reliefs. I had assumed the small offsets were sloppiness in my z-axis, but now you have me wondering if they are related issues. I’ll be interested in hearing if you’re able to get any offset to show up.

    Is there a way for me to ensure the firmware/eeprom contents are in a known good state? Seems like that’s one variable we should try to eliminate if possible.

    For background info, here’s the sequence of events as best as I can recall:

    1) I was using the firmware that shipped on the board. I believe this was 380.05, but not positive. This seemed to work great for 2D cuts, but i don’t recall if i had done any reliefs with that setup.

    2) i was testing out various methods of sending gcode to tinyg and really wanted a program with a DRO. This, of course, led me to try tgfx which had considerable issues such as slowing down to a crawl on long jobs and the screen didn’t display right on my windows system. So I decided to try the latest version i could find to see if it would be at all workable. This version has the embedded “update firmware” feature and it indicated that my firmware was out of date and asked me if i wanted to update to the latest, which was 380.08. I selected that option and tgfx updated the firmware. At that point things went downhill. My 2D cuts were no longer accurate. It would handle stepdown cuts of a single hole accurately, but from hole to hole the locations would be off in x and y. After trying many different settings to try to get the system to work as it had, i gave up on 380.08 and wanted to go back to 380.05 since that was a known good setup. However, 380.05 is not on your download page, so i finally decided i had nothing to lose by going to 412.01.

    3) i followed the wiki directions for flashing the firmware with avrdude and was successful updating to 412.01. This fixed the issues with 2d cutting and everything appeared to work great until i tried to do reliefs, that’s when this issue appeared. I haven’t been able to get a relief to successfully cut yet. Some reliefs have different offset issues, but i’ve focused on this particular one because it was a big offset and it was repeatable.

    4) as mentioned in an earlier post, somewhere in the firmware updates i ran across the issue where some of the values changed by a factor of “x1million” which brought things to a stop until i adjusted the values to compensate.

    5) by the way, is $MS still supported? I can view the other hidden variables, but not that one.

    March 25, 2014 at 3:08 am #5671
    alden
    Member

    Thanks for the update. Some questions and answers.

    – Have you tried running the reliefs under coolterm? I believe you said you had – and had the same results – but I wanted to be sure. This may help isolate to cause. The setup I used was Coolterm on OSX. I will have to check the version of coolterm and should probably re-run with the latest just to be sure. Settings 115,200, XON/.XOFF flow control. I was capturing a file while sending the RABBIT file.

    – Is the problem repeatable when running the entire RABBIT file, and if so do you know the line number (even approximate)? I used the first set of settings you posted, and should try again on the second set. I’m game for a new set if that reveals the problem. Here’s a link to a version of rabbit with line numbers.
    https://www.dropbox.com/s/osd97sa5b33c7eh/RABBIT%20test%204%20FINISH%20ONLY_NUMBERED.gcode

    – I will try running the obstacle course, which appears to be a longer file.

    – The “x 1 million” should not have affected you. We had requests to make the jerk numbers more manageable – it was too easy to get the number of zeros incorrect. In order to remain backwards compatible with old configs the system will still take a jerk value of over 1 million as the literal value, but if it sees a value of less than 1 million it assumes it needs to be multiplied by 1 million. I wonder what happened in your case and if there’s a bug somewhere about that.

    – Yes, $MS was removed. You can really mess up the system by playing with the time budget. This was changed to a compile-time variable. It also allowed for some more efficient code as the value became a constant.

    March 25, 2014 at 9:38 am #5672
    sparkcrafter
    Member

    Yes, i’m only using coolterm now. I’ve also tried jcnc with the same result as well as an old pentium laptop running xp. I’m using xon/xoff at 115,200.

    Keep in mind that this problem is very timing sensitive (i.e. Removing gcode from the beginning or end of the snippet can get it to run) so any changes to the file like adding line numbers or capturing a file while sending could mask the problem. For example, if tinyg has to parse the line to remove or skip over the line numbers this will give the execution unit more time between gcode lines which could solve the problem. I’ll try running your gcode with the added line numbers later today and see if there are any changes in behavior. I would suggest you try running without line numbers and without capturing a file just to ensure we’re running the same setup.

    The problem is repeatable with the whole rabbit file. That’s how i was able to systematically cut the file down until i found the offending section. So, the line numbers would be the same section as seen in the snippet. However, keep in mind that where it fails in the file will change based on settings or perhaps other factors that change the timings.

    March 25, 2014 at 12:50 pm #5673
    sparkcrafter
    Member

    As a follow-up to try to determine if this is a buffer/timing issue I re-ran the failing snippet, but added a G4P1 delay midway through the code. This fixed the problem. So it seems like there is a buffer overflow or timing type of issue happening. It’s possible that the problem is in the USB/Serial flow, but the problem shows itself on two completely different systems and it doesn’t seem to matter if I use CTS or XON for flow control.

    Depending on the setup, the problem can be sporadic, so be sure to try any test multiple times before concluding whether it worked or not.

    Not sure if it helps narrow down the problem, but it looks like there is a small X offset occurring as well as the Z offset. The X offset is an order of magnitude less than the Z offset, so it only becomes obvious after the error builds up over multiple failures. So, the failing offset is probably an X/Z vector and not just a Z offset.

    Note that I’m using xvm=5000 for these tests just to keep everything the same.

    1) Are there any adjustments you can make in the firmware to change buffer size? Other suggestions on what I can try to help narrow down the issue?

    2) Here is the snippet that works with the delay added in:

    (RABBIT)
    (Material Size) (X=50.000, Y=80.000, Z=3.000)
    G90G80G21G49
    (Tool Number:1) (0.063 inches dia. ball nose)
    G0Z2.0000
    M3 S25000
    G0 X0.0000 Y0.0050 Z2.0000
    G1 X50.0000 F1270

    X50.0000
    Y70.4950 Z-3.0001

    X33.5304 Z-2.1475
    X33.3406 Z-2.1903
    X32.7767 Z-2.4060
    X32.7743 Z-2.4064
    X32.3565 Z-2.3703
    X32.0144 Z-2.3756
    X31.3308 Z-2.4528
    X30.9967 Z-2.5216
    X30.6646 Z-2.6242
    X30.3437 Z-2.8173
    X30.1884 Z-2.9967
    X30.1845 Z-3.0001
    X20.7875 Z-2.9995
    X20.7858 Z-2.9988
    X20.6700 Z-2.8529
    X20.4777 Z-2.7141
    X20.1713 Z-2.5987
    X19.8357 Z-2.5130
    X19.1605 Z-2.3967
    X18.3062 Z-2.3685
    X18.1502 Z-2.4033
    G4 P1
    X18.1483 Z-2.4026
    X17.6741 Z-2.2195
    X16.8486 Z-1.9886
    X16.1831 Z-1.8643
    X14.8809 Z-1.7256
    X14.2701 Z-1.7060
    X13.5774 Z-1.7086
    X12.5567 Z-1.7910
    X11.2472 Z-1.9902
    X10.8224 Z-2.0914
    X10.3240 Z-2.2195
    X9.9958 Z-2.3447
    X9.6709 Z-2.5462
    X9.5459 Z-2.6918
    X9.4113 Z-2.9945
    X9.4079 Z-2.9967
    X0.0000 Z-3.0001

    G0 Z2.0000

    G0X0.0000Y0.0000
    M5
    M30

    March 25, 2014 at 8:09 pm #5675
    sparkcrafter
    Member

    Oops.. Meant to say I was keeping xjm=5000, not xvm.

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