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..
cunningfellow wrote:
>
>HUH - who said motor control chip. The PWM
>straight from an Atmel into a FET on the low
>side. The Atmel counts the pulses from a
>single channel of the encoder to do speed feed-
>back. Cheaper and less chips than a high side
>switch and whats all the complexity of going
>into the analog domain about :S
>
>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 will keep track of pulses line to line - but I
>am NOT willing to manually ZERO the thing. I am
>a dork - and if there is something I can do wrong
>I will 50% of the time. And wasting every second
>sheet of film because I could no be bothered
>making it automatically detect the start of frame
>is not my idea of fun.
>
>
>
>
Simply add your own setup to get a once per line index, just easier
than keeping track.
>Also - I am not trying to be nasty about any feed-
>back about my circuit.
>
1>
> I welcome all feedback
>especially if I am doing something stupid and
>obviously wrong.
>
2>
> 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)
>
>
>
3>
>Once I have it running (give me 6 months) feel
>free to bag me endlessly for having one too many
>resistors in there and tell me I could have made
>it much less complex if I had done something
>differently.
>
>
>
I find the excluding of advice a bit strange after your earlier
understanding that software and less hardware is generally better.. You
seem to be taking things like 3 and categorizing them under class 2
instead of class 1. Maybe the only reason you're only seeing it as an
'either/or/nearly equal' case instead of a very bad idea for hardware is
because you don't already know the other method fully? Even if it would
still fall into class 2, 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. Knowing the hardware PLL, you know how
others who don't know their use ascribe more work to using them than
there actually is, simply because they aren't familiar. But you're also
doing the reverse. Software PLL is a breeze, not the work you seem to
be deciding it is without looking at it enough. Your not being familiar
with it is letting you way overestimate the work involved, you seem to
have classed the advice into category 2 off hand. Really you'd have to
investigate it far better than reading an email or two to even have an
idea whether it is just an either/or comparison or really falls into
category 1 and is way more important advice than how you're seeing at
first.. Knowing both at least somewhat, I'd say instead of the 50/50
toss up or maybe even in favor of the hardware since you're familiar
already, 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..
Have your index so you know where the line start is without much
work. For speed control, you simply time from one positive encoder edge
to the next with a counter. If the count is under what it should be,
you slow down, if it's over you speed up. Not much else to it. If from
one edge to the next doesn't give tight enough control, you simply roll
over a set of multiple counts. Keep track of the last 4 pulse timings,
overwriting the newest one onto the oldest one. Add all 4 after each
pulse, and if that last 4 counts are over or under the right total,
speed up or slow down respectively.. Or 8 or 16 counts etc, however
many needed to get a large enough count to have tight enough control..
There is no need for any multiplication or division, that is completely
taken care of by the fact that the rate you're expecting counts from the
encoder is different than the rate you're clocking out on the beam from
the index. As long as your speed is right with accuracy, and you're
outputting at the desired clock rate from the index, there is no need to
relate the two values directly at all. It is simply keeping track of 2
factors of different scale within the same loop, it's way less work than
required by a loop within a loop. Or you can completely split them up
and keep them independent, the only real linkage is the mechanical one
from the encoder to the beam. Either way it'll spend very little effort
on the PLL control part, there is near nothing extra needed to control a
motor like this..
From your later message, motors are slow creatures. You don't really
need a bunch of 16 bit math to keep up with this, even at a higly
accurate count, you only need a delta signal to decide if you need
faster or slower. You spin up and do a full count once, to make sure
you're in the right speed range with the high byte or bytes. Then you
simply subtract the oldest low byte from your accumulated count, and
then add your new count low byte. Say you have a 16 count rollover, you
just subtracted your 16th count ago, and now added your new first count,
then increment the index for next time. As long as your current count
sum low byte isn't 128 out from the desired total count low byte, you
are within range and know your high byte is the same, you don't have to
add anything 16 bit really. And you have really tight control across
many pulses with just one 8 bit subtract and one 8 bit add. (Really it
has to be within 128- the difference from the old byte and the new byte,
that eats up some of your headroom for the high byte rollover..) You
can exercise extremely accurate control with almost no work, you only
need to check enough low bits to make sure you're within the error range
of the motor's speed variation. This way is ∗more∗ lazy and less time
consuming and much more flexible than doing it in hardware, you just
haven't already seen that part for yourself yet.. :) I've done it some
before so these are older ideas for me already.. Say your full count
has whatever high bytes, and the low byte of the full high res count
from 16 pulses should be 237. Anything short of 128 out either way for
total change and you'll stay accurate and can figure the delta, no need
to worry about if the high byte went up or down with the wrap even.
Generally get it so your variation is like 16 or less, that way you're
well inside, and staying within 16 counts of say a random total of
13,837 for your full 16 value count is pretty tight control. If it's a
little too jittery on controlling by a single pulse value, you could
easily keep two rolling counts, say one at 16 or 32 counts and one just
the last 4. Then use two bits up in the 4 (shift divide by 4 to average
the last 4 values) related to 4 bits up in the 16 (shift divide by 16)
to generate the delta for faster/slower. Still not that many
adds/subtracts and compares to do, even with two seperate rollover averages.
Haven't worked the numbers, you have to make sure you're generating a
delta value toward the correct running total. My description may even
be off somewhere on verbage etc, but it's the right basic idea. Haven't
written out the numbers etc to make sure I'm saying it 100% correctly..
It seems you're maybe taking some of the advice a little too
critically too. I'm as slack as anybody, and took way too long to
decide to figure this stuff out for myself when I finally did. But now
that I do, and know how useful it is in many areas, and it's obvious you
have most of the necessary related ideas anyway, I wouldn't be mean
enough to not give you an extra kick or two too to hurry up and learn
it, even if you say a million times how much you don't want it lol..
You'll be kicking yourself a lot more if you wait years, having these
ideas in your head improves your thinking on solving a ton of different
programming problems. You learn to adapt almost everything to these
ideas, because they are so simple after you have them in mind. Theymake
many things easy that would be hard to keep track of without them.
DDS (direct digital synthesis) is almost directly related, sort of
like the difference between working with whole numbers or fractions
between the two. Learn it at the same time if you don't already know,
if you do then you need to look at it again while looking at the PLL
idea to see how related they are. The combination of the two ideas let
you do almost anything real world without too much actual work.
Of course even typing this up isn't entirely altruistic, pulls it back
into the front of the brain for me, have done some slack coding lately
where I should have tightened it up more with these ideas. Use them all
the time on little tasks, sometimes don't bother to back up and use the
right big picture after adding code on, very bad and slack habit.
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..
Alan