Synthetos Shop

Tuning a tinyG - an alternate approach

From the original Synthetos forum (2011–2025)

Started by cmcgrath5035 on in TinyG Support. 3 replies, last activity Apr 23, 2014.

cmcgrath5035Staff #

Forword:
My experiments are on a modified ShapeOko 2.
My tinyG is Hdwe V7, running 412.01 FW
My tgFX is build 3009.
I do virtually all my work from Linux, when things don't seem to work I verify similar results with Win7_64

After an entertaining exchange with member flux over the past weekend, I realized I had never property "tuned" my tinyG. It seemed to work out of the box, but after this experience it was clearly time to explore the boundaries of my machines performance.

For those who have not tried it, this thread , started by flux, is a wonderful tutorial on stress testing your machine, whatever it may be.

https://www.synthetos.com/topics/tinyg-edge-drifts-on-series-of-small-movements/

The methodology used by flux, in my opinion, aggressively evaluates the whole machine; software tool chain, firmware, analog interfaces(a.k.a. servo motors) and just how well you assembled your machine was assembled.
It found a couple loose M5s in my ShapeOko.

I will summarize the methodology:
Set an origin in your workspace (0,0). (Z performance not addressed here)
Run a set of Gcode thru the machine.
As the last step in the Gcode, return to X0, Y0.
Metric - how close to (0,0) at the start is X0,Y0 at the end?
Flux defines this difference as "drift".

Please do keep in mind that starting at (0,0) and ending at (0,0) does not guarantee that everything in between is absolutely accurate, but this is a good start.

While all aspects of the process are involved in this test, I particularly like the resulting "Metric" - it is measurable to whatever tolerance you might have for your intended use. It seems uniquely capable of measuring the analog potions of the process, specifically current settings, and resulting servo motor performance issue, as well as belt slips and some (not all) assembly and maintenance issues.

The test case flux uses , test.7.gcode, had my Shapeoko rockin' and rollin' all over the place. Much faster motion with very small detail,
essential for his target application(PCB fabrication) but not currently for mine.
I chose to attempt a simpler test case for initial evaluation of my ShapeOko. A design file is here

https://dl.dropboxusercontent.com/u/50261731/ShapeOko%20Tuning/tinyG%20tuning%20pattern.dxf

Visually, it has three layers, the first a zig zag polyline all drawn at G01 feed rate, a layer of G01 diagonals with long horizontal G0 moves at
x or y velocity maximum ($xvm, $yvm) and two diagonal polylines of variable arc length run at Feedrate.
[image: Selection_141.jpg, no longer available]

A Gcode file was generated, with all layers 2 to 3 mm above zero level, with -0.5mm points marking starting (0,0) and ending (X0,Y0), offset is the distance between the two points. G01 Feed rate is set in one row of GCode, easily editable to increase stress.

https://dl.dropboxusercontent.com/u/50261731/ShapeOko%20Tuning/tinyG%20tuning%20pattern_noOpt_mm_with%20points_edited.nc

My machine config parameters can be found here

https://dl.dropboxusercontent.com/u/50261731/ShapeOko%20Tuning/2014-04-21_17.31.08-tinyg.conf

They are based on Alden's updated Wiki post here for tinyG build 412.01

https://github.com/synthetos/TinyG/wiki/TinyG-Shapeoko-Setup

My current pots on tinyG were at 12 o'clock, NEMA 17 motors (X, dual Y), 24V power supply.

I typically run at F200, I'm not in a hurry at this stage and like to study what is going one; obviously for many higher feed rates are essential.
At F200 feedrate, the GCode runs for 14:08 using tgFX. Drift is unmeasurable.
I then iterated the feed rate by editing and reloading the GCode file (F600, F1200, F2000, F2400,F3000, F3500, F4000) and experienced my first drift error at F4500, an x drift of 1mm. The job now runs in 0:58 minutes.
I continued with F5000, F6000, F7000 and F10000, which showed an offset of 2.5mm in X position.
I would say at this point I would not use feed rates for the materials I mill much above F1200, so have tentatively concluded that the 12o'clock setting for servo drive current is adequate with headroom.

If you have not tried a test like this with you machine, I highly recommend it. Also the play with $xjm and $yjm to see how they affect the machine motion. With the spindle not running, you can hear variations in the servo mechanisms. And no dust to deal with!

