triffid/fived_on_arduino

Rewrite of reprap mendel firmware

fived_on_arduino's Issues

Clash between stepper timer and serial communication

Recently I started to run larger GCode sections and have run several hundred lines successfully. The unfortunate truth is however, in some rare circumstances FiveD on Arduino drops steps. If the drops happen in the middle of a longer movement, you can hear these drops, as the sound coming from the stepper motors sounds a lot rougher than normal. Sometimes one axis even stops entirely for a second or two, just to continue the same movement as if nothing happened. Again, you can hear the difference easily and the pause in movement isn't a pause in the controller sending something to the stepper drivers.

Once I've found a sequence exposing the problem, I could repeat it reliably.

One part of the diagnosis is, if you send these GCode sequences line by line to the controller, everything runs fine.

To diagnose further, I was even brave enough to add some debug messages into dda_step(), below line 470:

if (dda->step_no % 100 == 0) {
    serwrite_uint32(dda->c);
    serial_writechar(' ');
}

With ACCELERATION_RAMPING turned on (to enable the used variables), this nicely outputs the current speed at a rate the serial channel can follow easily.

However, each time a number is sent, you hear a little knock from the stepper motors. Eventually, the controller (168' Arduino) hangs up entirely, it's LED flickers and the serial connection is no longer responsive. Pressing the reset button isn't sufficient, I have to power-cycle the thing to get it back to life.

My current conclusion is, steps get lost in a movement if serial communications is busy at the same time. These two timers don't work independently from each other, but get into each other's way.

Undoubtly, I'd like to reduce serial communication's interrupt priority, but how would one achieve that?

BTW., most movements run at about 4000 steps/second.

Store steps/mm in eeprom

it can be a bit cumbersome to rebuild the firmware when changing microstepping on the drivers, so it would be nice if the step/mm can be runtime adjusted. It doesn't need to be the actual steps/mm, but could a LUT or something similar.

Timing not entirely accurate

When testing new features I recognized acceleration is no longer accurate for higher speeds. It's difficult to describe, but ramping up is fine and at about 80% of the end speed, speed jumps to that end speed immediately. At lower speed this happens unnoticed, but at 600 mm/min, which translates to 3200 steps/s here, one can hear that well. Not sure wether this also involves step losses, but it also prevents me from maxing out my stepper motors.

Whatever, I tracked it down to this commit: http://github.com/triffid/FiveD_on_Arduino/commit/92eb4c97cae2b4773f86e6ba666dd4cb3af6ca19 , more precisely the timer reset in line 107 (file timer.c). If I comment out this single line in the current version, everything works well again.

Probably there's a reason why this code in timer.c was introduced, so I'm holding back from just reverting the commit. Please enlighten me :-)

STEPS_PER_MM_{X|Y|Z|E} should be more precise

Currently we use STEPS_PER_MM values to calculate the required number of steps from a given position. However, for half-stepping, belt-driven machines this is not precise enough. The correct value would be about 8.12 STEPS_PER_MM, bringing in an dimension error of about 15% when using the next integer (8).

My idea goes towards using STEPS_PER_M, so precision is increased by a factor of 1000. Didn't have a chance to view this in the light of numerical accuracy/overflow, however.

Problems compiling ...

Hi
Just been trying to compile your code and get the following errors (using make)

CC mendel.o
CC serial.o
CC dda.o
CC gcode.o
CC timer.o
CC clock.o
CC temp.o
CC sermsg.o
CC dda_queue.o
CC watchdog.o
CC debug.o
CC sersendf.o
LINK mendel.elf
OBJCOPY mendel.hex
OBJDUMP mendel.lst
SYM mendel.sym
0 [main] perl 1784 open_stackdumpfile: Dumping stack trace to perl.exe.stackdump
SIZE Atmega168 Atmega328p
bin/sh: objdump: command not found
0 [main] perl 4012 open_stackdumpfile: Dumping stack trace to perl.exe.stackdump
ake: *** [size] Error 5

Stackdump gives

MSYS-1.0.12 Build:2010-02-05 01:08
Exception: STATUS_ACCESS_VIOLATION at eip=68008DAA
eax=300A5360 ebx=305926EC ecx=00020CCC edx=00000770 esi=00000000 edi=305900D4
ebp=0023FED0 esp=0023FEAC program=d:\Program Files\Git\bin\perl.exe
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame Function Args
0023FED0 68008DAA (305900D4, 00000770, 00000003, 680044EA)
0023FF20 6800466B (00003F6F, 805584A0, 0023FF60, 00401EF0)
0023FF40 68004C5F (00401068, 30064AD1, 00E7A5E8, 89E7A570)
0023FF60 68004C98 (00000000, 00000000, 80544EDC, 00000000)
0023FF90 00401DB8 (00401068, 00000001, 00000006, B20EAD04)
0023FFC0 0040103D (30064AD1, 300A92EC, 7FFDE000, 80544C7D)
0023FFF0 7C817077 (00401000, 00000000, 78746341, 00000020)
End of stack trace

Any ideas as to why this is happening?

Help geatly appreciated as your code looks cool.

Bodgeit

SD card and fat16 support

I love being able to start a build on my makerbot and unplug the computer to do something else. Being able to use SD on a 328 or bigger would rock!

Firmware should check behaviour of heated elements for plausibility

This is a feature request.

Temperature sensors becoming loose might result in a situation where the temperature readout of one of the heaters becomes unrelated to the actual temperature of the heated element. Likely, the heater would turn on and never again turn off, regardless how hot the heated element is. Actually, this can cause an unattended machine to melt down or even catch fire.

A plausibility check would watch the temperature rising as the heater is switched on, and switch it off in case there's no, or no sufficient rise in temperature.

Optimize heating algorithms automatically

In conjunction with http://github.com/triffid/FiveD_on_Arduino/issues#issue/5 , FiveD on Arduino could observe behaviour of the heating elements, calculate optimized parameters for the regulating algorithm and use that.

"set bed temperature" and "echo off" (DEBUG) have the same M-code

Firmware won't compile if DEBUG is defined