I am tracking a bug in the Marlin source code.
Background
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.
The Problem
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.
The Question
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?
Versioning
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.
Further details
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 setup
.
UPDATE
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 setup()
:
EEPROM_RetrieveSettings(); // Loads data from EEPROM if available
However, since I grep
ed for 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.
extrudemultiply
has changed Dec 3rd 2012! I suggest you update to a more recent version.