Extruder _code_update?

Hi All,

I now have a functioning darwin extruder and extruder control board.
I am seeing the eratic values that were reported by others going back to july.
There were various fixes discussed that involved adding flags and discarding measurments that were corrupted by interupts. The only release of the firmware I have found is the zip file dated July 20 07 on sourceforge. Can some one either send me an updated binary, point me to the patched sources or the patches? This seems like a prime candidate for a new sourceforge release.

Best,
Dan

i pinged adrian about it... hopefully we'll hear back soon.

The extruder temperature measurement bug is now (almost) eliminated. I spent the weekend working on the code and have improved both the Java end and the PIC C end. (I have updated both in the trunk and also updated Simon's autoconf-firmware branch).

Here's a summary of what I've done:

JAVA:

The Java now takes a majority vote between the last three temperature measurements; this reduces the impact of isolated dud measurements (the temperature can never really change very fast, because of thermal inertia).

PIC C:

The PIC C code now detects when the capacitor charge/discharge timings are interrupted and discards such measurements, only keeping clean ones. Unfortunately, with largish capacitors, the measurements are always interrupted because of the times taken to charge and discharge, so this means reducing the capacitor otherwise one never gets a reading... For the standard thermistor (beta = 3480; Rz = 29K) this means a capacitor of 10nF. I have modified the calculator at [reprap.org]
to put in a fudge factor to give this and have changed the extruder controller PCB wiki page to say this, but more thought there is needed.

I have reduced the frequency of the heater PWM interrupts by reducing the value of HEATER_PWM_PERIOD from 255 to 253 'to calm things down'.

I have set the main loop so that it doesn't call the temperature measuring function each time round, as that used to mean that the PIC spent all its time in that function, making large the probability that it would be interrupted and cause trouble*. The heater pwm function now sets a flag, and the temperature measurement function just gets called once after that flag is set. (Having the function instead called as a result of the heater pwm interrupt would cause further trouble, I suspect, so I didn't do that, even though it's more obvious.) This means that the extruder PIC spends most of its time spinning in its main loop waiting for something to happen.

*Actually this is a statistically spurious argument: if interrupts occur in a Poisson distribution (which they don't, but never mind) then the function is just as likely to be interrupted, but any given interrupt is less likely to interrupt it. As it is, interrupts are quasi-regular, which has the same effect. But anyway it seems to work better...

RESULTS:

All this seems to make the temperature readings a lot more stable. But you still get the occasional dud. I suspect that this is a timing issue between my majority-of-three vote in the Java and the interrupt rate in the PIC. The Java is taking its readings too rapidly - more experiments will be done...

The much-reduced capacitor value means that the temperature auto-ranging runs vRefFactor up to 15, where it more-or-less stays. This is probably a bad thing - more experiments will be done...

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

hi adrian,

the java-chances are nice and working.
the pic code is not working for me. after destroying the last thermistor I have only one with 30K.

but I have been working on a similar rewrite of the temperature measurement during my serial-communication rewrite, and this is now working.

I have synchronized the messages from the main-loop, the forwarding-messages and the interrupt-messages. after a lot of troubles with the sdcc I have finished it.

from within the interrupt-messages you must call sendMessageISR(), sendDataByteISR() and endMessageISR(). sendMessageISR() returns 0 if sending is not possible (because of blocking). I changed the code of the devices so that the messages are sent later.

please try it and give me a feedback if it is working.

best wishes
andreas

Edited 1 time(s). Last edit at 09/23/2007 05:17PM by andreas.

Thanks Andreas.

I have to go to a conference tomorrow, and term starts next week, so things are getting a bit hectic here. I'll try to test your code at the weekend.

---

best wishes

Adrian

[reprap.org]
[reprapltd.com]

Hi Adrian,

have a nice conference, and next weekend you can test the new version which I attach here. I found some problems with the error-handling, which occured during startup with the java-software in the case when the extruder has not been connected.

bye
andreas

Edited 1 time(s). Last edit at 09/24/2007 03:13PM by andreas.

sorry, I had still the same startup (of the stepper-excerciser) problem with the last version, I improved the error-handling again, so please try this version.

emf has tested the version v3, this version didn't work for him. I have removed some debugging statements before making the tgz-file. I think a have been hit by the sdcc bug again
I will test it at the weekend and build a new version (I am not at home now), until than you can try the version v2. it should work for testing the extruder, if you only have connected the extruder.
it should also work for the rest, if you first switch on the boards, then send same poke commands and than start the host software.

andreas

I have testet version v3 again, it is working for me. but I have improved the detection of serial-errors again. so please try version v4.

best
andreas

Edited 1 time(s). Last edit at 10/02/2007 07:40AM by andreas.

hi,

finally here is the version which is working for me and emf (see topic: "Extruder temperature woes"). I had to change the order of the initialization to prevent an endless call of interrupts at startup before the interrupts are disabled (it shouldn't happen, because all interrupts should be disabled at startup by default, but that seems not to be the case).

best
andreas

nice! you should email adrian. this stuff should definitely get put into the subversion repository. if you want, we can probably even get you access to commit directly, but obviously i'd have to run it past the team first.

yes, I think its time to put it into the repository. I will email simon.