Bookkeeping and janitorial duties

There isn't much that is flashy to report at this time. A lot of my time in the past few days has been focussed on a telepresence 'bot project I have intended to design and build for years that the Rapman finally lets me design and print parts for. Oddly, though, getting the basic software modules that will control the 'bot all working together looks to be far harder than printing and building the 'bot itself. I guess that having worked on Reprap for five years now makes me a lot less intimidated by hardware tasks than previously.

Last week, I discovered that Slice and Dice's vectorization routine, which converts pixel defined boundaries to print areas into vectors usable in gcode, wasn't particularly nice. It was not reducing the boundary definitions nearly as much as it ought to have been. What that means as a practical matter is that it generates a lot more gcode than it ought describing very sort little print roads of a few tenths of a mm. Rapman is not designed to deal very efficiently with that kind of gcode and what happens is that the print speed drops well below the nominal rate set with the "F" specification. That not only wastes time but also puts more plastic on the print than it needs to have in areas where the perimeter curves. THAT makes for poor print quality.

I got to the bottom of that problem over the weekend.

As I set up for testing some new approaches to vectorization, I remembered that shifting from BMP to PNG reduced the disk requirements for a print project dramatically. I have plenty of disk space, but the reduction in disk requirements led me to redesign the files handling for Slice and Dice so that one can readily process and work with more than one print project at a time. That job holds no challenges as such, but is merely a bit of tedious restructuring files handling routines and testing to make sure that they all work. I've got that about two-thirds done.

Thus, slowly but surely Slice and Dice begins to look like very preliminary beta code.

Collapsing the hard disk requirements of Slice and Dice

I managed this by the simple expedient, suggested by my son Adriaan, of replacing the BMP format slice image files with the Portable Network Graphics (PNG) format which uses a lossless data compression scheme.  This reduced my slice image files in size from 16-22 Mbytes per slice to 80-100 Kbytes.

Delta 'bot Axis

It's one thing to design and print plastic parts that have to mate with steel rods. As I am finding it is quite another to design plastic parts that have to mate with other printed plastic parts. During the last week in my spare time I proved out a design for a hexagonal column which I think might accommodate a herringbone rack and a sleeve seating a pinion gear, stepper motor and two guide plates.


Heretofore, I have been butt seating the column sections and then post-tensioning them. While that was okay for demonstrating the design approach, worries about creep said that I needed to have a male/female attachment technology so that I could fit sections of the column together and avoid having them do a lateral creep out of alignment. That proved to be considerably more difficult than I imagined.


This last weekend, I decided to take a different approach and instead of doing a conventional slice and dice of an STL, I decided instead to work with the print roads of my thin-walled column instead. What I did is a radial 45 degree overhang inside the column onto which I printed the male insert. I think it is worth mentioning how I achieved that.


The column was achieved for most of it's length with three concentric print roads of 0.6 mm width. What I needed to do was to build a ledge inside the column. When I began the ledge I widened the innermost print road to 0.8 mm. On the next layer I replaced the 0.8 print road with two 0.6 print roads. This process left me a 0.2 mm miniledge onto which the new innermost print road could adhere. I repeated this process until I had a ledge wide enough to print the male insert onto.


You can see the insert successfully executed here.

I would like to be able to say that that was all an easy exercise. It wasn't.  I did exactly thirty text prints like the one you see before I was satisfied with the seating of the guide strips, herringbone rack and the male/female column connector system.  I also had to chase several heretofore unsuspected bugs in Slice and Dice AND extend the coding somewhat.  All the same, it's done and works so far.


At that point, I decided to see how tall a monolithic column section I could print.  It appears that Rapman three can handle about 225 mm in the z-axis.  I designed a 200 mm column with a 4 mm male connector and am printing it at present.

It is 2120 and I am up to about 50 mm.  I'm doing a 0.25 mm layer every 45 seconds, so I expect to be finished at about 0500 tomorrow morning.


With such a large print I began to encounter xy and z faults.  The xy faults were annoying, but the z faults tended to plunge the hot extruder head into the print.  Upgrading the Rapman firmware to 2.0.8 got rid of the z faults but the xy faults remained.


I reduced the column test print to 55 mm, relocated the Rapman further away from my PC on a table by itself away from the cold window and switched ABS to HDPE because the acrid fumes were getting to be too much when I wasn't able to open the windows.

A thorough cleaning of the extruder with compressed air was also undertaken.  After a few test prints I got the flow rate sorted out for HDPE and was able to successfully print a 55 mm column section in HDPE.