Printing - More And Maker Faire UK...

Last week we went to the Maker Faire in Newcastle (England). It was fantastic and my youngest really enjoyed building a flashing LED name badge. There were quite a few 3D printers with one guy demonstrating a 3D router built out of 3 old flat bed scanners and a Dremmel type device. The whole thing was held together in a retired PC case. Hacking at its best! There were a few Makerbot devices, a Cup Cake and a guy in the throws of building a Rostock. There was good STEM support and Daleks to boot. You could have spent all day there, we did! The people were fantastic and the food was good value for money. For once we were not ripped off by a venue, thanks Centre For Life.

I went ready to buy filament but found none for sale and no 3D printers for sale either, but plenty of working printers and lots of people ready to talk to about 3D printing.

I managed to post our Minecraft Creeper derivative this week as we have not been twiddling much with

Huxley #710 - First Print

Huxley #710, having had so much fun at Maker Faire. I also managed to find a picture of Huxley #710 in completed form. This picture was taken during Huxley #710's first print of a whistle, Thing 1046.

The Minecraft Creeper shown here is a derivative of Thing 11825. The boys wanted a version that had improved facial features (no drooping) and a swivel head. So I created a clip that fits into the body and head. We have printed around 10 of these now, as the boys friends wanted some. At Maker Faire UK (Newcastle), Creepers were seen hanging out on top of the Printcraft computer monitors. But yours could look around! (The leg pitch is just over 11mm).

The clip arms are designed to compress together completely and be a snug fit into the holes in the head and body. If your printer produces blobs on parts you may have to clean up the clip to avoid issues assembling the clips. The images shown are how Huxley #710 prints parts, no clean up was required or performed. Similarly if your holes are too small or too large then you might have issues. I posted STEP files so you can tweak things if you prefer.

Minecraft Creeper - Thing 83942

Design For Manufacture
By removing the head from the body, the head can be printed without distortion. Tthe drooping seen in the green creeper (our first, whose head does not move). The mating features are designed to locate and allow rotation. The clearance between the head and body bearing location diameters and the clip centre locating diameter is 0.20mm by design. To accommodate the slightly out of round holes manufactured in FDM layer manufacture. The clip deformation assumes a non brittle material in this case Faberdashery PLA. As the clip is significantly deformed on insertion into the head and body. The part was printed as three elements as a clip on the head or body might have needed material support. The clip is intended for use in other assemblies and allow for repair, if required. Which would be more of an issue with parts having integrated clip features. At the time the clip was designed, there were limited versions on Thingiverse. A redesign might use one of the clip designs on Thingiverse.

Minecraft Creeper - Thing 83942

Safety
This item has small parts and is not suitable for young children as a result. With some effort our Creeper head could be removed, unlike Lego Duplo characters for example.

Sample Part Manufacturing Technical Documentation
Printer : Huxley #710 (RepRap Pro)
Firmware : Marlin 1.0.0 RC2 - 15 Feb 2013
Software : RepRap Pro Software 811708f - Pronterface
Material : PLA - Faberdashery - Arctice Whilte - Village Green
Material Dia. : 1.75 mm (Msd 1.80 mm )
Nozzle : 0.50 mm
Layer height : 0.25 mm
Layer width : 0.6 mm
Extrusion T : 198 C
Bed T : 60 C
Feed Rate : 28 mm/s
Perimiter rat. : 0.5
Infil pattern : Hexagonal
Infil solidity : 0.15
Cooling Fan : Yes
Bed material : Borosilicate Glass
Over hangs : Yes
Support : No
Design For Manufacture Parameters
Model : Absolute dimensions
Scale : 1:1
Holes : Yes
Layer height : 0.30 mm
Layer width : 0.6 mm
Over hangs : Yes
Support : No

Model Tools
Function: Model Fix up
Tool: NetFab Studio Basic
Version: 4.9

Utility cabinet lock

Safety
The item below is intended only for a Utility Cabinet which has no service equipment fitted.

Unique Utility Box Key And Lock

This week I designed a new lock for a spare utility box outside our house. I suspect the gas utility supplier told the builder they could not use the original location due to its proximity behind the central heating system and directly below the exhaust flue!

So I have re-tasked the cupboard as an external water tap box. This will keep the tap warm in winter and secure. The water already runs on the other side of the wall to the central heating and there was even a hole through the wall for a water pipe.