If interested in more of this, head back to flux's thread.
I have not found machine setting for my setup that are offset free.
His test case is VERY aggressive, but targeted at a different application.

flux #

Thanks for describing your method. I have not yet tried it, but:

I would say at this point I would not use feed rates for the materials I mill much above F1200, so have tentatively concluded that the 12o’clock setting for servo drive current is adequate with headroom.

As you note, it's different when moving in free air and then milling something. I had some trouble missing steps when milling aluminum, so I decided to just go full throttle in my current pots. (The motors are rated 3A anyway and TinyG can give 2.5A.) So while this approach can give bounds for doing free-air G0 movements, it doesn't really answer what kind of settings one needs to actually mill hard materials.

Sadly we cannot adjust the current limits in software for different situations (or can we? the edge branch gives some new 'motor power' setting ranging from 0.0 to 1.0), I bet that could be useful in using different settings for moving in air, milling PCBs and milling hard materials.

cmcgrath5035Staff #

flux wrote

As you note, it’s different when moving in free air and then milling something. I had some trouble missing steps when milling aluminum, so I decided to just go full throttle in my current pots. (The motors are rated 3A anyway and TinyG can give 2.5A.) So while this approach can give bounds for doing free-air G0 movements, it doesn’t really answer what kind of settings one needs to actually mill hard materials.

Sadly we cannot adjust the current limits in software for different situations (or can we? the edge branch gives some new ‘motor power’ setting ranging from 0.0 to 1.0), I bet that could be useful in using different settings for moving in air, milling PCBs and milling hard materials.

It will be interesting to see if Alden describes the motor power parameter as a 'software potentiometer'. I believe he said somewhere to leave it at = 1 for now, it is a feature that he is working on in the future.

I have a somewhat different interpretation of drive motor current, that being that the drivers can switch up to 2.5A into an inductive load before they near their dissipation design limit. The pots are available to reduce un-needed torque, which becomes heat, to extend the longevity of the driver and motor components.
Does your tinyG run hot, particularly near the end of test.7.gcode?
I keep finger checking mine - no rise really noticeable, but I have a somewhat unique (I think) implementation with the tinyG pwb bolted to a large heatsink, no fans, plus the small individual driver 'dip-sinks'.

For jolly’s, I am going to put an ammeter in series with my 24V supply just to see what it says during the various phases of my test case and your test cases.

If, as I suspect, the torque required from the motors, with the available current, is inadequate to control the spindle in air while running the test, then clearly they won't have reserve torque to push the spindle along if the force required to push the spindle thru the material is even moderate. That force is a complex combination of the spindle motor torque, material hardness, bit sharpness, diameter, etc.,
you know all that from dealing with Al.

An interesting question then becomes: for a given machine mass (spindle plus X gantry), how does increased velocity in an air test case translate into reserve force available to push the machine at lower feed rate (real work) with the same accuracy.
Sounds like a good Homework and followup lab experiment for ME 305 or perhaps a good Master Thesis!

Its probably time to revisit the Spindle pages on the ShapeOko forum, to see if other have test results in this space.

cmcgrath5035Staff #

I ran a few pot position tests with more or less expected results.
Increased current to the motors did improve my machines performance/ reduce drift.

For example, moving the pots from 12 o'clock to 4 o,clock, my test GCode described at the top of this thread ran without drift at F10000, where it had begun to drift with the pots at 12 o'clock.
I did not attempt to go higher in Feedrate, so this is just another data point.

I attempted some instrumentation with two DMMs, low cost items from HFT (free, actually). I have no knowledge of their averaging capabilities/characteristics.

One DMM in series using the 10A setting, the other measuring Power Supply output Voltage.

With pots at 4 o'clock, I measured input current = 1.61A while the motors remained 'locked' after reset. When released, current dropped to about 0.1A, so roughly 1.5A was feeding the motor windings.
I don't have a 'scope and have not dug enough to know what the tinyG drive waveforms look like.
Does anyone have a guesstimate as to the average duty cycle for the winding waveform?

I also observed a fairly consistent input voltage of 24.2V when idle, 23.5V when measuring 1.6A. That is about 3% drop, probably within spec for my less than premium 24V 6A power supply.

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

Reply

Different problem? Ask a new question

Back to TinyG Support or latest activity.