Firmware freeze when moving z-axis

After some irritating bugs with the reprap software I decided to move to the newest version. So now i am running 20110207 on my gen3 electronics. I use skeinforge, so I disabled acceleration.

But when I home my Z-Axis the firmware freezes and I am left with no other option then to reset the firmware. After enabling acceleration, I can home my Z-axis. I guess this is a bug?

---

---

reprapworld.com
PLA, ABS, PETG multiple colors (3 and 1.75 mm) €16,49 / kg
Megatronics 3.0 €79.99 / Minitronics €37,19

After digging through the code, the problem seems to be in qEmpty() or the functions that fill the cdda array. When I comment out the following line in process_gcode the firmware no longer resets, but throws a fatal error, which is probably ok:

while(!qEmpty()) delay(WAITING_DELAY);

So my theory is that when the z is moving with no acceleration, qEmpty references an invalid cdda entry.

---

---

reprapworld.com
PLA, ABS, PETG multiple colors (3 and 1.75 mm) €16,49 / kg
Megatronics 3.0 €79.99 / Minitronics €37,19

Fixed it by replacing

#ifndef SLOW_Z_FEEDRATE
#define SLOW_Z_FEEDRATE 0.0
#endif

with

#ifndef SLOW_Z_FEEDRATE
#define SLOW_Z_FEEDRATE 20.0
#endif

in configuration.h, sort of. Probably a division by zero or something, when acceleration is off.

I have attached my current firmware

---

---

reprapworld.com
PLA, ABS, PETG multiple colors (3 and 1.75 mm) €16,49 / kg
Megatronics 3.0 €79.99 / Minitronics €37,19

brupje I could have your babies! Thanks for the upload!!

your welcome, my reprap is currently all the baby I need

---

---

reprapworld.com
PLA, ABS, PETG multiple colors (3 and 1.75 mm) €16,49 / kg
Megatronics 3.0 €79.99 / Minitronics €37,19

You are my hero.
The guys at the makerspace Tangleball, and myself have spent weeks trying to get the code working to a state that is reliable for calibration, I had been using firmware from 20100806, but encountered a serious bug that I know got fixed much later on, so upgraded it, and had a whole new set of problems, and I couldn't work out what the code was doing.

But here we are, and I get "Start", and no compile errors, yay.

We had tried to hack the code to get a compile without error, but just ended up with the same problem Adam.M.Nelson had, after boot, the electronics would keep outputting "ststststststst . . ." indefinitely.

We know it has to do with how the way the code was rewritten to "better" (lol) setup the electronics.
Someone forgot to do a basic QC check, and would have noticed the bug, prior to doing a release on sourceforge.

Anywho, not at Tangleball tonight, will go there and try out the new code.

Thanks so much.

I'm gonna have to ping Adrian again, so that he is aware of your work.

Grogyan Wrote:
-------------------------------------------------------
> We know it has to do with how the way the code was
> rewritten to "better" (lol) setup the
> electronics.



Understatement