A redesign of the GUS Arm for easy external stringing

[jwm]

Cool, yeah, probably not worth it unless the count can be radically reduced, pulleys are pretty cheap. I now have 2 working arms and am waiting on more filament for the third.

https://youtu.be/7Edp8caTa-g so far the main issue has been the fishing line ”walking” off the pulleys as it moves up and down the sool. Extra tightening seems to help, but maybe there is a winding trick to avoid it. I am using printed spools which may be an issue.

Other notes:

There is a mystery hole next to the stepper on the back that doesn't correspond to a pully, does something go there?

What limit switches are you using, the limit switch spot is like half the size of the ”standard” sized limit switches used in most other reprap.

Apparently guitar tuners are handed, and only one side fits, makes sense in retrospect. I suppose a fully mirrored set of arms can use up the rest of my tuners,

[Jfriesen]

The arm looks great! When you say "Fishing line" in your video I hope you mean braided line and not a nylon monofilament? Nylon is going to be far too stretchy and have too much creep to work at all I think so it must be braided, can't tell in the video.

The limit switches I use are these guys:

https://www.amazon.com/gp/product/B00LV ... UTF8&psc=1

This is a common limit switch size so you can probably find them elsewhere also. They are actually the same as the limit switches used in most mouses! I repaired one of my logitechs where the click was going out with a spare one haha.

I definitely wrestled with the "walking off the pulley" issue. There are two things that help here:

1) make sure you have a string with diameter 1mm or less (the reason tightening helps is it reduces string diameter) I tested about 7 different types of braided line and found this one worked best for my machine:
https://www.amazon.com/gp/product/B011D ... UTF8&psc=1

2) make sure that you have a good balance of distance between each of end of the string coming off the pulley. I had to adjust the slack on the fixed end vs. the end I reeled in with the tuner to make sure I didn't walk too high up or too low on the pulley.

One design element that also helps not to walk off the pulley is increasing the distance between the pulley that feeds the spool and the spool itself. This requires arm redesign and reprinting though and I got too lazy to figure it out. I get the full range of motion out of the arm on my properly adjusted arms though but it would be nice if you had more room for error.

The mystery hole you mention is a screw hole for my anchor of the end of the string not attached to the tuner if that makes sense. There are other places you could affix that end of the string to but I liked having that one there for neatness.

Printed spools should probably work but may introduce some error. You can get a set of 3 well machined aluminum pulleys at the bottom of this page for $20 if you find the printed ones don't cut it:
http://www.tridprinting.com/Mechanical-Parts/

Excited for your build keep up the good work! What board/firmware do you plan to use?

[jwm]

It is beginning to take form!

IMG_20170112_033137.jpg (3.71 MiB) Viewed 103307 times

IMG_20170112_033149.jpg (3.44 MiB) Viewed 103307 times

[jwm]

I ordered some of the machined spools and they work much, much better, I also switched to 100lb spectra from 80lb which is a bit thicker and it seems to help with the string overlapping itself but making the 'walking' up and down the spool worse but it seems to be a good compromise.

I think the main issue with the printed pullys was the rather large layer height I used (0.3mm) making 'grooves' that pushed the line to the point of overlapping itself rather than spiraling nicely, I think they should work printed at a much higher resolution or milled to round afterwords but my metal ones arrived before i had a chance to try.

An issue is that at full extension the line will separate from the pully closest to the motor which loosens the string enough for it to come loose. I can solve it by limiting travel with the limit switch, but i feel a slightly different pully placement a tad further from the motor would do it as well. Due to using what i already had on hand all three arms actually use different pullys, one uses 604UU, one uses 624VV and the other is 603VV. all work okay, the worst are the 624VV due to the thickness making the stacked pullys really stick out. However, the thickness also makes them more immune to the string walking up and down the spool as it can get much further before it comes loose. Perhaps a hybrid approach is best? 624VV for the one immediately next to the motor and its counterpoint, 604UU for the rest? I may experiment with that.

