Switching to a TinyG Controler

I am in the process of swapping out my GShield for a TinyG controller.

I decided to try out the TinyG (as opposed to the X Controller) because I am hoping that changing acceleration strategies may help with the surface “ripple” issues I am having in my 3D Carves. Which I am thinking may be related to ‘Jerk’ vibration? (We will see.)

Even if that does not help, the TinyG has 4 stepper drivers and I think having the Y motors on their own driver chip will be a good idea. I have noticed that the Y motors are cool to the touch (with the current turned up as high as the chip can handle) while the X and Z motors are warm to the touch. So I should be able to give each Y motor a lot more current with the new controller.

I do not believe Easel is compatible with the TinyG but I use VCarve and UGS for most of my carves so I think I will be ok.

I am apprehensive about configuring and tuning the TinyG settings as it does not seem to have the amount of info / troubleshooting /advice that the GShield has. I am anticipating a steep learning curve as I try to figure it out :confused:


I ordered one up direct from Synthetos and it arrive in a few days, faster than I expected.

It was smaller than I anticipated. :slight_smile:

I made a really quick case out of some scrap pine (I will make a better one when I get a chance).

Once safely in a case I got it hooked up to the power supply and have loaded the Shapeoko settings into it.

I noticed it gets all it’s power from the main power supply and not the USB (unlike the Arduino for the GShield)

I had to load the FTDI drivers on my computer and configure coolterm correctly (took a bit) before I could communicate with it properly. (info on how to do that here)

I tested UGS with it and was able to connect and run some GCode with no motors hooked up. The “Homeing” button on UGS did not work saying “This feature is not supported”. I don’t know if that is a limitation with UGS in TinyG mode or something in the TinyG configuration? I will mess with it once I get everything else wired up.

Because I was rewiring everything anyway I decide to add terminal blocks between the controller and the XC. I figure that will make it easier for me to relocate the controller later, or switch back to the GShield if I have problems.

More info as the project continues.

1 Like

I finished wiring the terminal blocks and got the TinyG temporarily wired up.
(I ran out of shielded wire and had to switch to some old twisted pair I had on hand, I will replace it as soon as possible)
The TinyG and case don’t weigh much and easily dragged around when I move a wire. I need to make a bracket to bolt it to the power supply (like the gshiled) to keep it in place.

I managed to connect to it with UGS and successfully run an air cut. The Z steps are way off. Checking my notes I entered the wrong values so I will update that.
I need to figure out how to copy the TinyG configuration values to a text file for easier review.

I could not get the homing function to work. But apparently this is really tricky as you need to make sure all your switch configurations are correct. I found more info and will go over that next.

I was very disappointed to discover that the Pause “!”, Resume “~” and Cancel “%” buttons on UGS are not supported with TinyG yet. That will be a problem. I guess I will take a look a chilipepper.

Armed with lots of printout from the TinyG wiki, I got the homing function working. I had to configure the various switch settings. I was having a heck of I time until I realized I had the x and y switches mixed up -oops!

I calibrated the steps to my Z axis so it is moving correctly.
As I understand it, in GRBL the settings are mm / step and in TinyG mm / rotation (200 steps)
But my numbers were way off. I suspect that the XC GRBL build may be modified? or I am missing info. But no mater, I got it working :slight_smile:

I am getting more comfortable with the TinyG settings. There just are a lot more variables and options to go through. But I am starting to get a feel for it.

Here are my original GRBL Settings:

$0=10 (step pulse, usec)
$1=255 (step idle delay, msec)
$2=0 (step port invert mask:00000000)
$3=3 (dir port invert mask:00000011)
$4=0 (step enable invert, bool)
$5=0 (limit pins invert, bool)
$6=0 (probe pin invert, bool)
$10=3 (status report mask:00000011)
$11=0.020 (junction deviation, mm)
$12=0.002 (arc tolerance, mm)
$13=0 (report inches, bool)
$20=0 (soft limits, bool)
$21=0 (hard limits, bool)
$22=1 (homing cycle, bool)
$23=3 (homing dir invert mask:00000011)
$24=25.000 (homing feed, mm/min)
$25=750.000 (homing seek, mm/min)
$26=250 (homing debounce, msec)
$27=1.000 (homing pull-off, mm)
$100=40.000 (x, step/mm)
$101=40.000 (y, step/mm)
$102=188.976 (z, step/mm)
$110=8000.000 (x max rate, mm/min)
$111=8000.000 (y max rate, mm/min)
$112=500.000 (z max rate, mm/min)
$120=500.000 (x accel, mm/sec^2)
$121=500.000 (y accel, mm/sec^2)
$122=50.000 (z accel, mm/sec^2)
$130=790.000 (x max travel, mm)
$131=790.000 (y max travel, mm)
$132=100.000 (z max travel, mm)

