Archive for the ‘reprap’ Category

After months of anticipation my Raspberry Pi (RasPi) arrived last week. So I spent a little bit of time putting it through its paces. After waiting for the last couple of months I had a short list of things I wanted to test immediately:

Operating System

First order of business was to boot up and try out the various distributions currently offered. On first boot I was a little disappointed to find the RasPi had a few issues with my SD card. When booting the Debian distribution I saw lots of errors when booting. The errors were “mmc0: Too large timeout requested for CMD38!” which I believe are to do with the time the card takes to erase blocks. The card was one I bought very cheaply at a market when I was on holiday in Italy a few years ago so I wasn’t that surprised to see it fail. When I switched to a newer card it behaved normally and the errors disappeared. The SD card images are available from the Raspbery Pi downloads page via bit-torrent.

Debian “Squeeze”

This is the recommended install and comes with an X-Windows GUI using a fast, light-weight desktop environment (called LXDE). The image booted into the standard text mode login prompt. After logging in I started the GUI by typing startx. I was a little surprised to find the ssh server not running by default but that was easily fixed. As I don’t have any HD TVs around, the composite video output works fine but its not ideal to do command-line work. By starting up ssh I’m able to login and develop on the RasPi using my laptop or other computer.

To start the ssh server for the current session you can type the following into the command prompt via a USB keyboard:

sudo service ssh start

To ensure this service is started every time the RasPi is powered up type the following:

sudo update-rc.d -f ssh defaults 20

I also installed a couple of utilities for later testing out the RasPi:

sudo apt-get install screen
sudo apt-get install minicom

Other than the ssh daemon not being run at boot and having to login and manually start the GUI this distribution behaved as I expected. It’s standard Debian and behaves as such, being able to apt-get anything I tried from the repositories without problems.

Arch Linux ARM

I’ve not worked with this distribution before so didn’t do much more than boot up and see what was installed. As expected this booted into text mode as there is no GUI installed at all. As ssh was running and the Ethernet interface was working out of the box I was able to log in remotely and poke about without any problems.

This is a very basic install, without even another user other than root. I like this cut down system as it seemed very fast with a low memory (both RAM and SD card) footprint. It looks like it will be a good starting point for an embedded server project. Having no experience with the pacman package management system I didn’t investigate very much at all, but think I think I will have another look at this distribution in the near future.

QtonPi

The QtonPi image was the largest of the three images to download, but that is because as well as an image for the SD card it also contains the cross-compilers needed to develop for embedded Qt on ARM via your standard x86 Linux machine. In addition to the compilers and Qt libraries it also contains tools for making new SD card images.

This image is based on Fedora 14 and booted into the console as with the previous two images. This distribution also didn’t have an ssh server running by default. To get ssh working on I needed to bring up the ethernet interface by typing:

ifup eth0

After getting this sorted I was able to ssh into the RasPi. To ensure this happens every boot I edited the file /etc/sysconfic/network-scripts/ifcfg-eth0, changing the ONBOOT option to YES:

This is helpful when looking through logs or trying to figure out what files you just changed.

Like the Arch Linux image previously mentioned this distribution also had no X-Windows GUI installed. This image is designed to use the Qt libraries to draw direct to the framebuffer. This is great for embedded systems as you don't have the overhead of a full X-Windows installation.

After following the QtonPi "getting started" instructions from here I could not get the Qt5 "Hello World" example to do any more than produce a white screen. Poking about the system I found some examples already on the card. Some of these "segfaulted" when run while others appeared to have the framebuffer off-centre and while displaying a little text, would not operate as intended.

The workflow for this project seems very nice and well thought through. Developing on the host and then automatically running on the target seemed very slick from within the QtCreator IDE. I look forward to working with it as the Qt5 platform matures.

NOTE: the QtonPi wiki pages seem to be moving about so here is a link to the Google cache version of instructions I followed.

An Enclosure

