Tektronix 8560 still going strong

And now for something completely different...

I have been tidying my lab post kit production to make room for future experiments. In the process I have been skipping loads of junk. I do have trouble throwing things away that work just as well as when they were new and expensive but are now utterly out of date and superseded by much smaller,  better and cheaper things. I power them up periodically to test them and hope they might fail and give me an excuse to chuck them.

I powered up an old PC and six electrolytic caps exploded in quick succession, sounding like a distant firework display! Presumably a victim of the great capacitor plaque in the early 2000s. Remarkably it still managed to boot into XP but it had signed its own death warrant and went straight to the skip.

Several more PCs with only 256MB of RAM went when I found they wouldn't even load a supported version of Linux. Only a Shuttle with 1GB of RAM that successfully runs LXLE survived the cull.

I also have a Tektronix 8560 multi-user software development unit that is actually a DEC PDP11-73 mini-computer in a 19" rack with a Kennedy Model 9000 open reel tape drive and a Dylon Model 1015B Magnetic Tape Controller.

It was purchased by the company I worked at for £48,000 in 1984 and supported 8 software developers on dumb terminals connected via RS232. They gave it away for nothing in the early 90s.   To put that in perspective £48,000 would buy a decent house in 1984 that would have been worth a lot more in the nineties. Computers must be the worst investment ever! The rack is probably the only bit that retains any value.

It has 1MB of memory on two large cards and the processor is only about as powerful as an Intel 286, but with a much nicer instruction set. We had to write PDP11 assembler in some university workshops and it is the nicest instruction set I have come across.

It was replaced by two MicroVaxes and later PCs of course. The ironic thing is it replaced Motorola  EXORcisers, which were single user desktop computers, so things sort of went in circles.

When the machine was delivered it had a PDP11-23 but the embarrassing thing was it didn't perform as well as the 8 bit EXORcisers because, although it was a 16 bit processor with 1MB of memory, each process had to fit both the instructions and data into a 64K segment, just the same as the 8 bit machine. The 8 bit linker program was smaller so there was more room for the target program. We had to immediately upgrade to the PDP11-73 CPU that has separate instruction and data segments allowing the full 64K to be used by a process for its data. I still have the original processor: -

It runs Unix version 7 re-branded TNIX. It is built like a tank, so of course it still powers up fine, asks if the time and date is still 2006 (the last time I powered it up) and if not suggests I enter a time and date with 1982 as an example. No Y2K bugs here!

It is nearly as loud as a vacuum cleaner and smells of burning for the first few minutes. I think there must be a thermistor or a dropper resistor in the PSU that quickly gets very hot and burns off the dust.

Even the tape drive still works once I had remembered how to set it up, but it only holds about 20MB and would take something like an hour to write that much. The only thing that failed is the foam block that holds the end of the tape in place in the spool. It has started to disintegrate as foam seems to do eventually.

It is in need of a good home but I think it is too modern and not rare enough for a Museum. One day I might skip the insides and use the case to house a big 3D printer or lots of little ones.

Ultra Low Dropout Regulator for flicker free LEDs

Cheap 12V LED lighting strips are very sensitive to small voltage changes. This is because they just have multiples of three white LEDs in series plus a small resistor to set the current. The voltage across the LEDs is more or less constant at 3 × 3.2V, so the resistor sees the difference between that and the supply voltage, around 2.4V. This means that a 10% change in supply voltage produces around 40% change in current and hence brightness.

ATX PSUs have poor regulation on the 12V rail but this doesn't affect the rest of a 3D printer because everything is regulated downstream. The stepper drivers are constant current and the heaters are temperature controlled.

Here is a dip in the 12V rail caused by the 10A bed switching on. As you can see the swing is 12.2 to 11.6V, around 5%. This results in about a 20% reduction in light which is very noticeable.

One way to fix the problem would be to make an accurate 12V from the unused 5V rail using a small boost converter. I didn't want to cause any EMC issues, so I decided to use a low drop out (LDO) regulator to regulate to just below 11.6V. I thought it would just be a single chip solution, but after a lot of searching, the lowest drop LDOs I could find were 0.5V and I didn't want to waste that much.