Here are the current TinyG settings (these will be changing a lot):

[fb] firmware build 440.20
[fv] firmware version 0.97
[hp] hardware platform 1.00
[hv] hardware version 8.00
[id] TinyG ID 3X3566-YYX
[ja] junction acceleration 2000000 mm
[ct] chordal tolerance 0.0100 mm
[sl] soft limit enable 0
[st] switch type 0 [0=NO,1=NC]
[mt] motor idle timeout 2.00 Sec
[ej] enable json mode 0 [0=text,1=JSON]
[jv] json verbosity 2 [0=silent,1=footer,2=messages,3=configs,4=linenum,5=verbose]
[js] json serialize style 1 [0=relaxed,1=strict]
[tv] text verbosity 1 [0=silent,1=verbose]
[qv] queue report verbosity 0 [0=off,1=single,2=triple]
[sv] status report verbosity 1 [0=off,1=filtered,2=verbose]
[si] status interval 500 ms
[ec] expand LF to CRLF on TX 0 [0=off,1=on]
[ee] enable echo 0 [0=off,1=on]
[ex] enable flow control 1 [0=off,1=XON/XOFF, 2=RTS/CTS]
[baud] USB baud rate 5 [1=9600,2=19200,3=38400,4=57600,5=115200,6=230400]
[net] network mode 0 [0=master]
[gpl] default gcode plane 0 [0=G17,1=G18,2=G19]
[gun] default gcode units mode 1 [0=G20,1=G21]
[gco] default gcode coord system 1 [1-6 (G54-G59)]
[gpa] default gcode path control 2 [0=G61,1=G61.1,2=G64]
[gdi] default gcode distance mode 0 [0=G90,1=G91]
[1ma] m1 map to axis 0 [0=X,1=Y,2=Z…]
[1sa] m1 step angle 1.800 deg
[1tr] m1 travel per revolution 40.0000 mm
[1mi] m1 microsteps 8 [1,2,4,8]
[1po] m1 polarity 1 [0=normal,1=reverse]
[1pm] m1 power management 1 [0=disabled,1=always on,2=in cycle,3=when moving]
[2ma] m2 map to axis 1 [0=X,1=Y,2=Z…]
[2sa] m2 step angle 1.800 deg
[2tr] m2 travel per revolution 40.0000 mm
[2mi] m2 microsteps 8 [1,2,4,8]
[2po] m2 polarity 1 [0=normal,1=reverse]
[2pm] m2 power management 1 [0=disabled,1=always on,2=in cycle,3=when moving]
[3ma] m3 map to axis 2 [0=X,1=Y,2=Z…]
[3sa] m3 step angle 1.800 deg
[3tr] m3 travel per revolution 2.1420 mm
[3mi] m3 microsteps 4 [1,2,4,8]
[3po] m3 polarity 0 [0=normal,1=reverse]
[3pm] m3 power management 1 [0=disabled,1=always on,2=in cycle,3=when moving]
[4ma] m4 map to axis 1 [0=X,1=Y,2=Z…]
[4sa] m4 step angle 1.800 deg
[4tr] m4 travel per revolution 40.0000 mm
[4mi] m4 microsteps 8 [1,2,4,8]
[4po] m4 polarity 0 [0=normal,1=reverse]
[4pm] m4 power management 1 [0=disabled,1=always on,2=in cycle,3=when moving]
[xam] x axis mode 1 [standard]
[xvm] x velocity maximum 8000 mm/min
[xfr] x feedrate maximum 8000 mm/min
[xtn] x travel minimum 0.000 mm
[xtm] x travel maximum 900.000 mm
[xjm] x jerk maximum 10000 mm/min^3 * 1 million
[xjh] x jerk homing 10000 mm/min^3 * 1 million
[xjd] x junction deviation 0.0100 mm (larger is faster)
[xsn] x switch min 1 [0=off,1=homing,2=limit,3=limit+homing]
[xsx] x switch max 0 [0=off,1=homing,2=limit,3=limit+homing]
[xsv] x search velocity 750 mm/min
[xlv] x latch velocity 100 mm/min
[xlb] x latch backoff 20.000 mm
[xzb] x zero backoff 1.000 mm
[yam] y axis mode 1 [standard]
[yvm] y velocity maximum 8000 mm/min
[yfr] y feedrate maximum 8000 mm/min
[ytn] y travel minimum 0.000 mm
[ytm] y travel maximum 900.000 mm
[yjm] y jerk maximum 5000 mm/min^3 * 1 million
[yjh] y jerk homing 10000 mm/min^3 * 1 million
[yjd] y junction deviation 0.0100 mm (larger is faster)
[ysn] y switch min 1 [0=off,1=homing,2=limit,3=limit+homing]
[ysx] y switch max 0 [0=off,1=homing,2=limit,3=limit+homing]
[ysv] y search velocity 750 mm/min
[ylv] y latch velocity 100 mm/min
[ylb] y latch backoff 20.000 mm
[yzb] y zero backoff 1.000 mm
[zam] z axis mode 1 [standard]
[zvm] z velocity maximum 500 mm/min
[zfr] z feedrate maximum 500 mm/min
[ztn] z travel minimum 0.000 mm
[ztm] z travel maximum 100.000 mm
[zjm] z jerk maximum 50 mm/min^3 * 1 million
[zjh] z jerk homing 1000 mm/min^3 * 1 million
[zjd] z junction deviation 0.0100 mm (larger is faster)
[zsn] z switch min 0 [0=off,1=homing,2=limit,3=limit+homing]
[zsx] z switch max 3 [0=off,1=homing,2=limit,3=limit+homing]
[zsv] z search velocity 250 mm/min
[zlv] z latch velocity 100 mm/min
[zlb] z latch backoff 20.000 mm
[zzb] z zero backoff 1.000 mm
[aam] a axis mode 3 [radius]
[avm] a velocity maximum 230400 deg/min
[afr] a feedrate maximum 230400 deg/min
[atn] a travel minimum -1.000 deg
[atm] a travel maximum -1.000 deg
[ajm] a jerk maximum 5760 deg/min^3 * 1 million
[ajh] a jerk homing 11520 deg/min^3 * 1 million
[ajd] a junction deviation 0.0500 deg (larger is faster)
[ara] a radius value 0.1989 deg
[asn] a switch min 0 [0=off,1=homing,2=limit,3=limit+homing]
[asx] a switch max 0 [0=off,1=homing,2=limit,3=limit+homing]
[asv] a search velocity 600 deg/min
[alv] a latch velocity 100 deg/min
[alb] a latch backoff 5.000 deg
[azb] a zero backoff 2.000 deg
[bam] b axis mode 0 [disabled]
[bvm] b velocity maximum 3600 deg/min
[bfr] b feedrate maximum 3600 deg/min
[btn] b travel minimum -1.000 deg
[btm] b travel maximum -1.000 deg
[bjm] b jerk maximum 20 deg/min^3 * 1 million
[bjd] b junction deviation 0.0500 deg (larger is faster)
[bra] b radius value 1.0000 deg
[cam] c axis mode 0 [disabled]
[cvm] c velocity maximum 3600 deg/min
[cfr] c feedrate maximum 3600 deg/min
[ctn] c travel minimum -1.000 deg
[ctm] c travel maximum -1.000 deg
[cjm] c jerk maximum 20 deg/min^3 * 1 million
[cjd] c junction deviation 0.0500 deg (larger is faster)
[cra] c radius value 1.0000 deg
[p1frq] pwm frequency 100 Hz
[p1csl] pwm cw speed lo 1000 RPM
[p1csh] pwm cw speed hi 2000 RPM
[p1cpl] pwm cw phase lo 0.125 [0…1]
[p1cph] pwm cw phase hi 0.200 [0…1]
[p1wsl] pwm ccw speed lo 1000 RPM
[p1wsh] pwm ccw speed hi 2000 RPM
[p1wpl] pwm ccw phase lo 0.125 [0…1]
[p1wph] pwm ccw phase hi 0.200 [0…1]
[p1pof] pwm phase off 0.100 [0…1]
[g54x] g54 x offset 0.000 mm
[g54y] g54 y offset 0.000 mm
[g54z] g54 z offset 0.000 mm
[g54a] g54 a offset 0.000 deg
[g54b] g54 b offset 0.000 deg
[g54c] g54 c offset 0.000 deg
[g55x] g55 x offset 75.000 mm
[g55y] g55 y offset 75.000 mm
[g55z] g55 z offset 0.000 mm
[g55a] g55 a offset 0.000 deg
[g55b] g55 b offset 0.000 deg
[g55c] g55 c offset 0.000 deg
[g56x] g56 x offset 0.000 mm
[g56y] g56 y offset 0.000 mm
[g56z] g56 z offset 0.000 mm
[g56a] g56 a offset 0.000 deg
[g56b] g56 b offset 0.000 deg
[g56c] g56 c offset 0.000 deg
[g57x] g57 x offset 0.000 mm
[g57y] g57 y offset 0.000 mm
[g57z] g57 z offset 0.000 mm
[g57a] g57 a offset 0.000 deg
[g57b] g57 b offset 0.000 deg
[g57c] g57 c offset 0.000 deg
[g58x] g58 x offset 0.000 mm
[g58y] g58 y offset 0.000 mm
[g58z] g58 z offset 0.000 mm
[g58a] g58 a offset 0.000 deg
[g58b] g58 b offset 0.000 deg
[g58c] g58 c offset 0.000 deg
[g59x] g59 x offset 0.000 mm
[g59y] g59 y offset 0.000 mm
[g59z] g59 z offset 0.000 mm
[g59a] g59 a offset 0.000 deg
[g59b] g59 b offset 0.000 deg
[g59c] g59 c offset 0.000 deg
[g92x] g92 x offset 0.000 mm
[g92y] g92 y offset 0.000 mm
[g92z] g92 z offset 0.000 mm
[g92a] g92 a offset 0.000 deg
[g92b] g92 b offset 0.000 deg
[g92c] g92 c offset 0.000 deg
[g28x] g28 x position 0.000 mm
[g28y] g28 y position 0.000 mm
[g28z] g28 z position 0.000 mm
[g28a] g28 a position 0.000 deg
[g28b] g28 b position 0.000 deg
[g28c] g28 c position 0.000 deg
[g30x] g30 x position 0.000 mm
[g30y] g30 y position 0.000 mm
[g30z] g30 z position 0.000 mm
[g30a] g30 a position 0.000 deg
[g30b] g30 b position 0.000 deg
[g30c] g30 c position 0.000 deg

