Monday, June 14, 2021

NOP21's Kinetic Gears Sculpture

 I my previous post about triaxial tourbillons, I mentioned that I had built the Gyrotourbillon designed by Thingiverse user NOP21 (build, video). I've built a few other designs from the same person including a complex and beautiful escapement (build, video) and some intriguing gears (build). NOP21's designs are always careful and well thought-out. Their recent designs include a couple of kinetic sculptures (1, 2), and as this is something I've been getting interested in, I built the first of them.

Here's a couple of pictures and some video:




The filaments are Geeetech silver, bronze and gold silk PLA, Mika3D white and black PLA, and Sunhokey rainbow PETG for the base.

I've found that the tolerances for most mechanical designs off Thingiverse are too tight. The design was an exception. The frame elements (the black structural parts) didn't fit together tightly, and the bearings were also too loose to stay in securely. I made the bearings fit better by lining the inside of the opening for them with a sliver of blue tape, and I got the parts to fit together by gluing them. Usually cyanoacrylate glue works fine for PLA but in this case it didn't do a good job and I resorted to using a hot glue gun instead. This worked OK, though you have to act fast after applying the glue, which can be tricky in the stages where you need to fit several pieces together at once.

The original design used a motor like this one with a variable speed controller board. I though it would be interesting to replace this with a small stepper motor, the widely used 28byj-48. In combination with an Arduino Nano and a ULN 2003 driver board, it means you can program more complex movement pattern, such as a gradual change in speed or a reversing the direction. I designed a simple coupler to connect the frame to the stepper shaft and I also redesigned the base to accommodate the motor and electronics.

There are two other minor changes. The axles for the gears are designed to be printing lying on their side (axis horizontal). This entails some cleaning them up afterwards to smooth out the lowermost layers. I prefer to print them with the axis vertical. This doesn't quite work as the triangular end of the axles is not quite flat. It's designed to follow the curvature of the overall design. I flattened out the ends; you can't really see the difference unless you know to look for it. Secondly, I needed to make the washers for the gears ("rondelle A") thinner. As originally printed they were simply too thick and the gears wouldn't turn. Either 0.4 or 0.2mm worked better.

I wrote controller code which allows you to create a program made up of steps., each consisting of a move of specified duration and speed, followed by an optional pause. You can have several programs. The box design allows for three buttons, which I use for pause, faster and slower. When pause is pressed, the faster and slower buttons are used to step between programs or set up to auto-advance to the next program when the current one is complete. There are also some status LEDs.

There is a bit of wobble in the movement, especially at slow speeds and when starting or changing direction. I think this is due to the shaft coupler not being a tight enough fit.

The modified parts and code are available on request; leave a comment if you are interested. I'm not usually posting remixes on Thingiverse now as the site has become so difficult to use.

Thanks to NOP21 for the original design. I am thinking of exploring kinetic sculptures further and this was a good initial project, easy and enjoyable.


Friday, June 04, 2021

Triaxial Tourbillons

Some History And Background

I've written in the past about 3D printing tourbillons. These are, in essence, the timing core of certain clock and watch mechanisms. They regulate the rate of the overall mechanism by means of an arrangement of a spring, an escapement wheel and a shaped piece called a fork. You can think of a clock as consisting of a power source (like a weight or mainspring) and a gear train which provides the right ratio between the movement of the hour, minute and seconds hands. The tourbillon alternately locks and then releases the entire mechanism so that the timing of this gear train is regulated. It requires precision, to get the timing right, and strength, as it has to slam into place to halt the whole mechanism and then hold back the power source until it is time for the next tick