I decide to roll my own using a low RDSon MOSFET as the series element. The LEDs only take about 0.5A, so the drop out voltage with a MOSFET with an RDSon of a few milliohms can potentially be a few millivolts, hundreds of times better than any LDO chip I could find.

In practice I used a BTS134 MOSFET I had lying around with an RDSon of 60mΩ. To put that in perspective that is less than the voltage drop in the wires I used.

This is the circuit I came up with: -

I regulate the negative side of the LEDs so that I can use an N channel MOSFET. Virtually any logic drive MOSFET should work. I wired this after my RPi switching circuit described here: hydraraptor.blogspot.co.uk/2014/06/lights-camera-action.

I use a TL431 adjustable precision reference as the control element. These are great little chips that can do anything from replace a zener diode to being an audio amplifier. The green LED acts as a level shifter to ensure the cathode voltage of D1 is higher than the reference voltage, a requirement of the chip. A white LED would give more margin.

VR1 should be initially set for the maximum output voltage and then gradually reduced until the flickering stops when the bed is switching. Handily the green LED flickers when the LEDs are flickering aiding adjustment without being blinded by the light.

C1 prevents the circuit oscillating at about 50kHz by providing negative feed back. I found its value by trial and error as there wasn't any phase shift versus frequency data in the data sheet. Basically R3 and R4 form an RC network with the gate capacitance of the MOSFET. This will produce a 90°phase lag at high frequencies. The TL431 must also create a 90°phase lag around 50kHz. To prevent oscillation C1 has to reduce the loop gain to less than one when the total phase shift is 180°. The circuit was stable with 1nF but had a bit of ringing. With 10nF it was a bit slow to respond.

The scope view below shows the performance of the regulator. The yellow trace is the 12V supply to the LEDs. The cyan trace is the negative supply to the LEDs (shown at a bigger scale). The purple trace is the difference, i.e. the voltage the LEDs see. It is virtually constant and the drop across the regulator goes as low as 40mV.

The maximum voltage across the MOSFET is only about 600mV (the size of the dips in the 12V rail). That makes the dissipation about 300mW, which is easily dissipated without a heatsink. Don't set VR1 too low though as the dissipation will go up rapidly.

Here is a veroboard layout done in VeeCad: -

If there is enough interest I could make a PCB to combine this with the RPi interface and also add a 5V in connector to avoid the need for the micro USB plug.

Mendel90 GitHub catch up

I finally found time to update GitHub with some Mendel90 changes that I have had in the works for a long time. The problem with releasing them sooner was that they were all not quite finished and / or would make unintended knock on changes to the kits I was producing. In particular the changes I did to make a Huxley90 in a hurry for the TCT show and the E3D mods kindly contributed by Philippe LUC that conflicted greatly with it, so needed a lot of work to merge.

OpenScad

I also updated to the latest version of OpenScad. The upside was that hull and some of the 2D operations are much faster. I was also able to replace all the calls to minkowski with offset as I was only using it for 2D offsetting. The net result is it is now four or five times quicker to generate the preview and the STL files. The downside is that the 2D sub-system now uses fixed point coordinates but the rest of OpenScad doesn't. This makes it difficult to get 2D and 3D geometry to match up. For example, an extruded circle now has slightly different vertices to a cylinder of the same size. This created a few degenerate triangles requiring that I changed the way I constructed some objects in order to get nice clean STL files.


The solution in the case above was to make the cylinder slightly bigger than the circle used to make the pointer.

On the up side it seems OpenScad has got better at handling unioning exactly coincident faces since I first wrote Mendel90, so I could remove some of my small offset bodges to avoid z-fighting.

Another benefit is that the X end brackets now slice correctly in Slic3r, as the bug that caused internal faces to point the wrong way has now been fixed. Skeinforge doesn't care about face orientation, it just counts edges to work out what is inside and what is outside. Other slicers got confused and filled in the nut cavity.

