I’m struggling to visualize how this would work with both the left and right attach points. Would we expect the sled to stay vertical? Or would there be a different type of attachment for the right side, like a half-ring or something?
The two wires up top would be at slightly different heights so they can cross… the bottom wires don’t cross.
At the top, the end of the cables are fixed but allowed to swivel… It doesn’t have to be a pulley or anything. The slack is take up by the spools at the bottom of the sled.
2 Likes
Ideally the wire should be mounted right at the center of the bit above the router and not at the sled. And at the motor side, right above at the center of the gear also on a bracket.
Just my 0.02
l like this idea of having motors on the sled and having the chain go to both corners for increased stability. However this brings back the old question about what to do with the excess chain on the sled as the sled moves to the top areas of the work piece? Some kind of take up spool either spring or motor driven is needed.
or some new type of cable measuring system.
I don’t know that it’s practical to do this with chain. It would be doable with wire rope that you can spool up. But then you have to account for wire stretch, but if you use a calibration matrix (like the optical calibration method) you can overcome it.
@madgrizzle - How would you calculate the change in diameter of the spool as it feeds and unfeeds the cable. I’d think you’d still need an encoder mounted outside of that mechanism to build the control loop, yeah?
-J
1 Like
@Jacob, separating the encoder mechanism from the cable spool would certainly simplify the mechanism.
1 Like
Well, you could spool up about 20 wraps of cable on a 3-inch diameter spool and it would give you enough length to go from the near corner to the far corner. So, if you can control the winding of the cable, you can avoid overlapping (maybe a helical groove in the spool). Next, since I don’t think you can readily find a helical grooved spool, you can maybe 3D print your own. And if you can do that and you pass the cable through a fixed eyelet, oh say 3-inches from the spool, you can vary the diameter of the spool you print such that the amount of cable that is fed out is equal for each revolution (though if you use optical calibration, even this could be overcome). A spool like this would work for 1/16-inch cable:
I’d print it out and give it a go, but it’s too big for my printer… maybe I can split it in half and glue it together.
1 Like
I really like this concept as a mechanical system, but I’m thinking relying only on the motor encoder and cable introduces enough variable noise to risk negating the benefits, regardless of potential solutions.
FWIW a 3" spool is really large, but it is really only experiencing the equivalent of a 1.5" spool’s torque with the system doubling back the cable path ----- That also means that you are spooling twice as much cable to cover the corner-to-corner distance. More like a bit under 40 wraps, rather than 20.
Does this same system work if you put the motors at the top of the sled instead? If so, you could probably accomplish this same thing using chains in a similar config where you just route them back to the outside of the frame after they transit the chain cogs on the motor.
Unless I’m calculating it wrong, which is possible, I think you only need to wrap about 13 feet feet of cable and 20 wraps at 3 inch diameter gives you 15 feet. I imagine you would lose precision with the encoder going to a larger diameter… not sure how that would effect things. What do you mean by “variable noise”?
If the system works, I don’t think it matters where the motors are placed on the sled. Are you suggesting a slack chain arrangement like we have today with bottom feed? Something like this:
Oh, my math could be way wrong on the number of wraps… I was using a diagram that’s definitely not to scale.
I was wrong about the spool. you are correct. I was thinking 3" circumference, not diameter.
The picture is correct, yeah, though I’d do the gravity thing on the sides rather than the bungee.
That idea sits more easily with me anyways… You sometimes need a rather large lead-in for cable to follow their designed paths, and a good bit of tension to behave.
Either way, I think your original ideas are worth trying for sure. Always glad to help prototype and troubleshoot.
Yeah, I don’t have much experience with cable systems… I’m just throwing out ideas for those that might be working on something. I’ve got too many irons in the fire at this time.
I wonder about the resolution of the encoders and having a larger effective distPerRot. The spool I posted was designed to mount directly to the output shaft of the current gearbox, but if you put in some gears or maybe used a belt drive, you could get back to the current 63.5 mm distPerRot. If you found some kinda of cable that’s more flexible, then maybe you could use a smaller diameter spool, but steel line, even at 1/16-inch, has a decent bend radius that has to be maintained.
I’ve been loosely following this thread. Has anyone discussed putting a wheel with an encoder near the eyelet to measure how much cable was unspooled? You’d need to have a way to make sure it didn’t slip or else you’d get drift, but at least you wouldn’t need to have a perfectly precise spool. I’m not sure that this is a good idea, but maybe worth considering
That’s a good approach. The wheel could either run on the cable with friction, or have one wrap of cable around it like an old-school radio tuner.
1 Like
Ooh I like that idea. Then the tension on the cable from the sled weight would help prevent slippage
1 Like
Yep… makes sense… but you need an external encoder to incorporate into the design. I was just looking to try to keep it as simple as possible using the same equipment. But if you could incorporate an external encoder, a lot of issues get eliminated. If someone is interested in trying to build the thing, I can figure out a version of FW for a controller that will work with a looped cable/wire design.
I’ve been prototyping a circuit that talks to the AMT213D encoder. That one offers 14-bit resolution per turn and counts turns besides. It would need two of these to handle the right and left cables. The Arduino Mega has two unused hardware UARTS that can keep up with the 2Mbit communication rate needed, they’re currently mapped as AUX1-4 on the stock Maslow board and unused on the various TLE5206 board. Each poll takes 80uS per encoder to complete, so it’s a little slower than the present interrupt-driven encoders but might be fast enough.
2 Likes
I wonder about the resolution of the encoders and having a larger effective
distPerRot.
That should not be a problem, it’s fairly easy toget 8k or 16k positions/rev
encoders, and with our current 8k/rev 2cm diameter sprockets, the resolution is
overkill, you should be able to go to 3x-5x the diameter with the appropriate
encoder
If you found some kinda of cable that’s more flexible, then maybe you could
use a smaller diameter spool, but steel line, even at 1/16-inch, has a decent
bend radius that has to be maintained.
This bend radius makes the ‘go through an eyelet’ a problem. I also worry about
the cable aquiring a ‘set’, at low tension, that will have a significant effect
on the effective length.
David Lang
Remember, we don’t need to continually poll the encoders, we only need the
encoder positions when we are running through the PID loops and need to check
where we are
This potentially opens us up to being able to run this on a non-realtime system
(like a Pi) as it’s no longer time-critical to watch encoder pulses, and with
the PID loop, we aren’t trying to generate stepper pulses at extremely precise
intervals.
David Lang