Quote
atmark
I'm currently designing a bracket for the HP4 bldc servo motor and the spool, and I wanted to share my tests so far.
The bracket is meant for the ODrive D5065 motor. My goal is to design a single motion unit, that includes the motor, a belt tensioner and the spool system in one rigid frame, which I probably am going to lasercut out of sheet metal. For now, I'm still thinking about the spool system. If you look few posts back in this thread, there was a discussion about the constant radius of the spool and how to compensate the line build up. An idea I had, was to route the line in a small groove in the middle of the GT2 spool, in the way that the belt is pressing it against the spool as you can see in the last pic.

I just tried to block the spool from rotating and pulled the line as hard as I could and it didn't move at all :D
It's still too early to say this concept works, but it is a promising start. It might be, that constant line movement is going to bite into the belt and it fails that way. You'll never know. What I'll do next is rerouting the end of the line onto a second spool, which I most likely will attach onto the same spool axle. And that spool will rotate independently from the first one. I was also thinking to spring load it, so that the excess line is always spooled up as the line moves.

Quote
tobben
Cool!

Independent spool units are nice.
If you can place them at the anchors (instead of having all several spools at one anchor), you will get less line flex, since there will be less suspended line in the air.

Good idea to pinch the line under the belt.
That might actually work very well =D
You could pinch it for several rounds (along a helix groove), or just increase the spool radius, if one round of pinched line isn't enough.

It might be a challenge assure zero slippage over time, since both line and belt will change properties as they get old/worn down.
Some data on that would be super interesting, like accelerating a 5kg weight quickly up and down 1 m 10000 times or something.
Using high accelerations would be interesting because the belt will flex/contract a bit when tension changes, and I don't know how it will affect the line.
Hopefully very little.

Anyways, that might be a very nice upgrade of the spool system :)

Quote
atmark
Thanks!

I just put a heavy weight on the line and looked first if the line holds, and after I couldn't see any slipping, I bounced the whole system until the line snapped Video: testing slipping
No slipping what so ever :D

I believe the line should be able to handle 40 kg of drag, so friction-wise I can't see any issues. Obviously the long term failure rate is a question mark, but I think it might work quite well because the line isn't cutting radially into the belt. The only force is applied axially and the belt is pressed by the line by only 0,25 mm

Your idea of hooking some weight on the line and do some repetitive acceleration testing sounds very good! I'll try to set up the electronics next week. What values would you suggest for weight, speed and acceleration?
Here are also some close ups of the GT2 spool and the belt directly after the test. For the spool I used Octofiber PETG-CF.

Quote
tobben
Woah, that's even more friction than I imagined. Impressive!

CF enforced plastics have a quite rough surface.
Where did the line snap?
Was it the CF that wore down the line?

Since I would be aiming for HP usage, I'd test numbers relevant to the application first.
I'd use ca 50% more weight, speed and acceleration than my HP4 prototype is experiencing.
So ca 5 kg of weight, accelerate 15 m/s² , up to 1 m/s. Use a distance of 1 m up and down, say 10k times.
That's a 3h test. You could go crazy and just let it run all night if you're feeling confident ;)

It would also be interesting to know if the mechanism works with pure PLA.
A spool out of PLA printed hot (say 240 C) would give much less friction than the PLA-CF in your prototype, I guess.
It would be interesting to know if it would still be enough, or if the CF is required.

Images like the one you showed would be a very interesting part of the result.
In particular, if the line does slip, I'm interested in how damaged the belt gets.
Also interesting to know if a slipping line cuts into the spool.

The mechanism is interesting in it's own right, so if the HP4 application proves to be well within limits of the mechanism, I would have done additional tests.
Like, measuring a slowly applied force up until the line breaks or starts slipping, or until the plastic spool breaks.
(Film a weight that is hooked onto a one end of a line, and pulled. Could capture both force and amount of slip/flex in one shot.)
Abruptly applied force is also interesting (requires a high-speed camera, or a weight that can store a max value).

Quote
atmark
Yeah, I was quite amazed too to be honest.

The line snapped 5 mm before the knot I made to hold the weight. So the CF spool didn't have any effect on the snapping. I'm aware of the abrasive nature of CF, so it's not said that it could not happen, but in this case it didn't. I can print a new spool out of PLA, no problem. It will be interesting to test it.

Let's see how I can setup a test rig. The motion repetition won't be a big issue once I get to setup the ODrive board and Duet. Is the firmware easy to install? Then, I assume a simple gcode does the magic?

Btw, I wrote you yesterday a mail, but it's still in my to be sent folder (I forgot that the schools network is down for maintanance for couple of days) anyway, I wrote that I ordered braided PE fishing line that is two-colored (yellow/black), so it has a repetitive weave pattern, which could be used for line length readout with a IR sensor, as black plastic does not reflect IR light very well. That's why the material of black plastic can't be identified in automated recycling. Different plastics reflect IR light differently.

So, additionally to the mechanics I was thinking about position feedback via sensor readout. Whats your opinion on that? There was also some discussion about measuring the line tension. Could that be useful to integrate in the motion system? At school we have a quite big range of sensors and other electronic equipment for prototyping. You can check technIcal details at Seeedstudio Grove
You can hook these sensors very easy to arduino, rasbi, etc.

Quote
tobben
Yes, the firmware should be straight forward to install. Just use the Duet2CombinedFirmware.bin you find in the repo (https://gitlab.com/tobben/hangprinter/tree/version_4_dev/firmware/RepRapFirmware), and follow standard Duet installation procedure. Gcode should to the magic, yes :) Be aware that your ODrive configuration will affect the movements. Max acceleration, max speed, step size etc needs to be configured correctly in the ODrive firmware. There's an example that matches my specific motors here: [gitlab.com] Follow the official ODrive documentation to find numbers that match your motors.

If the fishing line has any flex at all, this will affect the readings. So if the line (and hence the pattern) is stretched out, you might wind in 10.1 mm when you thought you did only 10.0.
On the other hand, since you're detecting the pattern, you'll know when you have unwound the same segment of fishing line, regardless of how stretched it was when wound and unwound.
This makes the system immune to a family of errors where flex is "stored" on the spool when wound in under heavy load.

The line will always be twisted though. How would the system cope with that?
And how would it behave if the line got very slack? Could we route the line through a very thin transparent tube, to keep it from kinking under the sensor?
For such a sensor to be useful, it would need to be very fool proof since so many weird things can happen during a print.