The second order of business now that I had an operating system was to get a case printed. I chose v12 of "thing" 16104 with the large Raspberry Pi themed ventilation holes. It printed okay but it took a couple of attempts with slic3r to get it to slice the thin walls correctly.

I also needed to move a couple of the connectors to make things fit nicely. I did this the old fashioned way with a file and knife but altering the OpenSCAD model looks pretty straight forward, so I'll probably do that before I print more cases for other people.

USB Serial Drivers

Third on my hit list was to check the drivers are present to talk to my RepRap 3D printer and other serial bits and pieces I have lying about. Both prolific USB to serial (PL2303) and FTDI seem to work fine. I didn't test the devices thoroughly, I simply noted that the drivers was installed and new /dev/ttyUSBx device was created when I plugged them in. I'll probably look at using the GPIO to control my RepRap and other electronics directly but for the immediate future, serial comms to an Arduino will do just fine.

General Purpose I/O (GPIO)

Last on my list was GPIO. I would like to use the RasPi as a real-time controller in embedded systems so I am quite curious to see if I can do anything useful with the GPIO. Later I plan to use it to drive the RepRap directly so I can repurpose my Linux machine in the workshop to do greater things without interrupting the printing process.

While using the information from http://elinux.org/Rpi_Low-level_peripherals I wasn't able to get anything to happen on the GPIO but as this was a late night investigation I'll assume there was something simple I overlooked.

I recently decided to treat myself and get an oscilloscope. After much consideration I decided to go with an entry level Rigol. I liked the large number of positive reviews I was reading for these scopes all over the net (two examples here and here). After patiently waiting, unpacking and having a good play I can honestly say I’m impressed.

Figure 1: A sample of the bitmap output from the Rigol 1102E

Figure 1 above shows serial communications on my Reprap Mendel. This has been my test signal as I put the scope through its paces while I try to locate the source of intermittent serial communications problems. Having bitmap output makes blogging about electronics a whole lot easier.

After having a few weeks play I have to say I’m a fan of the interface. I was pleasantly surprised by the center push feature on all the dials. A center push on the vertical position will center the trace about the zero point and a center push on the horizontal will center the trace about the trigger point. These are very nice interface enhancements that feel very natural and intuitive to use.

The performance of the scope is great although I have not pushed it anywhere near the limits.

To give you a better idea of what I am comparing this to I’ve compiled a list scopes I’ve used in the passed. These are scopes I’ve used in the workplace, spending countless days interacting with.

This is the first scope I’ve used which I’ve actually forked out the cash for so I am very happy with my purchase and find it compares very favourably to those I’ve used in the past. This scope has more features than I’ve ever had before. The datasheet for the DS1000E Series is here.

Using thermocouples with the Reprap Mendel is pretty straight forward, although I did overcome a couple of issues in getting it working.

A known issue with the MAX6675 Arduino/Reprap code

The MAX6675 chip can take up to 220ms to take a reading from the thermocouple and the reading begins automatically after the previous read. If another read is attempted before the current reading has been completed then the chip returns the previous value and restartsthe internal analog to digital the conversion. This means that if you read from the chip every 150ms or so you will always get the same first reading returned again and again.

The taking of a single reading rather than taking a number of readings and averaging will contribute to a high noise level in the thermocouple readings when using this software.

Discovering the problem

When testing the PCB with the library code everything works fine. The arduino returns a reading every second and everything looks good.

When using the Reprap firmware with the thermocouple code it always returned the first value read from the chip (usually 24°C or so). This lead to things getting pretty hot as the extruder would turn the heater to full duty cycle while recording no change in temperature.

I first looked at the SPI lines on the scope to see if there was excessive noise or some other issue. I also compared this side by side with the ‘working’ arduino system. The scope traces are shown below. The reference channels (R1 and R2) are the reprap firmware and the bottom traces (1 and 2) are the arduino. I noticed nothing wrong with the traces, they both looked very good.

