Hangprinter version 3

Ok.. Those are all good points. I will keep that in mind if I decide to build one. Thanks.

Some thoughts on moving anchors and frames:

Thinking of anchors that move in z-hight I do not see it as a frame. It's just three axis coming up vertically from the floor.

I guess if the anchors can move 70 cm to 1m in Z, it would be very useful for a lot of printable objects. Seeing how slow the hangprinter moves due to layer hight and flow rate of the extrusion, I dought there will be a lot of situations to build bigger objects. Print fails can occure more often in a long print eg. 1 week!, 2 weeks!? or 12 weeks???

In my oppinion it is very important for the concept of the machine that it doesn't need a frame to work and it can easily adapt to different rooms. I see the wooden frames more as another existing structure which can be used with the printer.

After working for some weeks under the sealing I guess it would have been better to use a small frame (maybe 180 cm high or lower) to install everything for the first time and get it running. If one is experienced with the hangprinter it wont be to much effort to install it in different environments.

Some thoughts on simulations:

As the hangprinter has the design principle to solve as much as possible in software (did I understand this right?), a simulation seems to be more and more important. One can prove this by the new auto-calibration feature using Mechaduinos and a simulation in Python to get the auto calibration work. simulations are a very good tool to develop a robot. openSCAD looks interesting but I think in the future it would be better if the simulation can be tangled with the control of the machine. It would be great if you can use the same platform to build a performing (printing) virtual model, get (real-time) sensor data (eg. cameras, cable tension meter, temperature) and control the actuators (eg. motors, heating, fans, maybe a moving anchor or a moving build platform). Auto calibration could be performed, too in the best case.

I guess ROS and Gazebo are a good choice for that. It is open source and there's a community all over the world. It fits to the design principles of the hangprinter in that case

Thinking of Chris problem with cables colliding with the printed object and Tobbens suggestion (raytracing) the ROS/Gazebo Sim could maybe solve that problem too.

In the existing Gazebo/ROS Simulations of cable driven parallel robots there is no model for flexible cables. It is solved with rigid joints and rigid connectors..... First there must be a model of flexible lines and tension - a formula. With this model one can start to build a 3D sim in ROS. To build such a model you will need a bright mind and mathematics. I read somewhere that someone is working on that for the hangprinter as a bachelor thesis. How does the line flex modelling develop? Sounds great! Such a model could be used as a basis for a ROS development. I am not a simulation designer, but I will try to get the simulation topic forward as a kind of organizer. Chris is building anchors later this year. It might be better to concentrate on simulation now from my side. Anyone else interested in collaborating on a simulation of the hangprinter in Gazebo/ROS?

Edited 4 time(s). Last edit at 07/04/2018 12:29PM by Dahah.

PS: Using a complex simulation - which can run on computers at home - would be an update - auto callibration of the hangprinter did it allready - of the RepRap technology (2008) from 1980s tech eg. home computers, cheap microcontrollers, stereolithography (1983), FDM (1988) and the broad use of the internet (1990s) to a more contemporary approach using complex software to solve problems in normal/ordinary/everyday life (2018). By the way: It is not just the 10th anniversary of RepRap in 2018 it is as well the 30th anniversary of Stratasys FDM patent.

Edited 4 time(s). Last edit at 07/04/2018 12:26PM by Dahah.

@Dahah
I agree on your point that we can see the wooden frame as just another existing structure.

I'm super happy that you and other builders are building experience and some HP expertise by getting your hands dirty. Having to climb up to the ceiling to do fixes and adjustments is indeed a potential Achilles' heel in the Hp3 design that is easily underestimated, particularly for first-timers.

I just want to stress one point that is easy to miss about installing alternative anchor points at higher z: When preparing higher-up anchor points, before we start the tall print(s) that might use them, we should do a full auto-calibration procedure for every set of anchor points that we might want to use later. This will allow auto-calibration to compensate correctly for inaccuracies in spool buildup compensation, and for any deviation from a perfectly placed origin, for every set of anchor points.

