Hangprinter With DuetWifi and Two ODrives

I recently decided to use three circuit boards in my Hangprinter v4 prototype: One DuetWifi, and two ODrives. It turned out to be a challenge to get wiring and communication to work the way I wanted.

I wanted to use stock RepRapFirmware (RRF) on the DuetWifi, and stock ODrive Firmware (OF) on the ODrives. No special "Hangprinter Firmware", only Hangprinter configuration of stock firmware. I wanted to connect the two types of boards directly with jumper wires. No special multiplexers, filters, level shifters or anything like that between the boards.

I aimed for something like this:

Why The Non-step/dir Wires?

Convenience. Let's call them convenience wires. The step/dir wires can only be used to communicate a desire for incremental movement. Through convenience wires we can tell ODrives to more exciting things, like:

• Live PID tuning
• Live tuning of min/max speeds and currents
• Live configuration of microstepping
• Trajectory planning
• Interfacing with yet more circuitry, like cameras and load cells
• Anti-cogging
• Torque estimations via motor current readings
• Motor shaft position readings
• Enable/disable position control, current control, or velocity control

The first exciting thing I'll focus on implementing in HP4 is better auto-calibration. Anchor positions and line buildup parameters should be calibrated during the same routine, and the user should just have to start this routine and wait for it to finish.

Making Boards Talk About Exciting Things

The basic step/dir communication was straightforward to set up. Both boards and firmwares had good support and documentation already. So we got to feature parity with HP2 quickly. Not super exciting, but a really nice start. With no more than basic setup and a step/dir connection, the ODrives showed promise of being able to make HP4 run really really fast.

The HP3 got beyond HP2 features by talking i2c protocol through convenience wires (and a level shifter). Unfortunately, ODrives lack i2c support. ODrives are only prepared for controller communication via their universal asynchronous receiver-transmitter (UART). To be more precise, ODrives have one pair of Tx/Rx pins with 3V3 logic levels, talking RS-232 with 8-bit words, no parity bit, one stop bit, at a rate of 115200 bits per second.

So, I had to go for UART in the HP4 convenience wires. There were two small problems to overcome:

• ODrive Firmware did not support UART and step/dir to be enabled at the same time.
• DuetWifi had only one pair of Tx/Rx pins exposed.

Madcowswe, ODrive's main dev, helped solve the first problem real quick. Within a few hours, he added firmware support for step/dir and UART to be enabled simultaneously. I carried out some basic tests of the step/dir communication.

Dc42, who is DuetWifi and RRF's main dev, helped me with the second problem. He told me that one of the DuetWifi's pair of SPI pins were really USART pins, and could be reconfigured in software to act as UART pins. It took me a few days to get the pin re-configuration right, and stock RRF currently doesn't support it. I will of course stay in touch with dc42 and try to get all HP4 functionality merged.

How To Connect And Configure HP4 Convenience Wires

There are 12 communication wires to be connected between the DuetWifi and the two ODrives:

All the pre-compiled binaries and configuration files you need are found in the firmware directory of the version_4_dev branch.

Config Comments

To enable the right pins on the ODrive, use ODrive Tool to send

odrv0.config.enable_uart = True
odrv0.axis0.config.step_gpio_pin = 6
odrv0.axis0.config.dir_gpio_pin = 5
        

• Pin 5: dir axis0
• Pin 6: step axis0
• Pin 7: step axis1
• Pin 8: dir axis1

I'm still a bit unsure whether dir signal on the non-filtered pin 5 will work well in the long run. An oscilloscope would be needed to really see if the dir signal quality is good enough. The small tests I've conducted by just counting steps with the encoder have shown no dir errors thus far.

The following gcodes will enable right UART pins on the DuetWifi:

M569 Q0:1:115200  ; Connect ODrive 0 to Serial device 1 at 115200 baud
M569 Q1:99:115200 ; Connect ODrive 1 to Serial device 99 at 115200 baud
        

M669 K6                 ; This is a Hangprinter
M584 A5 B6 C7 D8 P4     ; map ABCD-axes to ext driver pins (four visible)
        

- tobben

2018-12-26T12:00:00Z Torbjørn Ludvigsen I recently decided to use three circuit boards in my Hangprinter v4 prototype: One DuetWifi, and two ODrives. It turned out to be a challenge to get wiring and communication to work the way I wanted.