I go some more wire so I can swap out my temporary wiring.
Then I need to get the spindle control wired up to my solid state relay.
Then we should be ready to start the final calibration and adjustments.

I replaced the wiring on my limit switches with the correct type and got my spindle control relay working.
I was having a lot of problems. For some reason the solid state relay was having issues being driven directly from the TinyG output.
The TinyG logic is 3.3v and the solid state relay can trigger on as low as 3V so it should work.
I even tested it by connecting the relay to 3.3 Vcc - and it triggered. But the “Spindle On” output, “Coolant (Flood)” output, even the “Spindle Direction Bit” output, would not trigger it. Once it was actually running if I switched to the output it would stay on, so the outputs are working. I guess there is some kind of load issue with the relay? Probably need some kind of pull up resister or such.

What I wound up doing is reverting the relay wiring back to having it driven by the motor speed control output on the power supply and hooking that up to the “Spindle On” output.
It works fine. Eventually, when I upgrade to an actual spindle, I will have to figure this out as I will want the dust collection trigger by the “Spindle on” output and the Spindle speed controlled by the PWM power supply output. But that will not be for a while.

UGS is not really TinyG compatible. The code for it is mostly placeholder. I talked with the dev about how to mod it to work. I am in the process of figuring out java coding to try it out.
But my initial test with normal UGS yield some strange results.
Using macros I was able to home and z-probe just fine. But I am having issues resetting zero. Which isn’t actual resetting machine zero, but an offset.
I don’t know if I screwed it up (using the wrong offset type) or UGS had issues but after running my rough cut, and successfully z probing for the new bit it decided to reset the X Y zero to around x300 y300 and wound up air carving the final pass.
I noticed that the machine position data on UGS was not updating properly so that may have something to do with it.
On the plus side this was a “torture test” carve at MAX feed and the whole XC shook like crazy!
I could see the router shivering, stuff rattling on the worktable. So there is defiantly a “Vibration” issue with the default settings.

