pic: Custom encoder mount for Mini CIM/CIM

[iambujo]

loading photo ...

[xXhunter47Xx]

I like it! Although is there any reason you're direct mounting it instead of on the output shaft of a gearbox or other?

[Peyton Yeung]

Does that still leave you much space for pinion gear mounting inside a gear box? Very similar to this one.

[jojoguy10]

Originally Posted by iambujo

loading photo ...

Actually, according to CUI's datasheet, the maximum RPM is 15,000RPM if you go down to 512PPR

Great design BTW! How much of the CIM shaft is left sticking out?

[iambujo]

Originally Posted by xXhunter47Xx

I like it! Although is there any reason you're direct mounting it instead of on the output shaft of a gearbox or other?

We wanted an option for cases where either a gear box isn't used (like our shooter this year) or another type of encoder mounting just isn't a convenient option.

[iambujo]

Originally Posted by Peyton Yeung

Does that still leave you much space for pinion gear mounting inside a gear box? Very similar to this one.

I'm not sure, it might not work for some pinion to gearbox applications, but it works well for an 8mm inside diameter keyed shaft (or equivalent shaft adapter).

I hadn't seen the one in the link before! Here I thought we had a novel idea!

[iambujo]

Originally Posted by jojoguy10

Actually, according to CUI's datasheet, the maximum RPM is 15,000RPM if you go down to 512PPR

Great design BTW! How much of the CIM shaft is left sticking out?

Right, it can go up to 15,000 RPM at a lower encoder resolution. I only quoted the range that a mini CIM or CIM could reach, but good catch.

I'll measure the final shaft length tomorrow and let you know.

[Ether]

Originally Posted by jojoguy10

Actually, according to CUI's datasheet, the maximum RPM is 15,000RPM if you go down to 512PPR

What exactly is CUI's definition of "PPR"? "Pulses Per Revolution" is ambiguous.

Do they define it as

• rising edges per rev on one channel?
  
  
• rising and falling edges per rev on one channel?
  
  
• rising and falling edges per rev on both channels?

Couldn't find the term defined unambigously anywhere on the website or in the product datasheet.


Note: US Digital rates their encoders according to CPR, which they define as "Cycles Per Revolution", which is unambiguous. For example, a US Digital 360 CPR encoder would mean 360 cycles per rev, which is the same as:

360 rising edges per rev per channel
720 rising and falling edges per rev per channel
1440 rising and falling edges per rev both channels

[iambujo]

Originally Posted by Ether

What exactly is CUI's definition of "PPR"? "Pulses Per Revolution" is ambiguous.

Do they define it as

• rising edges per rev on one channel?
  
  
• rising and falling edges per rev on one channel?
  
  
• rising and falling edges per rev on both channels?

Couldn't find the term defined unambigously anywhere on the website or in the product datasheet.


Note: US Digital rates their encoders according to CPR, which they define as "Cycles Per Revolution", which is unambiguous. For example, a US Digital 360 CPR encoder would mean 360 cycles per rev, which is the same as:

360 rising edges per rev per channel
720 rising and falling edges per rev per channel
1440 rising and falling edges per rev both channels

Good question sir, I'm not sure yet. I plan to test that tomorrow and I will let you know.

[Munchskull]

if you want to save cnc time and have a 3d printer.

[Ether]

Originally Posted by iambujo

The AMT10 has a configurable resolution ranging from 48 up to 2048 at a max of 7500 RPMs

Assuming¹ for the moment that 2048 means "rising edges per rev per channel", let's do the math if you set this up for quadrature at 7500 RPM with a 20ms control loop period:

CPR: 2048$

decoding:4$

secondsPerControlLoop: 20/1000$

FPGAsamples: 127$

edgesPerControlLoop: RPM * (1/60) * (decoding*CPR) * secondsPerControlLoop = 20,480

secondsPerEdge²: float((1/RPM) * 60 * 1/(decoding*CPR)) = 0.9766e-6

secondsPerSamplesize: secondsPerEdge * FPGAsamples = 0.1240234375e-3

As can be seen, that is way overkill for operation at that speed.



¹ I am inferring that because there are a couple of odd-number PPRs in the list, namely 125 and 385. You can't have an odd number of "rising and falling edges per rev per channel" or "rising and falling edges per rev both channels"

² This number is even smaller if quadrature tolerance is included. But the 40MHz sampling rate of the roboRIO theoretically should handle it.

[iambujo]

Originally Posted by iambujo

Right, it can go up to 15,000 RPM at a lower encoder resolution. I only quoted the range that a mini CIM or CIM could reach, but good catch.

I'll measure the final shaft length tomorrow and let you know.

There appears to be 13/16" of the shaft remaining.

I didn't get a chance to test the encoder signal today.

[iambujo]

We ran the encoder class on the encoder with the resolution set to 256. We got roughly 25,000 from the encoder class. 25,000ticks x (60sec/min) / (256ticks/rev) = about 5,859 RPMs. Since this was a full speed minicim I'd say the data was valid and I'd say the encoder's resolution is based on rising (or falling) edge and not both. Otherwise the RPM data would not be right.

The beauty of this encoder is that we can set the resolution lower if there was a sampling rate issue, simply with dip switches.

[Ether]

Originally Posted by iambujo

We ran the encoder class on the encoder

You left out one piece of information crucial to your argument: decoding mode.

[Alan Anderson]

Originally Posted by Ether

You left out one piece of information crucial to your argument: decoding mode.

The mode doesn't change the value, just the resolution. One cycle of the quadrature signals is one count.