Synthetos Shop

A Bad Day in the Shop

From the original Synthetos forum (2011–2025)

Started by cmcgrath5035 on in TinyG Support. 19 replies, last activity Jun 29, 2014.

cmcgrath5035Staff #

Yesterday I reported that tinyG build 429.04 appears to resolve a long nagging error in drawing tight diagonals, here is the thread

https://www.synthetos.com/topics/tests-with-updated-tinyg-and-tgfx-versions-linux-environment/

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
[image: Dash run_v1.jpg, no longer available]

The Gcode for this is found here

https://dl.dropboxusercontent.com/u/50261731/Dash%20Test%20Failures/Dash%203.8.nc

This code has run well since tinyG build 412.01

The machine config parameters are here:

https://dl.dropboxusercontent.com/u/50261731/Dash%20Test%20Failures/2014-05-31_18.28.12-tinyg.conf

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.

cmcgrath5035Staff #

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.

chmr #

Hi, I tried to reproduce your problem. The "unusual noises" sound like someone hitting the axis with a hammer, and the machine is nearly rocked off it's stand. No wonder it misses steps.

In trying to narrow down the problem, I tried to make small moves with different settings for speed and jerk, and measure the actual travel distance. See for yourself: <embed width="640" height="640" type="application/x-shockwave-flash" src="http://v8.tinypic.com/player.swf?file=30vd72g&s=8"><br>Original Video

The upper part is coolterm, lower part is the output of a USB microscope mounted next to my spindle. When vmax is 11999 or lower, moves of 1mm are executed correctly.
When vmax is set to 12000 or above, moves of 1mm do not have a accelleration/deceleration phase, they just seem to travel a single motor step (0.12mm with my settings). After two moves of 1mm each and a move of 2mm back, the spindle is not back at 0 as it thinks, it is at -1.8.

The really strange thing is that the difference between 11999 and 12000 vmax. Might be dependent on motor settings tho. At the lower speed, the problem still occurs at moves of 0.5mm.

chmr #

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.
Video

In 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.

cmcgrath5035Staff #

Thanks, Chris, for the confirmation and detailed analysis.

Could you perhaps make you test Gcode available (e.g. post a link)?
It might be easier to work with or more revealing to Alden than mine.

chmr #

My test "gcode" is that I typed in in the videos. It consists of "g0 x1" and "g0 x0.7" (might have to watch the videos in fullscreen mode, tinypic resizes it by default).

cmcgrath5035Staff #

Ah, gotcha. Yes, the CoolTerm widow is tough to see, plus it was more fun to watch the microscope :).

But you answer my real question - you induced failures with short X-Y moves, not short arcs, but (relatively) high max velocity.
I guess that might explain why the tough test cases flux and dataway provided ran OK, as the short moves were at G1 velocity, not G0.

That also explains why some of my engraving short arcs are OK (no knocks) as they are continuous arc to arc, no G0 moves.
It is the "Illogical Gcode" hopping around (at G0) that reveals this.

I'll retry this Job with 429.04 with the $xvm and $yvm set much lower.

Thanks

cmcgrath5035Staff #

Final update on this topic, I hope.
With build 429.01 loaded, I dialed back xvm and yvm to 1000 (from 16000), experienced no "clunking" and got a clean production run. Since the bulk of the job is G1 machining, already run at F200, not a significant increase in overall job execution time.

chmr #

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)

chmr #

Also this simple piece of gcode:

G0 Z1
G0 X0 Y50
G1 Z-1 F100
G2 X100 R50
G2 X0 R50
G0 Z3
G0 X0 Y0

Instead of feedrate 100, it tries to do it with a very high feedrate (I have seen speed 13k+ in the status reports). And the clunking sound is back.

cmcgrath5035Staff #

chmr
Thanks for info; I am on holiday without my Shapeoko, so am waiting for info from early testers such as yourself.

I am curious; my read of your first post(#6252) is that you considered NO motor movement after the G0 X0.8 was "OK", or expected. Why?
One microstep on my shapeoko is 0.0228mm; I would expect the motor to move.

chmr #

I think this was (part of) the fix for the clunking noises: If a movement is too short to execute in a controlled manner, don't do it. I consider that OK as long as the physical position is remembered and the move is not forgotten (i.e. no drift between logical and physical position at the end of a cycle).
But I agree that 0.8mm is a very high value, on my machine a full step is 0.12mm and a microstep 0.015mm . I have found no direct influence of max speed or jerk to that value, like it was before.

I consider the other problems much more critical.

cmcgrath5035Staff #

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?

aldenStaff #

Thanks for the detailed analysis. THis is a case that should probably be handled as an exception. If a G0 movement is too short to plan at the max velocity, reduce the velocity so it is moved. I will take a look at this over the weekend. Thanks for the diagnosis and the reporting.

cmcgrath5035Staff #

Alden;
My interpretation is that Post 6255 above, the rather lazy tinyG generated arc moves that result in clunking, were of equal/greater concern to chmr.

chmr: can you confirm that the clunking was on both the Z move AND the arc moves, or just a subset?

In my 'clucking' experience with build 429.04, the clunk was bad but worse it represented a guaranteed missed/failed move, and therefor immediate offset/drift.

Of course the root cause there may be that the F100 command resulted in a bogus feed rate, ??

aldenStaff #

I am looking at the feedrate issue. This needs to be addressed before the clunking in any event.

There was a rather glaring error in the feed-rate calculation that overlooked arcs. Here is a hex that corrects that. I'm positing it now so you can give it a try. I will be testing this over the weekend before pushing to edge if it's OK.

https://www.dropbox.com/s/23f54xjgnj0i0ku/tinyg_435.07_dev.hex

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

Reply

Different problem? Ask a new question

Back to TinyG Support or latest activity.