It was here however that I noticed that the arduino code calls another read to the chip immediately after the preceding read. After a bit more investigation I noticed that the library software calls the temperature reading function 5 times consecutively and always returns 5 identical results. A quick read of the data sheet confirmed the typical conversion time to be 170ms with a maximum of 220ms. The arduino library starts a conversion just 20μs after finishing reading the last. Reading the data sheet further also confirmed the action of restarting a conversion every time the chip is read.

I monitored the lines on a scope and found that the Reprap software was indeed reading the chip every 136ms. To fix this I simply changed SLOW_CLOCK in configuration.h to 8089 from 5000. Based on the current delay giving 136ms, this gives 220ms delay between calls to the thermocouple chip. After making this change to the firmware the thermocouple now works perfectly.

Time between calls to the MAX6675 thermocouple chip using the standard firmware on my reprap.

Fixing the problem

A more robust fix to the reprap extruder firmware is shown below, but I have not tested this code yet. This simply exits the temperature reading method if enough time has not elapsed between calls to the function. The advantage of this is that the main loop can run as fast as it needs to without impacting on the operation of the thermocouple sensors.

#ifdef MAX6675_THERMOCOUPLE
#define MAX6675_CONVERSION_TIME 220 // number of milliseconds between valid temperature readings
int value = 0;
byte error_tc;
static unsigned long last_read_time=0; // number of milliseconds since power on at last MAX6675 read
unsigned long time_since_last_read=0; // number of milliseconds since last read of MAX6675
/* check the chip is ready to produce a new sample */
time_since_last_read=millis()-last_read_time;
/* only read from the chip if a conversion has been completed */
if(time_since_last_read > MAX6675_CONVERSION_TIME){
digitalWrite(TC_0, 0); // Enable device
/* Cycle the clock for dummy bit 15 */
digitalWrite(SCK,1);
digitalWrite(SCK,0);
/* Read bits 14-3 from MAX6675 for the Temp
Loop for each bit reading the value
*/
for (int i=11; i>=0; i--)
{
digitalWrite(SCK,1); // Set Clock to HIGH
value += digitalRead(SO) << i; // Read data and add it to our variable
digitalWrite(SCK,0); // Set Clock to LOW
}
/* Read the TC Input inp to check for TC Errors */
digitalWrite(SCK,1); // Set Clock to HIGH
error_tc = digitalRead(SO); // Read data
digitalWrite(SCK,0); // Set Clock to LOW
digitalWrite(TC_0, 1); //Disable Device
last_read_time = millis(); //remember the read time for next time
if(error_tc)
currentTemperature = 2000;
else
currentTemperature = value>>2;
}
#endif
}

The arduino library can be improved by simply inserting the following at line 55 of the file MAX6675.cpp just before the end of the for loop.

if (i>1) delay(220); // Wait 220ms for next sample to be ready

This will force a 220ms delay when reading the thermocouple multiple times via the read_temp(int samples) function. Alternatively you could use the millis() function to track the last time it was read and automatically delay the read by the appropriate amount.

You’ve probably all noticed by now that Ponoko are now offering fabrication facilities in the UK via RazorLAB. I thought I’d post to show off my new laser etched bed for my Reprap Mendel. I could have cut this one by hand, but I got it lasercut and etched for reasons of curiosity.

In the course of building my extruder I chose not to modify my stepper motor. Instead of having a splined shaft on the motor I decided to use a splined pinch wheel similar to the brass M4 insert used in the geared extruder driver. My pinch wheel is shown below in Figure 1. By making some simple assumptions and using basic geometry I was able to calculate the necessary firmware parameter to accommodate my changes from the original design.

Figure 1: Splined pinch wheel. It is designed to fit a shaft with a diameter of 5mm and is fixed in place using a M3x3 grub screw.

I wanted to keep the motor unmodified so that it would be interchangeable with any of the other motors I’ve used on the reprap. The upside of this is that I don’t need to keep a separate modified motor as a spare just for the extruder. The downside of this is that the default value for E_STEPS_PER_MM used in the reprap motherboard firmware would not be correct for my extruder.

What does E_STEPS_PER_MM do?