Along the way I discovered that, although OpenScad now has trig functions that are accurate for multiples of 90 degrees, etc., it doesn't use them in rotate, or vertex creation for circles and cylinders. It converts to radians and uses the library trig functions. Degrees can never be represented accurately as radians in floating point because Pi is irrational, not to mention transcendental. To get round this I now override the built in rotate with a user space version that uses the accurate sin and cos degree functions.

module rotate(a)
{
 cx = cos(a[0]);
 cy = cos(a[1]);
 cz = cos(a[2]);
 sx = sin(a[0]);
 sy = sin(a[1]);
 sz = sin(a[2]);
 multmatrix([
  [ cy * cz, cz * sx * sy - cx * sz, cx * cz * sy + sx * sz, 0],
  [ cy * sz, cx * cz + sx * sy * sz,-cz * sx + cx * sy * sz, 0],
  [-sy,      cy * sx,                cx * cy,                0],
  [ 0,       0,                      0,                      1]
 ]) children();
} 

Not surprisingly every STL and DXF file generated is now slightly different numerically but hopefully not dimensionally. I made a stable branch to record the state before these global changes, just in case. GitHub has some excellent image and STL comparison views but unfortunately it gives up if more than a handful of files have changed and there are hundreds in the Mendel90 tree.

Wade's Block

After a few people started to report broken or cracked Wade's blocks I strengthened it a bit around the bearing block. I also made the bearing sockets a bit bigger so there is less stress created pressing them in. Kits from around March 2015 have shipped with this version.

X Carriage

When Philippe LUC created the E3D branch he fixed a few bugs. One of these was that the X carriage top was only 2mm thick, when the design intent was 3mm. This was due to the fan duct using the same variable name. Whoops! I have updated it now in the main branch. I also made the nut traps for the fan bracket screws deeper to allow for longer screws and to allow them to be withdrawn further without loosing the nuts. This makes it easier to remove and replace the duct. Simply removing the washers is an alternative.

E3D Hotend

I temporarily parked Philipp's mods in an E3D branch until I could merge them. I have now updated the master branch to support E3D V5 and V6 hot ends with this one line change to the config file. The generated files for V6 that are different from standard build are in new folders dibond_E3D and sturdy_E3D and I have deleted the temporary E3D branch.

There is no room for the right hand wing nut because it clashes with the hot end's fan. Fortunately the carriage has always had nut traps to allow the screws to be inserted from below. A plain nut above can then be used to secure the extruder.

Primarily the things that change are the Wade's block, the fan duct and the fan bracket. The Wade's block has no extension to avoid losing more Z build height than necessary and a plain screw hole on the right end instead of the hex socket.

The fan duct has to slope downwards to avoid the E3D heatsink. That creates a sloping bridge that is also skewed horizontally. I haven't found a slicer that handles this properly yet, having tried Skeinforge, Slic3r, Cura, Kisslicer and even paid for Simplify3D! I have blogged about their failings in another post here: hydraraptor.blogspot.co.uk/2016/01/a-bridge-too-far. Any other slicers I should try?

Another bug Philippe noticed is that there was almost no clearance between the fan and the belt. Fortunately the belt is twisted so it actually does clear the fan. I have added more clearance as
Philippe did. It makes the fan bracket and fan duct 2mm longer. If you print either from the new files be sure to print both or the duct will be misaligned.

I also improved the internal shape of the duct a bit. From this: -

To this: -

It probably doesn't make a lot of difference but a comparative test of various fans and ducts will be the subject of a later post.

Even with the shortened Wade's block the E3D V6 hot end is 4mm lower and the V5 is a bit longer still. If you retro fit it to an old machine you will lose 4mm Z travel. If you are building a new machine then there are alternative files which add 4mm to the height of the frame and lengthen the Z smooth rods and threaded rods on the bom. That also has a knock on effect on the shape of the spool holders and the dust filter. If you use the larger sheets be sure to get the correct size rods and use the correct spool holder parts to match the frame.

New Lighting Options