Simulation
A simulation, as complete as possible, would indeed be a great tool for HP development. I would love to steer my dev role in that direction, since it would fit my interests, formal training, and the future I envision for the project. Any help with other parts of the project (such as producing images and video of builds, writing documentation, programming firmware, hosting workshops, coordinating technical development, promoting and finding new builders/supporters), that could free up more of my time for working on simulation, is greatly appreciated. Help on the simulation itself is of course equally appreciated.

Linking in HAW#1-participant, Chris (we'll be up to 3 active Chris'es in this thread), who wants to work on a steady space model of the HP

Formula for flexible lines and tension
A first approximation for a line flex formula could be Hooke's law:

F = kx,

where F is force, x is line deflection (flex), and k should be measured directly, to make sure we match reality at least to some extent.
But we could start of with the crudest of the crude models by using:

Modulus
k could be approximately calculated from the expected modulus of dyneema line (115 GPa, source: [www.mse.mtu.edu]), but the lines we buy are not perfect.

fredrudolf has done a (rough) measurement of flex in 0.18 mm FireLine, which gave a modulus of 63 GPa.
This one measurement should ca halve the error of our model!

However, the approximation is still very crude since it doesn't take into account flex in other mechanical parts, and line flex that is stored by being rolled onto the spools (where friction helps keep the line stretched).
The 0.39 mm FireLine and the 0.5 mm FireLine might also behave differently than the 0.18 mm line, because of how they're produced.

Blindly scaling the 63 GPa result up for the standard 0.5 mm FireLine gives the following formula:

k(L) = E*A/L = (63*10^9)*(pi*(0.0005/2)^2)/L,

where E is modulus, A is cross-sectional area of the line, and L is the length of the suspended line at any given time.

It's a starting point.

---

torbjornludvigsen.com

Modulus

It is a starting point! And a quick one

Formula for flexible lines and tension

What sensors on the hangprinter could measure k or could measure data to calculate k? High-res cameras?
(Just quick thoughts: Line tension could be measured with a load cell - easy and cheap - and three v groove bearings, line length with a rotary encoder.)

Other flex than line flex.
We should try to get as low flex as possible in the mechanical parts except lines. Otherwise the model becomes to complex. I do not mind to use four heavy bolts and maybe bigger bearings to hold the spools. The same for the brackets and line rollers. It is better to have them a bit more sturdy than needed in my opinion. Of course costs and production time might raise a bit but its just some €s.

Edited 5 time(s). Last edit at 07/04/2018 08:04AM by Dahah.

Yup. The line flex is described in more detail here: [vitana.se]

Finding k
If we measure force and deflection on a hanging effector (mover), we would get a new k that is lower because it takes flex from the whole system into account.

If we have smooth transmission (like the belts I'm in favour of adding to the v4), and good torque control (I'm hoping Mechaduinos are good enough, otherwise oDrives should be), then HP can measure its own k values simply by tightening its lines, noting down forces and deflections, and doing the math in firmware.

Adding Sensors
Yes, load cells would be an interesting addition if it turns out we still need it after adding belts. See here for relevant experiments with force sensing resistors here: [vitana.se]

In the priority list for my own work, I've placed load cells a bit down (see here: [vitana.se]) because of limited time. Load cells coupled with normal open loop stepper drivers might enable a very cheap closed loop system, including my beloved torque mode, but excluding the possibility to recover after missed steps (unless we do Prusa style re-homing by crashing into a bracket in the ceiling). I'd gladly assist any one who wants to carry out experiments with load cells!

Rotary encoders along lines could be made to work, but it maybe wouldn't be as cheap, easy, and useful as one would imagine. For it to be useful, we would have to guarantee that lines never slip. Tiny flex anywhere in the system would also have to be monitored and compensated for, or we would get degraded precision (imagine the line being stretched when rolling in, and slack when rolling out). If we were to base motor control on encoders along the lines, then we would have to make the control loop sloppy because the motor is so loosely coupled to its lines. Keeping the encoder on the motor shaft gives us high speed, high precision, but lower accuracy. It might be possible to use encoders along lines to easily and cheaply increase accuracy without degrading speed and precision too much. I would be surprised and impressed if I saw it.