Office And HP4 Prototype One

I recently got my own dedicated Hangprinter space. It is a room in an old industrial building, in a collective of potters and musicians. Well, it wasn't really a room when I first got it. We built a wall, and made it a room. To the right in pic below.

It's within walking distance from my home, has home made coffee cups in the kitchen, two massive kilns at the entrance, and good live music every single evening. It's a messy, friendly, and beautiful place. I feel free here.

If you look closely at the picture you'll notice my little Mendel and its latest offspring; the latest HP4 prototype. I've been working on it quite intensely since I got my new space. Check out the version_4_dev branch if you want the source. Here's a quick overview:

HP4 Prototype One

This hardware prototype is made to allow faster, stronger, smoother, more accurate motion. The first three goals motivate choices like

• BLDC motors driven by oDrive PCBs
• DuetWifi main PCB
• All ABCD axes are geared down with pulleys

To really get more accurate, we need better calibration, which motivates

• Belt driven spools
• Larger spools
• More spools (one for each line)

Other hardware changes are made just for looks and tidy order:

• Spools are raised upright
• Lines are routed via idler pulleys internally on the ceiling unit

Previous anchor line rollers could break if you stepped on or kicked them by accident. The new ones are much more likely to survive such treatment.

HP4 Prototype One - Not As Finished As It Looks