I redesigned the lighting system I described here to work with some commonly available LED light strips. These consist of an aluminium PCB strip that slides into an aluminium extrusion with plastic end caps, which I discard. Instead of printing a bar to hang the lights and camera from I now add printed end caps to the light strip and uses those to hinge it from the frame edge clips. I then hang the camera from the strip with its own hinge.

The strips come in 500mm lengths but they can be cut at discrete points between every third LED. They are described as "50CM 5050 SMD 36 LED Warm White Aluminium Rigid Strip Bar Light Lamp" and I bought them from bgood2010 on eBay.

I got some from another seller and although the eBay picture looked the same the extrusions where actually not as deep. The STL files on GitHub are for 8.6mm deep extrusions and are generated by light_strip = RIGID5050_290. Setting it to Rigid5050_290 generates the clips for 7mm deep extrusion. Other sizes can easily be accommodated as long as they are rectangular. The definitions are here.

Rather than waste the off-cut I mount it above with a second pair of end caps that clip onto the main light strip. These are set back just far enough to avoid the build volume in the unlikely event you print something tall at the back edge of the bed. This is calculated by the model with lots of trig and Pythagoras maths. Set show_rays = true to see this view showing that the camera and lights are pointing at the centre of the bed and the build volume is clear.

Another light strip that can be selected is this one: FSRP3W, discovered by Alzibiff.

Again the end caps are removed and replaced with printed ones that clip into the screw channels in the extrusion. There is no room for the plug so I just solder the wires on.

It looks neater and gives a more diffuse light but is not as bright as the double strip of 5050 LEDs and is more expensive. I bought it from www.ledlightingandlights.com.

The only problem with these light strips compared to my original Sanken ones is that they are unregulated, so they flicker when the bed switches on and off. I described how I fixed that here. I also need to update the mounting for the Raspberry Pi to accommodate the plethora of new Pis that have appeared since my original design.

Huxley90

The Huxley version is scaled down in the same way as the Sells Mendel was scaled to make the Huxley. It has a build volume of 150mm cubed and uses NEMA14 motors, 6mm smooth rods and M3 fasteners for the frame. There is a good photo of it alongside the full sized machine on Ivor O'Shea's blog post.

The NEMA14 motors have about half the torque of the NEMA17s when driven with the same current. The Y carriage and bed have about half the area hence half the mass, so that is about right. Also a NEMA14 has half the mass of a NEMA17, so the X carriage also has about half the mass.

I believe the flex in the middle of the rods is proportional to the length cubed times the weight divided by the bar radius to the power of four. The length of the X rods is almost exactly 75% of the Dibond version and the diameter is obviously 75% as well. The relative flex then boils down to 0.5 / 0.75 = 0.67. So going down to 6mm rods is justifiable as well. Everything scales very nicely physics wise.

As the design is fully parametric shrinking it should have been easy, but because vitamins don't scale perfectly lots of snags arose where things clashed. A typical example was the x_motor_bracket. The NEMA14 motors are smaller but the raised boss around the shaft is the same size. This makes the bracket a different shape and it then needs a support to print it.

Half a truncated teardrop with a crutch!

The heated bed was made with veroboard and coincidentally has the same resistance as a full sized Prusa PCB, so the machine takes the same amount of power but heats up about twice as fast. There is no room on the frame for an ATX PSU, so I used an external XBOX 200W PSU. I couldn't find a spec for the 5V standby rail but it seems to supply enough current to power a Raspberry Pi.

Direct Drive Extruder

The extruder is where the scaling fell down a bit. The original Huxley used a Bowden drive to make the carriage small. I didn't fancy that but I didn't want to have the carriage as big as a geared extruder would need, so I went for direct drive with a NEMA14 and 1.75mm filament. 

The filament needs about one third of the force to feed and a Wade's has roughly 1:3 gearing, so a direct drive NEMA17 is about equivalent. The NEMA14 has half of the torque, so it is a bit under powered. I used the smallest drive pulley I had which was a mini hyena from Laszlo Krekacs' Indigogo campaign. Unfortunately I don't think the small diameter version is available now. I could probably make one from a hobbed bolt if I needed to or hob one from scratch.