E_STEPS_PER_MM is defined in the firmware documentation as “the number of steps that the extruder stepper needs to take to produce one millimetre of filament.” The firmware then uses this value to calculate the number of steps needed to drive the extruder in relation the print head’s current horizontal movement. If this value is wrong then the reprap will push out too much or too little extrusion into the print.

As I had no way of knowing just how different my untested design would be to whatever extruder was used to determine the values given in the code, I wanted another way to determine this value. These calculations are used as a check to avoid wasting plastic and the possibility of breaking the extruder first time.

To simplify things I chose to calculate the parameter by treating the filament and melted plastic as an incompressible fluid. This simplification should hold true once the system is in a steady state extruding plastic. If no material leaks out, is absorbed into the body of the extruder itself, or is vaporized, then logically the volume of material that goes into the system must also leave the system. This also assumes that there is no thermal expansion or any change in density of the material (which is what I really mean when I say “incompressible”). Figure 2 below shows a diagram of my greatly simplified model of the system.

Figure 2: Model of the simplified system shown with the extrusion chamber shown as a grey box.

Bear in mind that I’m not a mechanical or chemical engineer. I’m an electrical engineer, so my calculations and assumptions might be way off. If anyone knows a better way to model and or calculate this sort of thing, I’d love to hear from you.

Assuming the filament is moving at the same speed as the outermost point on the teeth of the drive gear or surface of the pinch wheel then the length of filament fed in should be the same as the linear distance travelled by the outside of the pinch wheel. This is assuming that no slippage, no compression, and no deformation of the filament occur.

A point on the outside of the pinch wheel travels a linear distance of one circumference per revolution. This is calculated by π multiplied by the diameter.
ØPW (pinch wheel diameter)
lenf (filament length per revolution) = π × ØPW

The total volume entering the extruder per step is easily calculated by dividing the volume per revolution by the number of steps per revolution. If a gear reduction is used between the stepper and then the steps per revolution are multiplied by this ratio.
RM:PW (ratio of motor rpm to pinch wheel rpm)
steps360 (motor steps per revolution)

step-volf (filament volume per step) =

volf

steps360 × RM:PW

Real world examples

In addition to the standard extruder I have also built a version of Adrian’s geared extruder. My version of this is shown in Figure 3 below. The ratio for this gear reduction is 5:1. I will compare this with the standard splined shaft extruder in the calculations below.

Figure 3: A geared extruder. The large gear has 55 teeth and the small gear has 11 giving a 5:1 reduction.

This means that for each half step of the motor the original extruder draws in 0.278mm³ of plastic. If the geared extruder is used then the volume of plastic drawn in with each step of the motor is an order of magnitude lower at 0.0885mm³. This means that the geared extruder should have much finer control as well as increased torque.

Calculating the length of extrusion leaving the extruder:

The output of the system is via a smaller diameter nozzle. Working from our main assumption, what goes in must come out, the system must extrude all of the material entering the system but with a smaller cross sectional area.

Reworking our formulas from above gives us the length from a known volume. This assumes the extrusion, like the filament, is also a perfect cylinder.
lene (length of extrusion)
vole (extrusion volume ) = lene × CSAe

lene =

vole

CSAe

Substituting in the known volume drawn into the system per step:
vole = step-volf

lene =

step-volf

CSAe

This is the length of extrusion output per step. By inverting this we get the number of steps per mm of extrusion required by the software.

These values match up well with the values for the standard extruders given in the firmware.

Tying it all together

After reading through the working above you can see the result is proportional to the ratio of the square of the diameters and some of the terms will cancel out.

Combining and simplifying gives a single formula:

E_STEPS_PER_MM =

ØNOZZLE² × steps360 × RM:PW

Øf² × π × ØPW

Where:

Øf =

filament diameter

ØPW =

pinch wheel diameter

ØNOZZLE =

nozzle diameter

steps360 =

number of steps per revolution

RM:PW =

ratio of motor revolutions to pinch wheel revolutions