To be able to use the Utility Box in this way we had to prevent any accidental entry to the wrong boxes. So we could not allow the standard Utility Box key to be used for this box. A custom key was required.

I designed a new key and lock based on the current lock and Thing 88,  created by Nophead. Using the STL to STEP conversion program to allow easy modification and a new key element to be added. I then measured the original elements, having removed the spring washer and parts from the box.

In the original design, the lever has a moulded triangle and uses a spring washer to retain the moulded part in place. This could simply have been inverted but would have meant the key would be very unique and annoying if lost. Additionally the standard cabinets may be opened by utility company service personnel. Any implementation should not be mistaken as simply a key they may not seen before even if they were inexperienced. Despite there is nothing dangerous inside the box.

There are two parts to the lock, the barrel which has a square drive to mate with the lever. The whole assembly is kept together with a stainless steel screw inside the box. Holding the lever against the barrel through the cabinet door via the square drive. The key shown at the top of the image fits from the outside as if its a normal key but will not open the standard utility cabinets. As it can't drive the triangle form used on a standard cabinet. Printing used the parameters shown above. The Key prints in one piece (upside down from that shown in the image).

'Hey - Presto' new key and no risk of people going in the wrong box. A unique solution for a unique situation. If we loose the key, the unit can be opened with a standard Allen Key. In the event we move, no issues for new occupants either, although I will leave the original parts in the box.

Printing - Test Objects And Other Things

Thing 64549 by Conseils - derivative:35077

There are many test objects on Thingiverse for 3D printers, each with its own particular purpose. Recently Makerbot released its own STL test object into the wild. According to the Makerbot blog, its primary intention is to test slicing engines. Below is how I managed with Thing 64549 on Huxley #710

This month has been about design and printing rather than twiddling with Huxley#710. I also ran a rapid prototyping course for my colleagues so they could appreciate some of the benefits and limitations of 3D printing technologies.

You can see the printed test object in PLA Faberdashery Village Green. I chose this colour for a number of reasons. The main being I had sufficient for the print, I also like the colour. But the second reason is our eyes are most sensitive to green / yellow additionally my camera seems to represent the colour well. Finally, it was in the printer as we also use it for printing Minecraft creepers, which the boys have been selling at school. The youngest forgot to negotiate with the manufacturer and was surprised the manufacturer had to make a profit too! More than one dimension to using a 3D printer, practical lessons in business, scheduling, bills of material, quality, design for manufacture, costing and so on!

Dimensional drawing of Thing 64549

Slicing the object took around 4 hours and I left it to run without monitoring the computer. I had no problems using the original file, which seems to have been a problem for some peoples slicing engines. Of course this would appear to be the principle purpose of the file, to test slicing engines. So an STL clean up could be considered an unrealistic test at some levels. Netfabb reported the model file Manifold, however InStep reported a few inconsistencies in the file. Knowing the tool chain used to produce the STL file would be helpful to know what the design intent is for various features in the model. So the usefulness of the STL file without this information is somewhat limited.

We can't for example understand what influence the specifying geometry has interacting with the STL generation. Although not the principle purpose of the test, it would non the less be very useful. For example my CAD program has limited (crippled) STL output resolution for curves. You can see this sometimes where peoples STL curved features have steps in them. As the STL is after all generally triangular facets, the output filter will also usually set an angular resolution. As an STL object though, it has features which clearly 'stress' a slicing engine.

For the test object the following tools and settings were used for printing:

Sample Part Manufacturing Technical Documentation
Printer : Huxley #710 (RepRap Pro)
Firmware : Marlin 1.0.0 RC2 - 15 Feb 2013
Software : RepRap Pro Software 811708f - Pronterface
Material : PLA - Faberdashery - Village Green
Material Dia. : 1.75 mm (Msd 1.80 mm )
Nozzle : 0.50 mm
Layer height : 0.25 mm
Layer width : 0.6 mm
Extrusion T : 198 C
Bed T : 60 C
Feed Rate : 28 mm/s
Perimiter rat. : 0.5
Cooling Fan : Yes
Bed material : Borosilicate Glass
Over hangs : Yes
Support : No
Print Time : 04:37
Material : ~ 21.2m

Model Tools - Used only for inspection of the design in this print - Original file sliced
Function: Model Fix up
Tool: NetFab Studio Basic
Version: 4.9

Thing 64549 by Makerbot