I am not sure what electronics I will use yet, probably whatever dev boards i have on hand I can wire some stepper drivers to at first. I may use one of my arm boards like the msp432. Exploring the motion equations and movement algorithms is as interesting to me as the build so I wasn't planning on using stock firmware anyway for a bit.

Attached is the STL file for the base pieces I used that let you use misumi 1515 or openbeam as the base, it is quite stable with the single beams. I did it this way as i may want to swap the size out as i experiment with the hub design and already have lots of random parts that bolt nicely to 1515 and I can throw a spare prusa pcb heated bed on there as a temporary build surface easily.

[Jfriesen]

This is great work! I'm excited to see you tried some different types of pulleys.

I agree a printed spool could work if implemented correctly (I did try turning one down but didn't have the best setup) but for $20 it was more trouble for me than it was worth.

In response to your mention of a hybrid approach I find it interesting, just keep in mind that if the pulleys have different inner diameters you will introduce non-linearities into the arm movement which will be difficult to compensate for. I only ever tried some 623vv pulleys that were very low in quality and introduced non-trivial amounts of friction/wobble. Upon replacing these with a bit more expensive pulleys I found on amazon I noticed a dramatic reduction in the force required to back-drive the arm indicating a sharp reduction in friction. This friction reduction was definitely reflected in the quality of my prints. I think I mentioned previously in this thread:

viewtopic.php?f=6&t=224&start=50#p9211

I did notice the phenomenon with string diameter you mentioned.

Doing the forward and inverse kinematics was quite fun! Glad to hear you are going to work it out yourself, it is definitely part of the fun with this build if you have the math/programming background for it.

I like your approach for a modular base, it will definitely be handy for quickly swapping things out. My solution looks clean but is quite painful to re-configure, lots of wasted time there when I was debugging. Also if you don't have easy access to laser cutting it is a bit annoying. Perhaps I (or you if you'd like to be added to the repository) could add a sub folder for your alternate base solution with the CAD/STLs to the git repository?

Good luck with your build keep us updated! It really makes me happy to see someone continuing the good fight. Let me know if you need any of the files in different formats etc. I'll be checking this thread every few days.

[Jfriesen]

Guys, someone just commented on one of my videos who used this arm update and got it working!

https://www.youtube.com/watch?v=iLPg2Sstj_8&t=0s

This is pretty cool!

[jwm]

Guys, someone just commented on one of my videos who used this arm update and got it working!

Cool, do we know if they are using your modified smoothieware, nicolas's g-code preprocessor or something else? is there another out there, I seem to remember someone working on a marlin modification.

Eagerly waiting my next McMaster shipment for the final bits to finish mine up.

[Jfriesen]

I asked a similar question and he said:

"I modified marlin-RC7 to use.It could understand gcode from any slicer"

From this I take that he must have a modified version of marlin running which does not require a G-code preprocessor.

[jwm]

Heh, I gave in and used this as an opporotunity to buy a smoothieboard, I must say I am super impressed so far. Thumbs up.

I do think the atmega would be powerful enough but Marlin and others always suffered from trying to be arduino programs too which is a huge pain and bloats code immensely for the sake of pretending it isn't c++ when it is just broken c++.

[Jfriesen]

Yeah, additionally the code was made by so many different people with so many different styles/requirements/etc. that it feels very frustrating to use if you need to change something beyond a simple config setting (and even that can be difficult with the bloated settings therein). Smoothieware definitely benefits from a clean start and "less cooks in the kitchen" wherein the code architecture seems more intuitive and the documentation is cleaner. Add that with the benefits of C++ which is implemented correctly and you get an awesome modular codebase. Too bad the price tag is a bit higher though I will say. Would be nice if someone could make a similar codebase that would run on the atmega processors but I suppose there isn't a ton of money in it up front.

I guess this whole discussion is a bit off topic whoops