Below in Listing 1 are my changes to configuration.h to automatically calculate the steps per mm based on the characteristics of the extruder. This is calculated when the main firmware is compiled. I’ve also created a google spreadsheet here to help calculate the same value if you just want the number to throw straight into configuration.h. These values form a good starting point for the inevitable fine-tuning which is required later.

In order to improve and verify the performance of my Reprap Mendel extruder I decided to build a system based on a K-Type thermocouple. I ordered some samples of a MAX6675 from Maxim Integrated Products. I decided to use this chip over the Analog Devices AD595 out of curiosity as it was new to me and due to the 12-bit digital output. Although plenty of breakout boards already exist for this product I decided to design my own based around this PCB-mount thermocouple connector. I like the idea of being able to simply unplug a thermocouple and quickly plug another one in so the use of a standard miniature socket sounds like a pretty good idea to me. It makes switching between probes a breeze and allows me to use cheap thermocouple probes from Maplin

I haven’t tested this board yet so I’ll have to update the post later after I’ve had a chance to play with some ferric chloride.

Having stood back from the design for about 3 seconds it occurs to me that I should probably combine this with my ATTINY45 USB Key project to make a standalone Thermocouple to USB converter, but who has the time 🙂 .

Last weekend I managed to blow up the motor driver chips on the reprap mendel extruder board. I did this by enabling the #FASTPWM option in the extruder firmware. I’m not sure exactly why this caused the chips to blow up, but what I do know is that the smoke got out and now they don’t do anything. I believe the problem was that either the PWM wasn’t working at all or that the current in the motor windings was not able to decay enough in the time allowed for by the faster PWM frequency. I have been investigating using a standard v2.3 stepper motor board to drive the extruder motor but I will need to modify the motherboard firmware to get it working properly.

While poking about in the extruder firmware I noticed that the thermistor lookup tables could be improved. Currently I have been extruding my PLA at 250°C for reliable results. Looking at the standard lookup table, 255 is the second entry which means that most of the look up table is spent defining temperatures much below where I really want the most accurate temperature readings.

By choosing the points more carefully and tailoring the spread we can achieve better accuracy where we want it. This is most clearly seen when the table is plotted.

Figure 1 : Comparison of thermistor lookup tables

Figure 1 above shows a hand modified table as compared to both a perfect table with 1023 values and the standard table. If you look at the difference between the perfect line and the standard line you can see that above 255°C the graphs diverge significantly. What does this mean? It means that an actual temperature of 270°C will appear to our controller as 400°C. While this probably won’t make a large difference to the control of temperatures below 250°C it would be nice to know the system is accurate right up to 300°C. Changing the table may also improve the response of the control system near 250°C and reduce unexpected behaviour. An example of this might be when the system is set to 255°C and overshoots by only 5°C, the system will compensate for a measured overshoot of 20°C.

The Python script used to generate these lookup tables first generates an even spread of ADC values that the software will see and then generates the corresponding temperatures. While this approach generally gives a great conversion across the entire range of readings, it’s not the best use of the lookup table for this particular application. I’ve edited the script to reverse the process and select a number of temperature points where we are interested in and then look up the corresponding ADC values to match. This results in a table (shown in Table 1 above) that ensures the 200°C to 300°C range has plenty of points and the sub 100°C region has the minimum required. The modified Python script is here.

Unfortunately I broke my last thermistor while building a new extruder heater so I haven’t been able to test the new table. When I get a replacement I plan to check the results with a thermocouple to ensure accuracy across the range.

When I was ordering the parts for my reprap last year I accidentally ordered some thermistors that were only rated to 150°C rather than the 300°C of the recommended part. I can’t remember if it was just an oversight or I was swayed by the fact that they were only £0.58 each as a opposed to £3.99.

After realizing my mistake I ordered the correct part but assembled an extruder using the thermistor at hand out of both curiosity and impatience. The results of initial testing were quite good (see this post) and the initial prints seemed acceptable. I decided after printing Adrian’s geared driver it would be a good time to rebuild the heater of the extruder using the glass bead thermistor.

