Thursday, July 14, 2016

Bringing up MicroPython on the GHI Electronics G30TH

I noticed that GHI Electronics makes a number of devices using the SM32F4 fmaily of processors, which also happens to be supported by MicroPython.

The G30TH caught my eye, which is basically a breakout board for the STM32F401RET6 which has 512K of flash and 96K of RAM.

Provide 3.3V

The board includes a USB connector, but doesn't include any onboard regulator, so you'll need to provide 3.3V to power the board.

I happened to have a Pololu 2842 in my drawer, so I decided to use that.

Being paranoid, I put a piece of kapton tape over the bottom of the regulator since it would be coming in contact with the metal housing on the USB connector. The Kapton tape makes the white silkscreen look yellow in the photo below:

While I still had access, I soldered a piece of wire to the VIN signal on the regulator, and then I soldered 2 header pins to the 3V3 and GND pins:

VOUT on the regulator connects to 3V3 on the G30TH, and GND on the regulstor connects to GND on the G30TH. The red wire connects from VIN on the regulator to V+ on the G30TH. V+ on the G30TH connects to VUSB on the USB connector.

Now if you plug in the USB connector, both the PWR and USB LEDs should light.

Build the firmware

You can grab the micropython source code using git:
git clone
and then install the G30TH board defintion into the tree:
cd micropython/stmhal/boards
git clone
cd ..
Finally, build the firmware (from within the micropyton/stmhal directory):
make BOARD=G30TH

Get the Board into DFU mode

I used a wire jumper to connect from 3V3 and pressed it on the B0 (BOOT0). Since I used a female to female jumper wire with a single header pin plugged in one end:

I also used a short 6" USB cable to plug it into a USB extension cable. I found plugging the 6" cable into the extension to be quite a bit easier than plugging into the Micro B connector on the board. I could then hold the jumper on B0 with one hand and plug the USB cable into the extension with the other and get the board into DFU mode.

With the board in DFU mode, lsusb should show an entry like this:
Bus 001 Device 014: ID 0483:df11 STMicroelectronics STM Device in DFU Mode
and running dfu-util --list should report something like this:
$ dfu-util --list
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to

Found DFU: [0483:df11] ver=2200, devnum=14, cfg=1, intf=0, alt=3, name="@Device Feature/0xFFFF0000/01*004 e", serial="377A364D3234"
Found DFU: [0483:df11] ver=2200, devnum=14, cfg=1, intf=0, alt=2, name="@OTP Memory /0x1FFF7800/01*512 e,01*016 e", serial="377A364D3234"
Found DFU: [0483:df11] ver=2200, devnum=14, cfg=1, intf=0, alt=1, name="@Option Bytes  /0x1FFFC000/01*016 e", serial="377A364D3234"
Found DFU: [0483:df11] ver=2200, devnum=14, cfg=1, intf=0, alt=0, name="@Internal Flash  /0x08000000/04*016Kg,01*064Kg,03*128Kg", serial="377A364D3234"

Unprotect the device

The firmware on the G30TH is protected, so the first thing that needs to be is to unprotect the device.

IMPORTANT: Once you unprotect the device (which will erase it) there's no going back to the .NET firmware that came with it (since I don't believe that firmware is distributed anywhere). So don't expect to "try" MicroPython and go back to using .NET later.

The device can be unprotected using dfu-util:
dfu-util -s :unprotect:force -a 0 -d 0483:df11 -D build-G30TH/firmware.dfu
Note that DFU requires the -D option even though it won't be using the firmware file. Unprotecting the device has the side effect of erasing it.
$ dfu-util -s :unprotect:force -a 0 -d 0483:df11 -D build-G30TH/firmware.dfu
dfu-util 0.8

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2014 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to

Deducing device DFU version from functional descriptor length
Opening DFU capable USB device...
ID 0483:df11
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuERROR, status = 10
dfuERROR, clearing status
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 2048
DfuSe interface name: "Internal Flash  "
Device disconnects, erases flash and resets now
Unprotecting the device also resets the device, so you'll need to put it back into DFU mode once more.

Flash MicroPython

Now that the device is back in DFU mode once again, we can flash MicroPython:
make BOARD=G30TH deploy
If you've never flashed MicroPython before, there may be additional steps required. The wiki page for programming the STM32F4 Discovery Board should have the information required.