As such, 3D printing from plastic doesn't seem like a good design choice. Plastic deforms (bad for holding back the mechanism), is springy (bad for exact timing) and is weak (bad for resisting the forces when it has to halt the mechanism). Nevertheless, there have been some remarkable successes in printed designs for clockwork mechanisms based on tourbillons. Here are some examples:

  • Mechanical watch by TheGoofy (design, video), driven by a plastic spring.
  • Clockwerk deep space tourbillon (design, video), driven by a weight.
  • NOP21's Gyrotourbillon (design, video), driven by a metal spring.
  • Cabestan triaxial design by mcmaven (designvideo), driven by a stepper motor.
  • Astronomia triaxial tourbillon, based on a watch design by Jacob and Co. This has been through multiple versions:
    • the original design by A26 (design, video). It used a weight as a power source.
    • mcmaven's improved version (design, video), also using a weight.
    • a variant in which the overall motion and the tourbillon are driven mechanically with a weight as the power source, but the timepiece is replaced by an off-the-shelf quartz clock (design, video).
    • a further modification in which the weight is replaced by a pair of stepper motors (design, video 1, video 2). This is called the Triaxial Motorized design, and it's what I'll mostly be talking about here.

There are more on Thingiverse and other 3D printing sites, plus a few on YouTube for which the designers have not released the build files or charge for them.

I have tried building several of these, with varying degrees of success. I never got TheGoofy's watch to work, and didn't have much success with the Clockwerk design. In both cases, I tried these when I had a printer that is less good than my current one (Prusa MK3S) and when I had less understanding of how to debug the mechanisms. Over time, the designers have also provided better documentation. mcmaven's assembly notes are good and with the most recent design, the stepper driven Astronomia, go into a lot of detail about the assembly process and problems to watch out for.

Here are videos of some of the my past builds:
The second of these took a lot of weight to run. What you can't see on the videos is that there is a bag containing two heavy iron wedges. The weight was so heavy that it was quite scary attaching it, and it pretty quickly distorted the mechanism, magnifying any imbalances or misalignments in the assembly.

The use of stepper motors as a power source is interesting. Stepper motors can apply a lot of torque and then hold the mechanism in place when they are halted. However, it's also weird to have them as well as a tourbillon, as there are now two separate elements which regulate the timing: the step period, and the period of the tourbillon. Bad things happen when the periods are not equal. If the stepper tries to advance the mechanism while the tourbillon is blocking it, then something is going to give. Usually this means a gear somewhere jumping forward. It could also break weaker components. If the stepper is running slower than the tourbillon, when the tourbillon releases there won't be a need dollop of energy ready for it, and it may not have enough momentum to drive the escape wheel and fork to the next tick.

A Build Of The Triaxial Motorized Tourbillon
After a long break from printing mechanical devices, I decided to have a go at the Triaxial Motorized Tourbillon. Here are some videos and photos, including a few at intermediate stages.




I'll come back to that weird little circuit board in a moment.

The tourbillon running:

The core at normal speed and slowed down:



There is no battery in the clock mechanism in these videos, which is why the hands don't move.

In previous builds, I used whatever filaments I had in stock, but this time I chose ones which were a bit more pleasing aesthetically. mcmaven took some trouble in this latest design to emphasize the appearance, for example in the shape of the carrier and the "jewels" which cap parts of the mechanism. The filaments I picked included silver, gold and bronze Geeetech silk PLA, and white Mika3D PLA. For the base, globes and clock face I used Sunhokey rainbow PETG. The rainbow filament is just filament which is dyed with different colors along its length. I had used it before when printing PPE faceshield frames and enjoyed using it. I was lucky with the transitions, so that where there are cut-out letters and numbers on the base on clock face, the color that shows through is different from the surface color. It's a little hard to see, but here is an example:


I also used a little orange Prusa PETG for the base bottom.

(I'm going to refer to a few specific parts in the following. If you care about the details and want to understand what I am referring to, look at the PDF in mcmaven's design under "Thing files".)

