threshold change in reprap.java

> Also, I'm still on an old version - following my
> change-one-thing-at-a-time theory - so could someone else put these
> threshold values right? (see attachment) This presumably means Andreas
> has progressed to extruding plastic...

The lower threshold is a workround for a bug. The extruder controller
returns a low temperature value if the temperature calculator gets an
interrupt as it's doing its count (I think). We really need to fix
this, then we could put the threshold back to a sensible value. But
more urgently we need to get all the firmware working with the latest
SDCC and put a buffer in for draw-a-line commands (in progress...).

The threshold problem doesn't manifest itself with polycaprolactone, as
that doesn't much care what temp it's at as long as it's warm. HDPE is
a different matter, of course. If you put the threshold back high,
then the temp bug causes the machine to return to it's heating-up spot
all the time unnecessarily.

A work round for the work round :-( would be to make the threshold
function take a majority vote amongst it's last three (or five, or
w.e.) temperatures.

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

Adrian Bowyer wrote:
> The lower threshold is a workround for a bug. The extruder controller
> returns a low temperature value if the temperature calculator gets an
> interrupt as it's doing its count (I think). We really need to fix
> this, then we could put the threshold back to a sensible value. But
> more urgently we need to get all the firmware working with the latest
> SDCC and put a buffer in for draw-a-line commands (in progress...).
>
> The threshold problem doesn't manifest itself with polycaprolactone, as
> that doesn't much care what temp it's at as long as it's warm. HDPE is
> a different matter, of course. If you put the threshold back high,
> then the temp bug causes the machine to return to it's heating-up spot
> all the time unnecessarily.
>
> A work round for the work round :-( would be to make the threshold
> function take a majority vote amongst it's last three (or five, or
> w.e.) temperatures.
>


The fix I thought I made (but perhaps I just thought about), was to have
a global variable that is set to false when a temperature sample is
about to be taken. Whenever an interrupt occurs, set the variable to
true in the main interrupt handler. If at the end of a temperature
sample that variable is set to true, then just disregard the sample
entirely. Another sample will happen pretty much immediately so there
is very little lost. This would only be a problem if there was a
constant barrage of interrupts, but I don't think it can really happen
that fast for a sustained period. It's very simple and should entirely
fix the interrupt problem.

A similar problem can also occur due to sample aliasing. Optimising the
capacitor size and timer settings for the thermistor significantly
reduces this problem. The problem should also be less significant at
higher temperatures. As soon as I have have my new extruder going with
the "official" new thermistor, I'll re-optimise everything for it.
There is also a little more work that can be done in the autoranging to
improve the resolution and decrease jitters.

_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]

Quoting Simon McAuliffe :

> The fix I thought I made (but perhaps I just thought about), was to have
> a global variable that is set to false when a temperature sample is
> about to be taken. Whenever an interrupt occurs, set the variable to
> true in the main interrupt handler. If at the end of a temperature
> sample that variable is set to true, then just disregard the sample
> entirely. Another sample will happen pretty much immediately so there
> is very little lost. This would only be a problem if there was a
> constant barrage of interrupts, but I don't think it can really happen
> that fast for a sustained period. It's very simple and should entirely
> fix the interrupt problem.

Yes - I remember our discussing that ages ago, but I don't think we
actually did it.

The 16F648A code under the latest SDCC very nearly works completely.
All the comms is fine, but there is a small bug that causes one of the
X or Y motors to lock up after it's been homed. There must be a
pattern to it, and the non-locked motor continues to work fine, but I
can't quite figure it out yet.

When this all works as well as the trunk code, I propose we make it the
trunk. Then I'll start to make the mods we've discussed (including the
temp fix).

Best wishes

Adrian

Dr Adrian Bowyer
[staff.bath.ac.uk]
[reprap.org]
_______________________________________________
Developers mailing list
Developers@reprap.org
[reprap.org]