Calibrating endstops with GCodes

Took a look under the bottom and fixed the bearings holding the X stage straight. Seems more stable now.

Time to find out why running a simple program crashed the Y stage into the end.

Trying G28 commands to home moved X and Y in the wrong directions. Trying to move G01 X10 just gave a loud noise of futile attempt at moving --was that why the X stage could run so much faster, it wasn't properly held. Must recalibrate X speed - max is 2000, not that different. So why did it object? Let's run back and forth at high speed for a bit... seems to be quite happy, except at 1950 it gives a crunchy sound when turning. Since the others are slower, I'll just keep this at 1800.

Doing G28 and G01 F300 G01 {X/Y/Z} NNN to figure out why it's homing like it is. Turns out I had the direction bits exactly reversed, since it apparently likes to home to max. Not sure why, but with inverted X and Y it homes appropriately.

Looking at the generated GCode from ReplicatorG. They use GCodes that are not defined on either Wikipedia or the RepRap.org wiki, and get some basic facts wrong like the maximum feedrate. Editing the slicing profile to fix this (setting rapidMoveFeedRateXY to 1200, zMaxHoming to true, all extrusionProfiles to feedrate 1200). It's problematic that every layer of the system has its own slightly incompatible way of designating which direction to go.

Frustrating. I can run individual GCode commands and the manual control fine, but trying to run the generated GCode, and it just seems to do weird random things. Hate!

Also, every 5th or so Y move is stuck. Again no idea why.

Tried G161/G162 from the Arduino serial console, and got homing to work. That way lies a lack of madness. I should test each command that the GCode creator makes and get them to work independently, before trying to run them together.