I made a number of changes to the design. Some of these were to make fitting parts together a little easier when the tolerances were tight. In a couple of cases, I took large parts and split them up, so I could divide up the printing time, and also to reduce the need for support. An example is the base bridge which conveniently can be split into two parts. A few of the original parts are designed to be printed in pieces and then glued together. In some cases, I modified them so that I could insert a 1mm pin to keep the parts aligned while the glue set. For example, the globes each have three pins aligning the halves, and similarly for the two halves of the carrier shaft. Speaking of the globes, I replaced the original sun and moon globes with a smooth sphere and a faceted one, made using a UV sphere and an icosphere in blender. Both were printed with rainbow filament, though I happened to hit a rather boring part of the roll and so the colors are not very striking.

The electronics in the original design uses a rotary encoder to adjust the speed, with the push button pausing the steppers. As several others have found, there seems to be a bug which means it can never be unpaused. I've started at the code for some time and it's not apparent to me why other than one slighly suspicious call to the stepper library. I also found reading the rotary encoder to be flaky even with debouncing, and so I replaced it with three microswitches (faster, slower, pause) mounted on a small piece of stripboard. This entailed rewriting the code to control it. Otherwise, I am using the same as the original: an Arduino Uno, and two 28BYJ-48 steppers attached to ULN2003 driver boards.

Here's a more or less complete list of the parts I modified or gave special treatment to:
  • Escape wheel: needed special slicer configuration to set the perimeter width to 0.35mm. Otherwise the PrusaSlicer discards part of the model.
  • Fork frame back: slightly changed the dimensions of the hex "plugs" so they fit more easily into the fork frame.
  • 40T fork frame gear: added a MR52 bearing
  • Crown gear: dispensed with the bearing spacer and instead added set screws for the bearings. . More on this and the 40T gear below.
  • Base Gear 2: split into two parts.
  • Base Frame 2: split into two parts.
  • Carrier shaft: added 1mm pins for aligning the halves and scaled by 0.98.
  • Stepper pinions: slightly scaled the interior hole so it fits more easily on the stepper shaft, after breaking them several times.
  • Counter weight and cover: added screws to hold them together. Slightly scaled down the length so it fits in the crown gear more easily.
  • 8T gear: scaled the interior hole for a closer fit.
  • Base bottom: added a rim to get extra depth for the wiring. This would have been better as a change to the base, but by then I had already printed it.
  • Globe shafts: merged the half models and then split them perpendicular to the axis. This gives a nicer appearance in the printed result. Used a 1mm pin to align the parts.
  • Globes: I replaced these.
  • T Frame Middle B: slightly reduced the size of the top cylindrical element. See below.
  • Fork: made the fork pin slightly thinner. See below.
Several other parts needed sanding or filing. In general I found most of the fit to be too tight rather than too loose. This was quite widespread (see the scaling on the carrier shaft in the list above, for example), and I wonder if either slicer settings or my printer's calibration made the parts slightly larger than mcmaven's. I have the same model of printer as mcmaven, and only changed the settings that he specifies as needing non-default values. Perhaps the climate or variations in the filament diameter make a difference.

I'm not intending to publish a remix for the modified parts on Thingiverse as it's such a pain to use these days, but if anyone reading this wants them, please leave a comment.

One other minor note. The steppers are specified as drawing 240mA, and the USB chip on the Arduino Uno is supposed to have a limit of 500mA, with most people recommending you don't draw more than 400mA. I didn't see any problems, but it could be pushing the limits. As an experiment I used an external power source and took the stepper power from the Vin pin on the Uno. I couldn't see any difference in this other than the steppers getting hotter and a bit louder.

Making it run
The biggest issue is getting it to run reliably. The tourbillon in isolation ran fine right off when I drove the escape wheel by hand. I tested everything else by assembling it with just the 8T gear from the tourbillion omitted so as to temporarily disable the escapement. There were a few minor problems, such as some elephant's footing on the carrier globe gears causing friction against the carrier, but nothing serious.

