Hangprinter version 2

I also noticed that you swapped s and f when you punched in the numbers (makes no difference for vid, just teasing )

The correct s and f values would not produce NaN, but swapping highlighted a real bug. Published this fix: [github.com]

The v3 doesn't include an extruder like the v2 did since there are no space restrictions. So people can use their favourite extruder or mount clay tool heads if they want =) The mover on the picture has a Bondtech BMG extruder mounted. Works very well.

Getting people through manual calibration feels a bit like saving sinking user enthusiasms onto dry land. Thanks for helping out.

---

torbjornludvigsen.com

HA HA HA, I did and didn't even know it! Thanks for the fix.

I would love to try out a bondtech, they are a little price for me at the moment. Maybe someday I will spring for one.

Anything I can do to help the project, I will.

Well here is what a hang printer looks like after it snaps a fishing line and falls 8 feet on to a concrete floor. Back to square one.





Edited 1 time(s). Last edit at 09/20/2017 01:06PM by brotherchris.

Oh my! I can't see your pics, but that sounds terrible.

Did the lamp hook chew up the fishing line?
Why didn't the two other lines (who didn't snap) prevent disaster?

This never happened to me, but I've heard about it happening to others, and switched to bearings everywhere on v3...

---

torbjornludvigsen.com

It snapped it in half pretty much. I added some line to make the D axis longer. It looks like one of the knots failed. Once the first one failed the rest followed. Maybe some pullies wouldn't be a bad idea.

Oh, the knots. I always often get them on the D-axis too, when moving between different locations with different ceiling heights. FireLine is so hard to knit. Super glue helps.

---

torbjornludvigsen.com

In regards to knots: may I suggest borrowing the most important knot in climbing, which is the double figure eight knot?

It has these benefits:

Easy to tie even with stiff stuff
Maintains over 80% of strength of a straight line without knots
Gets tighter the more you put strain in it (if you keep falling, you'll have a devil if a time untying yourself)
Easy to tie two lines

What about using power line communication?

[en.wikipedia.org]

Then you could just have each stepper module plug up to the mains to get power and instructions. No messy wires, easy to setup. Just a thought.

Quote
Linkreincarnate
What about using power line communication?

[en.wikipedia.org]

Then you could just have each stepper module plug up to the mains to get power and instructions. No messy wires, easy to setup. Just a thought.

While technically possible, and it would reduce reciprocating mass by quite a bit, unless you had all stepper motors physically at the same socket, then you'd still need a stepper controller and associated regulated power supply for each one, along with a microcontroller: this would greatly increase the price as the big tradeoff, while also increasing complexity and things possible to go wrong. You still need power/control to go to the hotend and extruder on the platform, no matter what.

For the sake of argument: how much faster would the platform with as much moved off of it be able to print without giving up accuracy? Even with an overconstrained system, it's still strings with a non-zero amount of stretch, and catenary tendencies. With a fine enough resolution, a lot of that can be dealt with by software to achieve a desired accuracy/repeatability, but it's also quite likely that to get that accuracy with stepper motors you give up too much torque for what's left, so there's a balance there somewhere, somehow.

I usually go for some variant of uni knot. This one looks good: [www.youtube.com]


PLC might be a good idea for a multi unit design (motors at all anchors), but only if it's easier to set up than bluetooth or wifi communication. I think price and ease of setup would be the most important factors, since speed and reliability requirements would be quite low. We might get away with transfering the full gcode (or even a per-anchor gcode) only once, and synchronize execution with broadcasted ticks.

---

torbjornludvigsen.com

Thanks for the suggestion, I tired the double figure 8 and it seems to be working well.

Torb,

What software do you use to stream gcode to your printer? I am trying to use pronterface over Bluetooth. It keeps pausing the print.

Thanks,
Chris

I’m glad to hear that!

Now, what other things that are taken for granted in other fields can be found useful for FDMs?

I'm using Pronterface, and sometimes Octoprint (Octopi), when I run via wifi. BT+Pronterface is better when I need responsiveness, wifi is better for long prints (where I might want to use my computer for other things during print).

Does the printer pause and then resume, or just pause? My Bluetooth connection pauses when my laptop runs out of available RAM, and resumes when RAM is available again. Could that be what's happening to you as well?

@JonathanThompson
Many, many things

---

torbjornludvigsen.com

It just pauses. Then I have to hit pause, then resume and sometimes it will take off again. I think I will try a octopi setup next.

Ow, that's not good.

I've only used Octopi with the v3, since it has a stationary RAMPS to connect with. But I know people have set up Pi Zeros with wifi and Octoprint on them, and mounted that on single units too. =)

---

torbjornludvigsen.com

It might be the PC I have it hooked to, its not a very good one. I might just have to cable it up.

Also, it seems the higher the printer goes that loser the A B and C lines become. This might be from some slight miss calibration on my part. Do you run into line length changes on really large prints?

Yup, ABC my lines also get slack at high Zs if I have errors in my anchor location measurements/calculations. Errors in the spool buildup compensation parameters are smaller (< 1cm at Z=1m), but sometimes noticable.

I don't know why, but I experience slack lines more often than I experience over-tight lines.

I mostly experience calibration errors on weekend, one-off prints at venues and such. At such events, I send a G6 A-0.2 B-0.2 C-0.2 once every ca 15 min (during print, no problem). At more permanent locations, I do manual measurements along each cartesian axis, very tediously.

Because these measurements are so hard to get right, I believe that Hangprinters cannot get wide spread before the auto anchor locating algorithm works out of the box. Working on it

---

torbjornludvigsen.com

I am going to try again after I check all my measurements. Here is my benchy, its about 300mm long. It started out very well. I think the pausing cause the layer shift you see. By the top of the print it was pretty much just oozing plastic with no direction because the lines were so lose. Still a fun experiment. This was at 0.8 layer height.











Benchy Time Lapse

The first few centimeters have quite usable print quality, and it did finish =)

