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.

Where did all my movement go? ... Wheeee!

Starting again from the cliffhanger last time: Why, suddenly, does nothing move? What bone-headed mistake did I do this time?

Unplugged all but the Extruder stage from the Arduino (that one can't hit an endstop). When connecting ground to the correct pins, it stutters, when not connected to ground it does nothing.

The stepper output shows a regular 90 mV on the stepper pin and the direction pin switching between 0 and 5 V. The 90mV may just be the meter sampling a rapidly changing value, since the stepper pin goes up for each step, then down.

Wasn't the high speed I had set it to (unless I have burned out the motor). It just blinks once when getting power, then the stepper lights go out.

Main power looks good -- slightly low on 12V, only 11,3V.

Tried on the Y stage. Putting ground on pins 8, 9, 10 does nothing, but pin 2 works. Re-checking the diagram, yes indeed, pins 8-10 are reserved, not ground. Which means I probably need to remake my shield. I bet they printed them just now:)

That means I need to have a common ground bar rather than chaining them like I'd been doing (I don't know why that worked, obviously it doesn't now). X and Z agree. The extruder is a different beastie, so I shall leave it alone for now and do speed tests on X, Y, and Z.

Noticed that the speed variable was highlighted like a keyword, so I renamed that, no effect. Comparing with a working program, I noticed the setCurrentPosition being called in init. Remove that -- and it works. Testing Y speed now. Speed 100 is quite slow. Changing initial speed to 300, then 800.

Y stage is happy up to 1400 mm/minute == 23 mm/second. For safety, let's say 20 mm/second.
X stage goes all the way up to 1950 mm/minute == 32 mm/second. For safety, let's say 30 mm/second.
Z stage goes to 1800 mm/minute == 30 mm/second. Calling that 25 mm/second.
Ex also works no, up to an amazing 2350 mm/minue == 39 mm/second. Call that 35 mm/second.

They also all run together, very good. Temperature test also works once it's been all wired up. Now for the real firmware setup.

Seems to ignore my changes, giving an error on Z_MAX_PIN even after I comment it out. Turns out the Arduino software doesn't reload from symlinks when the base file is changed. Restarting it helped.

When generating GCode, I set feedrate and travel feedrate to 20 mm/s.

Trying to build still gives me errors, though:

• Homing in the wrong direction for selected machine: 'G162 X Y F2500 (home XY axes maximum'
• Homing in the wrong direction for selected machine: 'G162 X Y F2500'
• You're moving too fast! G1 X-0.0 Y-8.9 Z1.7 F1080.0 E146.57 turns at least one axis faster than it's max speed.
• You're moving too fast! G1 X-0.0 Y-8.9 Z10.88 F1200.0 E790.555 turns at least one axis faster than it's max speed.
• You're moving too fast! G1 X-0.0 Y-8.9 Z11.42 F1200.0 E887.258 turns at least one axis faster than it's max speed.
  ... and many more 

This is curious. G162 doesn't even exist in several of the GCode specs, and the feed rates for G1 should be well within the limits. Trying with 15 mm/s feedrate. Crawl, crawl, crawl... even that is too fast. Trying with 9 (i.e. 540 mm/minute), which is below the search feed rate. I have the Teacup set to the following: 

/// used for G0 rapid moves and as a cap for all other feedrates

#define MAXIMUM_FEEDRATE_X 1800 // 226

#define MAXIMUM_FEEDRATE_Y 1200 // 226

#define MAXIMUM_FEEDRATE_Z 1500 // 226

#define MAXIMUM_FEEDRATE_E 2100

/// used when searching endstops and as default feedrate

#define SEARCH_FEEDRATE_X 600

#define SEARCH_FEEDRATE_Y 600

#define SEARCH_FEEDRATE_Z 600

// no SEARCH_FEEDRATE_E, as E can't be searched

But the real culprit is the ReplicatorG machine definition in /Applications/ReplicatorG.app/Contents/Resources/machines/reprap.xml, which set a max feedrate of 500. Just below what I stopped at:)

With this fixed, the only errors I get are

• Homing in the wrong direction for selected machine: 'G162 X Y F2500 (home XY axes maximum'
• Homing in the wrong direction for selected machine: 'G162 X Y F2500'
• You're moving too fast! G1 X105.0 Y-70.0 Z10.0 F3300.0 (move to waiting position) turns at least one axis faster than it's max speed.
• You're moving too fast! G162 X Y F2500 (home XY axes maximum turns at least one axis faster than it's max speed.
• You're moving too fast! G162 X Y F2500 turns at least one axis faster than it's max speed. 

Fixed these instructions in the generated GCode (except for homing in the wrong direction, which I'm not sure of). Running it sounded like a helicopter warming up! After apparent attempts at homing the Z axis with no effect, the X and Y axis moved at steadily increasing speeds -- Y towards 0, X away from 0. Y crashed into the endstop, while I stopped X before it could get away. Not a perfect success, but it's the first semblance of control from ReplicatorG, so it's a success after all.

From the control panel, I see all stages turning, and the heater heating and being measured. So it's all good.

Calibrating is hard. Let's do math.

Wanted to calibrate the speed of the motors, since the ReplicatorG setting had a much larger speed than we seemed to support. So I made a nice little state machine that first moved a bit away, then moved to the min endstop, then a larger bit away, then back and forth with increasing speed. I tested it during development with the X stage, improving it over a couple iterations until I noticed I was reading from the wrong endstop. Fixing that, everything stopped moving. No response whatsover from any of the motors regardless of program. I still hear back from the Arduino, but no reaction otherwise. Odd, but time to go now.