Comments
The design of this test beast is quite nice and there is clearly some thought put in the model. I saw some reports of issues, but I had none. It printed straight from the model which is important, if it's the slicing engine you are trying to benchmark. Although the 21m of filament and 4 hour print time with my default settings mean I won't be repeating a print of this soon.

The slicing engine put in a full solid layer across the 4.5 mm first platform step from the bottom. This would only really be needed under the bridged area above the spiral and cylinders. The Slicing engine has obviously simplified the representation, using quite a bit of plastic in the process. As this could have been left open being and interior feature. Additionally it would have made the print easier reducing shrinkage forces, to assist with polymer bed adhesion. This effect occurs each time a new layer of the same type is employed. Subsequently leading to shrinkage distortions in the part, visible as irregularities in the wall edges.

Generally quite happy with the results. Especially bridging, as I always thought it was a problem for Huxley #710, it appears not. Though clearly a fan is required. In fact I think slicing needs modifying for unsupported overhangs to modify the extrusion rate and nozzle velocity. I imagine Makerbot are checking filament quality as well with all the colours shown in the article. As printed items will be affected by filament diameter, melt viscosity etc. which will be influenced by the additives in the filament and base polymer quality.

From the reference page here are my results
1) Some spiral elements not filled
2) Block dimensions good (+0.15mm)
3) Internals spurs as Makerbot example
4) 5.5mm high, not quite square as per the model. No output from slicing engine.
5) Beautifully flat
6) All bridges correctly formed, some minor sagging. Does require a cooling fan.
7) Wall clearly don't have spurs but there are some interesting effects from quantisation, rounding and flow. Otherwise quite good.
8) Cylinders appear round 9.95, 8.18, 6.09, 4.16, 2.31
9) Removal gap, not needed with the glass bed.

Makerbot annotated view of Thing 64549

Summary
The quality of the slicing engine clearly has an important impact on what's printed, of course tuning and alignment matter as well. I quite frequently find myself designing around the slicing engine and printer, in design for manufacture. An improved slicing engine would help and I suspect there are more parameters to be considered in the design than called out above.
Some tuning is required to my retract rate for the nozzle plastic as I have little blobs at the start of extrusions which might be improved. This would impact both the pyramid and 2.00 mm cylinder.
Huxley #710 is performing nicely though.


There is a huge amount we don't know about the object, related to the tool chain used in its creation. So the value of its release is limited, perhaps intentionally. The drawing of 64549 included here should help if you want to better understand the meaning of your print. My CAD program would not generate the same font used in the test object and the STL to STEP converter I have being testing could not handle the large STL file or small sections, an unintentional benefit. I did send it to Solve Engineering but am awaiting a response. I also discovered limitations in my CAD program's ability to produce spiral features, which would require some script to overcome. STEP files of my model and a no version model can be downloaded from the associated links if you want to test your own tool chain.

Here are some useful CAD, Meshlab and Netfab views of the object. The intention of the Meshlab views here is to show the mesh construction. The STL could have had included errors in it.In order to test the slicing engine.

Meshlab rendered view of Thing 64549

Meshlab Wire frame view of Thing 64549

Meshlab point cloud of Thing 64549

NetFabb rendered view of Thing 64549

NetFabb mesh view of Thing 64549

Here are a few of the Things we have printed this month.

Derivative 34708 - Earbud holder

Just because it was useful, Thing 53455.

Derivative 25949 - Compressor Wheel

Working Panelolu 2 I2C...

I managed to configure and compile the latest version of Marlin on Huxley #710. Huxley #710 consists of a Sanguinololu board upgraded with an ATMEGA 1284 PU. Now with a Microchip MCP23017 I²C I/O Expander controlling a Hitachi HD44780 compatible display device. The prototype hardware configuration previously tested worked a treat, however the new Marlin software did not work quite so readily. The new Marlin software makes Huxley #710's display compatible with Tony's Panelolu 2 implementation but at a cost.

Huxley #710 - Panelolu 2 Using I2C interface

The enabling addition to Marlin is that it now includes references to the LiquidTWI2 library selected by Tony for Panelolu 2. This Arduino library provides support for the Microchip I2C integrated circuit and a connected Hitachi HD44780 compatible display device.

The library extensions also allows for buttons, LED's and a buzzer to be included. The buttons, buzzer and additional LED's are not included on the prototype hardware.