(At least better than the first HP3 prototype's slogan: might be awesome if it works.)

Those hardware changes are all fine and dandy, but the more important improvements require better software, which is not yet written. The more important improvements include

• Flex compensation
• Better calibration
• Automatic homing

Without them, we can't ave adequate accuracy, except close to the origin. I mean, you can make 1 m movements (video), but you can't print a decent Benchy out there.

Flex Compensation

Flex is an obvious pain point in the HP3 since its firmware assumes nothing flexes, while in reality everything flexes. In extreme positions, this can give errors at the order of centimeters.

I mentioned earlier that all axes are geared down with pulleys on the HP4 prototype. This means twice as much line between anchors and effector, and hence only half the flex. Sturdier plastic parts also helps.

The real fix however, is to measure flex and compensate for it in firmware. The equations have been worked on in an earlier post, and the HP4 should definitely use them when planning its every move.

Better Calibration

There's actually a conceptual error in the current semi-automatic calibration routine (apart from the truncation error that was found and fixed). The M114 S1 command outputs line lengths. It gets these line lengths by reading motor shaft position and compensating for line buildup. But line buildup compensation requires correct anchor calibration in order to work correctly. So the data is imperfect even if the user does a perfect job while collecting it.

The obvious way to fix this is to have M114 S1 output shaft positions, and do the line buildup compensation within the cost function instead.

And once we've moved buildup compensation into the auto-calibration code, then we have the chance to throw the buildup factor in there too. The buildup factor is a measure of how much volume a meter of line takes up. This has been guesstimated based on line diameter up until now, and it's been known that the guesstimate is imperfect, which makes the whole buildup compensation even more imperfect than it could be.

Hopefully, the improvements described above would allow us to auto calibrate by moving the nozzle to known positions. Such calibration would give more accurate result than the current random-position-based method. We tried it with the HP3, but it failed. I think it failed because errors from flex, truncation, and imperfect buildup compensation were too big for the optimization algorithms to work with.

Automatic Homing

Perhaps the most obvious accuracy bottleneck in HP3 stems from the manual homing. Human hands are great precision tools, but not good enough for 3d printing. Three things vary between manual homing procedures.

1. The actual home position of the nozzle.
2. The tightness of the lines in that position.
3. The flex or loose line that has accidentally gotten wound onto the spools.

A good, cheap, and simple homing routine would be to crash (with a repeatable force) the effector into a bracket in the ceiling, and then tighten ABC-lines to a repeatable tension, before moving down to the origin in a controlled fashion.

We have previously been prevented from doing that long moves in a controlled fashion. This was due to inaccurate calibration parameters, both for the anchor positions and the buildup compensation. It's funny how bad accuracy leads to worse accuracy and vice versa.

Epilogue

And, well, that's only the beginning of the prototype's overwhelming unfinishedness. Will the belts stay on, or will they jump off? Will they wear out quickly? I don't know.

I'm still unsure if the extensive use of vgroove bearings is wise, or if the lines will occasionally fall off. My unstructured testing has convinced me to at least try and trust the 44 line guiding bearings in this prototype. I've only been able to make lines fall off bearings by pushing hard with needles and the tip of a knife. But you know, I fear Murphy's law will come and bite me. Time will show.

I'm also unsure if the BLDCs will give satisfactory stiffness and smoothness at the same time. I'm planning to use the experimental anti-cogging feature to make the motors move really smoothly like expensive BLDCs with tilted magnets do.

Last, but not least, will the world make fun of my line_verticalizer because it looks like a fish? Only the brave gets to learn interesting stuff the hard way.

- tobben

2018-10-17T12:00:00Z Torbjørn Ludvigsen I recently got my own dedicated Hangprinter space. It is a room in an old industrial building, in a collective of potters and musicians. Well, it wasn't really a room when I first got it. We built a wall, and made it a room. To the right in pic below.

Crashdummies Wanted

The Hangprinter support in RepRapFirmware is looking for pre-alpha testers! You can be the first person to combine Hangprinter with Duet, RepRapFirmware, and 32-bit controllers. If you get it working, your Hangprinter will be the fastest one on earth. You will be on the bleeding edge, and help Hangprinter development. See the previous blog post and duet3d.com for more on how Duet and RepRapFirmware will make HP4 better than HP3.

Wiring

I don't have a Duet specific wiring diagram. You will have to compare with two other diagrams: Compared to Duet's default wiring, you will wire the ABCD (Mechaduino) motors differently. You will not connect endstops or bed heater, but you will connect i2c cables.

Compared how the RAMPS is wired in the HP3 manual (click for larger):

Upload Pre-Alpha Binary

Once your Hangprinter+Duet parts are put together, upload the latest official RepRapFirware release to your Duet. Recommended resources: Duet getting started guide, and RepRapFirmware releases page.

Then go on to learn about the changes I've made in the pull request, here. I've built a Duet2_RTOS binary that you can upload directly. It is found here. If you're experiencing RTOS related bugs, you could try the non-RTOS build. Binary here.

RepRapFirmware Configuration

Now, with the Hangprinter compatible binary uploaded and installed, you need to configure it right. There is a slightly outdated Hangprinter config guide on the duet3d dozuki.

After the dozuki-guide was written, I've added spool buildup compensation, and support for ABCD-parameters to the gcodes M589, M92, M201, M906, M203, M208, M350, and M566. I've also added support for torque mode (G95) and gcodes needed for auto calibration (G96 and M114 S1).

Here are some gcodes I would use to set up my RepRapFirmware for use with Hangprinter and a DuetWifi:

M669 K6 ; Set Hangprinter Kinematics
M669 Aax:ay:az Bbx:by:bz Ccx:cy:cz Ddz ; Set anchor positions
M584 A5 B6 C7 D8 P4 ; The step/dir of Mechaduinos connect to exp E2 E3 E4 E5
M584 E0:1:2:3:4 ; Regard all TMC2660s as extruder motor drivers
M569 P5 I0x0a ; The Mechaduino connected to driver 5 (E2_step/dir) ...
M569 P6 I0x0b ; ...  is connected to i2c and has address 0x0a
M569 P7 I0x0c ; ditto for BCD.
M569 P8 I0x0d
		

Mechaduino Firmware

The Mechaduino firmware found here should make your Mechaduinos respond to RepRapFirmware's G95 and G96 calls.

Getting Help

This month (July 2018) I will take my first ever holiday from the Hangprinter Project. Me and my wife will seek family roots in the northernmost parts of Norway. This means I won't check the forums as often as usual, if at all.

RepRapFirmware Related Questions

I'm sure the RepRapFirmware maintainer dc42, and the general community of Duet/RepRapFirmware users, will do their best to help if you ask good questions. Reading the Duet documentation and information in the pull request itself will help you ask good questions.

The dev branch that I'm making the pull request from is found here. Remember that no RepRapFirmware users have previous experience with the Hangprinter.

Hangprinter Related Questions

Both the forum thread and the Facebook group reach people who are knowledgeable about Hangprinter. They are eager to help and to see you succeed. If you haven't already, give them a chance and ask a question =)

- tobben

2018-07-09T12:00:00Z Torbjørn Ludvigsen The Hangprinter support in RepRapFirmware is looking for pre-alpha testers! You can be the first person to combine Hangprinter with Duet, RepRapFirmware, and 32-bit controllers. If you get it working, your Hangprinter will be the fastest one on earth. You will be on the bleeding edge, and help Hangprinter development. See the previous blog post and duet3d.com for more on how Duet and RepRapFirmware will make HP4 better than HP3.

Design Goals and Electronics

For Hangprinter v4, I'm changing out the design goals, and hence also the electronics and the firmware. TL;DR: I'm going for DuetWifi and RepRapFirmware.

To talk meaningfully about design goals, I feel like I must first give you some:

Hangprinter Design Goal History

The initial goal of the v1 design was simply to prove the Hangprinter concept. I was not convinced that it would work at all, so it didn't make sense to talk about design goals beyond proof-of-concept.

However, reading between the lines of the potential rewards that I listed in a forum thread at the time, one can get some hints about what I hoped for:

• The most compact, easily printed, easily installed and easily distributed RepRap out there
• Possibility to retract its strings and park close to the ceiling when not in use. Could make it popular where indoor area is scarce
• Extreme print heights (> 1 m)

The concept worked, and the v1 and v2 designs fulfilled the hopes in the above list (except the one about becoming popular where indoor area is scarce).

The above picture was taken at the recording of a campaign video. The subtitle of the campaign was (and still is) a design goal

• Print big at low cost

Many Reprappers embraced the Hangprinter concept, but failed to complete their first Hangprinter build. In a blog post in January 2017, I wrote in a blog post:

• "It's made to be useful, so it also needs to spread."

• Ease of build

In March 2017, Alexander Osika (above) suggested a dual-unit Hangprinter, with the motors in the ceiling. This would allow us to lay the spools out in a two-dimensional pattern, and could be made straightforward to put together.

I also knew that new challenges would face us once ease of assembly got figured out. The v1 and v2 machines had been hard to calibrate, and quite unreliable, so in April 2017 I stated some new design goals in a blog post:

• Closed-loop control
• Automatic calibration

Even before achieving those goals, we started getting way better prints out with the dual-unit than we ever got with the v1 and v2s. Here from December 2017:

By the end of 2017 I iterated on this blog that I wanted Hangprinter to be spread and be useful. The goal of usefulness motivated some compromising. Auto calibration and closed-loop control were made possible with Mechaduinos, who also made the build harder.

Below is an experimental single unit prototype using Mechaduinos. It was never made standard because it was very hard to assemble.

The Mechaduinos are also very expensive. Up until this point, I had stuck to cheap parts because both myself and most builders I've met wanted to keep investments low. Keeping parts cheap had helped the design spread, but using cheap components was not a goal in itself.

This might seem contradictory to the goal of low cost stated above, but cost must be compared to that of other large scale 3d-printers, ie thousands of dollars per print. Cost must also take raw materials and percentage of failed prints into account.

With (human assisted) auto calibration in place, the dual-unit design with Mechaduinos was ready to spread through assembly workshops. Below is a picture from the very first hangprinter assembly workshop in May 2018.

Version 4

The Mechaduinos with their powerful processors and "smartness" also gave a glimpse of a machine I'd really like to own and use. There is a new local design optimum down that road, one I hope we will call HP4 or HP5.

Version 4 will not seek to prove a minimal investment concept anymore. The new design goals on the block are

• A reliable workhorse
• that people will enjoy using
• and spreading
• for profit

Since Hangprinters will often run over night close to where people live and sleep, there's also a smaller and more specific new design goal:

• Silent operation

Towards The Universal Manufacturing Machine!

There's also a social goal in the Hangprinter Project. As I see it, robots are rising towards becoming the dominant power factor in society. I think it's important that the people owns the robots who fill their needs.

Giving away and selling robots is easy, but having it fill peoples needs is hard. I think the best strategy for getting us there in the long run will involve gearing Hangprinter (and indeed other designs) towards:

• Becoming a Universal Manufacturing Machine (UMM)

Needless to say, the software part of the Hangprinter Project will grow with time.

Experiments Underway And To Come

To create the version 4, we'll aim for:

• Better main board electronics and firmware.
• Belt drive: This will make axes smoother, which will improve the auto-calibration. The belt drive will also be faster to print, easier to build and more quiet in operation.
• Line flex compensation: This will improve accuracy and build volume much in the same ways as buildup compensation did.
• Ceiling Landing Bracket: Both the ability to home by clamping towards it, and the ability to stay up when unpowered will improve the user experience.

Getting on towards the UMM from there will involve:

• Tool changing: What E3D develops right now will be useful and relatively straightforward to implement on Hangprinter. Particularly a super fast coarse infill tool is important for making HP practical and useful.
• Computer vision: Both for auto-calibration, sanity checks, run time compensation, and dimensional guarantees.
• Load Cells Along Lines: This will make the auto-calibration and line flex compensation better, which gives better print quality.
• Multi-unit: Independent winch units communicating wirelessly.

Some of the listed experiments have already been started by myself and others. Today I want to dive into the first one:

HP4 Electronics and Firmware

I won't try to give rigorous reasoning, because the parameters are so many. Instead, I will give a vague list of priorities and share my limited knowledge and experiences.

Priorities. Ish.

1. Open Source Hardware.
2. Firmware we can incorporate into HP repo, preferably GPL.
3. More processing power (at least 4x Atmega2650).
4. At least 4 pairs of exposed, driver-less step/dir pins for connecting Mechaduinos.
5. Exposed 3V3 serial pins for connecting Mechaduinos.
6. A web interface.
7. Reasonable price.
8. 24V input.
9. No streaming of gcode over serial USB, because of stuttering.
10. Willingness to incorporate Hangprinter software changes upstream.
11. Enough processing power to do on-board auto-calibration and line flex compensation.
12. Likely to support tool changing.
13. Lots of motor outputs and GPIO for tool heads.
14. Be compatible with cheap 32-bit hardware (Due+RADDS).
15. Do computer vision processing on-board.

Candidates

RAMPS+Marlin+Octopi

Most HPs in operation have this solution. Builders add the optional Octopi for its web interface. Stuttering from serial gcode transmission has been annoying on some prints, but bearable on new Pi hardware. The top speed limitation caused by RAMPS (Atmega2650) being slow is also annoying, but has been bearable in the pre-SuperVolcano era, since melt rates have limited print speeds anyways.

BeagleBone Black Wifi+Replicape+Redeem

This is by far the solution with the most processing power. It might be the only commercially available 3d-printer solution that can realistically do onboard computer vision processing.

This solution doesn't have the four exposed step/dir pins we need to connect our Mechaduinos. There have been some signals from lead dev Elias Bakken that we might get our pins in future versions of his new board Revolve :)

Smoothieboard+Smoothieware

As far as I know, the Smoothieboard also lack the extension pins we need to hook in the Mechaduinos. If I'm wrong, or if you know how to get the servos in there in another way, go for it and show us how! I honestly have too little knowledge about this platform.

RADDS+Marlin

This was our first idea for HP4, and it is a strong candidate simply because it's the cheapest viable 32-bit option. It requires very little programming to HP3's firmware onto a RADDS board. However, Marlin devs are worried that merging Hangprinter support upstream will disturb their work flow. See pull request here.

DuetWifi+RepRapFirmware

This is the solution I'm currently developing for. It ticks all the boxes. The well written RepRapFirmware, the great support, and all the available extension pins are really killer features. See my RepRapFirmware fork here, and my first substantial pull request here.

RepRapFirmware, despite being most often used with DuetWifi, also has support for RADDS, so users who prefer the cheaper RADDS are not left in the dark here ;)