If layer shifts are paralell with the direction towards an anchor then you probably have missed steps. The shift is large enough to partly explain you increasingly slack lines. Placing the printer in another position than it's internal one (the one it echoes when you send M114) has the same effect as a mis-calibration of anchor locations.

Edited 2 time(s). Last edit at 09/29/2017 11:01AM by tobben.

---

torbjornludvigsen.com

I am continuing with testing. It seems like the printer doesn't advance up ward at the proper rate. After 100mm or so the printer will be resting on the model. Should I increase the D axis measurement number?

Did the Benchy come out the expected height, or is it too low?

If it is the expected height, then the ABC-motors are letting out too much line, letting your printer move towards the center like a pendulum, when not printing near origo. A wrong d measurment number could be the cause of this, but you would have to be off by several tens of centimeters to have visible effects.

If your Benchy is too low, did you slice it with z-lift? I've had problems in the past with loosing steps on the D-motor when trying to do quick z-lifts.
This can be fixed by lowering max D acceleration and feedrate in Configuration.h
[github.com]
[github.com]
You can also use
M201 D100 ; Set max D acceleration to 100 mm/s^2
M203 D8 ; Set max D feedrate to 8 mm/s

If your calibration is the issue, then you should still be able to do correct movements vertically above origo. Try if pure vertical movements work like expected,something like this procedure:

