Over the summer I designed a 3D printed mount that allows the CUI 102-V encoder to be mounted to any motors that have the CIM mounting profile, including but not limited to the Mini CIM, and the CIM-ile. You can find pictures, and a variety of different CAD files in the GrabCAD link below.
Please give feedback.
https://grabcad.com/library/cimcoder-2
(http://www.chiefdelphi.com/forums/showthread.php?t=131030&highlight=CIM)
Excellent! This looks wonderful, thank you.
I love the design!
Just FYI for those using the CUI encoders, the case is connected to ground and can cause issues. We used nylon bolts for mounting them to avoid any issues but they definitely caused some pain for a brief period.
Thank you. The grounded case was taken into consideration when designing this. The CIMcoder 2.3 (the one currently published) is my 6th revision on the design. This exact revison has not been tested but the CIMcoder 2.2 has. The difference between the 2.2 and the 2.3 is that the 2.3 has an extra .05th of an inch added to the top to keep the encoder’s metal body from touching any conductive gearbox.
How much usable length is left on the key with one of these?
Do you have any info on how much error you’d see due to backlash using this on a typical drive gearbox (such as the KOP toughbox)?
You have hit on the two flaws that I have found with this mount.
To answer your first question you loose about 0.25" on the CIM shaft but due to the way it mounts you also have to calculate the thickness of you gearbox plate into your shaft length lost. From my experience that thickness is about 0.25". That means that the total shaft lose is on average 0.5" leaving you with 0.75" of shaft to work with. This is just enough to fit a pinion gear and the required hardware to hold it on. While I have not tested this I believe that in its current state it will not work with Vexpro dog shifters.
I have not calculated back lash but I plan to, I will post the results as soon as I can.
Thanks for using GrabCad… that’s a great resource for CAD stuff. I do have a question for you (I’ll have to check out the measurements). I’ve been trying to solve the problem of error precision with my printers, and I know for example if I print a part with holes… for example 0.25" for a 0.25" bolt… I have to really use 0.27"… (This is for flash forge creator). I tried to narrow down the precision error even further when testing with Legos where it is about 0.5mm diameter increase on holes for (Flash forge), and about 0.25mm for Statasys.
My question to you is… do you use exact measurements in the CAD, and do you solve for precision loss of your 3D printer… if so how? I’m still trying to work-out an elegant work-flow to keep exact measurements in CAD while converting to STL with the adjustments (e.g. equations or something along these lines).
I did end up using exact measurements for this part. I printed it using my team’s Ekocycle, while I hate the price of filament it does a very nice job of printing. Since the Ekocycle prints in PET I found that with exact measurements all the bolts would grip the print, cutting their own threads.
Ah… that sounds about right… it would be interesting to use a caliper on the holes made and see how accurate the print was.
As I’m running some numbers please let me know how you ended up with:
0.113 and 0.1935 diameters?
I use a pitch diameter table such as this:
For example:
So for a screw 10 -24 it is .1900… if this mount uses a 10 and it cuts its own threads using 0.1935 my guess is the actual hole printed is roughly 0.17 - 0.18 diameter.
It’s just nice to do a reality check and see if you are seeing the same numbers I see.
For me what I’ve been doing is using the helix and groove cut and print my own threads… I’ll try to throw some stuff on grab cad at some point… I did take a sneak peak at solidworks for 2016 and they’ll have their own threading stuff, but it won’t work for 3D printers unless they have a solution that can compensate for precision loss.
When I print bolt holes I usually undersize a little and print with extra shells (maybe 4 instead of my typical 2) and then drill it out with a free fit tap drill bit. Steel machine screws easily tap themselves into the hole and make their own thread. Otherwise I will drill a clearance hole for non-threading situations.
It is generally a very easy extra operation that saves the hassle of worrying about print tolerance.
Fantastic design, this will work very well with Versa-planetary CIM input adaptors, just less shaft to cut off.
I confirm that this will not work with WCP Dog shifters, due to the CIM gear-first stage, meshing at the end of the shaft.
After about an hour of trouble shooting and math, I developed** a new mount**](https://grabcad.com/library/cimcoder-wcp-dg-edition-1)that works an the WCP DS Gearbox. The one catch is you have to use an Andymark 12t pinion gear (or any pinion gear that is 0.52" or less).
Looks nice!
Note that using your encoder mount on a shifting gearbox like the WCP DS will mean you won’t be able keep track of actual distance travelled after shifting.
Correct me if I am wrong but couldn’t you use a true-false variable to determine if you were in the high or low gear? Then from there you could a just the way your code reads the encoder.
You would probably want to measure if the ball or dog is engaged or the change in velocity. I would recommend this over checking against a variable as shifting isn’t instantaneous.
I would much rather put the encoder wheel side so you don’t have to keep track of it/probably easier for repairs as well.
I feel like for most teams in most situations the minor time lag associated with shifting shouldn’t affect them significantly.
I prefer having the encoders on the gearbox, as they’re more protected that way. We occasionally (around once per year) lose encoders due to insufficient protection/some small mistake that destroys the already-vulnerable encoders.
Ah that’s a good approach… thanks for sharing.
I’ve went ahead and uploaded a little camera mounting project I did which illustrates what I do for the holes… I found on my printer to just expand the diameter by about 0.02… the threading pitch works out well enough, and I also experimented with 3D printed screws as well… not sure yet if I’ll do that again, but if weight matters… it may be worth consideration.
The more I think about it, the less I think you’d need to measure encoder values during shifting. We usually use encoders for auto, and it’s not likely that we would shift during auto. Even if we had some sort of fancy always-on gyro compensation, we could probably disable it for a second during the shift.
Thanks for sharing!
We put our encoders on the gearbox, down stream of the shifting mechanism. This gives us less backlash in our measurement and we don’t have to worry about shifting. The accumulated hex backlash due to the clearances that Aren specs is quite large, and the dog engagement also adds to the problem. When you are trying to design a precision autonomous mode, every little thing counts. The best way to design an awesome control loop is to have awesome hardware to control.
We printed one of these using our statasys. The holes for the screws for the encoder are just slightly too large to tap them for 4-40. We ended up putting a bit of glue in the hole and then taping it (READ: forcing the screw in). Worked out well.
Overall, a very nice design.