TinyG Configuration

The tinyG v8 controller is the brains of the CNC machine. It takes in commands through a USB cable, and controls the stepper motors and monitors the limit switches.

It also has a lot of configuration options that can be set to optimize the operation of the CNC.

Motor current adjustment

The TinyG has four stepper motor channels it can control. A 3-axis CNC like the Beta 01 would really only need three: one each for X, Y, and Z. However, the design of the Beta 01 actually has 5 stepper motors: 1 for X, 2 for Y, and 2 for Z. The TinyG allows configuring more than one channel to behave as a single axis, and it is also possible to split one channel to drive two stepper motors by wiring them in parallel. Both of these methods are used on the Beta 01.

Here is how the channels are wired:

• Channel 1: X axis
• Channel 2: Y axis, reverse polarity
• Channel 3: Y axis
• Channel 4: Z axis, wiring split to two stepper motors

Note the reversed polarity on one of the Y channels. This is due to the physical configuration of the steppers, where one needs to turn in the opposite direction of the other when moving.

The TinyG has four small adjustment trim pots on the circuit board to control how much current is sent to each of the four channels. Too much current will make the motors run hotter and louder than necessary and potentially skip steps, and too little can make them too weak and also skip steps. If you command an axis to move some distance, but it actually moves less than that, then there is a good chance you are skipping steps (or a pulley is slipping).

A general procedure for adjusting the motor current is discussed on the TinyG wiki at:

https://github.com/synthetos/TinyG/wiki/Connecting-TinyG#setting-motor-current

I did end up adjusting the current a little, but it may not have been necessary. Out of the box it performed quite well for me. But if you do experience motors getting quite hot, or skipped steps, adjusting the current might be one solution.

Setting axis configuration

[May 2015 Update - I updated to the latest firmware, version 440.14. More details further down on this page.]

My TinyG came with most configuration set reasonably, but there were a few changes I made. Here's what I changed:

[xtm] x travel maximum 360.000 mm (was 300)

[xsn] x switch min 3 [0=off,1=homing,2=limit,3=limit+homing] (was 1)

[xsx] x switch max 2 [0=off,1=homing,2=limit,3=limit+homing] (was 0)

[ytm] y travel maximum 410.000 mm (was 500)

[yjm] y jerk maximum 3000 mm/min^3 * 1 million (was 5000)

[ysn] y switch min 3 [0=off,1=homing,2=limit,3=limit+homing] (was 1)

[ysx] y switch max 2 [0=off,1=homing,2=limit,3=limit+homing] (was 0)

[zsx] z switch max 3 [0=off,1=homing,2=limit,3=limit+homing] (was 1)

To change these, you type commands in the Serial Port Console of Chilipeppr. The command is in the form:

$cmd=value

where "cmd" is replaced with the three characters between square brackets in the list above, and "value" is the numeric value listed. So for the changes above, you would enter:

$xtm=360

$xsn=3

$xsx=2

$ytm=410

$yjm=3000

$ysn=3

$ysx=2

$zsx=3

What do these changes do? These set the limit switches to actually act as limit switches rather than just simple homing switches. This means that if any axis is commanded to go beyond its physical capability, the switch will be hit and the TinyG will go into a type of safety off mode. To get it back functioning again, you either press the physical "reset" button that is on the box that holds the Raspberry Pi, or you click the reset button in Chilipeppr on the middle-right side of the screen.

The changes I listed also set the maximum travel distance when homing to values that are close to (but a little larger) than the actual travel distance possible. This ensures that a homing cycle will actually make it all the way across to zero even if the axis starts clear on the opposite side.

Finally, I also reduced the maximum jerk for the Y axis from 5000 to 3000. You may not find this necessary, but without this the table I have the CNC on was shaking pretty violently at times. This calmed it down a bit.

Nearly complete TinyG config

In case something bad happened and your TinyG lost all the default configuration, here is a (nearly) complete list of the defaults that mine shipped with. This does not include the changes I suggested above.

$x

[xam] x axis mode 1 [standard]

[xvm] x velocity maximum 5000 mm/min

[xfr] x feedrate maximum 5000 mm/min

[xtn] x travel minimum 0.000 mm

[xtm] x travel maximum 300.000 mm

[xjm] x jerk maximum 5000 mm/min^3 * 1 million

[xjh] x jerk homing 10000 mm/min^3 * 1 million

[xjd] x junction deviation 0.0500 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 2000 mm/min

[xlv] x latch velocity 100 mm/min

[xlb] x latch backoff 2.000 mm

[xzb] x zero backoff 2.000 mm

$y

[yam] y axis mode 1 [standard]

[yvm] y velocity maximum 5000 mm/min

[yfr] y feedrate maximum 5000 mm/min

[ytn] y travel minimum 0.000 mm

[ytm] y travel maximum 500.000 mm

[yjm] y jerk maximum 5000 mm/min^3 * 1 million

[yjh] y jerk homing 1000 mm/min^3 * 1 million

[yjd] y junction deviation 0.0500 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 3000 mm/min

[ylv] y latch velocity 100 mm/min

[ylb] y latch backoff 2.000 mm

[yzb] y zero backoff 2.000 mm

$z

[zam] z axis mode 1 [standard]