- tobben

2018-07-01T12:00:00Z Torbjørn Ludvigsen For Hangprinter v4, I'm changing out the design goals, and hence also the electronics and the firmware. TL;DR: I'm going for DuetWifi and RepRapFirmware.

Double Lines, Double Speed

I got the chance to test out E3D's coming Super Volcano hot end recently. The high melt rate let me try to print really fast for the very first time. At first, I just upped the speed, and it looked like this:

Encouraged by these initial results, I went on to try to to test printing with much stiffer strings, expecting better print quality. The first layers did look rather good. Warning: video is noisy.

However, the Hangprinter at E3D has very long lines, with anchors more than 4m from the printer's origin. The long stiff lines started acting like springs, and the ringing was very significant. The following octopus was printed at a mere ~30 mm/s:

Adding Mechanical Advantage to A, B, and C

I knew what had to be done, since I had experienced similar issues last summer when I tested the version 2 with extremely thin lines; I had to constrain xy-rotations by doubling up the A, B, and C-lines.

Lastly, a little video of the printer running with the doubled mechanical advantage.

With the added mechanical advantage, I got far less ringing. Prints done at 70 mm/s came out with much less ringing than the ~30 mm/s printed octupus depicted above, so the improvement was significant. Sadly, my camera broke, and I didn't bring my prints with me home from England, so I can't show you pictures yet.

