I have been playing around with these exact same issues in my head and it is so cool to see you working through them in real life!!!
Here are my thoughts.
I was initially planing to do a single wrap around a capstan, but I think there may be a long term accuracy issue because the diameter of the cable is a factor in that equation, and the diameter may not be a reliable dimension. I am planning to experiment with two pinch rollers to measure the rope as it passes in a straight line so it’s width is not a factor.
For the issue of loosing tension and so the outer roller is not working I was thinking that a second encoder on the motor to monitor what was going on could be a back up plan, but I think measuring the motors current draw should be enough to work out if things are ok and throw an alarm. If we can see that the motor is drawing current in a reasonable range then it is working. When the sled is moving up and the lower motor is feeding out cable is the time when it would be hardest to detect an error and I think some testing would be needed to determine if a current measurement would be enough under those conditions.
Keep up the awesome work!! I’m hoping to start playing with hardware for something similar in a month or so.
I like the idea. I assume the cable would pass between “rollers” before and after the pinch rollers to make the segment where the pinch rollers are straight or did you have other plans?
hmm, i wonder if you could have a limit switch of some sort… so that if it tries to pull too hard on the bracket, it pushes in the limit switch and stops the machine.
I think that’s doable assuming it flexes enough before breaking… not sure. But, I think we can also monitor chain length error and stop things when it exceeds a certain limit. Right now, it postional error limit stops everything based upon location of sled, but there’s no reason not to stop things if a particular chain isn’t keeping up either.
Hm, I was thinking about three motors, the third one at he bottom, in the middle of the span. That would prevent “jumping” in the vertical axes and eliminate the need for the weight on the router carriage, allowing it it move faster. Aaaaand… how about stronger servo motors in stepper/ servo driver configuration?
the problem is that you need more force to pull the sled into the bottom corner,
a motor in the middle will be pulling away from the bottom corner, exactly the
opposite of what we need.
to claify (this is a common enough issue that it may be that this needs a couple
pictures added and then added to the wiki)
One of the biggest weaknesses of the Maslow is cutting in the bottom corners.
This is because the Maslow relies on gravity to move the sled, and in the bottom
corners the chains are very close to vertical (80 degrees from horizontal, 10
from vertical) and so the force of gravity is effectively split into tension on
each chain, a large force to the near motor and a small force on the chain to
the far motor (we have a spreadsheet to give you an idea of what these forces
are, given the machine dimensions and sled weight). The limit fo how well the
sled can move towards the corner is the tension on the chain to the far motor
(because all you can do is pay out more chain and the tension on it is the only
force to move the sled). This force has to overcome the friction of the sled
(which is near a constant)
There are a number of ways to improve this
increase the weight on the sled (which can cause problems with the max
tension on the chains when the sled is in the top center)
improve the angle of the chains by making the top beam wider (which makes the
angles in the top center worse, making the top beam higher improves the top
center and makes the bottom corners worse, but there’s lots of room for tweaking
here)
reduce the friction of the sled moving across your workpiece (sand/wax the
sled bottom, angle the frame closer to vertical)
introduce a new mechanism to provide force to pull the sled into the bottom
corners.
There are a lot of ideas of how to do #4, but the ‘easy’ ways (elastic pulling
into the corners, a third motor pulling down in the center, etc) end up pulling
away from the corners rather than pulling in to the corners. This also needs to
be something that’s mathmatically predictable so that the tension on the chains
can be predicted to allow the firmware to calculate how much the chain sags
under that tension.
The 1/16-inch spectra rope I use is incredibly light and I hope the rope sag is negligible (i.e., way below other sources of error… like rope stretch). For the top motors, its under enough tension that you can literally pluck the rope and play music on it. The bottom motors will be the biggest challenge of the design as discussed above regarding a rope going slack. But I’m working on a new ‘pillar’ design and am trying to come up with a way to detect if the rope goes slack. Using @Jatt’s idea to use limit switches to detect the machine pulling itself apart as an inspiration, this idea is to use them to detect if the rope goes slack. The red outlined item is a limit switch that is “closed” when there is tension and if it goes slack, then the limit switch will open…
Another idea is to have a spring loaded “tensioner” whose compression can be measured using an analog input.
P.S. ignore the lone nut
One of the goals of my design is to build it out of all COTS parts and not require specialized fabrication, like bent metal parts, creating PCBs and soldering, etc. so that people can readily source parts and assemble it. The use of limit switches I think would fit that since they can be bolted down (i.e., don’t have to be soldered onto a pcb) and connected up with simple wires and crimp connectors…but I haven’t found an inexpensive force gauge that can do the same. Everything I’ve found that’s inexpensive is rather fragile and incorporating it into a design like above gets complex.
Just one comment on the desire to do it all out of COTS. That’s a wonderful goal, but in the spirit of “don’t let great be the enemy of good” perhaps having a goal of a small package of say 5 or less specialized parts that can be bundled and the remainder being COTS would give you enough leeway to get over the next few obstacles. If you can avoid soldering etc. and a user just needs to buy a small package and source the rest locally, I think that’s manageable.
It’s a goal. To give you an example, you can buy end stop switches that you can connect to the microcontroller, but you probably need to add some resistors and capacitors to them to filter out noise. However, you can buy end stop modules, like this:
that have them built in as well as connectors attached (and even come with cables). The hole spacing on the board will allow them to be mounted on the pillar fairly easily. This is much easier for someone to do. The module I picked is apparently based upon a makerbot design so I figured the hole spacing will be quasi-standard. So if someone can’t find that particular manufacturer’s module (whoever DZS is), a bunch of other people make the same design.
The encoders I picked are CUI AMT-102V… they are expensive for encoders, but are readily available from mouser and digikey… and they work really well.
Something I want to avoid doing is using something like this (when I looked into force measuring):
That’s not easy to work with and requires a lot more integration.
But I’m not sure I can get around custom completely… the controller and possibly motor controllers will likely be custom… just at a minimum to connect all the pieces together.
The sled parts will be fabricated, but are designed as SVG files that can be sent to a laser cutter service to make. I’ve used ponoko.com for all my work so far, so I’ve spent time packing things into their standard sheet sizes as efficiently as possible.
