|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
|||
|
|||
|
Re: Minimum Flywheel Encoder CPR
Quote:
It worked just fine. |
|
#2
|
||||
|
||||
|
Re: Minimum Flywheel Encoder CPR
jojoguy: I'm having a hard time working through the math that gets me to "setting CPR to 3 let's me specify setpoint in RPM". Can you lead me through the math?
we're off for 3 night (exams!), so I can't fiddle with it in the lab. |
|
#3
|
|||
|
|||
|
Re: Minimum Flywheel Encoder CPR
Quote:
I, for one, think this is terrible design. |
|
#4
|
|||
|
|||
|
Re: Minimum Flywheel Encoder CPR
Quote:
The config method wants the former, despite all the native units being calculated using the latter. Yes, this is confusing and bad and should be changed ![]() |
|
#5
|
||||
|
||||
|
Re: Minimum Flywheel Encoder CPR
Quote:
If I don't call .ConfigEncoderCodesPerRev(), then .set() works in the silly transitions / 100ms units. Do I have that correct? |
|
#6
|
|||
|
|||
|
Re: Minimum Flywheel Encoder CPR
Quote:
I would avoid leveraging the internal unit scaling, though, because some of the other lower level functions (e.g. getEncVelocity) will still return in native units/100ms and mixing units is a recipe for confusion. Just do the unit scaling in your own code - you need only write two methods (RPMToNative and nativeToRPM), and you will never have any doubt about what units a variable is in. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|