The display shown in the image is a Radio Spares (RS) 720-0226 Fordata FDCC2004B-FLYYBW-51SE. Note that only 4 wires are used in the multi colour ribbon cable 0v, +5v and two for the I2C communication.

The software issue was associated with the Buzzer implementation in the Panelolu 2 implementation. It seems from the error report that the lcd.buzz(300, 4000) function can't be located in the LiquidTWI2 library. The reported error was 'Error undefined reference to LiquidTWI2::buzz(long, unsigned char)'. For the moment I have commented out this line in the ultralcd.cpp module, as I don't have a buzzer attached to my prototype hardware.

The compiled size using the LiquidTWI2 library came to 100,650 of 129,024 bytes in the ATMEGA 1284 PU part. This is an increase of 27,130 bytes above the 73,520 of my PCF8574 implementation based on the LiquidCrystal_I2C for the Arduino using a Phillips (NXP) I2C chip PCF8574P. That's quite a footprint increase in the memory. At the moment I don't know what the root cause is, or what scope there might be to improve the situation.

I like the updated screen format on the display and the custom font definitions for indications of temperature and time for example. The screen update rate seems to perform reasonably well and the only thing I think I need to change is the 'Mendel Ready.' to suit Huxley #710. It would be nice if Marlin pulled up a machine name string from the configuration.h file.

Huxley #710 - Marlin LCD Menu

Next I need to design a panel for Huxley #710 based on my display type and I hope to allow support for the larger bezels that often seem to be used in the Panelolu display. Additionally I need to decide how much of the Panelolu 2 hardware to implement and if to use a custom PCB or a strip board implementation.

HD44780 Compatible display used on Huxley #710

Huxley #710 - I2C Panelolu Test...

Sanguinololu Huxley #710 connection to I2C And Panelolu 2

I received the Microchip MCP23017 I²C I/O Expander parts this week and put one on a prototype board to test out with the Sanguinololu hardware on Huxley #710. This implementation is intended to be compatible with the Panelolu I²C update.

Background
The intended configuration consists of the MCP23017 connected to a parallel LCD display device based on the Hitachi HD44780 device.  The MCP23017 device has an I²C connection (I2C) which can control 16 input / output lines. The input / output line direction can be configured independently.  There is an interrupt feature, where the chip monitors configured input lines and generate an interrupt when a change occurs. Useful, as the CPU can get on with other things and respond to an interrupt when it feels like it, without having to poll pins configured as inputs.

Using the I2C rather than a 4 bit parallel connection, releases I/O pins on the Sanguinololu board for things such as multiple extruder heads! Additionally more hardware can be tacked on the end of the I2C channel, less wires are needed and they can be screened more easily.

You can see my previous implementation using a more constrained I2C device here. 

Note

Huxley #710 Microchip I2C Panelolu Test

Although there is quite a thick ribbon cable running to the prototype board, only 4 wires in use!
The lead was recovered from an old personal computer and I use it for prototyping connections as it saves me making up cables until the project is stable. You can just see the connections from the ribbon cable at the back of the ribbon connection to the prototyping board.

There are two connections for the I2C (Yellow and White) and 5v power supply (Red and Blue) to the power strip at the rear of the prototype board. The LCD connections are 4 bits for the communication, 3 bits for RS,RW and E of the HD44780 compatible display unit.

Microchip I²C I/O Expander

Huxley #710 Sanguinololu Rev 1.3a PCB

Connections To EXT Connector

+5v
0v
SDA
SCL
Reset - later


The resistor (10kΩ) shown connected to the Microchip MCP23017 part is connected to the MCP23017 reset line to make sure that the reset line is not floating. The reset line could be tied to the reset on the expansion socket of the Sanguinolou board, but for the moment I thought I would do without it for testing.

The connector being used is the EXT connector which is the 14 way connector next to the ISP/SPI port connection used to program an Atmel device or connect an SPI device such as the SD card.

Huxley #710 Sanguinololu Rev 1.3a PCB Expansion connectors

On the Huxley machines the SD card connects to the ISP/SPI port and two pins on the EXT connection. One of the pins is not used (SCL/D16). The other pin, A0 pin acts as the device select line for the SD card. In principle more SPI devices can be added to the interface. Each requiring a device select line (more on that later). When the final display unit is implemented this pin will be used together with the SDA/D17 line.