I think I will give chillypepper a try until my coding skills are up to speed

I decided to give Chilipeppr a try.
Unfortunately the outdated laptop that I use to run the cut files won’t support WebGL. This is the main reason I don’t use easel. But it is needed to use Chilipeppr as well.
So I used my new-ish laptop instead.

At first I had nothing but troubles. Truly strange things were going on with the coordinates and I could not get it to keep a zero between cut files for multi bit carves.

After a bit of back and forth with the Google group and a lot of trial and error I figured out what was going wrong and that it seemed to be localized to my setup.
So a full reboot and reset of everything and the problem cleared up.
It took 2 days but I finally got it working properly.
In a way it was for the best as I know have a much better understanding of the coordinate system and how chilipeper uses them.

Things have been working well. I did a tone of 2.5 D plywood carves with very good results.
Last night I re-ran a old 3d cut file which ran fine on the gshield.
It was running horrible on the new setup. Apparently moving way to fast, jerking and clunking. It seemed like the y motors were missing steps?
The chips were already very hot and I didn’t want to turn them up. So I adjusted the jerk (acceleration) wayyyy down on the Y axis. Enough to run my print file as is.

I am going to have to go over the setup and settings and find out what the issue is. Especially knowing that that file ran just fine before.

I also attempted to carve maple for the first time. I did not relies just how hard a wood maple is and my setting were all wrong. Things when badly. I improvised some new settings a limped along but the results were sub standard.