After reinstating the 8T gear and so connecting everything together, two problems were immediately apparent, both resulting in the mechanism skipping. First, the 40T fork frame gear skewed out of position, and secondly the 608 bearing in the crown gear slipped so that the 40T gear's teeth only partly engaged with the crown gear. As mcmaven notes in his documentation, the 40T gear is one of the most critical pieces to print and assemble accurately. It takes a lot of force and will try to skew out of position. I found it helped to redesign it so that it has a MR52 bearing in it instead of mounting it directly on a 2mm shaft. This is a component which perhaps scales poorly from the original watch design, where it is subjected to much smaller forces and the bearing or shaft is made from a more rigid material. To solve the problem with the 608 bearings in the crown gear, I replaced the glued-on 22x19x2 spacer with set screws, similar to those used elsewhere in the design.

I played around with various speeds for the stepper. Too low and the movement of the balance wheel was so weak that it would stall. Usually it would restart by itself, but sometimes it needed a nudge. With the stepper speed set higher, the balance wheel swung nicely, but occasionally the mechanism would slip. I assume that what was happening is that they drive from the steppers and the timing of the escape/fork/balance combination were just enough out of step that the tourbillon would halt the mechanism but the steppers would force it on. I recall mcmaven noting a similar problem with one of his other designs, which he solved by replacing the gear drive with a rubber band.

It's possible to approach this more scientifically. The analysis in a comment thread for a make establishes that 2400 beats should be equal in duration to 9178 steps.  Using a sound recorder and running the tourbillon by hand, I measured the time between beats as 0.32 seconds on average, for a balance wheel with two M2.5x6 screws. This gives 0.0837 seconds per step of the motors. In the stepper library, the time between each step is 60/steps per rev/speed. The steps per rev is set to 32 (not actually the true steps per revolution: it's only used in time between steps calculation), giving a speed of 22.4. In fact these will be slightly out as the stepper library does not account for overhead both within its own code and in calling code. But even it that overhead was an extra 1ms, it would only change the speed by about 0.2. As the speed is an integer, the default value of 22 seems about right here.
(Side note: I later reprinted the spring and balance wheel, and ended up needing a faster speed, 30 or 31. However, the logic here still holds.)

Having said all this, the point of a tourbillon is to average out variations in timing caused by different orientations, so the idea of measuring the beat time and picking the exact stepper speed for it doesn't quite make sense. This goes back to the observation I made earlier that the presence of both stepper and tourbillon means there are two source of timing in the system, and that may result in problems.

The model sometimes ran for 10 minutes or more without any problems, and I also had occasions when it would run for less than a minute before stalling or skipping. After a while, things seemed to be getting worse. A very close inspection at various orientations showed two problems: the 40T gear was just interfering with the cylindrical top of T Frame Middle B, and sometimes the pin of the fork would just interfere with the balance wheel. The second of these was not initially an issue, but at one point I decided to reprint the spring as it was deforming, and in changing it I broke the balance wheel and so needed to reprint it as well. The new balance wheel was a fractionally different fit to the previous one and so interfered with the fork when the original one had not.

To help with these problems, I modified the models, to make the top of T Frame Middle B a bit smaller, and to make the fork pin thinner. After these changes, it ran quite well; not as perfectly as mcmaven's or jdirgo's, but quite successfully all the same. Here's a timelapse:




What next?
I enjoyed making this, and was glad to getting it working with moderate reliability in the end. If I spent longer (or was more generally ept to begin with), I could probably make it smoother and run longer. I'm not all that interested in it a functional clock. I have plenty of these already, and I am not sure that I want to share my life, or at least my room, with something that goes tick all the time. But it's entertaining and soothing to watch it run.

The design is an improvement over the previous variants both in the engineering and the aesthetics, and something I might do with it is use it as a base for kinetic sculptures. What I have in mind is to remove both the clock face and the tourbillon and replace them with other elements, perhaps something along the lines of David Roy's designs or Peter Verhaart's.

Like it? Leave me a comment!


Monday, January 20, 2020

Rob Dobson's Scara Robot