Once MicroPython has been programmed, then you can use your favorite terminal program to open /dev/ttyACM0 and get a REPL: (I often use
Waiting for USB Serial Device ...
USB Serial device with vendor 'MicroPython' serial '377A364D3234' connected @/dev/ttyACM0
Use Control-X to exit.
MicroPython v1.8.2-13-g08eac74 on 2016-07-14; G30TH with STM32F401CE
Type "help()" for more information.

Sunday, February 21, 2016

Raise3D N2 - Custom Spool Holder

The filament spools that came with my Raise3D printer are 200mm in diameter, 70mm thick, and have a central hole about 55mm in diameter.

I happen to have alot of spools of PLA which are 162mm in diameter, 85mm thick, and has a central hole diameter of 31mm.

Needless to say, my spools won't fit on the N2 spool holders. So I went and designed a spool holder using OnShape. I put the files on thingiverse and on my github account.

This shows the spool holder mounted in the printer:

And with a spool on it.

I can't close the door with this spool holder mounted, but that isn't really an issue for PLA.


As I notice people creating variations, I'll include them here:
Shorter 65mm shaft

Setting the date, time, and timezone on the Raise3D N2

UPDATE: It turns out that later versions of the firmware now have the ability to set the timezone, date and time. I currently have version installed. To change the timezone, click on the little gear icon in the upper right corner, which will bring up "Settings". Then chose the "Other" category and finally, "Date & Time". You need to press on the > over on the right hand side.

Touch the > over on the right of the Timezone line, and then in the search box start typing the name of your time zone city. You can find a list of time zone cities here (note that this list has the timezone name shown first).

I start to type van and then clicked on "Vancouver, Pacific". Once entered, then press the back < and then enter the date and time.

Restart (either by using Settings -> Machine -> Restart, or by power cycling) and your timezone and date/time should be correct.

The following is the original blog post, which I'm keeping for reference.

This is a bit technical. If I glossed over something, feel free to ask questions. Hopefully the good folks at Raise3D will fix their firmware to allow the date/time/timezone information to be entered.

I noticed when printing files from the sdcard or MMC card, that the time was being reported in UTC, and that the timestamp on internal files was from 2015.

Since you can ssh into the root account on the printer, I decided to see if I could correct this. The printer uses busybox, but it appears to be using glibc rather than uclibc.

With glibc, you can set the default timezone by making /etc/localtime be a special timezone file or a symlink to a special timezone file.

I run Ubuntu on my desktop, and it had an /etc/localtime which was a file (not a symlink). It mostly contains binary data (if you do a hex dump you'll see your timezone strings buried in there). For convenience, I put a copy of the /usr/share/zoneinfo directory tree in my github account. Many of the files are symlinks. For example, I normally use America/Vancouver as my timezone, and if I find that file, it shows ../Canada/Pacifc and ../Canada/Pacific is not a symlink, but a real file. So I downloaded the Canada/Pacific timezone file to use as my timezone file.

First thing to do is to verify your current timezone:
ssh root@
replace with the IP address of your printer. In my case it showed UTC as the timezone and a year of 2015.

I entered Control-D to quit from the ssh sesseion and then copied the Canada/Pacific file from my github repository (download the raw file) to the /etc/localtime file on my printer:
scp Pacific root@
Now restart the printer. If you now ssh into the printer then the date command should show the correct timezone, but will still show the incorrect time. You can correct the time by ssh'ing back into the printer and using the date command. To set the date, you need to call date with a bunch of numbers in the format MMDDhhmmYYYY where MM is the 2 digit month, DD is the 2 digit date, hh is the 2 hour time (in 24 hour format), mm is the minute, and YYYY is the 4 digit year. For example:
186 >ssh root@
root@raise3d:~# date 022023562016
Sat Feb 20 23:56:00 PST 2016

Tuesday, February 16, 2016

Raise3D N2 Printer - Unpacking and First Print

I ordered a Raise3D N2 printer as part of a KickStarter campaign. All of the Canadian orders were container shipped to the good folks at and then shipped out to individuals.

Mine finally arrived. Wow, that's a huge box (about 28" x 29" x 32").

It was fairly easy to unpack. My outside door is 36" so it came in through that easily, but with the cardboard cap and bottom on, it wouldn't quite fit through a 30" door opening (at least not without removing the door), so I unboxed it in the hallway and then moved it. The printer was very well packed, and the cardboard only had minor gouges and scratches on the bottom.

The buildplate was covered in BuildTak, but they didn't do a very good job applying it. Mine had at least a dozen bubbles on it. I used a rounded piece of plastic to smooth out the bubble and pricked each one with a pin to allow the air to escape.This photo was taken from the back (glass side).

Here's a photo from the BuildTak side before I removed the bubbles. It probably took me half an hour or so to remove all of the bubbles.

IdeaMaker (Raise3D's slicing software) is currently only available for Windows and Mac (they claim that a Linux version is forthcoming - I hope). I had to install windows on one of my laptops so I could run IdeaMaker. I tried running in a VM, but it immedialtely crashed. As far as I can tell, you can use any slicing software you like, so you should be able to use other slicers as well.

Here's a video of my very first print. I normally don't print a raft, but it seems to have added one. I expect that this is just a setting in the software someplace. I decided to do a Marvin as my first print. I made no adjustments to the printer before printing this. I upgraded to the dual extruder option, and my printer came with one spool of red PLA and one spool of yellow PLA. I printed the Marvin using the red PLA.

The printer comes with a builtin touch screen. Here's a shot while it was part way through printing.

The windows software can connect to the printer over the network and upload files to internal storage. It turns out you can ssh into the printer too. The printer contains a processor running linux to manage the network and touch screen, and also has a processor for doing the realtime control. Unfortunately, the root account on the linux side of things has no password (which is bad). If you set a root password, then the windows software will no longer connect remotely to the printer. Hopefully, they'll add an option to use passwordless ssh login so that I can set a root password.

Here's a shot while printing.

The build platform has 2 leadscrews, one on the middle of each side.

A shot through the front door, while printing.

The finished print. I let the build plate cool down to about 29C and was able to remove the Marvin by hand. This was sliced using medium settings (0.15mm layer height) in the IdeaMaker software.

A shot of the teeny tiny Marvin in the middle of the build plate (you can supposedly print 12" x 12" x 12").

Marvin removed from the build plate. I was able to remove the Marvin from the raft by hand.

The filament cooling could definitely be improved. There were some droops on the back due to insufficient cooling. Fortunately, it looks like it will be possible to wire in an additional fan or 2. I recommend signing up for the Raise 3D Mailing List. There have already been several mods posted.

That's all for now. I look forward to using this more.

Sunday, April 26, 2015

OX - More clamps and a TinyG firmware issue

I printed some clamps and knobs on my 3D printer:

I put them together like this:

You can find the stl files here, and the original OnShape CAD files here.

I used a cut piece of 1/4"-20 allthread for the stud. I used a punch to damage the bottom thread so the stud would stop at the bottom:

 This shows the stud being stopped. If it works its way through, I just bang on it some more!

4 clamps seems to work quite well for holding sheet stock down.

I started to cut a larger piece and my z-axis wound up dropping as it was cutting. I forgot to take some photos, but this was the aftermath:

After some vacuuming:

This was caused because the z-axis stepper was disabled while it was cutting, and then the cutting forces wound up pulling the head deeper and deeper into the cut.

I was running TinyG firmware version 438.02. I hooked up an LED to the Z-axis enable line on the TinyG board and sure enough, I could see the stepper driver being disabled while X & Y were still moving. I had the power management setting for all 4 motors set to 2, which is supposed to keep the motor enabled while any other axis is moving.

I asked about this over on the ChiliPeppr Google Plus group and it seems it was a firmware issue. So I downloaded the 440.14 firmware, flashed it, and immediately lost all of my settings. Sigh.

That created another diversion, and I went off and wrote a python program for archiving, restoring and viewing configuration files. You can find here. I've only tested it under linux, but it should work under Windows and Mac as well. Let me know if you have any suggestions, comments, issues, etc.

With the new firmware installed and my settings restored, I was able to cut the piece, and the z-axis stepper stayed energized through the entire cut. Here's a short video of the start of the cut:

That was cut with 1.5mm depth of cut 800 mm/sec travel, and max RPM (which I believe is around 12,000 RPM). This was the finished cut.

The flip side was white vinyl, and since I was using an up cut endmill, I put the good side down so it would have a clean edge:

That's all for now.

Saturday, April 11, 2015

Spray Can Tube Clip

I seem to forever lose those little (often red) tubes that come with my spray cans (normally with lubricant os some sort).

I've tried using elastics, but they often seem to disinegrate, so I decided to print something that would hold the little red tube instead:

Just stick the tube in:

and clip it to the can:

I created the file in OpenSCAD, and set it up to that you can easily customize various parameters (most likely can diameter and tube diameter, plus a few more). You can find the files on thingiverse.

Thursday, April 9, 2015

OX Build - Part 6 - Spindle and First Cut

Related: Unboxing, Part 1Part 2, Part 3, Part 4, Part 5Clamps

Since I decided to change my Z-axis bearings to proper thrust bearings, I was concerned about getting dust in the bearings.

Here's a side view of the thrust bearing:

I also noticed that the leadscrew was projecting below the bottom of the z-axis:

I also noticed my TinyG hanging below the cross bar, so I'll need to fix that as well. I wouldn't want that to catch a clamp. I cut the bottom piece off the end of the leadscrew and printed an end cap and some shields for the thrust bearings:

The endcap worked out great, but I had to make a few more refinements to the other 2 pieces in order to have the dust shields not hit the X gantry plate. I forgot to take picttures of the new parts, but you can see the changes in the STL files.

I recessed the screw heads and used button head cap screws, making the dust cap about the same thickness as the low profile screws used to hold the adapter plate:

This shows the thrust bearing inside the dust shield on the lower portion:

And the upper portion:

I printed up a spindle mount:

After installing, I don't like the fact that the mounting screws are hidden once the spindle is installed (but I'll fix that at a later time):

Here it is with the spindle installed:

And a video showing the Z rapids after a bit of tuning.

Ready to start cutting. Well almost. When I turned the spindle on, I totally lost all of my comms with the TinyG board. I verified that the noise was being introduced in the first cable chain. If I plugged the USB into the TinyG directly then it worked fine. I had two unshielded twisted power lines, so my first attempt to fix things was to replace the spindle power with a shielded cable run. That improved things, but not completely. The USB connection would bounce when the spindle was turned on, but would be usable after that.

I then looked closely at the USB cable I was using:

The cable has shielding, but it doesn't seem to be connected to anything. Sure enough, no connectivity from the shield on one end to the other.

I swapped in another USB cable. My multimeter confirmed that the shield was connected through, and everything works.

For my first part, I decided to try and create a T-nut out of some 1/4" hardboard. I first designed the part in OnShape:

I then created a sketch and "Used" (aka projected) all of the features onto it and exported that sketch as a DXF. The orange lines are the projected features:

I then imported the DXF into CamBam. The white lines are the DXF features. I added a pocket operation for the large recess, a pocket for the center hole that goes through all of the way, and finally, added a profile operation for the outline. CamBam supports tabs, so I added a tab on each side. These are small unmachined pieces which are left behind to keep the main part from moving while performing the very final operations. The tabs are represented by the rectangles you can see. If you look at the toolpath (blue and green lines except for the tabs) you can see that Z rises up to leave the tab behind:

I used a 3.175mm endmill for all of the operations, 600 mm/min feedrate, 100 mm/min plunge rate. The recommended depth of cut for MDF is 50% of the tool diameter, so I used numbers around 1.5mm for the depth increment, and for the final profile I used a cut width of 4mm so that the first cut (which is full width of the cutter) wasn't the final cut. The final cut would wind up being 4 - 3.175mm = 0.825mm, which will generally give a better finish than the finish on a full width cut.

I then generated the gcode, and ran it through OpenSCAM to verify that everything looked good:

Here's a video of the first cut:

And a photo of the finished cut:

And the spoiler board (I used some 1/8" hardboard). My total cut depth was 6.85mm for the 6.35mm (1/4") material:

This shows the tabs:

This is the T-nut cleaned up a bit:

The metal propel nut didn't want to go in, so I woud up drilling 3 extra holes:

And now the propel nut goes in fine:

So I'll have to modify my model to drill those 3 extra holes. Here's the T-nut in the slot:

I since discovered that you can import STLs into CamBam:

which doesn't look all that impressive. However, if you select the Surface, and then choose Edit->Surface->Edge Detect, and then delete the Surface object, you'll wind up with this much nicer looking wire frame:

And you can click on polylines from the wireframe to perform machining operations with.

I used the 3D printed T-nuts, a few scraps of wood with drilled holes, some all thread and knobs for my first clamps:

I think my next project will be some decent clamps.

3D Printed Parts:

Dust CoverOnShapeSTEP & STL
52mm Spindle MountOnShapeSTEP & STL

Related: Unboxing, Part 1Part 2, Part 3, Part 4, Part 5Clamps