Sturdier hardware
Bolts are nice and sturdy, but they come with the requirement for a straight, vertical hole in the ceiling plate. It was the standard before, but it was a relief to get rid of the need for a drill press.

The 608 bearings are just inherited all the way back from the v1 days. I'm in favour of using bigger bearings, with a bigger printed core, but to keep the center wood screw, as a standard on the v4.

Check out a sturdier motor bracket design here: [gitlab.com] The previous one twisted too easily. Haven't had the time to test the new one.

Another low-hanging fruit I'm in favour of for the v4 is to simply increase Base_th to reduce flex in all ceiling unit parts. (PS! If you want this already, you can get it by changing the number in parameters.scad: [gitlab.com]
and doing a
make openscad_stl/lineroller_ABC_winch.stl openscad_stl/lineroller_D.stl openscad_stl/spool_core.stl
to recompile the relevant stls.)

---

torbjornludvigsen.com

Finding k
Seems easy! One just uses good and precise hardware and gets precise calculations.

Closed loop
I would prefer o-drives over mechaduinos. It opens up the possibilities to use any dc motor, so in the whole there could be more individual iterations of the hangprinter depending what kind of dc motor is available. One could go without belts or gears using a hoverboard motor and o-drives. And you can control it using step/dir - so no big changes in the hangprinter system.

Load cells
I see....

Bolts and screws
Maybe one could use 3 or 4 woodscrews to make the axis sturdy?

Edited 7 time(s). Last edit at 07/05/2018 06:47AM by Dahah.

rotary encoders

If I would have an exact k-value, would it be possible to calculate/simulate the values for the line being stretched when rolling in, and slack when rolling out?

How to measure the flexibility in the system (except lines)?
How big are the flex movements in the mechanical parts?

Yes, everything is possible.

To measure flexibility except lines
Push a mounted effector with a force (F0), and measure how much the complete system flexes (x0). Divide the force by number of lines working against your push (n). You get a spring constant k0 = F0/(n*x0). Then get a line of the same lengths as the ones between your spool and your effector. Pull one end of that line, with no parts mounted along it, with a force F1 = (1/n)*F0. Measure how much your line flexes (x1). You get a new spring constant k1 = F1/x1. Flexibility in the system, except lines, is then

k2 = k0 - k1.

Keep F0 close to what you would expect during a print. That is, quite low, which makes Hooke's law still close to reality.

The flex in your mechanical parts (x) depends on force. Your measurements already gave you

x(F1) = x0 - x1

For small forces, you can use Hooke's law

x(F) = F/k2,

to predict how much your mechanical parts will flex.

---

torbjornludvigsen.com

Cool, I understand it. Thank you!

In the existing Gazebo/ROS simulation there are no flexible lines. They use ridgid joints and cables. How to formulate not just the line flex in a Hookes law sense but to simulate as well the way the lines bend on the spools, line rollers and anchors? I need to understand more of ROS.

Tobben, do you have experience in ROS? Do you think you could hack the existing sim to the hangprinters needs? Of course in case you would have the time. How many hours would it take?

Edited 2 time(s). Last edit at 07/05/2018 06:46AM by Dahah.

Maybe it is enough to see it as a rigid joint and a rigid cable that expands/decreases=flexes in length?

ROS Additive Manufacturing (RAM)
The ROS Additive Manufacturing (RAM) project is a set of ROS packages that enables automatic generation of trajectories for additive manufacturing
[rosindustrial.org]

Thanks for the link, I'll get into it if I get the time. I don't think I can drive simulation development now, only support others who want to take it on.

How closely you should simulate line flex depends on the use case you're trying to fill.
As a first goal and use case, I think it's good to start with analyzing whether lines will touch objects while printing, since that's such a practical use case.
Even a crude simulation, with no line flex, will prevent big expensive print failures.

---

torbjornludvigsen.com

Yes, it is a good idea to solve the problems step by step instaed of designing the best case scenario.