It feeds PLA fine at 200C but isn't able to pull it off a spool. I will try a spool holder with a central bearing rather than the rim bearings to see if that is low enough friction. If that doesn't work I might try a powered filament supplier like the one on the first Up printer preserved here. Or maybe even try Bowden drive.

The design is parametric so there is a NEMA17 version suitable for Mendel90. I just need to adapt it for a commonly available drive pulley. It should just be a matter of adding a description here.

It can also use the E3D hot end but that doesn't fit between the bars on a Huxley90.

So that is Github up to date and hopefully correct although I haven't tested a lot of these changes.

I noticed that Blogger is now a lot worse than it used to be. Headings and pictures are now a nightmare.

End Game

Since my last post there have been many expressions of sadness in the comments here and here. I'd be lucky to get so much mourning at my funeral I think! Yes it may be sad for potential customers that missed out, but not for us. Fortunately we are at a stage in life where time is more important than money to us. It does feel a bit weird though as the house is now silent after having three or four machines printing solidly for about five years.

The harsh reality is we always planned to stop selling kits before demand dried up completely because otherwise we would be left with unsold stock. In order to to get volume discounts and cover long lead times we needed to carry around £12,000 - 15,000 of stock.

As we didn't hire premises or staff, and had enough capital to cover cash flow, the only business risk we had was being left with stock. It was very hard to predict future demand because it fluctuates wildly with currency changes and, with a new 3D printer coming out nearly every day, there is a risk sales could suddenly dry up if a better cheaper kit emerged. For example, a £40 Prusa I3 from China with 2 rolls of filament and LCD, bargain!

In the end the issue with Dibond made the tricky decision of when to stop for us. This happened a few months ago and we synchronised most of our stock to all run out together.

Yes we could have used other sheet materials, solid aluminium and steel were suggested. However, these are more expensive to buy and machine, much heavier and therefore more costly to ship. Although they are a bit stiffer there is no real advantage to the frame being stiffer because the forces due to accelerating the axes is along the plane of the sheets, where almost any sheet is very stiff indeed. As long as the machine sits on a solid work surface it doesn't flex at all when printing, unlike some of the triangular prism machines.

The good thing about an Open Source product is that the design and instructions will always be available, so people can still self source, or another company could pick up the baton. We will always be able to supply printed parts and, fastener kits, wire and sleeving, hobbed bolts and the extruder PCB. See the RepRap forum for prices. Everything else can be self sourced.

No More Mendel90 kits

We sold our last Mendel90 kit today. We found it increasingly difficult to get Dibond that wasn't scratched and after going through four different suppliers we eventually gave up and synchronised the rest of our stock to the number of good Dibond sheets we had managed to get.

The problem is we don't have room for an 8' x 4' router, so we get the sheets cut into smaller blanks that fit on my A2 router. The sawyers that cut them keep forgetting that, unlike other materials like wood and acrylic, the aluminium chips that come off Dibond are sharp enough to cut through the protective film and damage the surface. That means that all the chips need to be cleaned off the cut pieces before they are stacked. You would think that companies whose main business is selling cut to size sheets for decorative use would know this, but they all seem to make the same mistakes over and over again, wasting my time and their money.

Many thanks to all our customers for all their kind words and recommendations.

Back to experimenting and blogging ...

PLA pipe cleaner

Yesterday one of my machines stopped extruding ABS mid print. I immediately suspected the filament as faulty filament is my main source of unreliability these days, having eliminated other things like push fit connectors and wires that break.

I removed the hobbed bolt to clean it and found that I could not feed filament forward by hand but I could pull it back easily, a sign that the nozzle aperture was blocked by something. I spent a long time trying to clear the blockage with several attempts that failed. Here is the method that successfully cleared it in the end: -

I pushed the shank of a 0.4mm drill up the nozzle aperture while it was hot. That cleared the blockage enough to be able to extrude but the particle of contamination kept finding its way back into the aperture causing the plastic to come out in a flat turbulent ribbon instead of a cylinder. That made poor prints with rough surfaces and strings.