Sanguinololu Rev 1.2 PCB Render

To test out the connections to the MCP23017  I used a small piece of software called I2C_scanner. It's really cool because it does not use any third party libraries and reports any device hanging off the I2C bus. You can find it here in the Arduino Playground.

I compiled this and downloaded it onto Huxley #710 to determine if the I2C device could be seen by the ATMega part on the EXT connection. The program scans all the I2C addresses from 0 to 127 and writes what if finds to the serial port, which you can monitor using the Serial Monitor (Ctrl+Shift+M key combination) in the Arduino software. I am now on 1.0.3 of Arduino by the way. You can see the output on the terminal screen shows that a device is present at address 0x20 which is the correct address for the MCP23017 with all the address lines held at 0v.

I2C Scanner output screen on the terminal

The output from the I2C scanner software on the serial terminal monitor in the Arduino software is very plain, but when you are hooking things up you don't want bells and whistles!

Having verified the hooked up Microchip I2C device, I connected the display to the I2C device and get the library working that Tony has selected for use with the I2C Panelolu device.

Testing with the LiquidTW2 Library
Testing with the LiquidTWI2 library next using the sample programme I had changed the code so that it would intialise the MCP23017 in the setup routine initially, I had issues compiling the Hello_i2C_LCD.ino sample programme. My code fragment looked like this:
// Connect via i2c, default address #0 (A0-A2 not jumpered)
LiquidTWI2 lcd(0x20);  // SC All MCP23017 address lines pulled to 0V

void setup() {
// set the LCD type
// lcd.setMCPType(LTI_TYPE_MCP23008);
  lcd.setMCPType(LTI_TYPE_MCP23017);
// set up the LCD's number of rows and columns:
lcd.begin(20, 4); // I have a 20 character by 4 line display
// Print a message to the LCD.
lcd.print("hello, world!");
}

This gave rise to the error shown below:
Hello_i2C_LCD.ino: In function 'void setup()':
Hello_i2C_LCD:26: error: 'class LiquidTWI2' has no member named 'setMCPType'

The error seemed to be with the definition of setMCPType however following an exchange with Lincomatic on GitHub who indicated that the setMCPType only needs calling if both devices are used. So using the following in the Hello_i2C_LCD example:

// lcd.setMCPType(LTI_TYPE_MCP23008);
// lcd.setMCPType(LTI_TYPE_MCP23017);


With both setMCPType lines commented out, the code compiled and downloaded successfully running the display as expected.

Latest news - an update library has been released (20 Jan 2012) which allows the definition to be retained as shown in the code shown above handling the issues internally. So I imagine either way will work now.

Next stop, integrate all this into Marlin - configure, design a custom panel and have fun...

I2C - LCD Test connection to Huxley #710

The futures Borosilicate...perhaps

Bath University April 2012 - The calm before the storm!

Amongst many of the comments passed whilst building Huxley #710 at Bath University. One stuck in my mind made when watching the guys print a parliament of Owls. We had seen filament being wiped by a sponge before entering the printer. But I also noticed glass on the table of one of the printers rather than the more usual Kapton tape. Whilst discussing the pros and cons, out popped the comment "Adrian Bowyer only prints on glass now". At the time we were reviewing his machine which had, amongst other things an interesting X carriage.

Now one of the things that sticks in my mind from physics at school, from a superb physics teacher (Mr J Jarzecki), was that heat and glass don't mix! To the amazement of the class and without safety net (although I do recall safety glasses, he was very advanced!) he applied heat from a bunsen burner to the center of a piece of glass to show that the glass expanded where heated and not away from the heat i.e. unevenly creating stresses in the material. Sure enough it did! Splitting, with rather a loud crack and if I recall the glass fell off the metal tripod it was positioned on with a smack.

When living in France, many years later, in the summer of 2003 (El Niño year), I asked for some windows to be painted to block the heat from the sun. I had expected them to be painted white, to my amazement they were painted black! Sure enough they cracked, probably as the steel frames were restricting the expansion and putting the glass under strain. Mr Jarzecki was right!

You can therefore imagine why I opted to reserve judgement on the glass table, until I had the opportunity to ask a few more questions and do some research.

Unfortunately my research left me no clearer as to an answer, simple and straight forward. On the one hand, some blogs seemed to indicate problems with PLA on glass. Then others seemed to say it was the greatest thing since - well, sliced bread.


