@ahull
so we need a few 'scope traces
Fig1 unstow @ 100 mS/div - (trig on POSITION PI POWER rising edge)
POSITION PI POWER
ENCODER PI POWER
Front ENC PI phototransistor
Back ENC PI phototransistor
Fig 2 unstow @ 5 mS/div - (trig on POSITION PI POWER rising edge)
ENCODER PI POWER
Front ENC PI phototransistor
Back ENC PI phototransistor
@ahull
I suspect we only need to simulate the fixed number of feedback pulses from the encoder
I got this data last night. The motor has two sensors at 120deg apart axially. The number of pulses are 420 in unstow and stow, in ~660 mS. The equal number in both directions suggests that probably anti-backlash is not applied on the ZOOM subassembly during these two events, one critical potential stumbling block I was concerned about. The other concern is inertia. You can definitely see it (Fig 2), but the real shot-in-the-dark is whether FW measures it or not. If that is being detected, I don't expect we'll have enough MIPS available to simulate. So I will begin without inertia and see if Canon complains. The phase shift may be important too, creating possible extra CPU expense.
@ahull
assuming we don't need to simulate/monitor the stall current in the motor
A real possibility too, but I don't expect so // it would be overkill for them to detect stall current when all can be done with the axial sensors. Also, if there is anti-backlash, motor direction will likely have to be detected by the microcontroller and simulated, but we really be sure yet. As I said, it's not simple
.
@Microfunguy
I have not read the full specification of the Arduino yet but I notice it has five pulse-width-modulated pins. Will they be of use in generating a pulse train as the zoom moves ?
That's the first thing I looked at. From what I understand ... the base frequency has to be a power-of-2, and that will likely not fit the solution requirement. So it looks like we'll have to synthesize it ourselves
. Ideas are welcome!