If you're going to try the doubled abc-lines at home, use the doubled_abc dev branch over at Gitlab. And remember to configure your mechanical advantage and correct line lengths in Marlin's Configuration.h.

- tobben

2018-06-08T12:00:00Z Torbjørn Ludvigsen I got the chance to test out E3D's coming Super Volcano hot end recently. The high melt rate let me try to print really fast for the very first time. At first, I just upped the speed, and it looked like this:

HAWS Replicating and Anchor Template

In preparation of the Hangprinter Assembly Workshop (HAW), I tested out the Hangprinter Assembly Workshop System (HAWS) recently. I'm fascinated by self-replication in software as well as in hardware, so I made Ubuntu run HAWS as a virtual machine that copied itself onto a USB stick that could then be mounted. Sort of a parasitic strategy. I recorded the whole thing as documentation:

I also did another video where I create a new Hangprinter part in HAWS.

The part CADded in the above video has already proved to be handy during anchor assembly.

Now, there is a lot more than templates and OS work going on in the Hangpriter Project. Yesterday, I did my first successful test print with the Super Volcano hot end over at E3D's headquarters in Oxford:

The deposition rate of ~250g/h is very promising. I hope we'll be able to go even faster, as print times currently limits the practical usefulness of the Hangprinter.

For more live updates (and a link to a live stream directly from the ceiling of E3D HQ) do check out my Twitter.

