Author Archives: Gary Hodgson

Thing Tracker Network Update

March 9, 2013 – 12:58 am

Time flies! It’s been almost two months since I posted about the Thing Tracker Network (TTN). Recently progress has slowed down to a crawl, mainly due to other priorities (RepRap Magazine, work, family, imminent house move, etc, y’know the usual things), and also because I am taking a slight detour with regard to TTN which I want to briefly describe here.

After the initial excitement of announcing the proposal there have been a series of suggestions and improvements which I have attempted to merge into the specification. I think the current version is a reasonable basis for defining Things and the relationships between them. Expanding to include the possibility of adding detailed bill-of-materials and tracker metadata, for example.

A quick aside: there are now several resources that make up the infrastructure of TTN which I will quickly list:

  • The website is the public face of the proposal and will be updated on an ad-hoc basis to reflect the current state of the proposal.
  • The Github repository holds the live specification along with examples. In the near future it will hopefully hold reference libraries, tools, and example applications. There is also a wiki and issue tracker to handle documentation and tasks.
  • A Google+ community to hold discussions, and an associated G+ page which is the source of “official” statements (as opposed to my personal thoughts as a fellow hacker).

Several people have mentioned in passing that the technology of the fabled Semantic Web, now known as Linked Data apparently, may be of interest. A little internet research led me to a useful resource in the Linked Data Book, and the more I read of it the more I realised that the TTN sounds like it is basically trying to be a Linked Data vocabulary. Consequently I think it is worth exploring the idea further, to see whether the goal of the TTN should be to define such a vocabulary along with tools and libraries to support it.

There are several considerations should a Linked Data approach be taken.

  • Many of the concerns that have cropped up in discussing TTN have already been discussed in the Semantic Web world, such as identity, security, and reliability.
  • A set of tools and libraries have already been developed which could potentially be utilised.
  • Linked Data seems ideally suited for describing the types of things the TTN is all about.
  • Using the language and specifications of the Semantic Web might interface the TTN to the wider internet of things, as espoused by Tim Berners-Lee.
  • The Linked Data specifications (e.g. RDFa,RDFS,OWL) are, however, more complex than those originally envisaged by TTN, and the learning curve to fully understand how the network works may be steeper.
  • Using a recognised and widely adopted standard would seem preferable than devising a proprietary, albeit open, standard.

From my reading so far, I believe the following would be possible using Linked Data:

  • Define a vocabulary using RDFS (Resource Description Framework Schema) which would be similar (if not identical) to the current TTN json schema.
  • Mark up a Thing with metadata attributes using one of the following ways:
    • RDFa (Resource Description Framework in attributes) to embed the TTN attributes within a web page describing a Thing.
    • JSON-LD (JavaScript Object Notation for Linked Data) to describe the Thing in a JSON document.
    • Traditional RDF (Resource Description Framework) in an XML document.
  • Use existing libraries, or build new ones, to interact and work with this data.

In fact I hope that the RDFS & JSON-LD combination might already be very close to the work we have done so far.

