Unresolved limit switch in +x direction

Unless the X axis has been "homed" the firmware does not know exactly where the extruder is. There is no maximum limit switch on the right side.

I tested my Robo and even if it has been homed, I can manually move the extruder over too far to the right. I would have thought the firmware would know the width of the bed (it certainly does) and stop any movement past the actual width - but it does not.

Looks like a design "feature" - I'll have a closer look at the firmware to see why.

 

After checking the firmware...

There is a "software endstop" for all axes (defined in configuration.h). I can also see in the Marlin G1 gcode handling that the software endstop is checked and the axes will NOT be moved past the software endstop.

So it appears the X_MAX_POS of 240 is too big.


#define max_software_endstops true // If true, axis won't move to coordinates greater than the defined lengths below.

// Travel limits after homing
#define X_MAX_POS 240
#define X_MIN_POS 0
#define Y_MAX_POS 254
#define Y_MIN_POS 0
#define Z_MAX_POS 240
#define Z_MIN_POS 0



Haven't got the time to reflash and test right now. I'll get back to it.

 

Good pickup Bill

I have updated and reflashed my firmware with the following software endstop parameters. The figures after the // are the original values. Obviously no one has ever actually checked these. Depending you might get the Z a little higher than mine (maybe up to ~ 140)


// Travel limits after homing
#define X_MAX_POS 212 // 240
#define X_MIN_POS 0
#define Y_MAX_POS 260 //254
#define Y_MIN_POS 0
#define Z_MAX_POS 120 // 240
#define Z_MIN_POS 0

After changing the values - no more crashing and crunching outside the x, y or z max hardware limits. Provided you have homed first of course.

 

Bill,

The more I look at this the more complex it becomes...

If you use

G28 X0 Y0 then move the extruder off the endstops, the firmware remembers where the extruder is even after the 60 second timeout. The software endstops will still prevent the extruder going beyond the maximums. But the fact that the X and Y were homed appears to be lost.

G28 (no parameters) then after the X and Y are homed the extruder moves to the centre of the bed and probes for Z home. Once this is done the firmware then thinks the middle of the bed is X = 0 and Y = 0!!! Obviously it is then possible to crash the extruder off the bed because the firmware starts keeping track of the X and Y moves from the centre of the bed not the endstops. Also auto leveling forgets the X and Y were homed after the 60 seconds timeout.​

In my opinion all of this complexity and strange behaviour has been created when Marlin introduced auto bed leveling and the idea of Z probes with no actual Z physical endstop. On top of that the idea of "safe Z homing" was also added into Marlin.

End result is a kludge of firmware code full of inconsistencies and strange behaviour - they are bugs really. But the code is now so complex I don't think anyone is willing to try to fix the logic. Touch one part of the code and risk unintended consequences elsewhere.

 

Bill,

TBH If your current firmware is all working just fine I would not update firmware just to prevent the odd problem extending past the max x or y.

But if you want to go ahead, download the correct firmware for your Robo model from

http://help.robo3dprinter.com/Wiki/RoBo_3D_Firmware

On this site there are also instructions for compiling and uploading firmware to your Robo.

To make the changes, find the file "configuration.h" in the firmware package. Open with a text editor (eg wordpad) find the following parameters, change them then recompile and upload.

// Travel limits after homing
#define X_MAX_POS 212 // 240
#define X_MIN_POS 0
#define Y_MAX_POS 260 //254
#define Y_MIN_POS 0
#define Z_MAX_POS 120 // 240
#define Z_MIN_POS 0

Once you have done the recompile/upload thing once it's very easy the next time.