Here are a few:
http://hydraraptor.blogspot.co.uk/2010/05/pla-on-glass.html
forums.reprap.org/read.php?1,35071,49047#msg-49047
forums.reprap.org/read.php?1,33327,51041#msg-51041
http://www.emakershop.com/forum?vasthtmlaction=viewtopic&t=592.0
http://www.emakershop.com/forum?vasthtmlaction=viewtopic&t=48.0
https://groups.google.com/forum/#!topic/bay-area-reprap/or_mVVH-y9g

And I am sure there must be quite a few more read.

Adrian Bowyer - Printing on glass

After hunting around for some glass ideally very cheap, if not free. I found some picture frames in IKEA with glass. These are getting rarer now as they seem to be moving to plastic sheet. Whilst thinner than the glass recommended by Adrian Bowyer (see video), I thought they should do. Additionally they had nice rounded edges. The thought of the Y table slicing my fingers off and the blood mucking up a print was vivid in my mind. I also didn't want the boys to slice themselves up!

As you might have guessed, no matter what I tried, I could not get PLA to stick to the stuff. It was OK in the middle but would peel from the edges readily and did not seem to have the adhesion that printing on Kapton tape gave. I tried all sorts of temperatures up to 100C in 5C increments. Cleaning the glass with nail varnish (Tesco brand no fancy additives). Measuring the temperature with traceable measurement equipment to ensure the required temperature were being reached on the surface of the glass and so on. Mr Jarzecki would be proud of the scientific approach, but all to no avail. Every print curled off the table from the edges, although the surface was superb. So I used the glass as an interchangeable table upon which I applied the Kapton tape; which was significantly easier that trying to place it on the Aluminum print bed directly!

I had almost given up on totally smooth surfaces like Nophead's, not fooling with Kapton tape for an hour to get all the bubbles out and the tape aligned nicely so there are no big gaps!

In the depths of my research on the topic I did however remember reading about Borosilicate glass (aka Pyrex) in a few locations and this seemed like a reasonable idea as it should at least withstand pretty poor thermal coupling and thermal cycling likely to arise from localized hotspots on the table and frequent use. Additionally I had not used the thickness recommended by Adrian, so perhaps some room for improvement.

With this in mind, I purchased some Borosilicate glass which was only available in 3.3mm thickness but that's twice the thickness of the IKEA picture frame glass. It was expensive, at least the 140mm by 140mm sheet I purchased was. Additionally the shop told me "it's a devil to cut" and the glass specialist told met they can not round the edges. So 25 UKP later I have some Borosilicate glass set up on Huxley #710.

The performance to date has been superb!

Borosilicate Glass Table Recipe
Table surface	Borosilicate glass 3.3 mm
Table temperature	60C
Material	PLA - Faberdashery Arctic White
Extrusion temperature	196C

Huxley #710 printing PLA on Borosilicate glass

Borosilicate Glass Table Technique
Heat the table to 60C, ensure its the top of the glass table at this temperature. I have a 20C thermal gradient between the indicated table temperature and my thermocouple bead on the top of the glass. Allow at least 5 minutes to thermally soak. Print the part, if using a fan I start it after the first layer has completed as the table will cool a little with the fan on. I leave the table heated throughout the print.
At the end of the print allow table to cool with fan. The part always seems to comes off readily by hand once the table has dropped below about 40C. Frequently there is a little crack as the tension of the plastic relieves once the table releases the part. If your fan is too power full it could blow the part off the table!

For PLA at least, no scraping, aligning tape or bashing parts to get them off! The futures Borosilicate for Huxley #710!






Adrian Bowyer video location
http://reprap.org/wiki/Mendel_User_Manual:_Host_Software#Heated_beds

Huxley Panelolu display and heated bed...

Ever since I saw the Panelolu LCD display for a RepRap printer, I just had to have one for Huxley #710. Unfortunately the original implementation used most of the I/O pins available and meant that one had to loose the heated bed and possibility of self setting bed height (not in a release yet as far as I know). Additionally any further developments that RepRap Pro might choose to implement might be blocked.

HD44780 Compatible display

With this in mind I have been working on an I2C implementation of Panelolu type display system. A couple of weeks ago I managed to implement the software based on Marlin release 97fa2a9c30 28 November 2012.

There are a number of advantages of an I2C implementation:

