> Alan wrote:
>
> A bit OT and longish, but other people might
> want to see how to run the software PLL with
> only a few adds and subtracts..
control loops.
P = add and subtract
PID != add and subtract
> >cunningfellow wrote:
<SNIP>
> >Digital pulses in - Digital pulses out. I spend
> >so much of my life avoiding analog circuits.
> >There is no way I am going to invite them in
> >the front door for no good reason.
>
> Of course the good philosophy, use it to decide
> to dump the PLL too..
I did say "for no good reason."
I am not a mechanic. I don't know if the motor
speed is able to be controlled without some
amount of jitter. I do know that I can predict
the loop in the analog PLL.
But maybe a better explanation of my "good reason"
comes from the other post I made when I said
"marching to the beat of the drums drum"
Think about the reltive merits of controlling
the pixel clock relative to the motor and then
controlling the motor relative to the pixel
clock.
> >I will keep track of pulses line to line - but I
> >am NOT willing to manually ZERO the thing.<SNIP>
> Simply add your own setup to get a once per line
> index, just easier than keeping track.
No - I will keep track. The index mark could be
out by a pixel or two each revolution if the jitter
is bad. Counting from the index EACH revolution
you could end up with a spiral along the print out.
(fairly obviously the errors could accumulate)
I MAY look at the index mark each revolution. This
would be part of "Checks and measures" to make sure
nothing has gone horribly wrong. I do however think
it would be foolish to rely on it.
<SNIP>
> if your timing is loose enough to not worry about
> it in 6 months etc, then there's certainly time to
> better evaluate other techniques more fully.
I just do not think that I should be doing it now
or in 6 months time. I was just trying to not be
rude and dismiss the idea outright.
<SNIP>
> it's really more like 80/20 or 90/10 in favor for
> the software PLL. It doesn't require some serious
> extra work, if you're already doing some related
> count then it's almost no work to add it into the
> loop and do it in the same routine. Much less
> work than you're guestimating so far..
If we are comparing apples and apples a digital
only loop would win. I used a digital only
control loop to do an automatic traction control
for a remote conrtol car 12 years ago and would
never have thought about using anything analog
in that case.
But please have a look at the relative merits of
controlling motor speed or controlling pixel clock.
Then if you agree with me that controling the
pixel clock is a better idea - tell me if you
think its a good plan to do that in a 16mhz atmel.
<SNIP lots of stuff about 8 bit math ect>
> It seems you're maybe taking some of the advice a
> little too critically too.
<snip stuf about learning things>
I like to think I don't take things to seriosuly
ever. On the internet though, you have to limit
the amount of people you will spend time listening
too. Everyone is an expert. Even if they don't
understand the problem. And I usually prefer to
say "thats a good idea - but I will stick to doing
it my way for now".
That is unless someone can show me that my way may
not work.
If you invite everyone to put in thier two cents
worth - you might end up rich - but you will never
the job done.
> Also, have you thought about skipping the red laser
> part and just drawing on a board with UV directly?
> Thought about it some myself before, and lower power
> non-cutting UV lasers aren't so bad pricewise
> compared to the cutters really. Still like the idea
> of a simple inkjet though for now, few of my boards
> are tight resolution. Of course I want a billion
> watt cutting UV laser anyway..
I have though about it - but dismissed the idea
quickly. I have a center lathe, a milling machine
a TIG welder and a whole shed full of equipment.
I can even use the lathe to turn up cone pieces.
I do know I don't have enough skill to build an
XY carraige large enough to hold a UV-gas laser
and position it to 0.01 mm accuracy.