Photo 1: The charred remains of a thermistor 100°C outside its comfort zone.

After removing the resistor from the charred heater (pictured above in Photo 1) one of my main concerns with the heater was that the polyimide tape was often melting and giving off fumes. As I was only heating to 220°C at most according to the extruder control board then either my tape was not the Kapton™ tape it said it was or the thermistor was reading the wrong temperature. I’m not sure that the wrong temperature was due to the bad thermal contact with the nozzle or the fact that I was operating outside the recommended temperature range. The new thermistor is much much smaller (0.8mm diameter (Ø) as opposed to 6.3mm Ø) and so should be much closer to the heater barrel and able to achieve much better thermal contact.

Once rebuilt, tested, the extruder firmware reprogrammed for the new thermistor look-up table, and the sanguino motherboard reprogrammed for the new extruder drive I started printing some test parts. The test parts are from a design I’ve started for an adjustable hub for use in feeding filament into the reprap.

Photo 2: The Hub-o-matic

I had found that with the previous heater I was able to extrude reliably at temperatures around 200°C – 220°C. With this new thermistor in place I needed to heat the system up to 250°C to get comparable results. I hope to get a thermocouple sensor at some point to confirm the actual temperature of the nozzle. My preliminary testing at temperatures below 100°C show the tip of the nozzle to be about 50°C below the temperature read at the thermistor. I am unsure if this is due to sensor error or simply heat dissipation along the heater barrel.

Once up and running though I did get some parts printed, but only after a couple of runs that ran out of steam half way through. The photos below show examples of the good and the bad prints. To get a sense of scale the spindle is M8 threaded rod and the screws holding the struts to the bearing holders are all M3x20. The bearings a 608ZZ (AKA skateboard bearings). The usual problem I find with my prints going wrong is that they print perfectly for the first part and then the extruder just runs out of heat and the extrusion becomes quite lumpy. This I normally try to fix by increasing the temperature. This works to an extent but costs you in quality as the extruder begins to ooze uncontrollably or simply extrudes too much filament.

Photo 3: A good print of a 60mm x 10mm x 10mm strut for the Hub-o-matic

Photo 4: A bad print of a 60mm x 10mm x 10mm strut for the Hub-o-matic

After the initial prints I built up a second heater barrel using the same type of thermistor and confirmed the temperature behaviour and performance to be the same.

The new extruder driver certainly has plenty of torque and I feel it could almost push through the filament cold. I must admit I had my doubts about the design when I first looked at it and printed out all the parts. There didn’t seem to be enough parts to hold all the bearings in place, and the 55 tooth gear seemed a little loose and unconstrained in its positioning. After building it and threading the filament through I am impressed. The brass insert from Conrad Electronics really does grip the filament well and the gears mesh beautifully. It is also worth noting that I initially overlooked the last instruction in the build, to use some silicone grease on the gears, but it does make a dramatic improvement in the gears ability to mesh nicely, smoothly and quietly.

I did deviate from Adrian’s design slightly. As my motors have a 2mm Ø cross drilling on the end of the shaft, instead of filing the end of the motor shaft flat, I drilled a 2mm Ø hole through my drive gear and used a spring tension pin to retain it. I’ve also made one other change to Adrian’s design. I can’t stand using glue or epoxy for something like this so I retain my PTFE thermal barrier using two M3x20 screws through the base and thermal barrier (perpendicular to the direction of the filament and heater barrel). This allows me to swap out extruder barrels quickly without cutting any tape when they give trouble or become blocked.

While I am reasonably happy with my initial prints I have decided to build Adrians geared extruder driver to improve the consistency of the extrusion.

The three photos show my new extruder driver. Although the printed parts look good enough to work in this situation a close inspection of the print show the extrusion tends to “bead” a little and on some prints just stop altogether. I’m hoping a driver with more “torque” will improve this as well as better spool management. I’m also building a new extruder head as well to improve the temperature stability.

If anyone has other ideas on how to better improve the print quality of my reprap I’d love to hear about them.