- tobben

2018-05-15T12:00:00Z Torbjørn Ludvigsen In preparation of the Hangprinter Assembly Workshop (HAW), I tested out the Hangprinter Assembly Workshop System (HAWS) recently. I'm fascinated by self-replication in software as well as in hardware, so I made Ubuntu run HAWS as a virtual machine that copied itself onto a USB stick that could then be mounted. Sort of a parasitic strategy. I recorded the whole thing as documentation:

How to Build a Temporary Hangprinter Frame

I demoed Hangprinter v3 at the 3D Meetup Sweden recently. I could not mount it in the ceiling of the venue, so I had to build a temporary frame. Knowing how to whip up a temporary Hangprinter frame is useful, so I'm documenting it here.

Bill of materials:

• 7 pcs 45x45x3000 mm wooden beams
• 50 pcs ca 4x65mm wood screws
• 1 small (ca 200x200 mm) top plate sheet
• Your Hangprinter's D-anchor (ceiling plate) and 3 ABC-anchors sheets
• 1 print bed

• Hand saw
• Cordless drill
• A friend to help you out with the last step

Step 1: Make an equilateral triangle out of three beams

Step 2: Prepare your three standing beams

Step 3: Screw standing beams onto the top plate sheet

Step 4: Temporarily mount your standing triangle

Step 5: Mount your D-anchor

Step 5: Get the orientation right

Step 6: Secure and mark everything up

Now you're done, you just want to make sure it stays the way it is.

• Secure your triangle legs to your corner pockets with screws.
• Mark up the origin point on the bed surface.
• Mark the position of your print surface on the floor with tape or similar.
• Mark the position of your frame's corners on the floor with tape or similar.

Big thanks to my dad for coming up with this frame design while me and Fred were running around him like chickens in the middle of the night before Maker Faire Rome 2017.

- tobben

