- This topic has 19 replies, 4 voices, and was last updated 10 years, 2 months ago by
.
-
Yesterday I reported that tinyG build 429.04 appears to resolve a long nagging error in drawing tight diagonals, here is the thread
Today, Using tinyG build 429.04 and tgFX build 3259, I set out to do a final run on a long standing engraving project, the end result that looks something like this
The Gcode for this is found here
This code has run well since tinyG build 412.01
The machine config parameters are here:
My first run went bad very quickly – the Gcode machines basically bottom to top. The Outline rounded rectangle ran OK, but the engraving of the text started OK for the first few characters, but then started to drift diagonally up to the right, accompanied by some very unusual noises from the X and Y servos. I stopped the job mid way thru the bottom row of characters to diagnose.
I reran the Gcode several times with the spindle off (in air) and verified that by the middle of the bottom row of characters the X,Y 0,0 point had drifted by +5,+7 mm and the strange servo noises continued.My next step was to reprogram tinyG to build 429.01, using avrdude. That was successful.
Rerunning the job with tinyG build 429.01, first in air then actual machining, I was able to get good results but still heard some strange servo ‘clunks’, but somewhat less distinct (fainter noises?). Adjusting X and Y jerk down from 5000 million to 1000 million reduced the servo noise further (but did not eliminate it).My next step was to retry tinyG build 429.04 with the lower jerk settings.
Alas, avrdude started the upgrade from 429.01 to 429.04, but failed in the middle, with a write failure. TinyG was clearly stuck in the boot loader (blinking LED), I was able to rerun avrdude, but specifying to load 412.01 and avrdude completed. I restarted tinyG build 412.01 and tgFX and things seemed back to normal. Hmmmm
So I tried again to use avrdude to install 429.04, avrdude again failed mid stream. This time I was unable to get avrdude to load 429.01, or 412.01, but was able to load build 380.08. I restarted tinyG build 380.08 and tgFX and things seemed back to normal once again.
Once again, I tried running avrdude to load any of 412.01, 429.01 or 429.04. All failed to load, save writing error.TinyG is now bricked, won’t load any FW image (380.08, 412.01, 429.01, 429.04), just blinks, probably in bootloader.
So, my tinyG will be back in the mail on Monday for yet another bootloader reprogram.
In the meantime, perhaps Alden/Riley can make some sense of what is going on, given strange behavior of tgFX with the new 429.xy builds.
Additionally, Alden I suggest you give my Gcode a try on your test bed. You will see that this Gcode includes some short, somewhat illogical Gcode Arc commands, different from the test code that flux and dataway provided that had numerous very short segemnts that were pure X-Y moves. Has something broken in tinyG’s ability to deal with GCode ARCS?
I believe the servo clunking I hear is related to some of these Arcs commands, such as when drawing the lower case “m” characters (and others).What do I mean by “illogical” Gcode? Many of the characters have several arcs. Some are machined continuously and smoothy, the end of one arc is the start of the next. But others seem to have the machine randomly jumping from the end of one arc to drawing a short arc in the reverse direction to complete the path. I have a suspicion this code is confusing the planner and causing bogus drive pulses to the servos.
Sort of a bloody end to the day, to be expected I guess when playing with a sharp EDGE.
Update – not quite so bad a day
Rather than count sheep last night, I mulled the days activities.
One item that bothered me a bit was that when I was shutting down my laptop, which I normally do via Suspend to RAM, it crashed.
I had encountered some issues between tgFX builds 3259 and 3256 and tinyG during my session, and I am aware of other reported memory issues that Riley is currently chasing.I just tried once again to load tinyG build 429.01 using avrdude after a full reboot of the laptop. When I powered on tinyG, it was already in fast-flash mode, presumably in boot loader.
I issued the avrdude command for installing, and the install completed first try. Verified by starting a tgFX-tinyG session.The good news – no reload of boot loader required.
I still believe there is an issue with tinyG builds 429.01 and 429.04 processing the short arcs Gcode posted above.
And another short video, featuring the hammer-sound with $xvm=9600 $xjm=80. First, a moves to 1mm and back are done ok. Then, a move to 0.7mm and back produces the clunk.
VideoIn this case, the actual travel was accurate. But this is not always the case, I have seen it also miss steps, or even jump in the wrong direction.
I tried the new firmware version 435.06, and at first it looked much better. When trying simple G0 moves like above, I found the following:
(machine freshly reset and at 0/0/0)
G0 X0.8 (X motor does not move at all, ? shows X=0.8)
G0 X1 (X motor moves for 1mm, ? shows X=1.0)
G0 X0 (X motor moves back to 0, so far OK).G0 X0.8 (motor does not move, like above)
G1 Z-1 F100 (Z axis moves down, but X axis moves as well. Goodbye drill bit)
(X is now physically and logically at 0.8)OK, understand your logic now.
Might I suggest you try the following simple tests as well
Test 1
(machine freshly reset and at 0/0/0)
G0
G0 X0.8 (X motor…)
G0 X1 (X motor …)
G0 X0 (X motor …).Test 2
(machine freshly reset and at 0/0/0)
G0
G0 X0.8 (…)
G1 Z-1 F100 (Z axis …)
(X is now …)I have frequently found, when commanding from the tgFX command line, that a freshly reset tinyG does not respond to the very first G0 … command.
It is as if it is in a state where it is not listening, and the first G0 wakes it up.
Or, perhaps, it is expecting a JSON command and the G0 sent to it switches it to listen for text, but the first command gets lost (a guess on my part).See any difference?
- You must be logged in to reply to this topic.
