@deckingman:

I could be wrong but seem to recall I had something similar a while back which turned out to be a dodgy file name. Maybe it's the apostrophe that DWC doesn't like? In my case, renaming the files fixed the problem but it was a long time ago so I can't be sure that my issue was the same as yours.

Would that cause the problem for the whole directory?

"testcube_20mm.gcode" is doing the same thing.

If so, do I need to put the SD card into a reader and manually delete?

EDIT: HAHA! You fixed it! Thanks so much!

Printed successfully, attempted to upload another file, it uploads and I hit OK, then the gcodes directory comes back looking like this -

http://i.imgur.com/Vx0cNL7.jpg

Tried m999, tried powering off for several minutes, tried reseating the sd card with power off, tried reinstalling the main firmware.

I can still upload files (Which do the same thing and can't be deleted.) and create new directories (Which I can delete.)

If I mouse over the gcode directory piece of the page my mouse cursor switches over to a busy spinner.

So I guess my question is "What the heck?!?!"

@3dprinting:

can you program the z offset in config.g? That's what I do. I've never used the g92 zo. or is that because you have multiple tools? that also wouldn't make sense, because if they were at different z heights, one would crash while using the other.

Well I was using that for first layer adjustment. Just fast. But that happens after the g28, which is the command that is failing to play out correctly when attempting to print, and starting the snowball so to speak.

@3dprinting:

slic3r has start g codes, gotta make sure G29 is in there after G28. In slic3r, it's under printer, custom g code.

Not all printers have auto leveling so by default, it doesn't include it in start g code.

You can also enter G29 S1 to make it load your saved height map without probing again, this would come after the G28 as well

Yeah in both Slic3r and S3d I have this as the start code -

G28; Home all axes
G29; Start ABL
G92 Z0; ABL offset in mm (This isn't set yet)

But when a print starts the g28 homes x and y and then goes straight down without the tool offset. It's completely weird.

So I'm about 90% certain that this is a slicing problem.

If I'm in the web interface and send a g28, everything is perfect. Goes right to the front left corner drops until Z triggers. If I follow that up with a g29, it proceeds to probe the entire bed, no issues there.

Now, if I pull up simplify3d and slice a model (In this case a 20x20mm cube, it homes X and Y and starts dropping the Z without moving first to the tool offset of x45,y15 so it attempts to drop into empty space.

So I attempted to see if the g29 would happen after that point by artificially triggering the Z probe (Holding a metal ruler under it flat against the bed but sticking out enough to trigger the probe) the probe stops at that level, rolls over to the first probe point, then throws a "Error: Z probe was not triggered during probing move" and attempts to just shoot over and start printing willy nilly.

This has to be a slicer issue right? I mean sending the codes manually in sequence acts exactly like it's supposed to.

This happens both in Slic3r and Simplify3d.

@James:

@windiesel mentions the motors being loud when standing still. I just started a thread about that earlier today. It appears that I am not alone here. I bought new motors and have not tested them yet, but I'd be curious to know if anyone else is experiencing this, and if so, with what motors and what current settings, so we can see if there is a common cause.

Yeah my motors are doing that, too. Kysan 1124090.

Okay I think I have it now. My Y was reversed and my home files were sending the Y axis + rather than _ to go toward the endstop.

Thanks so much. I really appreciate it.

My ignorance is showing.

First, is there any functional difference between changing the S variable in M569 and flipping wires?

Next, my X and Y are printing in reverse, so if I have a cube with Front, Back, Left, Right, written on the appropriate sides, when it prints, the text is all backwards on both the X and Y.

Ideally I could reverse the motor directions with M569, and change *Some Setting That May Not Exist Or I Am Not Aware Of" so that I don't have to physically move my endstop switches.

Is this a thing, or am I forced to make motion platform changes?

I have another issue but I'll save it because my brain has a slow leak and I need to make baby steps. Thank much.

Wanna say thanks again and show my work - http://imgur.com/a/jtS2V

Okay switching it to the correct diode did the trick! Thanks so much for the help!