I have now recalculated more conservative settings, which fall in line with the feed and speed everyone else talks about.

It looks like I need to increase motor current. Pulling by hand on the XC as it moves the steppers are slipping under load. The thing is it seems to be “weaker” with the TinyG than it had been with the G shield.
I have the pots turned higher and the chips running hotter now with the TinyG than I had with the G shield but it seems to "slip’ easier.
It holds just fine at lower feed rates, but as the feed increase it then slips. I don’t remember that being an issue with the G shield. I double checked that I had the micro stepping correct, matching what I had set for the G Shield before. I will have to research how feed rate effects torque with the TinyG. This has got to be a settings / configuration issue.

I had the pots on the TinyG turned even higher before but started to miss steps due to overheating. So I remade the box and added a fan on both the top and bottom of the board. Maybe I just need a top cooling fan, like the G Shiled, for effective cooling. (though the TinyG states that the large copper pad, under the chip, on the bottom of the board is the best heat sink location.)

Now that you’ve had time to figure everything out … how do you like the switch to the TinyG? Do you have a list of pros and cons compared to the GShield?

I like that it has each Y motor on its own chip. It did help me determining that the “ripple” issue in my high speed carving was not due to the Y motors being connected together.
The motion does seem a bit smother, but not as dramatic a difference as I had expected. There doesn’t seem to be any good guide or machine defaults for these settings. it is a trial and error and tune by yourself situation. My thought is that the mechanicals of my machine may not be able to handled the increased speed performance that the smooth motion allows.

It is very configurable. You have so many different configuration options. Especially if you want to use a rotary axis.

I still have not got the current levels dialed in properly. I am not having motors slip during carving, but can make them slip with hand pressure. I am not sure but it seems like the gshiled was stronger. Again I may just need to adjust things better as they used the same chips.

The dual cooling fans helped with the overheat issues. I don’t know if it needs both or just the one on the top, but the one on the bottom was not enough. (I out it on the bottom because the bottom of the board is the main heat sink)

I am pretty much locked into using chillipeppr with it. But this is not necessarily a bad thing as chillpepr has more features than UGS. And the tinyG version has a lot more coordinate systems. It was tricky to figure out but a bit more versatile. Handy if you want to carve the same object over and over on a large piece of stock (I did this)

My thoughts are
If you are running a stock machine you don’t need it. The stock machine will no be able to take advantage of any performance enchantments the tinyg provides.

If you want to add a rotary axis, you want this. Being able to configure the rotary axis with deg per step means you don’t have to re-calibrate your setps per mm ever time you cut a different diameter object.

If all you want is higher current without cooling issues, and a separate y controllers, I would take a look at the X-Controller instead.

I am thinking that down the line I will build a rotary axis machine (with the left over bits from all my upgrades) and drive it with my tinyG. and Use a x-controller or maybe a gecko controller on my main machine.