• Place printer in origo (slack ABC-lines doesn't matter)
• Measure distance between print bed and a point on the printer (d0)
• G92 X0 Y0 Z0 ; Make sure printer's internal position is (0, 0, 0)
• G1 Z250 F200 ; This movement is slow to rule out problems with lost steps
• Measure distance between print bed and a point on the printer (d1)
• See if you get the right difference between the two measurements (d1 - d0 = 250 mm, or at least between 248 and 252 mm ?)

If the above difference comes out out wrong, then either steps per spool radian (or, steps/mm if line buildup compensation is not activated), or the line buildup parameters are wrong. For errors smaller than 5 mm, I expect that changing DEFAULT_SPOOL_BUILDUP_FACTOR will a good first fix.

Since the default acceleration and max speed values are a bit high, my first guess is that lost D-steps is the main source of the problem. Lowered them from 2000 mm/s^2 to 200 mm/s^2 and 20 mm/s to 15 mm/s.

Thanks for keeping up! I really want to see your printer work properly

Edited 1 time(s). Last edit at 10/02/2017 07:56AM by tobben.

---

torbjornludvigsen.com

The benchy is the right height.

With that said, I printed the benchy with a different ramps board and a4988 drivers. Because of an "accident" I shorted out the MEGA/RAMPS and all the motor drivers. Now I am running with some drv8825 motor drivers.

There is the new problem, these are set for 1/32 micro stepping. I could just double the steps in the firmware, but for the hang printer I am not sure what I would edit. The line compensation is confusing me a little.

I could also just change up the jumper settings on the RAMPS.

I did the D measurements like you stated above and they are right about half of what they should be, so I found my first issue.

#define SPOOL_RADIUS2 1089.0

// Motor gear teeth: 9
// Sandwich gear teeth: 43
// Steps per motor revolution: 1600 (that is, 1/8 stepping a 200 step per revolution motor)
// ==> Steps per spool radian = 1600/(2*pi*9/43) = 1216.651
// D-motor has 1 tooth instead of 9 teeth. 1216.651*9 = 10949.860
//const float STEPS_PER_SPOOL_RADIAN[DIRS] = {1216.651,1216.651,1216.651,10949.860};
// Double all of those if 1/16 stepping is used
const float STEPS_PER_SPOOL_RADIAN[DIRS] = {2433.302,2433.302,2433.302,21899.720};

// If EXPERIMENTAL_LINE_BUILDUP_COMPENSATION_FEATURE is enabled
// then constant ABCD values are calculated on the fly and used only used to calculate accelerations
#if defined(EXPERIMENTAL_LINE_BUILDUP_COMPENSATION_FEATURE)
#define DEFAULT_AXIS_STEPS_PER_UNIT {0, 0, 0, 0, 134.0}
#else
#define DEFAULT_AXIS_STEPS_PER_UNIT {36.87, 36.87, 36.87, 663.7, 134.0} // steps per unit with no line on spools for Hangprinter
#endif

Yup, that's the right lines

If you haven't commented out line 435 in Configuration.h, then EXPERIMENTAL_LINE_BUILDUP_COMPENSATION_FEATURE is defined, and STEPS_PER_SPOOL_RADIAN is used, not DEFAULT_AXIS_STEPS_PER_UNIT.

For 1/32 stepping, you could use {4866.6, 4866.6, 4866.6, 43799.4} steps per spool radian, but I recommend changing jumper settings instead. Other sources of error makes the difference between 1/32-stepping and 1/16- or 1/8-stepping unnoticeable anyway. It's nice to save in on those processor cycles.

And I'm back to suspecting skipped steps to have caused the slacker-than-usual lines during the Benchy print... Assembling a force sensing resistor driven feedback loop for the steppers of v3.3 right now. Hoping to run the first real print tests this week.

---

torbjornludvigsen.com

Thanks, I am going to get some a4988's and switch back.

Very interested to see how your test goes. Good luck.

Have you ever played around with 3D printed fishing line eyelets? I am working on some now that use 3mm craft eyelets. Going to try and use them tomorrow.

I haven't myself, but Fargo 3d has made some PTFE tube based eyelets that look quite good: [www.instagram.com]

---

torbjornludvigsen.com

Those look pretty sweet. I have just made some printed parts and set an eyelet in the top portion. Seems to be working for the D axis very well.

Nice!

---

torbjornludvigsen.com

The testing continues, I am running on a4988 drivers again. This model was to be 575mm tall and 100mm round. This was printed in vase mode at .75 layer height. It turned out to be 515mm high, and oval shaped. The lines did slack and I could manage it if I did G6 A-0.2B-0.2C-0.2 pretty much every 10 minutes. As the lines slack the model would get smaller, then I could bring it back out with the G6 commands. It seems like the B line would get slacked faster than the other 2. The opposite side from B would get smaller faster. I don't think it is skipped steps, it really seems like the line compensation isn't moving at the correct rate. Trying to figure at how I can make 100% sure my calibrate is correct. My goal now is to get a print I don't have to babysit. Accuracy is secondary at this point. I did roughly 160 G6 A-0.2B-0.2C-0.2 commands during the print. Seems like the the lines slacked faster the further it went up.







TIme lapse print

Edited 1 time(s). Last edit at 10/10/2017 07:59PM by brotherchris.