After reading a Hackaday article about a sandbot, I got interested in building the Scara robot designed by Rob Dobson for it. I ended up making a number of changes to the design, controller and software. Mr. Dobson has not replied to comments on his blog or YouTube channel, so here are a few notes on the changes I made. But first, a picture.

Changes to the design

The design and construction are described in the blog post A New Sandbot and the STLs and code can be downloaded from Github from the links in that article. The article and the STLs are not quite the same, though it's still easy enough to work out how to assemble it. I used the laser cutter at work to make the acrylic pieces (the first time I'd used it). The changes I made were:

  • different spacers for the motors. I had two motors of different heights and neither was quite right with the original spacer.
  • made the "forearm" thicker. This is the grey piece with the magnet at the end, and it was very flimsy and wobbled whenever it moved.
  • changed the magnet holder to take a round 12mm magnet instead of the original square one. I had some of these magnets from a previous project and they are also much easier to find.
  • redesigned the lower arm locking piece to accept a 6mmx1mm magnet. This is used to trigger the endstop. The original design again used a hard-to-find square magnet.
The endstops in the original design used a board that can't now be purchased and required modification. I replaced it with some easy to obtain Hall effect sensors. They are not ideal as they trigger over a range if positions, though this can largely be fixed by adjusting the homing command, as described below. I designed new mounts for each of them.

Electronics and Software

Dobson uses a control board of his own design. There are two versions, one described in outline in the original blog post and a more recent one. I started by trying to use an off-the-shelf set up consisting of an Adafruit Huzzah32 and an Adafruit motor shield. The combination worked, though not very well, and I later replaced it with Dobson's Stepper Hat Trio board. (Another first: I haven't ever had custom PCBs made. At least, not since I was a hardware designer back in 1984). The Trio board is quite a good design, and there is an assembly video on YouTube. If you follow this video, note that one thing he forgets to say is that you have to put a jumper on J16 or the pullup resistors for the endstops will be floating rather than actually being pulled up, and won't work properly.

My experiments with the Adafruit parts worked OK, but were not great. The motor shield is not a modern stepper driver, and the motors run very noisily. I had to change Dobson's code to work with the Adafruit library (Github repo here). While I think his software is broadly good, doing this revealed a few things which were not ideal. Specifically:
  • there is a Stepper class to abstract the details of the motor, but the code writes directly to the digital pins outside this class, making it tricky to figure out where the changes need to go.
  • most of the motor control is done within an interrupt handler. As well as going against the general principle of doing as little work as possible in interrupt handlers, it's also not possible to call the Adafruit library from within the handler. ESP32 code requires all such code to have a special annotation, and so I would have had to change the Adafruit library and the libraries it depends on in the same way.

With the Stepper Hat Trio, things went more smoothly. I encountered a few issues. I suspect the published version of the code is not up to date with the board design.

The direction pins on the board are driven by a 74HC138 3-to-8 decoder. Different outputs are used for each stepper, but the effectively share the 3 pins that are the inputs. However, the code sets up the direction on a single pin, and does this some time before sending the step pulses. I fixed this by removing the 74HC138 and replacing it with a header that directly connected one of the 3 inputs to each of the direction pins for steppers 1 and 2. I am not using any of the other outputs of the decoder, so this worked fine.

The stepper drivers I used are TMC2208s. These can be controlled with SPI, and the board is designed to do this, but the code does not seem to support it yet. Instead, I added a couple of lines of code to pull the SDI/CFG1 and SCK/CFG2 pins high, so setting them for 1/16 microstepping. These pins are shared with the SPI interface, which in turn is used with the SD card on the Stepper Hat board; not a problem as I hadn't added the parts for the SD card. One final issue I found is that stepper 2 kept suddenly halting and turning the wrong way. This turned out to be because the configuration I had adapted was pulsing pin 14 to provide a WiFi status light, and I was using the same pin for the direction control of stepper 2.

