On 2011-05-12 07:07, Olin Lathrop wrote:
>
> That's the basic idea, although use of floating point and 16 bit integers=
 is
> totally silly if this was done on a PIC.  Just because you can do somethi=
ng
> easily in a higher level language doesn't make it a good idea.  The probl=
em
> with 16 bits is that the repetition period can be very long, much longer
> than the thermal time constants.

It is being done on a PIC, and I am happy with the reasoning process=20
that lead me there.  The float argument makes for an easy interface to=20
the rest of the PID code which uses floating point in C.  But you are=20
right, there is no real point in using a 16-bit integer for the=20
accumulator.  This is an 18F2680 with loads of code and data space=20
remaining, and I decided to trade off space optimizations for high-level=20
maintainability a while ago.  I am enjoying the luxury of normal math. =20
The ISR remains all-integer and pretty minimal.  Even if I wanted to, I=20
couldn't reduce the PID cycle time below the 300ms required for the=20
thermocouple ADC to take a sample.

>> It was my understanding that it's "bad" to draw DC from the line, so I
>> was wary of drawing half-cycles.
> It's probably not great if lots of devices did it all synchronized.  In m=
y
> case the unit is driving 32 heaters, each independently controlled.  The
> chance of them all turning on every other half cycle and being in sync fo=
r
> more than a few cycles is pretty much zero.

Indeed.  If you were crazy you could always accumulate the half-cycle=20
error and feed that back too :)

Joe



--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.