Home › Forums › TinyG › TinyG Support › A Bad Day in the Shop
- This topic has 19 replies, 4 voices, and was last updated 10 years, 4 months ago by alden.
-
AuthorPosts
-
May 31, 2014 at 9:19 pm #6052cmcgrath5035Moderator
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.
- This topic was modified 10 years, 5 months ago by cmcgrath5035.
June 1, 2014 at 11:28 am #6054cmcgrath5035ModeratorUpdate – 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.
- This reply was modified 10 years, 5 months ago by cmcgrath5035.
June 2, 2014 at 3:23 am #6056chmrMemberHi, 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.
June 2, 2014 at 5:28 am #6058chmrMemberAnd 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.
- This reply was modified 10 years, 5 months ago by chmr.
June 2, 2014 at 6:26 am #6060cmcgrath5035ModeratorThanks, 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.June 2, 2014 at 7:00 am #6061chmrMemberMy 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).
June 2, 2014 at 8:28 am #6062cmcgrath5035ModeratorAh, 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
June 2, 2014 at 11:15 pm #6065cmcgrath5035ModeratorFinal 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.June 27, 2014 at 7:25 am #6252chmrMemberI 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)June 27, 2014 at 7:37 am #6255chmrMemberAlso this simple piece of gcode:
G0 Z1
G0 X0 Y50
G1 Z-1 F100
G2 X100 R50
G2 X0 R50
G0 Z3
G0 X0 Y0Instead 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.
June 27, 2014 at 8:36 pm #6256cmcgrath5035Moderatorchmr
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.June 28, 2014 at 2:42 am #6257chmrMemberI 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.
June 28, 2014 at 5:47 am #6258cmcgrath5035ModeratorOK, 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?
- This reply was modified 10 years, 4 months ago by cmcgrath5035.
June 28, 2014 at 7:28 am #6260aldenMemberThanks 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.
June 28, 2014 at 10:23 am #6262cmcgrath5035ModeratorAlden;
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, ??
-
AuthorPosts
- You must be logged in to reply to this topic.