As I mentioned, the Hall effect sensors trigger over quite a wide range, and so for homing, I changed the homing commands in the configuration so that they execute the following sequence: drive the motor one way until the endstop is not triggering; drive it the other way until the endstop triggers; then slowly drive it a fixed distance further, determined by experimentation. It's not super accurate but ends up with both arms centered fairly well at the home position.

For the record, here are my changes to the code to hold the extra two pins high (possibly unnecessary), and my configuration (with apologies for the horrible formatting).

  • In MotionHelper.cpp, after the loop which calls configureAxis.

    pinMode(33, OUTPUT);
    pinMode(16, OUTPUT);
    digitalWrite(331);
    digitalWrite(161);
    // Also set up auto standstill current reduction. Again, this conflicts with a SPI pin.
    pinMode(5, OUTPUT);
    digitalWrite(50);
  • Configuration
// ========================== DAHE config ===============================
"{"
\"robotType\"\"SandTableMooseScara\","
\"cmdsAtStart\"\"\","
\"webui\":\"SandUI\","
\"evaluators\":"
" {"
"   \"thrContinue\": 0"
" }"
" ,"
\"robotGeom\":"
" {"
"   \"model\"\"SingleArmScara\","
"   \"homing\":"
"   {"
// Search one way until the endstop is off, search the other way until it is on; then advance for centering, determined empirically.
"     \"homingSeq\"\"FR50;B10000n;#;B-10000N;#;FR1;B-120n;#;B=h;FR50;A10000n;#;A-10000N;#;FR1;A-450n;#;A=h;$\","
"     \"maxHomingSecs\": 120"
"   }"
"   ,"
"   \"blockDistanceMM\": 1,"
"   \"allowOutOfBounds\": 0,"
"   \"stepEnablePin\"\"21\","
"   \"stepEnLev\": 0,"
"   \"stepDisableSecs\": 10,"
"   \"axis0\":"
"   {"
"     \"maxSpeed\": 50,"
"     \"maxAcc\": 50,"
"     \"maxRPM\": 30,"
"     \"stepsPerRot\": 9600,"
// UnitsPerRot and things derived from it are only used in GeistBot, HockeyBot, MugBot and XYBot.
//"     \"unitsPerRot\": 628.318,"
// maxVal is the arm length in mm.
"     \"maxVal\": 100,"
"     \"stepPin\"\"27\","
"     \"dirnPin\"\"13\","
"     \"endStop0\":"
"     {"
"       \"sensePin\"\"39\","
"       \"actLvl\": 0,"
"       \"inputType\"\"INPUT_PULLUP\""
"     }"
"   }"
"   ,"
"   \"axis1\":"
"   {"
"     \"maxSpeed\": 50,"
"     \"maxAcc\": 50,"
"     \"maxRPM\": 30,"
"     \"stepsPerRot\": 9600,"
//"     \"unitsPerRot\": 628.318,"
"     \"maxVal\": 100,"
"     \"stepPin\"\"12\","
"     \"dirnPin\"\"14\","
"     \"endStop0\":"
"     {"
"       \"sensePin\"\"36\","
"       \"actLvl\": 0,"
"       \"inputType\"\"INPUT_PULLUP\""
"     }"
"   }"
" }"
" ,"
\"fileManager\":"
" {"
"   \"spiffsEnabled\": 1,"
"   \"spiffsFormatIfCorrupt\": 1,"
// Disable SD as we are holding the MOSI and SCK pins high for the microstepping config
"   \"sdEnabled\": 0,"
// The next 4 lines are unused with sdEnabled = 0
"   \"sdMOSI\"\"23\","
"   \"sdMISO\"\"19\","
"   \"sdCLK\"\"18\","
"   \"sdCS\"\"4\""
" }"
" ,"
/* Disable wifiLed as we are using pin 14 for dir 1.
" \"wifiLed\":"
" {"
"   \"hwPin\": \"14\","
"   \"onLevel\": 1,"
"   \"onMs\": 200,"
"   \"shortOffMs\": 200,"
"   \"longOffMs\": 750"
" }"
" ,"
*/
\"ledStrip\":"
" {"
"   \"ledPin\"\"25\","
"   \"sensorPin\"\"-1\""
" }"
"}"
,

