Homebrew PCBs

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