Problem Log

I am really enjoying my Beta 01, although I have run into a few issues along the way. This shouldn't be too surprising, given that this is considered a beta design.

I will keep a log of these here, including any solutions I find, hoping that it will be helpful to other Beta 01 users and perhaps to Printrbot.

Broken limit switch wires

I found that a couple of the limit switch wires were broken out of the box:

• One of the wires from the Z axis limit switch was severed a couple inches from the switch as it passed down near the Z stepper motor. It must have been pinched somehow.
• One of the wires from the max X axis limit switch was broken right at the switch.

Both of these were pretty straightforward to re-solder without disassembling anything, although they were a little tricky to reach with the soldering iron.

X-axis pulley set screw not tight

I had an issue where movements in the X axis were not landing exactly as they should as measured by a ruler. After close examination, I found the set screw in the X-axis drive pulley was not in far enough, and allowed some slop in the X movement. It was in enough to not allow the drive shaft to completely slip, but rather could slip a certain amount in either direction before the set screw hit.

I wiggled the pulley back and forth to find the center of the slop, and tightened the set screw. This fixed the problem, and did not require any disassembly of the machine to repair.

X-axis belt rubbing

I was experiencing an issue where the X axis would sometimes skip teeth on the drive pulley. You could hear the sound of this happening, and the X axis would drift off from its proper position.

I found that the belt was slipping down and rubbing on the tensioning bracket as shown in the photo below:

To fix this, I removed the two screws holding the tensioning bracket, put some masking tape on the top half of the bracket where the screw holes are, and then re-installed the bracket making sure to tighten the tensioning screws enough that the masking tape came in contact with the machine frame. The masking tape acted as a spacer, changing the angle of the tensioning bearings a little so the belt would ride higher. After this change, the belt now runs like this:

This solved the problem nicely, and was a pretty easy fix. Note that one of the screws from the aluminum frame that screws into the steel frame near the tensioning bracket is a bit long and hits the bracket. I had to back that one out temporarily to work on the bracket.

Static electricity issues

I had some issues with static electricity. The first symptom I saw was the tinyg controller restarting at seemingly random times. Upon further experimentation, I found that if I rub my feet on the ground (or pet the cat) and then touch any part of the machine, the tinyg would restart. If a job was running, it halts, and sometimes starts again but having lost some commands/state so the job goes really bad as you might imagine.

My shop vac hose also builds up some static while running, and this would seem to be another source of static into the system.

The first thing I tried was to tie the machine chassis to earth (mains) ground. That seemed to solve the shock problem, but created a new one. Whenever I turned on my shop vac, and sometimes even the Makita router, both of which were on the same power strip as the CNC, the tinyg would restart too. All I can think of is there is some noise getting into the system via the ground.

As another experiment, I tried connecting the ground from the 24V supply to the chassis as well (earth ground still connected too). That behaved the same as above (static shocks ok, but starting shop vac kills it).

In the end, I found that this second problem could be addressed by running the Makita and shop vac directly to the wall outlet, and then have the power strip with the CNC 24V supply going to that outlet as well. So, basically not having the shop vac and Makita on the power strip with the CNC. My power strip was on a moderately-long extension cord, which may have contributed too. I'm not 100% sure the problem is gone, but my last several cuts have had no issues. I ended up disconnecting the earth ground, but left the 24V ground tied to the chassis.

Raspberry Pi SD card corruption

After a couple uses, the raspberry pi failed to boot anymore. Some searching revealed that it is apparently pretty common for the SD card to get corrupt, especially when you just cut power rather than shut it down gracefully. I purchased a new SD card (I could have re-imaged the old one) and loaded it with the Raspbian image from http://www.raspberrypi.org/downloads/ and then loaded the latest version of serial-port-json-server.

Full details of how I rebuilt the SD card can be found in my Raspberry Pi Config section.

Other than emergencies or power outages, I now make an effort to shut it down gracefully every time by SSH-ing into the Pi (user "pi" and password "raspberry") and doing:

sudo shutdown -h now

Update Feb 2015: The card became corrupt again in mid-February. I have been leaving the Pi powered up at all times (see more detail in the Spindle Light/Control section). We had a brief power outage, and that did the card in again. It is either a pretty common issue with the Raspberry Pi, or I'm rather unlucky. Fortunately, I just followed the steps to rebuild the card, which gave me an updated version of Raspbian as a bonus. So, back in business again.

Update Feb 2016: Everything has been stable with the raspberry pi for a while now. Perhaps updating to newer versions of Raspbian helped. Either way, this seems to no longer be a problem.

TinyG and G2/G3 Arc Issues from Fusion 360

I have had some issues with gcode generated from Fusion 360. It seems to be an issue with G2 and G3 commands, which define arcs. My guess is that the rounding or accuracy Fusion is using is not being accepted as valid by the TinyG. Unfortunately the TinyG simply skips those arcs and continues to run the job. It would be much better if it stopped and gave an error.

The symptom I see is portions of my gcode are skipped, resulting in uncut regions and sometimes movements slicing through parts of the work that should not be cut.

Specifically, what I saw in my gcode is that once an arc is skipped, then the math is definitely off for subsequent arcs, so a bunch of gcode is then typically skipped. But, eventually a G1 is hit, and the TinyG does make that move and things are back on track again. Of course, if I was unlucky, that move would slice through things that should not have been cut. So it was worse than simply omitting parts of the job.

Here's an example of this happening:

(machine starts at X-1.799 Y10.388)

N115 X-1.999 ;moves to X-1.999 Y10.388 CORRECT

N120 G2 Y11.875 I0. J0.743 ;no move INCORRECT

N125 G1 X41.999 ;moves to X41.999 Y11.875 CORRECT, used the Y11.875 from the above arc

N130 X42. ;moves to X42 Y11.875 CORRECT

...

So it skips the arc on line 120, but interestingly, it used the Y value that was a parameter to the arc as the parameter for the G1. Perhaps this is just a side effect of how parsed parameters are stored. I suspect it is truly fully skipping the arc, but carries over the reading of the Y parameter.

This was with TinyG firmware 440.20. I have heard that the edge version of the firmware solves it, but causes other issues (as of August 2016). Fusion is updated often, so it could be that this issue will solve itself. There's a thread on this topic at the Chilipeppr forums at:

https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topic/chilipeppr/ydHB-YVIcds