PLA has a useful property that you can heat it to a temperature between its glass transition and its melting point where it becomes a rubbery solid. When you pull it backwards it stretches and becomes thinner, so it peels away from the walls of the melt chamber and comes out in one piece. Anything in the melt chamber is pulled out with it leaving it completely empty and clean.

ABS does not have this property and is more like chewing gum above 105°C. It can be pulled back at around 130°C but it usually does not all come out because it is a super viscous liquid rather than an elastic solid.

Because of this I decided to flush out the ABS with some natural PLA. I did this at 240°C until it was extruding clear PLA,. then I cooled it to 80°C and pulled it out. This is how it looked: -

As you can see it stretches until the last bit comes away from the walls of the barrel and the shape of the end matches the cone leading to the nozzle. The problem is this did not get the particle blocking the nozzle because that was pressed into the aperture by the flow of PLA when I inserted it.

The final trick was to push a drill shank up the nozzle to force the contamination into the melt chamber before cooling it to 80°C. That ensured it was embedded in the PLA when I pulled it out. Here you can see the particle that caused all the trouble.

So to recap:

1. Heat to extrusion temperature and pull out the filament being used.
2. Use a 0.4mm drill shank to clear the aperture.
3. Insert PLA (preferably natural so you can see the contamination) and flush through the remaining original filament. You may need to keep clearing the aperture with the drill shank.
4. Cool the extruder to 80°C with the drill shank in place to ensure the nozzle is clear.
5. Remove the drill and then pull out the PLA.
6. Inspect the end that comes out to see the culprit contamination.

Of course if you are using PLA you can just do steps 4 and 5.

This method of cleaning with PLA is much better than using solvents or burning out nozzles that I often see recommended as it can be done in situ and doesn't risk damaging anything.

Lights, camera, action ...

I have been using the excellent OctoPrint by Gina Häußge to control two of my Mendel90 printers with a Raspberry Pi for a while now. I prefer the convenience of using an Ethernet connection rather than USB. It means I can control a machine from any PC in the house rather than having to dedicate a laptop that had to be close to a machine. Here are the details of my set up: -

Mounting

There are several places a Raspberry PI can be mounted but I chose to place it on top of the PSU so that the wiring was kept short and didn't need to pass though any of the frame elements or need any new holes drilling. I.e. all the electronics are together in one bay.

 The RPI model came from https://github.com/TomHodson/Raspberry-Pi-OpenSCAD-Model

I made a tray that supports the PCB all the way round and has a couple of pillars with M2.5 nut traps to screw it down. It shares the screws with the bottom of the Melzi, replacing the spacers, which are moved to the top.

raspberry_pi_assembly:
Vitamins:
  2 Nyloc nut M2.5
  2 M2.5 pan screw x 12mm
  1 Raspberry PI model B
  2 Washer M2.5 x 5.9mm x 0.5mm

Printed:
  1 rpi_bracket.stl

When it comes to mounting the camera there are again lots of possibilities. I contemplated something like this:http://www.shapedo.com/danielbull/raspberry_pi_camera_mount_for_the_nop_head_mendel90_3d_printer but I went for a straight on view from the back by printing a bar that spans the stays and clamps to the Dibond.

This gives a view orthogonal and centred with the bed so the only degree of freedom the camera needs is vertical tilt.

The bar can be clamped at any height. Lower gives a better view of the nozzle when it it close to the bed but tall objects soon go out of the field of view. Obviously a longer flat cable is needed to connect the camera to the RPI than the one supplied with it. They are readily available on eBay.

I also attached a 300 lumen LED light strip to the bar which gives enough light for the camera, even in a dark room. Having the light behind the camera avoids any glare from the glass. The particular strip I used is a SPS125 from Sanken Power Systems. I bought them several years ago and I don't think they are commonly available. However, the design is easily customisable by adding a new description to scad/vitamins/light_strips.scad. The clamps should then morph to suit.

