> Jan wrote:
> I guess what I would do is run the processor from
> a crystal oscillator, and try to sync the cylinder
> rotation with the processor clock.
OK - I understand where your coming from now.
Still I would prefer to PLL a pixel clock from the
motor rather than try regulate the speed of a motor
to match the xtal.
<SNIP>
> I wonder how much jitter there is, pulse to pulse,
> and from one revolution to the next?
>
> Note that the only feedback you have about the
> cylinder speed is the encoder pulse edges, which
> come one every 100 uS. The PLL isn't psychic...
> it uses those same encoder pulse edges, sees whether
> they arrive early or later than expected, and
> ramps the oscillator speed up or down as needed to
> stay in sync. The processor can watch those pulses
> just as well as the PLL can, and control the motor
> speed with PWM.
The motor has a very slow loop (big mechanical mass)
The VCO/Divider/Phase-comparator has a relativly fast
loop. I think that errors that are out by a few thou
and are corrected in 1mm will be less serious than
errors that last for 3 revolutions.
Take that back - PLLs ARE psychic :D
Yes - They both use the same encoder for feedback.
But the PLL can use the phase difference to affect
the loop every single singal pulse. An MCU like the
ATMega has to
A, Either add up several 100/1000s pulses in a
pulse accumulator over a period of time to
feed back into the loop. OR
B, Use an Input Capture to compare the absolute time
of each pulse. It has to then run the loop
filter every encoder cycle. This being 16 bit
math with multiplys and divides. Even if you
simplify the PID loop to P there is still going
to be plenty 'nuff 16 bit additions and
subtractions to keep the poor little atmel busy.
<SNIP>
> > So you have to do two control loops,
> Just one, I think: the motor speed, and that loop
> is s-l-o-w.
Second one on the servo for the X axis. Amazingly
s--l--o--w but still needs software.
> > decode group 3 fax and a SW shift register with
> > hopefully uS accuracy in 80 clock cycles.
>
> I don't know what's involved with group 3 fax, but
> 80 instructions is way more than needed for a sw
> shift register. I would do the shifting in an
> interrupt routine triggered by a timer.
G3 compression is Run Length Encoding that is then
Huffman (variable bit length) encoded.
Enter/Exit interrupt, Save states, + SW shift will
take at least 10 cycles. Take away the time taken
to service the UART, do XModem-CRC and run the
servo control loops - I am not sure that I could
get huffman decoding done in that time. Even with
fancy tricks and the oodles of memory an ATMega has.
However - Now that I know your idea was to regulate
the speed of the motor more accuratly than I planned
too - You're allowed to use the SPI hardware shift
register too :)
<SNIP>
> Sounds like you're depending on the internal clock
> being pretty stable.
Just the opposite. I am planing on the PLL to be
accurate WRT the rotating drum. Then the pixels are
accurate. What speed the atmel runs at is totaly
irrelivent.
Rather than making the drum speed the most important
thing in the world - I want to make the world march
the the beet of the drums drum :)
<SNIP>
> > Also - I am not trying to be nasty about any feed-
> > back about my circuit. I welcome all feedback
> > especially if I am doing something stupid and
> > obviously wrong. But please can we limit "I
> > ∗think∗ it would be better if you did this" kinda
> > feed back till I have something working. Even if
> > you think I am going about it the hard way. (rather
> > than the wrong way)
>
> Sorry... I just enjoy simplifying circuits to the
> bone... I don't see anything there that would make
> your circuit definitely NOT work.
OK - After I have it running with a PLL - I shall try
see if I can reduce the chip count by 1 with your
idea there.
OR I could just pack the finished unit in a cardboard
box and let you do it if you like ? I already have
about 10 years worth of project backlog to get through.
> In order to get 2000dpi accurately, so the dots line
> up from one revolution to the next, there can't be
> too much random jitter in the decoder pulses, the
> processor clock needs to be stable, the 12V needs to
> be stable or else compensated for...
∗OR∗ the pll needs to have the loop filter sorted and
you ignore all other variances :D
andrew = lazy.
PLL = Not having to optimize code too much.
andrew + PLL = HLA (Happy Lazy Andrew)
:D