2018-04-19T12:00:00Z Torbjørn Ludvigsen I demoed Hangprinter v3 at the 3D Meetup Sweden recently. I could not mount it in the ceiling of the venue, so I had to build a temporary frame. Knowing how to whip up a temporary Hangprinter frame is useful, so I'm documenting it here.

Presenting HAW-Nemesis

Hangprinter Assembly Workshop Nemesis is an operating system that you put on a USB-drive (size 4GB or more). It boots directly from the USB-stick, and loads itself into RAM memory. The hard drive of your computer will not be touched.

It contains all the computer tools that I use when I use and develop Hangprinter, and Hangprinter related programs. It will be given to participants of the forthcoming series of Hangprinter Assembly Workshops. The following video shows everything working on a virtual machine (VirtualBox) with 3 GB of RAM:

Watch on Youtube instead if above video doesn't load for you: HAW Nemesis on Youtube.

How To Get It?

It's packaged as an iso-archive, available here. Extract the contents of the archive to a USB stick. I use Archive Manager for this job. Then execute boot/Porteus-installer-for-Linux.com (or boot/Porteus-installer-for-Windows.exe), and follow the instructions to make your USB stick bootable.

Pro tip: If you're comfortable with formatting your USB stick, format it to ext4 before extracting the iso. It will enable you to save your changes.

Now, reboot your computer and get into BIOS. Usually repeatedly pushing F2, F10, or ESC during reboot does that. Otherwise, a web search on "boot from USB your computer model here" is recommended.

More Help

The iso-image is build from the Porteus with Arch packages called Nemesis. Some recommended sources of further information are:

• porteus.org
• The guide I followed
• List of computer models verified to boot

HAW-Nemesis has two goals:

• Bring down the threshold for new Hangprinter users.
• Give Hangprinter developers a common computing environment.

A test of the fore-runner of HAW-Nemesis, called D3D-Porteus, is motivated and described in my Master's thesis. It also contains lots of advise for future development that are not yet implemented.

HAW-Nemesis will see continued development as I collect experience from my series of workshops.

Other News

The first of those workshops are already planned together with RichRap and E3D! Read more and buy tickets here: eventbrite.com.

I've opened two Hangprinter Merchandise web shops. One for Sweden (hope it works in all of Europe): spreadshirt.se, and one for the USA (hope it works internationally): spreadshirt.com.

- tobben

2018-03-20T12:00:00Z Torbjørn Ludvigsen Hangprinter Assembly Workshop Nemesis is an operating system that you put on a USB-drive (size 4GB or more). It boots directly from the USB-stick, and loads itself into RAM memory. The hard drive of your computer will not be touched.

A Little Work on Line Flex

Today's Hangprinter firmwares assumes no flex at all in the movement axes. This is obviously a very rough approximation. In reality, all Hangprinter axes act like springs. Accounting for this can win us several millimeters of accuracy near the limits of our reachable print volume.

Solutions

Some flex comes from line modulus, but adding infinitely stiff lines alone won't solve our problems because ceilings, floors, ceiling unit sheets and plastic parts also flex. Very stiff lines are also thick, building more on the spools and making the imperfection of our buildup compensation more severe.

Another brute force solution would be to closely monitor the mover and constantly compute and execute ad-hoc compensation. This could be made to work well, but it would add to hardware cost and complexity.

A third solution is to include flex in the firmware's internal model of the movement system. This keeps hardware simple. Configuration overhead must be minimized by using standardized parts and providing scripted and straight forward instructions.

It would be possible completely circumvent configuration overhead by collecting flex data with force sensors. This would require extra hardware, which in turn would have to be configured. It is in the spirit of the Hangprinter Project to make hardware additions beyond the bare bones setup optional, and solve as much as possible in software.

Use The Force

The scribbles below derive how to synchronize the four forces from the four motors, so that all lines can be tightened or slackened, without moving the mover. A force magnitude can be approximately mapped to a line shortening/elongation by using Hooke's law, where a guessed or measured Young's modulus gives the spring constant \(k\). Note that the spring "constant" will vary with line length in our case.

The no-flex line lengths that current firmwares calculate can be used to calculate a new line length that does (approximately) account for flex:

\begin{equation} l_{acc} = l - F/k(l), \end{equation}