I may change my mind if I can get the jerk setting tuned for smother movement. :wink:

If I was building a machine totally from scratch, I would probably go with the tinyG because it is more configurable. (and i am getting used to how the corrdinate system works on chillpepr tinyG)
But I would not go out of my way to upgrade to it if I had a gShiled & Arduino laying around.

1 Like

Thanks, very informative, I’m considering building a new machine and just trying to gather information on different controllers.

Hi @AaronMatthews, thank you for sharing all of this information. I was wondering if you would mind sharing the latest settings you had for TinyG? I have just started with a TinyG2 to use with a 4th axis I bought and having your tried and tested values would save me a lot of time.

Sure. It is still a work in progress. Initially I had some problems because I had mistakenly not had the y motor settings the same (except for direction).
I also needed to disable the limit switch function (homing only) as I kept getting false switch trip errors. (the carve would shut down and the spindle turn off)

Here is my initial TinyC configuration for the stock XC:
TinyG Config.txt (9.2 KB)

Here is the updated config file for the modified XC.
Upgraded C-Beam for the X axis and Y axis. The main difference being the steps per mm values.
TinyG RXC Config.txt (9.2 KB)
(I will check later this weekend and what my current setting are.)

I still need to tweak the jerk and acceleration settings. But they are a lot more options to play with. So that will take a bit more reading and trail and error to get dialed in.

2 Likes

That is really nice of you Aaron. Thanks a ton.

Interesting.
I was thinking of switching to a new controller myself.
I want to have the play pause and stop switches on the controller.

The gShield should already support this, you just need to wire in the switches.
If all you want is the pause buttons I would consider the XController. having the higher current stepper drivers would be nice.
I went with the tinyG for better smoothing (it didn’t work out as I hoped) and rotary axis support. (degrees per step variable)
If I wind up making a dedicated rotary axis machine I will put the tinyG on that and get a Xcontroller or gecko for the XC

Where is this documented?

@StephenCook

Here:

Thanks LarryM

when you set the motors up in chili pepper what did you use for travle per revolution what Ive found so far is 2mm prt rev on the Z and 40 for the X,Y that seems a bit much on the X and Y.

I modified my XC so that the X axis is on a acme screw drive. So the X axis steps per mm are similar to the Z axis. And the Y axis is a thicker belt so it’s setting are different as well.
Motor 1 (X axis) 7.9700 mm (per revolution)
Motor 2 (Y axis-L) 59.7920 mm (per revolution)
Motor 3 (Z axis) 7.9700 mm (per revolution)
Motor 4 (Y axis-R) 59.7920 mm (per revolution)

I am using an 8mm Acme screw - one full revolution of the screw moves 8mm along the thread. So one revolution of the motor moves ~8mm. (7.9700 mm in my case)

I am using a GT3 Belt - 3mm per tooth, with a 20 tooth pulley - one full revolution of the pulley moves 20 teeth which is ~60mm (59.7920 mm in my case)

I assume you are using the standard GT2 Belt - 2mm per tooth, with a 20 tooth pulley. So for you it should be ~40mm per revolution for the X and Y axis

On the tiny g it should automatically recalculate the values for whatever micro stepping setting you have.

I have run into a problem with my TinyG.

I am not sure if it was static electricity damage, or if somehow some aluminum chips managed to get onto the mother board? But I have had some circuit failures with my tinyG.

First one of the micro stepping pins on the Z axis stepper driver chip stopped responding. This resulted in me being able to set the Z axis to 0 and 2x’s micro stepping, but not 4x’s or 8x’s.

This manifested when my Z travel sudden was 6x’s what it should be. It took me forever to figure out what was going on and that it was hardware related.

When I change to 4x’s or 8x’s micro stepping TinyG is adjusting the step per rev value but the driver chip is not actually micro stepping so the values were now off.

My work around was to set the Z axis to 2x’s micro stepping. Less than ideal but workable until I replace the controller.

Another problem that showed up is the touch probe pin stopped working. I don’t know if this occurred at the same time or if it happened later. This is more problematic, as I had gotten used to using the touch probe to adjust z height after a bit change.

For now, I plan to limp along as is, until I can afford to upgrade to a higher current controller. Thought I did make sure I have my old Gshield ready to go if the TinyG fails before then. :wink:

1 Like