Custom 3D printer firmware/g code issues

Hi all, I have not posted to this form in quite a while so please forgive me if this subject is off topic. I am just finishing off a neglected project (4 years!) . I am making a 3D printer from a Shapeoko kit I was given in a drawing. This is a low budget affair utilizing custom made parts and import quality when prudent (Ramps 1.4 Arduino Mega Pololu Shield and J-Head hot end). For firmware I am using Marlin V1.1.0-RC8. For software Repetier-Host V1.62 and Slic3r V1.2.9.

However I have a proble. The printer appears to work fairly well in Repetier manual mode. The print head moves as I expect e.g. origin at front left, X positive right, Y positive is back, Z positive is up. But after slicing and trying to print the Y axis appears to be reversed. The print head homes and then either moves erratically or the print is killed. I believe this is because the Slicer G Code “flavor: RepRap(Marlin/Sprinter/Repetier)” is for printers with moving platforms in the Y axis where my printer the print head moves in the Y axis.

I do not want to invert my Y axis direction if I can find another solution. Slic3r has several other G Code “flavors” but I am not familure enough with those to guess which one may be compatible with my firmware. What am I overlooking, any suggestions?

If your print head movement is as you describe, you are using a right hand coordinate system, which is what all slicers that I know of expect. So I don't understand why your prints come out mirrored.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

In Repetier I place my part away from the origin but the print head never moves far from the origin after homing. My thinking is that the slice3r is trying to move the platform in the y direction forward where I want to move the print head backwards. Thus the end stop is reached and the print killed. Although in some instances the print head does manage to move back some allowing a print of sorts, usually with the end stop being ignored and the head/carriage bouncing agents a hard stop. My test print is a rectangle for calibration so I do not know if it is mirrored.

It sounds to me that slic3r hasn't been configured to know the dimensions of the bed. But I don't use Repetier, so I don't know how it configures slic3r and I am unable to help.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Problem solved I hope. It turns out my firmware was not saving settings in EEPROM. Thus ever reset the firmware was going back to the default setting that were too fast for my hardware. After looking at the g code I found all my previous assumptions were all wrong!