where \(l_{acc}\) is the new line length that accounts for flex, \(l\) is the line length calculated and used by current Hangprinter firmwares, \(k(l)\) is the spring constant of the suspended line, and \(F\) is the desired force to be exerted by the line. The four different forces \(F\) are called \(A\), \(B\), \(C\), and \(D\) in the derivation/scribble notes below.

Lots of divisions. Probably not simple enough to be done on a Atmel2560. So... What to do?

As my professors always told me:

"Taylor expand, my good boy. Taylor expand for the sake of glory and honor! Taylor expand, and use only the first two terms, because everything ... Yes! EVERYTHING worth fighting for can be approximated to be perfectly linear! I tell you, boy, if you ever ever feel doubt in your heart, just Taylor expand, and your problems will all be cake."

Ok, they didn't quite say it like that, and maybe we should use three terms, but I'll save you the expansion for another post. If you're so excited right now that you want to Taylor expand yourself: do it around the origin, and remember that

$$ \begin{align} a_x &= \phantom{\text{ANCHOR_A_X}} - x,\\ a_y &= \text{ANCHOR_A_Y} - y,\\ a_z &= \text{ANCHOR_A_Z} - z, \end{align} $$

where ANCHOR_A_X is non-existent by convention, ANCHOR_A_Y is the y-coordinate of your A-anchor, ANCHOR_A_Z is the z-coordinate of our A-anchor, and \((x, y, z)\) is the position of your mover relative to the origin.

Also remember to handle the cases when denominators are zero in a graceful way. Fancy new 32-bit CPUs can probably compute the full expressions, but they can't handle division by zero.

Best regards,

- tobben

2018-02-21T12:00:00Z Torbjørn Ludvigsen Today's Hangprinter firmwares assumes no flex at all in the movement axes. This is obviously a very rough approximation. In reality, all Hangprinter axes act like springs. Accounting for this can win us several millimeters of accuracy near the limits of our reachable print volume.

Consequences of Miscalibrating Anchor Positions

I made a script recently, to get learn how a Hangprinter axis with bad anchor positions behaves. The script itself is here.

The Quick Take-Away:

Moving directly from/towards an anchor gives small errors, almost regardless of calibration errors.

The Details:

Four plots are shown below. Only the XY axes are shown, but the results are similar in three dimensions. Line length errors in different XY-positions are shown with color codes. They are normalized so that the error in the origin is 0 in all plots. In negative areas, the mis-calibrated axis will over-tighten. In positive areas, the mis-calibrated axis will let out too much line. Click the plots to get larger versions.

- tobben

2018-01-28T12:00:00Z Torbjørn Ludvigsen I made a script recently, to get learn how a Hangprinter axis with bad anchor positions behaves. The script itself is here.

New Extruder Holder Bracket

I've converted the extruder_holder bracket to be ziptie based like the rest of the mover:

It is a great deal sturdier than it's screw-clamping predecessor. I tested lots of little tweaks to find the stiffest solution around all axes.

The motor was possible to tilt downwards no matter how I changed the model it seemed. The winning tweak turned out to be adding a third ziptie first. Like this:

And to tighten the third ziptie with a wedge. Like this:

The end result is dead sturdy and looks like this:

All new files and are published to the working branch of the repo: Openscad_version_3.

- tobben

2018-01-18T12:00:00Z Torbjørn Ludvigsen I've converted the extruder_holder bracket to be ziptie based like the rest of the mover:

Ziptie Mover

I've implemented Tom's suggestion to use zipties on the mover corners.

Using zipties in stead of screws has some advantages.

• Works with beams of different widths (currently 12.5 to 17.5 mm).
• Does not rely on flexing fragile printed parts.
• Saves some weight.

I also find it easier to assemble since there are no fiddling with small screws and nuts.

For wooden movers, I've also thrown away the old beam_clamp. It's both more sturdy and lighter to just clamp the crossbeam with a little M3 screw and nut.

These two improvements combined save ca 60 g of weight compared to the previous mover.

I've also added a little nutlock to beam_slider, to make it easier to tighten/untighten with one hand.

More improvements inspired by what I learned in Hamburg is in the pipeline. Happy new year!

- tobben

2018-01-03T12:00:00Z Torbjørn Ludvigsen I've implemented Tom's suggestion to use zipties on the mover corners.