The bar is printed in two unequal halves and the shorter one (red) slides into the longer one. The seam marks where the camera should be placed for alignment with the bed and the overlap length is such that both halves are the same height in total, so printing them together allows better cooling without needing excessive slowdown.

raspberry_pi_camera_assembly:
Vitamins:
  2 M2 cap screw x 12mm
  2 M3 cap screw x 10mm
  7 M3 cap screw x 16mm
  2 Nyloc nut M2
  9 Nyloc nut M3
  1 Raspberry PI camera
  1 Sanken SPS125 light strip
  2 Washer M2 x 5mm x 0.3mm
  9 Washer M3 x 7mm x 0.5mm

Printed:
  1 rpi_camera_bar_stl.stl
  1 rpi_camera_back.stl
  1 rpi_camera_focus_ring.stl
  1 rpi_camera_front.stl
  2 rpi_light_clamp.stl

By default the RPI camera is focused at infinity and the lens is locked in place. It is possible to break the seal though and focus it very close indeed giving a microscopic view. For this application it only needs tweaking a little to focus at the middle of the bed. I designed a little focus wheel that can be glued onto the end of the lens carrier to make it easier to turn.

When I ran the camera with the default settings in OctoPrint it streamed data at about 16Mbits / second and used 40% of the RPI's CPU time. It worked fine printing from SD card but slowed down the comms when printing over USB. On a suggestion by Gina I added the usestills option to scripts/webcamDeamon, i.e.

camera_raspi_options="-fps 10 -x 640 -y 480 -usestills"

That reduced the data rate to 3Mbps and the CPU load to 5%. It also had the side effect of vastly increasing the field of view. Here is a time-lapse captured by OctoPrint before I made the change. Notice the reduced field of view compared to the picture above.

Nothing on my WinXP machine would play the mpg files produced by OctoPrint, so I downloaded VLC Media Player. I found that is also able to record the OctoPrint video stream on the host PC. This video clip was recorded during the same build as the time-lapse above.

On another Mendel90 that I only use to print ABS parts, and hence don't fit the fan duct, I use a Logitech C270 USB webcam mounted in front of the machine, which gives a view like this: -

For this machine I mounted the same light strip just behind the gantry on brackets that hang over the top of the stays in the same way as the spool holders.

light_strip_assembly:
Vitamins:
  2 M3 cap screw x 10mm
  2 Nyloc nut M3
  1 Sanken SPS125 light strip
  2 Washer M3 x 7mm x 0.5mm

Printed:
  1 light_strip_bracket_left.stl
  1 light_strip_bracket_right.stl

I prefer the  RPI camera at the back solution but it does have the disadvantage that it looks out into the room rather than at the wall behind the machine.

Wiring

I power the RPI with the 5V standby rail of the ATX PSU and use one of the GPIO lines to turn the rest of the PSU on and off and another to turn the light on and off.

One thing I don't like about the RPI is the use of a micro USB connector for the power. A lot of micro USB leads have two much resistance to have enough voltage left at the RPI end. When you buy them there no indication of resistance but I managed to get some that where about 1.6Ω! To get around that I simply cut the wire off close to the plug and soldered to what was left.

The 5V volt supply comes from the purple wire of the ATX power supply. It looks blue on the photo below, but that is the camera lying! For a solid ground referenced to the logic on the Melzi I run a stout wire to the top terminal of the X limit switch. This ensures any voltage drop or noise in the ground wire between the PSU and the Melzi does not affect the USB comms and I find them rock solid in this configuration.

The remaining connections are the green PS_ON of the power supply goes to the drain of a small SMT MOSFET mounted on the back of the vero board and the negative lead of the light strip goes to the drain of a larger MOSFET. The positive lead of the light strip goes to the FAN+ terminal on the Melzi.

To make the vero circuit I started by cutting the tracks in a few places and drilling out some holes to provide strain relief for the flying leads.

I wanted the board to mount vertically but I didn't have a right angle connector to hand. Since I only need a few pins from one row I surface mounted a through hole straight connector.

Here it is with the MOSFETs and wires added: -