To date my playing and experimenting has been limited. I have started formulating an RDF Schema (http://thingtracker.net/thingtracker.rdfs) and have added some RDFa to the example Githubiverse site (http://garyhodgson.github.com/githubiverse-tst), which appears to be readable according to the few tools I have tried out.

RDFa Source

Snippet from source html. New RDFa attributes highlighted.

Parsed RDFa

RDFa parsed using Green Turtle RDFa extension for Chrome browser.

There is a whole raft of things I still need to learn (help & guidance very welcome!), and this is still only an exploratory dive into Linked Data, but so far I feel it is worth pursuing further.

Permalink | Comments (9)

3D Printroom

February 17, 2013 – 10:43 pm

A small distraction I thought up a few days involves how we organise our STL and gcode files.  The Windows and Linux file explorers are rather limited when dealing with exotic files (no previews, no metadata). Additionally, I don’t know how other people manage their files, but mine are scattered across my main PC, my laptop and a NAS, within arbitrarily named folders filled with overly long file names (in an attempt to capture some metadata). It certainly has it’s limitations!

file chaos

Chaos! Chaos I tell you!

This seems ripe for an application of some sort (ignoring the patently absurd, if rational, argument to simply impose a little order on things).

I have always enjoyed using Adobe Lightroom to organise and work on my photos – it has several features that could be very useful when dealing with 3D printer files:

  • Directory scanning & sync
  • Arbitrary collections and groups
  • Adding additional metadata, including comments and ratings
  • Previews of non-standard files (e.g. RAW)
Adobe Lightroom

Adobe Lightroom – something to aspire to.

I wish I could announce that I have completely written a “Lightroom for 3D Printers” but at this stage I have only created a skeleton app with limited functionality:

  • Drop a directory in the top left panel to load it.
  • The top file view filters only STL files.
  • When an STL is selected the related gcode files are displayed below. This assumes the files start with the same name, e.g. cube.stl -> cube.gcode.
  • Any metadata in the gcode file is displayed in a table view (Slic3r only).
  • Double clicking a STL file displays a preview (thanks to Toby Buser’s Thingiview).
  • Double clicking a gcode file displays a preview (thanks to Joe Walnes’ gcode-viewer).
3D-Printroom

3D Printroom (Alpha!)

… and that’s it … so far.

The reason I am posting about this already is to share the idea, gauge interest, and to make the source code available in case anyone wants to pick it up and hack with it.

I chose to develop it with node-webkit, which allows you to develop with HTML + JS + CSS but still release a native binary. (This is necessary in order to use node.js so the local filesystem can be accessed). I’ve added a few notes on the github project on how to hack with it.  Or there is a Windows binary available to play with: 3D-Printroom-distribution.zip.

I’d be interested to hear if anyone thinks such an app would be useful.

 

 

Permalink | Comments (4)

Thing Tracker Network

January 12, 2013 – 9:41 pm

A little time ago, RichRap started a discussion on the RepRap forum about a model repository for the project. My response to this crystallised a few thoughts I had on the subject since the Thingiverse debacle from last year. The basic concern being that, whilst creating a content repository is relatively straightforward from a technical perspective, there are other factors which will determine whether it will succeed. The most obvious being the catch-22 situation whereby users are attracted to a service that is being used by many other people, i.e.  where they are more likely to have their project/design discovered by other people. There is also a concern that any one provider evolves into a monopoly, depriving the community of diversity.

 

With all this in mind, I have been developing the idea a little more and would like to present the resulting proposal for consideration to the community. To do this I have created an information website which I hope can be used as a central hub for distribution and further development of the idea: thingtracker.net

Overview

The site should have enough information to get the rough idea across, and so I shan’t repeat it all in this blog post, however a TL;DR summary may be helpful. The proposal simply suggests a way in which an ad-hoc Network of Things could be created. This is enabled by a short, flexible, and easy to implement specification, which, when followed, would allow a wide range of individuals and groups to participate in the network. Furthermore, the open nature of the specification should promote development of an ecosystem within the maker community, allowing a diverse set of applications and websites to emerge.

 

Use Cases

A couple of use-cases may help explain the potential of the proposal.

  • As an individual, when I create a design that I wish to share, I have several services available to me (Thingiverse, GrabCad, etc.). These being walled gardens means that anyone searching within one will not find results from another. Furthermore, search engines such as Google may result in my Thing being found, but its generic nature means that this is unlikely unless people use the right search terms. Therefore my options are either to limit the number of people who can discover my Thing, or submit, and maintain, the Thing to multiple repositories. Neither option is optimal, and the latter is particularly inefficient should my Thing evolve and I have to update the information in several places. Ideally I would submit my Thing to my favourite (based on features that I value) repository, and then have it discoverable by others, independent of where it is hosted. Having the option to self-host the Thing would also be good. What is missing at the moment is a standardised way for web applications to exchange data about Things.
  • As a member of a hackerspace, or other group, we would like to host and share our designs ourselves but still have them discoverable by a wide audience. Furthermore, we would like to provide much more detailed information, such as: bill of materials; instructions; and other information. In this case there may be a sub-Network of Things which has it’s own ecosystem but is still a part of the wider network.

 

Where Next?

To start dissemination of the proposal I made a brief post on Google+ and was pleasantly surprised at the positive feedback the idea received. I shall be collating this information and reflecting it in further revisions of the proposal and specification. In order to facilitate further discussions, without over-thinking the infrastructure, I have created a dedicated page on G+ to act as a blog and to collect discussions, etc.  There is also an email address: contact@thingtracker.net

 

The proposal is at a very early stage and is completely open to everyone,  so feel free to share your ideas, thoughts and opinions. If you feel that an open, distributed, Network of Things would benefit the maker community then please share the links, spread the word and join the discussion.

Permalink | Comment (0)

Custom Parts for Ikea Lillabo Train Set

October 2, 2012 – 7:42 pm

The wood composite seems well suited for printing some custom parts I designed to supplement the Lillabo Train Set from Ikea.


The parts printed out well on the first go, with only minimal clean-up required due to the oozing. The circle part of the buffer still had a hole in it even though I set the solid layers to three (infill=20%), but adding a red sticker easily solves that.

It makes me think that a useful feature for a slicer would be to gradually increase the infill for the last few layers, i.e. 20% on layer n-3, 40% on n-2, 80 on n-1 and then 100% on the top.

Permalink | Comments (2)

More Wood Composite Observations

October 1, 2012 – 12:20 am

A quick post with a couple more observations on the wood composite together with some photos.

Sam’s Gears

Whilst printing a tray of the excellent Sam’s Gears by pleppik I wanted to reduce ooze so I increased the speed and also the temperature to 230°C, and midway the extruder jammed due to a blocked nozzle. At higher temperatures the composite turns darker and becomes harder, and it may have been this that caused the jam, or possibly some other detritus. It could also of course been caused by something other than the material, however this is the first time this nozzle has jammed. Generally going slower and cooler seems to be the best tactic.

The Venetian Lion by tbuser I printed scaled down 50% and 25%, and with support. The support came away quite easily, but I can’t compare this to other materials as this was the first print I have done with support. The temperature was set to 220°C and layer height was 0.24, this produced a finish more akin to brown PLA rather than a “wood” finish.

A couple of Simplified Gekko’s by CodeCreations were next to test the hypothesis that visible layers look better with the wood finish. Whilst not terribly beautiful prints, the colour and texture detail, particularly of the heads, are quite pleasing.

Dizingof’s Dragon Bowl came out quite nicely, but highlighted a problem which crops up frequently: the latest version of Slic3r seems to jump around a bit, particularly when infilling, and because of the ooze problem this results in imperfect finishes.

Dragon Bowl

I printed out 2 copies of the bowl, one at 220°C and another at 185°C. The latter is lighter in colour, this is also clearly visible in the Sam’s Gears print, where the crank handle was printed cool, but the gears hot. Another property I am seeing: prints at lower temperature are much more compressible (spongy) and flexible. The pins I printed for Sam’s Gears were so flexible they were not really usable (hence the bolts instead). The texture at lower temperature is also more “wooly” and woodlike. Several of the prints, such as the pin board, have quite a look of MDF about them.

Sam’s Gears, Crank Detail

Whilst testing how paint applies to the material I realised that I hadn’t yet tried painting regular PLA. Surprisingly, at least to me, the PLA also took the water-based acrylic paint I tried well too – so long as the surface was sanded beforehand. The wood composite took the paint well without sanding, apart from the bottom plane, which is quite glassy. This would need to be sanded before applying a coat, otherwise the paint peels off quite easily.

Permalink | Comments (5)

More Wood Composite Printing

September 25, 2012 – 11:18 pm

A short post to give some more feedback about working with the wood composite. I decided to print out “Working Micro Gear Heart Keychain” by CrazyJaw.

Heart Gears – Under a Fluorescent Lamp

The stuff really sticks nicely to the bed without it having to be heated with no curling. The gear heart trays are quite small so I will try and print something larger to see how well it copes.

It acts largely like PLA, but oozes much more. I had to up my retract settings a little, and it still blobbed quite a bit. I was printing at 195°C and so it may be that a cooler hot-end might reduce the ooze. I chose 195°C because I got the impression at 185°C it came out a little rough. Now I have a couple of prints done I will be more daring and print at 180°C for longer.

An interesting observation is that the visibility of the layers, which is usually something we try and minimise, becomes a feature aesthetically. It gives the print more of a wood grain look. The photos were taken in a range of lighting conditions to try and convey how it looks.

Heart Gear – Daylight

The parts still feel, and act, like a polymer, which is to be expected, but it has a much rougher finish – at least at the temperatures I have been using so far.  Directly after printing it has a rather spongy feel and after a while it hardens somewhat, but it is generally a bit more rubbery and compressible than PLA.  Sanding, drilling and cutting is more similar to working with PLA than with wood, unsurprisingly. Sanding makes the surface much lighter and detracts from the overall appearance. I used various grades of paper, including wet&dry, to some success, but bringing out the Dremel makes it much lighter work, remembering to keep the revs nice and low.

I also drilled and tapped a small test piece for a 3mm bolt. It holds well though I would be wary of putting it under any serious load – as with PLA.

I also applied some water-based acrylic paint to a piece (not shown) and it appears to go one well. Once it’s dry I will report how it looks and holds.

 

So far it’s a fun material to work with, and the aesthetic quality will definitely add something new to 3D printing. From my very limited testing I would be wary about using it for precise or complicated engineering parts and would probably lean towards structural components. However, my machine doesn’t produce very high quality prints, plus I’ve only just begun playing with it, so there may be much more to this material than I have discovered so far.

I should state, the gears don’t actually turn, but this is due to my being unable to print out the pins to a sufficient quality. A tighter calibrated machine could well produce a working copy with this material.

 

Permalink | Comment (1)

Printing with Wood Composite

September 24, 2012 – 10:15 pm

The recent articles (3ders, Thingiverse) about printing with “wood” piqued my interest, and I was excited to see the GRRF sells 0.5kg rolls. It seems I submitted my order in time because they are now out of stock – but taking pre-orders. The filament arrived today and I got a chance to make a test print – the trusty, if now unoriginal, minimug.

The GRRF page and the original Thingiverse entry by Kaipa state that it’s warp-free and requires no heated bed, so I gave this a try and true enough it printed out perfectly. The hot-end was set to 190°C at the start, and I manually increased the temperature in 10° increments to 220°C back and forth to produce the colour gradient.

The bottom of the print is smooth, similar to the finish from PLA, whereas the sides and top are rougher. So far I haven’t attempted working with it (drilling, cutting, etc), which I will try tomorrow. I did try a little sanding which required a bit more effort than real wood and again was similar to working with PLA. I’ll be interested to see how well it takes paints and lacquers.

I find this development pretty exciting as it opens up another material that works immediately with a reprap FDM printer. Kaipa isn’t revealing what is in the composite, nor his process, but Viktor from the forums pointed out  a material from Tecnaro called Arboform. This thermoplastic composite is based on Lignin, a natural polymer, which is a by-product of the pulp industry.

“Mixing lignin with natural fibres (flax, hemp or other fibre plants) and some natural additive produces a fibre composite that can be processed at raised temperatures and, just like a synthetic thermoplastic material, can be made into mouldings, plates or slabs on conventional plastics processing machines.”

What’s also really interesting is seeing the other products from Tecnaro: Arbofill and Arboblend. The latter having comparable properties to ABS, apparently.

I believe Tecnaro only sells granules, and cater for manufacturers, as their minimum order quantity is 25kg (1 bag) but considering the recent arrival of filament extruders (Lyman, Filabot) it seems it would be a perfect match for the 3D printing community. Anyone in Germany (Baden-Württemberg) want to split a 25kg bag with me?

 

… and of course the minimug was watertight!

Wood Minimug - watertight

Watertight!

Permalink | Comments (11)

Githubiverse – A Github Pages Template for 3D Printing Projects

September 15, 2012 – 9:27 pm

I’m a big fan of github, and I think it provides an excellent set of resources for hosting 3D printing projects. Recently I had the idea that it would be useful if these projects were able to utilise Github Pages to provide a project landing page, showing similar information to that found on Thingiverse.

It sounded like a fun little diversion so I threw together something called githubiverse. It currently consists of a Github Pages template: drop this into the gh-pages branch of any github project, add a little configuration, and your github pages will display the source files, STLs and any images, along with some other information. The beauty here is that the content is dynamically pulled from the github repository so it is always up to date.

githubiverse

The screenshot doesn’t do it justice so here is an example site: garyhodgson.github.com/githubiverse-tst.  The project has a master branch which contains folders for source files, STLs and images. The project also has a gh-pages branch which contains the template. Within this, _config.yml contains the configuration parameters that allows the gh3 github api client to connect to github and pull the information. Because it’s dynamically generated it’s a little slower than a standard website, but I think it’s an acceptable compromise for always having the latest information.

[Update: The way I have used Thingiview means that only ascii STL files are correctly displayed. I'll see if I an find a way to also load binary STLs.]

To get an idea of how other projects might look I took a few screenshots (via locally running instances) for Nophead’s Mendel90 and Josef Prusa’s PrusaMendel:

There’s a few pros and cons to consider.

  • + Free hosting of project site by github.
  • + Easy to set up.
  • + Always up-to-date.
  • + Easy to change the look and feel to suit your needs.
  • - Depends on Github, Github Pages and the API – any changes to the terms and conditions, or future availability, of these services could impact the site.
  • - No search function, tags or commenting system (although this could be remedied).

Further Ideas

 

An interesting advanced use case is the ability to use the same core template across many projects.  You could fork the githubiverse-template project and edit the html/css as you wish. Then, in each project’s gh-page branch create a submodule referring to this fork.  All that’s left would be to create a _config.yml file with the details in the root project gh-pages branch and an additional entry defining the source of the jekyll site as being the submodule folder.  I’ve added details on how to do that in the project’s readme.  The benefit of doing this is that each project can be updated solely through updating the template submodule. [Update: it seems I had forgotten to actually test this method when deployed to github, whilst it works locally via Jekyll it seems that github modifies the source folder settings during the build.  Thanks to dzach for finding this out the hard way.  I'll see if there is a way around this as I feel having a shared template system would be quite useful.]

Another idea is to edit the template to utilise the blog aspect of jekyll. The Slic3r.org site runs on Github Pages and already does this to announce releases.  The blog could be a development log, release history, or news section for example.

To address the search and discovery aspect I considered trying to implement some form of tracker service, whereby projects could register themselves and use the service for searching, browsing and tagging etc, also as a Github Pages site.  However I realised that something like the RepRap Development Tracker would do the job perfectly well, as this is agnostic to where a project is hosted – it only categorises each entry and refers to the originating pages.

Development Tracker is currently tailored specifically for tracking reprap and 3D printing parts and projects, but it wouldn’t take much to make it more generic and suitable for tracking all sorts of projects.  And of course the underlying software is open source, so anyone can fork and go!

Permalink | Comments (21)

Printrun Projectlayer Update

September 5, 2012 – 3:46 pm

I recently updated my mod of Printrun’s projectlayer with a couple of important improvements which are worth sharing.

  • Replaced wxpsvg with cairosvg.
    Wxpsvg didn’t handle scaling correctly and so I decided to replace it with the better cairosvg module. This means there is a new dependency on pycairo (I installed via: pip install pycairo).  Now each model should project to the correct size when the X and Y resolution, and the ProjectedX, values are set correctly, and the scale is set to 1.  See below for a brief outline of my XY calibration technique.
  • Slow SVG reading caused timing issues.
    When the SVG file is large (e.g. > ~5MB) the time it took to convert to bitmap caused the image to not be displayed in time, as the original code worked on a fixed time schedule. I changed it slightly so that the displaying of the image waits for the bitmap to be ready before continuing. This means that the “Blank” time is now really the minimum blank time – it could blank longer if the SVG takes a while to convert, but at least the amount of time exposed should be always correct.
  • Projectlayer settings are now saved between sessions.
  • Show filename, layer count and estimated time for print.
  • First layer can be displayed for a set number of seconds.
    Setting a positive value in the number box next to the “1st Layer” checkbox will immediately display the first layer for that number of seconds. Useful for testing or for exposing the first layer for longer before starting the print.  A value of -1 sets it to infinity.

XY Calibration

It may also be worth mentioning how I calibrate the XY dimension of the printer.  There may be better ways, but the following works for me.

Projectlayer - Calibration

Projectlayer – Calibration

The key settings are the X and Y resolution (in pixels), plus the ProjectedX value (in mm).  The former should be set to the resolution of the projector (in my case 1024×768), and the latter to the full width of the image that is projected onto the bottom of the vat – not just what is visible in the vat of course, but the entire width of the projection.  (I should also note that the display should of course be set to “fullscreen”).  With these figures dialled in the calibrate checkbox should display a grid of 10mm² squares.  The ProjectedX parameter can be modified to fine tune.

 

It’s also worth testing with a few real models to make sure – the “1st layer” option is useful here.

 

If anyone uses this and comes across problems then please let me know.
Permalink | Comment (0)

DLP Progress Report

July 11, 2012 – 12:04 am

Failed attempt at Tiny Planetary Gears at 80% scale


I had hoped to have some nice successful prints to show off but progress has been rather slow. Vat #2 also developed cracks shortly after the initial test runs. Whilst assessing the situation I made the uncomfortable realisation that the “perspex” I had bought was not actual perspex but rather polystyrene! A project manager from a previous job once dealt me some sage advice: “Assumptions are the mother of all fuck-ups”. Here I had assumed that the transparent sheets of plastic at the local hardware store were perspex, because that’s what I was looking for and that’s all they had, and it certainly looked and responded like perspex. On making this realisation I fell immediately into a second trap – that the cause of the vat failure was due to the material. So I merrily went off and found some real perspex and rebuilt the vat, which promptly failed in exactly the same way!

I recount all of this because I find it interesting how we have to deal with such traps and set-backs as part of the development process. We constantly have to fight against our own hubris, ego, and our willingness to mislead ourselves as we try and maintain focus on solving the current problem, whatever it may be. Robert Pirsig wrote about set-backs and hang-ups, as “Gumption Traps” in Zen and the Art of Motorcycle Maintenance (PDF, p.139 onwards) and I am reminded of them often as I tinker.

So, after 3 failed vats, I actually started to consider that the design might be the problem. Some rudimentary research on working with acrylic showed quite clearly that it “has a high thermal expansion coefficient compared to traditional glazing materials and allowance within the frames must be made in both directions for thermal expansion and contraction”. So the rapid heating of the center from the reaction in the resin, together with the use of bolts through the material, was a recipe for disaster. I had, once again, assumed that my memory of working with perspex (at school, so now a few years ago) was accurate and that it would tolerate such temperature changes and design. It was only after these failed attempts that my hubris was sufficiently dented that I was forced to question my assumptions and check, and double check, my work.

Vat #4

Build #4 removes the bolts and leaves some allowances around the edges for the thermal expansion. It uses aluminium U-bar to “clamp” the PTFE foil between the L-shaped walls and the perspex floor. All held together with a generous amount of silicone. It’s still far from perfect, but at least so far it hasn’t developed cracks! The main problem I foresee is that any damage to the foil will mean having to destroy and rebuild the whole thing.

I also built a second base from copper pcb board. So far it seems to hold the parts enough for the duration of the print and they can be easily scraped off afterwards.

New vat and base

During the times that I did have a vat, I attempted the Tiny Planetary Gears by Auebenc. I’m still waiting for my pigment to arrive and so am still trying to judge the cure depth of pure resin by timing alone. Because of this I wasn’t expecting a working print (which I indeed didn’t achieve) but I think the model shows the potential of what the printer will eventually be able to do.

Failed attempt at Tiny Planetary Gears at 50% scale, note the M3 nut for scale.

The above print would have been great however I had reduced the X/Y scale to 50% but failed to reduce the Z layer height, and so it is elongated x2 in the Z direction. I think I will have to put a reminder message in the host, or do something automatically, as it is all too easy to forget a variable whilst making adjustments such as this.

Tony Buser asked what the durability of printed parts is like and I replied that the belt pulley from the first test run certainly appear to be strong enough to use in that capacity, and these prints remain as strong now. One thing I did discover whilst attempting to clean up some of the planetary gear parts is that the material is very brittle directly after printing, and even after a couple of minutes under a UV lamp. When I tried to enlarge screw holes the resin cracked or crumbled quite easily. However it has to be noted that the models were ridiculously small (I printed at 50% and 80% of the already tiny size), plus I think that allowing the models to cure over time makes them stronger.

Brittleness directly after printing

Another thing worth remembering is that spotamaterials also offers harder, more robust resins – Spot-HH and Spot-HT. I will no doubt be trying this sometime soon.

Permalink | Comments (6)

Next Page »

Next Page »