Crashdummies wanted for RepRapFirmware's Hangprinter compatibility development: [vitana.se]

---

torbjornludvigsen.com

So silent out here...... In my hometown it is very hot these days........

I made a concept for a constant-k-spool. I attached an image....


I found the idea in the fb group. It was said it comes from historical weaving techniques.
By the way: The jaquardt loom was the first machine using binary code on a changable medium -> punch cards! It produces programmed digital imagery without electronics. Back to the hangprinter........

My idea is to place the 3 spools in a vertical stack to save space on the top plate. As the diameter of the (build up) spool changes as more line is rolled on it (line build up), I use a spring to compensate the difference to the v-groove spools. The v-groove spools clamp the string and guarantees a constant value to calculate constant-k! This could be used as well to get better results in measuring line tension (load cell).

I hope the drawing is understandable?

What do you think? Could this concept work?

Edited 2 time(s). Last edit at 07/31/2018 09:23AM by Dahah.

The concept seems to be very interesting and I don't see why it wouldn't work. The only thing I'm a bit concerned is if the stepper motors can handle mass of the spools. Do you have an idea how much weight it would be in total?

No, I do not know the weight. The printed parts and bearings should be quite light weight. But I do not know if the forces/weights on the spools increase if you pull with three spools (and the additional spool bearings and springs) and not just with one spool. As it pulls the same end-effector (mover) I guess it is not too much for the nema17 stepper motors. But I do not know it by calculation..........Otherwise one could use nema23.

Do the forces on the motor increase with the constant-k spool compared to the single spool?

PS: Is constant-k really the right name?

I'm not sure if I understand your sketch correctly, but I'll have a go. Please excuse if I've misunderstood the concept.

Does line enter the E-spool, and go via G-idler onto D-spool? If yes, why not skip G and D altogether?

I will call E+G+D the "effective spool". If all lines passes over this/these spool(s) without slipping, then firmware can assume a constant steps/mm value (effective radius is then constant).

I will call C the collector spool and A+B the compensator idler.
The effective spool and the collector spool rotates together like one rigid body.
Line wound in by the effective spool is collected and stored around the collector spool.
The compensator idler can be pulled closer to C.
This releases line behind the effective spool, which compensates for the extra line that enters the collector spool compared to what enters the effective spool, due to line buildup on the collector spool.

Is the purpose of the v-groove to "bite" the line with lots of friction? We do need to create large friction between the line and the effective spool. However, we need the grooves to be flat in the bottom in order to get a constant steps/mm. The pointy v-groove will deform the line differently depending on line tightness and thickness, and we will get a varying effective radius of the effective spool.

The springs must never pull hard enough to allow the line to slip around the effective spool, even if the line entering the effective spool is completely loose.
Line tightness will vary rapidly between zero and tens of newtons.
So either, the spring force must always be equal to line tightness (would require added mechanism), and/or the line must be pinched onto the effective spool, towards which it must feel lots of friction.

I see only one line drawn in around A. You can wind line several turns around A+C to suspend more line between them, and hence have more line available to compensate with.

I don't think a lack of motor torque will be a problem, but the no-slip requirement might be hard to enforce with the very unpredictable tightness that we have in Hangprinter lines.

The letter k in this kind of system is often used for the constant value of the spring stiffness in Hooke's law. I suspect you mean "constant steps per millimeter", "constant effective radius", or "a linear relationship between motor position and effector position", rather than "constant spring stiffness".

---

torbjornludvigsen.com

You did understand it right. I made some changes in the drawing according to your suggestions.




Lets call it "constant-effective-radius-spool".

Biggest problem I see is the variable spring force of the compensation idler. What kind of mechanism could solve this problem? Is there a way to do it without electronics?
If we would have a simulation we could predict the force on the strings and react with electronic actuators. To control this we would need a feedback loop through a line tension sensor.

Just a note:

The second effective spool (E) and the idler (G) in the first drawing where ment to clamp the string between those two. If you could measure the force of the string between (E) and the Mover and the force between (G) and (D) while clamping it in one could manually adjust the line tension.