• Only two I/O pins are required.
• More i/o can be added on the same two wires.
• The lines can be longer than a parallel implementation and readily screened.
• The Atmel part has a native I2C port
• Lots of support in Arduino libraries
• Could be bit banged if necessary

The principle disadvantage is the speed limitation associated with a serial communications interface. Polling is also not a good idea due to the speed limitation. Although it might be possible to implement an interrupt feature to support better responsiveness on the proviso it does not interfere with the printer software.

The implementation was based on the LiquidCrystal_I2C for the Arduino using a Phillips (NXP) I2C chip PCF8574P as described in the libraries associated documentation. Using this device a serial communication can be achieved to a parallel I/O port.  This essentially allows for a serial to parallel conversion and thus control of a HD44780 compatible LCD display device as used in the Panelolu design. The chip also has bi-directional i/o ports. Thus supporting input as well as output. So the plan was to use two devices one for the display and one for the switches etc.

The good, the bad and the ugly...
The great thing about open sources is that you get to benefit from lots of people working on projects thus 'standing on the shoulders of giant's'. Simultaneously of course you can find yourself working in parallel on a blind alley. In this case I selected the chip as the library seemed well supported and the chip is low cost, with alternates out there that would not lock a solution into one device.

LiquidCrystal_I2C implementation from the notes

After finishing the code, I was looking around the internet and came across an update from Think3DPrint3d who designed the Panelolu. Tony has also been working on an I2C implementation and has elected to work with a Microchip I2C part MCP23017. This beast has twice the I/O capability of the Philips part and the Microchip MCP23008 I2C part.

So I have decided to junk the Philips part and switch to the Microchip part as one part will support both the LCD and the keboard.

Whilst doing this, I also developed a CAD model to allow me to implement a neat box for my display and keyboard. If you would like a copy of the HD44780 STEP model for the 20 x 4 model, you can download it from here. You can get the software configured for Huxley #710 here. I have no intention of taking this software forward in this form at the moment. I have ordered the Microchip part so that I am hardware compatible with the upcoming Panelolu implementation.

Either way, I will have Huxley #710 running with the Microchip part by the end of January at the latest. Until then, the LCD panel with the Philips part is fantastic. The temperature updates are rapid and the status updates on the display are very handy.

RS 720-0226 Fordata FDCC2004B-FLYYBW-51SE

I may yet implement the Nokia 5110 display with Huxley #710, a graphic of the part being printed would be cool on a progress style screen. At the moment though we are just having too much fun printing and working with our new glass table!

Sparkfun Nokia 5110 LCD Display CAD mode

Christmas is going to be Fab..erdashery

Utterly fantastic service from Faberdashery

Thing 38444

I saw the robot and light sabre on Thingiverse this week and thought the boys might like to print one over the seasonal holidays. Along with the easier to print 'Mini Programable Cryptex' that has proven very popular at home and on Thingiverse. We needed more filament and fast! Before Christmas, I was not holding out much hope to say the least!

Faberdashery were recommended by the RepRap Pro guys down at Bath University and I have always been pleased with the quality of the Faberdashery PLA filament. My children tell me the smell is sweet when we print; although I personally can't detect any odour. Then again I have been working with polymers all my life, so it could be I just don't smell them anymore. The colour is always even through the roll and seems to be a consistent diameter based on my repeated measurements. I had a kink once in the tail end of a white roll but that could have been me, it pulled out readily enough. There have never been any issues with feed or blocking through the extruder and never any signs of excessive moisture in the filament which would lead to bubbles in the print.

Thing 37745

I ordered Robot silver and Bling Bling Gold and to my delight and amazement Faberdashery have managed to pull out all the stops and delivered our order, exceeding my expectations completely. 24 hours by post not a carrier, in the run up to Christmas with all the orders they must have had! The boys are ecstatic and its not even Christmas day!

Blink Bling Gold looks perfect for the Mini Programable Cryptex and the Robot Silver now looks as though it might offer a nice contrast for the separator segments.

If you have ever wonderd what a shipment from Faberdashery looks like, here are a few pictures (you can click on them for higher resolution images).

Fabersdashery

Chirstmas is HERE!

Beautiful colors

Look carefully!

It's Christmas just opening the pack! Look carefully under the beautiful Bling Bling Gold. There peeking from the bottom, is a beautiful sample of what looks like Raspberry Spark.

Compliments of the season and thanks Faberdashery.