Wednesday, July 11, 2018

Desktop thermometer

My office at work gets quite cold some days, and I wanted to know how cold. Also, I was at a loose end over the long July 4th break and looking for something to do. So I knocked together this project:


Inside the box there is an Arduino Nano, and a DHT11 temperature sensor, plus a 10k variable resistor to set the display brightness. The display is a 16x2 LCD. It displays the temperature and humidity and the range of temperatures it has seen. The readings can take a little while to stabilize, so until they do the C and F are displayed in lower case, and the % for the humidity is shown as H. The Arduino sketch is here, and the comments in this file also say how to connect it up. You might need to install the DHT library from Adafruit (info linked from this page). It uses a USB connector for power.

I designed the case with Fusion 360. It holds together with friction. I undersized the hole for the DHT11, meaning it's not quite large enough for the sensor to stick out. Rather that spend another 90 minutes printing a replacements, I just attached the DHT11 inside the case with hot glue, which works fine except that it came out a bit skew-whiff. But that's how you know it's home made.




Sunday, April 29, 2018

High altitude printing

Recently, I was printing a frame with a tall arch shaped part to it. The designer of the object  provides a version with built in support and one without. If I allow Cura to generate the support for the one without, the printing time is a lot less, so that's what I went with.

It was all going well until the support detached from the build plate. The printer then merrily continued, dumping the support material into thin air, where it gradually turned into a big pile of print snot. It is complete coincidence that I was using a green filament.


I trimmed away some of the slot and let it keep going. Amazingly, after a while, the printer managed to re-establish a bridge across the arch with a few layers of support to go, and get to the end of the print.
Here's the print with the snot that I trimmed away and the support that came loose.
After removing the support and the rest of the snot, the results are a bit ugly, but not too bad.

Sunday, April 22, 2018

Forcing variable layer heights in Cura

Recent versions of Cura have an experimental feature where it selects different layer heights according the slope of the model. As the slope changes from vertical to horizontal, it uses a lower layer height to get better shaped prints. Imagine a dome, where the later height gets smaller as it reaches the top, and you'll get the idea.

I have a piece that I wanted to print where I wanted most of it to print at 0.2mm or 0.3mm to keep the print time down, but wanted a small vertical extrusion to print at 0.1mm for strength and precision. As the extrusion is vertical, this won't trigger the adaptive layer heights.

A simple solution is to add a second object which has a dome at the same height a the extrusion. As the same layer height is used across all the objects, the low layer height needed for the dome also applies to the extrusion, while the remainder of the model prints quickly. Here is a screenshot from Cura to illustrate what I mean. I know it's a bit tiny; for a bigger version, look here. In short, the dark blue is 0.1mm layers and the yellow is 0.3mm.


Saturday, March 31, 2018

CoreXY frame

Continuing my noodling around from last week, I started to put together a frame for a CoreXY system. I could have done the right thing and designed this in a CAD package, got all the measurements right, blah-di-blah, but instead I'm just winging it and knocking together what I need in Blender. Here's the frame with motors and runners but no belts yet:
The motors are mounted on plates bolted to the bottom of the frame with spacers to raise them to the right height. These corners of the frame have internal L-shaped brackets.
The gantry is mounted on brackets with runner wheels:
They move quite smoothly, though I think the brackets will bend over time.

For the pulleys, I'm going to use flanged bearings. I really wanted ones with a 5mm inner diameter, but I would have had to wait a couple of weeks to get them, so I bought some with an 8mm inner diameter and added a insert.
I ran out of 5mm washers, but there is an easy solution to that:
The next stage will be to get all the pulleys set up. The motor height is designed to work with pulleys mounted on top of the gantry with a 30mm bolt as you can just see in the video clip. For the pulley fixed to the frame, I'll need a mount to raise them high enough. More to follow.