Could maybe work without (G) and (D), too?
Are there too many sensors?

What Do you think of the concept?

Quote

Biggest problem I see is the variable spring force of the compensation idler. What kind of mechanism could solve this problem? Is there a way to do it without electronics?

How about gravity? Just use a weight to tighten the string. It's called hang-printer for a reason

Like this?

Edited 2 time(s). Last edit at 08/04/2018 04:40PM by Dahah.

Of course the mechanism should be the other way around -hanging from the sealing. Then the weight would pull in the opposite direction.

Edited 1 time(s). Last edit at 08/04/2018 04:25PM by Dahah.

Interesting. Can you elaborate on how E and G in the first drawing would clamp the line?

There are interesting suggestions about how to predict, measure, control, and/or enforce line tension. Though, I don't think it would be good enough to completely avoid slipping on the effective spool.

The forces in the strings are not really predictable. The nozzle meets stray plastic sticking up of every layer during print. Preferably, it should even recover after somebody tripped in the lines.

The system must handle the situation where the line is completely slack. Both the spring and the weight idler (used alone) would cause slipping. Measuring tensions could provide us a slip warning, but not a slip solution. Slack line can run across a load cell undetected, and the motors already control line length (they can't easily be made to also control line tension at the same time I think).

Maybe the second sketch could be made to work if the effective spool had a sand paper surface, and/or two rubber wheels to pinch the line onto the spool? We're essentially trying to make the dyneema behave line a roller chain. With a long section of contact between line and effective spool, it might be possible to get large enough friction.

I love to see you're working on this!

---

torbjornludvigsen.com

"Maybe the second sketch could be made to work if the effective spool had a sand paper surface, and/or two rubber wheels to pinch the line onto the spool? We're essentially trying to make the dyneema behave line a roller chain. With a long section of contact between line and effective spool, it might be possible to get large enough friction."

Edited 2 time(s). Last edit at 08/05/2018 04:20PM by Dahah.

"With a long section of contact between line and effective spool, it might be possible to get large enough friction."
"Can you elaborate on how E and G in the first drawing would clamp the line?"

To multiply the contact area of the line and the spool I used the second effective spool and the idler in the first drawing. I hoped that if there is always friction on the line between both effective spools it could handle variable weights on the mover side as well as the variable weight on the collecting spool side. So the line should never loose friction between E, G and D, because of the two clamping/biting/rubber wheel mechanisms - I do not know if it works! In historical loom designs there are often 3 spools in equal size and I thought keeping a constant friction between two might be a function of these designs. I am just guessing...


"We're essentially trying to make the dyneema behave line a roller chain"

What if we would use a polygonal shape for the effective spool? Maybe with a movable rubber wheel The edges could divide the string in something like chain links. Do they??? -> complicated solution....

Sand paper or more predictable micro-surface-geometries seem a good solution. But the rubber wheels seem good, too. I thought of moving clamps in a non-electronic mechanism activated by the turning spool. I will try to make a drawing in the next days. I can not imagine it and I forgot where I saw something like this......Textile machines for shure. How do mechanical knitting machines catch the threads/strings?
Could a sticky surface generate enough friction? Very soft silicone for example? If you mold it you can get high resolutions of small geometries. Silicone is maybe too unpredictable in its flex......but maybe still computable?

Edited 11 time(s). Last edit at 08/07/2018 11:16AM by Dahah.

"The motors already control line length (they can't easily be made to also control line tension at the same time I think)."

In another cable driven robot (8 cables) the motors control line tension. Position, speed and velocity are controlled by calculation. The system senses the line tension of each line at the end effector. The motors are encoded to read out line length as a feedback loop. Each 5ms the system checks if the calculated position from the weight sensors (weight distribution) fits the actual position calculated by line length. If it does'nt fit the system corrects.

So one needs a model that calculates the relation between weight distribution and position and line length.

You will need a fixed home position then where the robot starts for the next time after beeing shut down.

Edited 4 time(s). Last edit at 08/07/2018 08:05PM by Dahah.