Glad to hear you got it working!
I added my config-override.g to the same folder on Drive. It only includes the results of the PID autotuning so nothing very interesting.
I see your other problem was already answered in the other thread, you just need to set some tool as active. I have it in my Slic3r start code, but I guess it could just as well be in the end of config.g.
Ah, did see you responded so quickly. Yes that is how mine looked, therefore I will put it back in that same position like you have. The screw did bend the end stop, but it looked like it wasn't hitting before the issues. I will check it again as well.
When I hit move Z in plus it does move down towards the bottom and - moves it towards the hot end. Is that correct?
Yeah, that seems correct. I was only saying to verify that as that was my first problem with getting Z homing to work, I had it the wrong way around and somehow associated "+" with "up", without realizing that it's inverted since it's the bed that moves and not the hotend like on my Prusa i3.
E: Another thing worth noting is that the end stops will not work when you're manually controlling the printer.
So if you're physically at Z50, and tell the printer to do a relative move of Z-100, it will crash right through the endstop. Just something to keep in mind, I learned this the hard way.
Yeah, I have a Z endstop. There's a link to a picture of it in the previous post. The pic can be found in the same folder as as the config files as well.
Regarding your Z endstop, it seems that the microswitch has been bent out of position by the endstop screw on the bed platform.
The original mounting bracket is correct, but the switch itself is supposed to be flush with the PCB, see: https://drive.google.com/open?id=0B4QI9opJS9SbTUp3VE0tWHVSY1k
The first thing I'd do if I were you is to verify that the platform moves in the correct direction, pressing Z +0.1mm in the UI is supposed to move the build plate DOWN. If it doesn't, you need to change the Z motor direction in your config.g then try again.
If that works, I would suggest you take a copy of my homez.g and verify manually that it works as it should.
What I mean by manually is that you
E: I'm using the default 2 Z-motor setup, but it's a pain in the butt. Be glad you only have one, my Z axis gets all wonky as soon as I turn off the Z motors since one side will start sagging while the other will stay put. Probably the first upgrade I'll do is either a 1 Z-screw or 3 Z-screw modification. I kinda like the linear rod setup you have on yours, will consider something similar.
For anyone else stumbling upon this problem, you can get rid of the spamming by disabling acceleration control in Slic3r (that is, setting the acceleration control values to 0).
According to https://github.com/dc42/RepRapFirmware/issues/37 it seems that acceleration control is not strictly necessary with RRF to begin with, so I disabled it and decided to configure firmware pressure advance instead.
I'm using 1.34.1 release of the Prusa Slic3r, which is the latest stable release. There are some newer release candidates available though, I could try those.
I'm not sure I want to upgrade a beta firmware while I'm trying to commission a new printer though, do you happen to have any rough ETAs for a release candidate or a final release of 1.19?
I just assembled a DBot with a Duet Wifi and am in process of calibrating/tuning now.
I finally got the homing working on all axis, relevant configuration files here: https://drive.google.com/open?id=0B4QI9opJS9SbSldRZjQ5NUd0U2c
I hope those are of some help.
I'm getting a metric crap ton of pop ups in the Web UI saying "Maximum printing acceleration 10000.0, maximum travel acceleration 10000.0".
See here: https://drive.google.com/open?id=0B4QI9opJS9SbdUFzYl84YXJnXzQ
In the bency gcode that it's printing I can see that it's sending the M204 command only with the S parameter, and from checking the sources this isn't handled by RRF at all, instead it's treated as a query since no known parameters are found.
In the latest sources I see that a check for the S parameter with [c]platform.Emulating() == marlin[/c] has been added, but I take it that isn't released yet? Should I configure Slic3r somehow differently to get it to produce an output that the firmware understands?
Config.g and the gcode being printed here:
https://drive.google.com/open?id=0B4QI9opJS9SbSldRZjQ5NUd0U2c
