I am tracking a bug in the Marlin source code.
Just for those who is not familiar with Reprap 3D printer and G-code: Marlin is firmware that controls a RepRap 3D printer. It receives G-code from a host computer (or read from SD card). Here the important thing is that if you send the "M114" command, it would report information about axis positions. Here, I extended this command to make it print some internal variable as well.
In Marlin.ino file there is a line that says:
volatile int extrudemultiply=100; //100->1 200->2
However my RepRap keeps extruding (and worse, ejecting back) a huge amount of filament. So I added some debug output for
M114 command to output this value. It turns out this value is not the default value, 100, but something like 12374.
I thought somewhere inside the
setup() function this value might be changed. So I defined another variable,
volatile int orig_extrudemultiply = 100;
And then at the first line of
setup() function, I added the following line.
orig_extrudemultiply = extrudemultiply;
Finally, I output this value for the
M114 command. Still, it is not 100. So it looks like the default value is not effective.
Although I have experience in C programming, I am new to Arduino development. How is a global variable being initialized in Arduino? In my case, what is the proper way to initialize this value?
I originally posted the official Marlin link for the reference. However, the version I actually use is this fork from the RepRap Pro team. I was just following the Melzi entry of the RepRap wiki, because my board is Melzi. I am not sure whether the latest version of Marlin works for my board.
As the commenter said, the first thing I thought of was memory corruption. So I wanted to narrow the problem down. Since that value is configurable through
M302 SXXX command, I tested this command, and it works without difficulty. This means there is nothing in the
loop function or the ISRs can affect this value when it is running stably. So I consider the problem must be in the
setup function or earlier.
Further tests shows that setting this value at the end of
setup or even at the beginning of
setup still works fine. This means the
setup function may not be the problematic one. The test in "The Problem" session was the last step, which, in my opinion, means the course of the problem must being run before entering
Further examination shows that although it looks like it works when I set the default value in the first line of
setup(), but that it is just luckily being 100. So once I add more padding variables it stops working until I move the default setting after the following line in
EEPROM_RetrieveSettings(); // Loads data from EEPROM if available
However, since I
extrudemultiply before any test, and I didn't figure out this function, this function should not change this value. I guess there is some data overflow inside this function, so the value was changed expectationally.
I got to figure out what is wrong in this function.