The small MOSFET is a 2N7002L and the larger one is a PHT8N06LT, but almost any logic drive N-channel enhancement mode MOSFETs should work. Neither gets fully turned on at 3V but both easily pass the current required, which is only milliamps for the PS_ON signal and about half an Amp for the lights.

On another machine I just soldered the MOSFETS to the connector and used heatshrink sleeving for strain relief for the flying leads on the drains. Much quicker but a bit fragile.

Software

OctoPrint

There are two ways to get OctoPrint onto a Raspberry Pi. You can start with a Raspbian image such as this one and then add OctoPrint by following these instructions or you can get an image for the RPI with OctoPrint already installed (called OctoPi) from here. The first method needs more steps and gets you the latest version. The second method is simpler but it takes me several hours to download, unzip and copy the image onto the SD card, so the first method can be quicker if you already have Raspbian installed.

When the RPI is booted you should be able to connect to it with SSH client like Putty or Tera Term. The default host name is octopi, username: pi, password: raspberry. If your DHCP server does not register the host name with DNS then you can find its IP address with a free application called Advanced IP Scanner found here. A good tutorial can be found here.

The first thing I do when connected is run :-

sudo raspi-config

to expand the file system, set the time zone and change the host name, etc.

VNC

In order to be able to update the firmware I install the Arduino IDE and to run that I need a remote desktop so I installed TightVNC following the guide here.

Arduino IDE

I install Arduino 1.0.1with:

sudo apt-get install arduino

I then get a copy of Marlin from Github with:

git clone git://github.com/nophead/Marlin.git

I then move the Melzi board support package to the Arduino IDE installation with:

cd Marlin
sudo mv Marlin/Melzi /usr/share/arduino/hardware

The Arduino IDE is a bit slow and clunky running on a RPI over VNC but it does work. A lighter weight alternative is a package called ino that can compile and download Arduino applications from the command line. It still needs the Arduino IDE installation but avoids the need for VNC.

Installation should be as simple as:

sudo pip install ino

But that installs an out of date version that does not scan the hardware directory for additional board support packages, and so does not support Melzi. Instead I install it from source:

git clone git://github.com/amperka/ino.git
cd ino
sudo pip install -r requirements.txt
sudo make install

If make install complains python2 does not exist then do:

sudo ln -s /usr/bin/python2.7 /usr/bin/python2

Ino expects the source code to be in a directory called src whereas the IDE puts it in a directory with the same name as the sketch. A simple workaround is to make a symbolic link in the directory above with:

ln -s Marlin src
rm -rf src/Gen7 src/Sanguino

(The other BSP packages have to be removed from the src directory because otherwise ino tries to build them and fails).

The firmware can then be built and downloaded with:

ino build -m atmega1284 && ino upload -p /dev/ttyUSB0 -m atmega1284

GPIO

To control the RPI's GPIO pins I followed the instructions here: https://projects.drogon.net/raspberry-pi/wiringpi/download-and-install/. This boiled down to:

git clone git://git.drogon.net/wiringPi
cd wiringPi
./build

Then I extended the systems actions section of ~/.octoprint/config.yaml with the following:

  - action: printer on
    command: gpio mode 5 out; gpio mode 6 out; gpio write 6 1
    name: Printer On
  - action: printer off
    command: gpio write 6 0
    confirm: You are about to turn the printer off.
    name: Printer Off
  - action: light on
    command: gpio mode 5 out; gpio write 5 1
    name: Light On
  - action: light off
    command: gpio write 5 0
    name: Light Off

After a reboot the printers PSU and the light can be turned on and off from the OctoPrint system menu. Obviously the light will only come on if the PSU is on.

Files

I added a new Python script that makes the STL files and BOM files for a list of accessory assemblies:

accessories dibond|sturdy|mendel

The STL files can be found here: github.com/nophead/Mendel90/tree/master/dibond/stls/accessories and the parts lists here: github.com/nophead/Mendel90/tree/master/dibond/bom/accessories. I also generated the files for sturdy and mendel variants but I haven't tested those myself.