sparkcrafter

Riley,
I assume you’re really interested in feedback from grim, as he is the one currently having an issue. My issues with the buffer issue seem to be ok now with 421.06. I did do a quick of the latest tgfx build you posted to see how it worked, however it crashed after just a few keystrokes so I’ll stick with coolterm for now. Here’s the quick feedback on the tgfx build:
1) “Hardware” is misspelled in two places in the section listing firmware version.
2) The graphical display of position will be great when it is fully working, but not having any ability to zoom limits its usefulness for me. Also, I like to put the 0,0 location of the spindle in the center of the work piece. This results in the graphical drawing extending out past the graphics window. For now, a simple constraint on the drawing to stay within the graphics window would suffice, but the optimum solution for me would be to auto-zoom the window to the extents in the loaded gcode file.
3) To hang tgfx I loaded the rabbit gcode mentioned earlier in this thread into tgfx and clicked on “run”. After running a few minutes I clicked “stop” and then clicked “run” again. There was no response from tinyg when “run” was pressed. I then clicked “reset” and then “run”. At this point tgfx was hung with the circular “wait” icon.

Alden,
Great to hear you may have a fix for this. Can you provide a temporary link to a .hex file for this build so I can test it against my setup?

Alden,
I am on 412.01 and the json settings I sent are current. I have a few more hours to test, then won’t be available to test until next week. Would be great to try a build with buffer size increased if you have a chance to do that.

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

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.

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!