Marlin firmware fork for MakerFarm i3v w/ auto bed level & Roxy's enhancements

[AbuMaia]

Well, I solved the hypot problem. The /* -*- c++ -*- */ at the top of marlin_main got replaced by some other text somehow. I've restored it, now I get

Marlin_main.cpp: In function ‘void retract_z_probe()’:
Marlin_main.cpp:1100:13: error: ‘axis’ was not declared in this scope
if (axis==Z_AXIS)

That would be line 1091 in the zipped file. I'm stumped this time.

[ctcwhexdx]

Go into configuration.h around line 455 or so, do you have #define PROBE_SERVO_DEACTIVATION_DELAY 300 enabled, if so put a // in front of it and see if it compiles.

I just ran into the same thing.....

Well, I solved the hypot problem. The /* -*- c++ -*- */ at the top of marlin_main got replaced by some other text somehow. I've restored it, now I get
Marlin_main.cpp: In function ‘void retract_z_probe()’:
Marlin_main.cpp:1100:13: error: ‘axis’ was not declared in this scope
if (axis==Z_AXIS)

That would be line 1091 in the zipped file. I'm stumped this time.

[printbus]

...now I get

Marlin_main.cpp: In function ‘void retract_z_probe()’:
Marlin_main.cpp:1100:13: error: ‘axis’ was not declared in this scope
if (axis==Z_AXIS)

I don't have the code with the retract_z_probe function in it. BUT, looking at the number of other places in marlin_main.cpp that where similar code exists in the older version, I'll bet the 'void retract_z_probe()' should really be 'void retract_z_probe(int axis)'.

[Roxy]

I'll bet the 'void retract_z_probe()' should really be 'void retract_z_probe(int axis)'.

I don't remember retract_z_probe() ever having any arguments. I have a different theory. If you go find the declaration:

void retract_z_probe()

and then search for the first occurrence of

if (axis==Z_AXIS)

because that is what that error message:

Marlin_main.cpp:1100:13: error: ‘axis’ was not declared in this scope
if (axis==Z_AXIS)

is complaining about... You find this stuff just before the if (axis==Z_AXIS)


#ifndef Z_PROBE_SLED
engage_z_probe(); // Engage Z Servo endstop if available
#endif // Z_PROBE_SLED
run_z_probe();
float measured_z = current_position[Z_AXIS];
#ifndef Z_PROBE_SLED
if (retract_probe) {
do_blocking_move_to(current_position[X_AXIS], current_position[Y_AXIS],current_position[Z_AXIS]+Z_RAISE_BETWEEN_PROBINGS );
retract_z_probe();
}
#endif // Z_PROBE_SLED


I bet those Z_PROBE_SLED #ifdef problems are biting you!

[AbuMaia]

That section with the Z_PROBE_SLED is about 64 lines after the line throwing the error for me.

[printbus]

I don't remember retract_z_probe() ever having any arguments.

That was exactly my point. All of a sudden in the retract_z_probe function an attempt to use variable axis shows up and the compiler errors because it doesn't know what it is. It's evidently not a global, so it should be passed to retract_z_probe as an argument.

The number of ifdefs in the Marlin code is incredible.

[Roxy]

That was exactly my point. All of a sudden in the retract_z_probe function an attempt to use variable axis shows up and the compiler errors because it doesn't know what it is. It's evidently not a global, so it should be passed to retract_z_probe as an argument.

The number of ifdefs in the Marlin code is incredible.

So... I don't know... But my thinking is a little different. What happened is the compiler thought it was in the retract_z_probe() function. But it wasn't. It got out of sync with the code and it was missing a curly brace or a semicolon somewhere. It was reporting the error the best it could. Even though where the axis==Z_AXIS stuff was clearly outside and beyond the retract_z_probe() function to you and me... To the compiler it never closed out and finished doing the work for that function. It thought it was still in that function. So it reported that it found an error while compiling that function.

That function isn't that long, but its got all those #ifdef's in it. I don't know... My guess would be somehow those turned off a closing curly brace that was needed to close out the function and the compiler got confused.

But like I said... Short of actually seeing the code causing it to happen, and finding the fix, it is hard to say for sure. But that is kind of how my thought process works and where I would start.

Its kind of like when the compiler complains I'm missing a semicolon and tells me where it should be. If it knows where it should be, just put it there for me!!!!