[zvm] z velocity maximum 300 mm/min

[zfr] z feedrate maximum 300 mm/min

[ztn] z travel minimum 0.000 mm

[ztm] z travel maximum 104.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.0500 mm (larger is faster)

[zsn] z switch min 0 [0=off,1=homing,2=limit,3=limit+homing]

[zsx] z switch max 1 [0=off,1=homing,2=limit,3=limit+homing]

[zsv] z search velocity 400 mm/min

[zlv] z latch velocity 100 mm/min

[zlb] z latch backoff 2.000 mm

[zzb] z zero backoff 2.000 mm

$1

[1ma] m1 map to axis 0 [0=X,1=Y,2=Z...]

[1sa] m1 step angle 1.800 deg

[1tr] m1 travel per revolution 59.9765 mm

[1mi] m1 microsteps 8 [1,2,4,8]

[1po] m1 polarity 0 [0=normal,1=reverse]

[1pm] m1 power management 1 [0=disabled,1=always on,2=in cycle,3=when moving]

$2

[2ma] m2 map to axis 1 [0=X,1=Y,2=Z...]

[2sa] m2 step angle 1.800 deg

[2tr] m2 travel per revolution 59.9765 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]

$3

[3ma] m3 map to axis 1 [0=X,1=Y,2=Z...]

[3sa] m3 step angle 1.800 deg

[3tr] m3 travel per revolution 59.9765 mm

[3mi] m3 microsteps 8 [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]

$4

[4ma] m4 map to axis 2 [0=X,1=Y,2=Z...]

[4sa] m4 step angle 1.800 deg

[4tr] m4 travel per revolution 2.1167 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]

[ja] junction acceleration 2000000 mm

[st] switch type 1 [0=NO,1=NC]

[mt] motor idle timeout 2.00 Sec

Hardware and software revision

The following is what my TinyG reported for its versions:

[hp] hardware platform 1.00

[hv] hardware version 8.00

[fv] firmware version 0.97

[fb] firmware build 435.10

Updating to 440.14 Firmware

I decided to try updating to a newer firmware. From reading the Chilipeppr forums, it seems that most people update to the latest "edge" firmware, and not the "master" version.

The important thing is the settings are lost during an update, so backing up and restoring settings is the majority of the work of updating.

I tried to use the backup and restore tool in Chilipeppr, but the current version was not working for me. So instead I issued a "$$" command to the tinyg via the console in Chilipeppr and saved the output in a text file.

Then I downloaded the TinyG TG Updater App, connected directly via USB to the tinyg, and started the update. Note that it returned an error at first, but on a second try it worked. (Note that for the second try I temporarily changed System Preferences -> Security -> General -> Allow Apps Downloaded From to "Anywhere", although I'm not sure that was what fixed it.)

I then went back into Chilipeppr and did a "$$" in the serial console, saving this new configuration output to another text file. I then did a diff of these files (I used BBEdit, but TextWrangler or any app that can do a file compare will work). I wanted to work through the changes manually to see if everything that was not set to defaults made sense.

Here is what my original configuration looked like:

And here is what I had after the firmware update:

My default assumption will be to restore the same configuration I had before. But going through line-by-line, I decided to keep some of the new defaults from the updated firmware. Here's what I changed from what I used to be running:

• [ja] junction acceleration 1000000 mm (was 2,000,000, default is 100,000)
• [tv] text verbosity 1 [0=silent,1=verbose] (was 0)
• [mt] motor idle timeout 3600.00 Sec (was 2)
• [1pm] m1 power management 2 [0=disabled,1=always on,2=in cycle,3=when moving] (was 1)
• [2pm] m2 power management 2 [0=disabled,1=always on,2=in cycle,3=when moving] (was 1)
• [3pm] m3 power management 2 [0=disabled,1=always on,2=in cycle,3=when moving] (was 1)
• [4pm] m4 power management 2 [0=disabled,1=always on,2=in cycle,3=when moving] (was 1)
• I also zero'ed out the g54 and g56 coordinate systems, as they retained some earlier values not needed anymore.

Note that I changed the power management because I noticed the new firmware is stricter about honoring the "always on" setting. With the old firmware, the "motors off" button in Chilipeppr turned them off, but this didn't work anymore in the new firmware. With this long idle timeout, I'm pretty much back to an always on but can turn them off when desired.

Updating to 440.16

A new version of the firmware is out now (July 2015), so upgrade time again. As before, I backed up my current tinyg configuration first by sending a "$$" in the Chilipeppr serial port console. I then downloaded the current TinyG Updater at https://github.com/synthetos/TinyG-Updater/releases and installed it. Finally I manually restored the settings into the tinyg.

Updating to 440.20

October 2015 - I again updated using the same procedure as before.

Adjusted Y-axis Homing Latch Backoff

I found that occasionally the machine would go into reset (halt, requiring a reset) when moving the Y axis after a homing cycle. It seems that the y limit switch was just on the edge of not releasing with the 2mm latch backoff value. I adjusted it to 3mm and that seems to fix it.

To do this, I simply typed the following in the text console in Chilipeppr:

$ylb=3

There is more info at the Homing and Limits Description and Operation documentation page for TinyG.