Z axis problem

From the original Synthetos forum (2011–2025)

Started by sparkcrafter on Mar 21, 2014 in TinyG Support. 35 replies, last activity Apr 22, 2014.

sparkcrafter Mar 21, 2014 #

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

grim Mar 22, 2014 #

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?

sparkcrafter Mar 22, 2014 #

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.

RileyStaff Mar 22, 2014 #

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

aldenStaff Mar 22, 2014 #

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?

sparkcrafter Mar 23, 2014 #

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!

aldenStaff Mar 23, 2014 #

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.

aldenStaff Mar 23, 2014 #

I equipped the Shapeoko with a ghetto DRO:
http://www.flickr.com/photos/rileyporter/13354377615/sizes/h/

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.

sparkcrafter Mar 23, 2014 #

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

;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

aldenStaff Mar 24, 2014 #

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.

sparkcrafter Mar 25, 2014 #

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.

aldenStaff Mar 25, 2014 #

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.

sparkcrafter Mar 25, 2014 #

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.

sparkcrafter Mar 25, 2014 #

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

sparkcrafter Mar 26, 2014 #

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

grim Mar 26, 2014 #

Turns out I'm still having this issue as well. I just tried running some new gcode and had the problem again. I had a specific gcode file that was repeatably having this problem while on fw380.08 and it went away when I changed to fw412.01 so I thought it was fixed. Very strange as I've run my machine a number of times now without this issue, but this new gcode was longer than the previous ones. It happened approx. 40 minutes into the program, so testing for it will be pretty time consuming. I don't have the gcode available right now to attach but I can later if you guys want it. I was using tgfx on a Win7 machine to send the file. Also, mine always plunges into the workpiece (negative z). I can try to measure the part tomorrow to try to determine how far it went off, but it's probably pretty close to the same amount as sparkcrafter (~4.5mm), just negative instead of positive. I think it occurred during a rapid +z move, so I guess it's possible that it was case of missed steps. I reduced my z velocity and jerk values after my last go around with this and it seemed to be running pretty good - no funny noises or any obvious missed steps while jogging or running. I've got an acme thread z axis coming this week too so maybe that will help if it is missing steps.

This topic is from the original forum (April 2014). Your reply starts a new discussion linked to it.

Different problem? Ask a new question

Back to TinyG Support or latest activity.