Only getting motion in negative coordinates

Searching the interwebs suggests that single direction movement is a limit switch wiring issue(or damaged switches). The reports in Repetier's UI seem to encorage that interpretation.

Can someone post a good picture of how the limit switches are plugged into the ramps board of their correctly working robo? (and yes, I realize that there is a design issue that makes flipping the robo3d a pain for z calibration as the x carriage flops off the bolts, so be careful!)

Thanks.

 

And yes, I know you need to home the machine before it moves at all. That's all negative motion and works just fine. Once there, it's pretty much stuck.

 

Ok, I am checking out 2 printers for someone else (mine has not yet shipped, though it definitely should have, since I am i n the may batch and these are june batch printers, yes, I have fired off a very angry email or 4)

Decreasing Z makes the head descend.
Decreasing X makes the head move left
Decreasing Y makes the bed move backward

You can continue to decrease Y until it forcably slams into the limit switch and keeps trying to move.

Any attempts to manually increase X,Y or Z gives a mechanical shudder like a bind up and then it stops. The log reports endstop hits, however those directions do not have endstops.

Needless to say, I'm pretty frustrated.

I would review the wiring video, but it doesn't exist. I assume it is the video marked private. And clearly, we can guess why, huh?

I guess I should check out the repetier wiring guide, since it is basically the same thing.

 

Ok, I have confirmed that the wiring is right, the endstops on the device are right.

And the firmware is looking for positive endstops as well as negative endstops. Since they don't exist, it seems the default state is floating and thus undeterminent. I have confirmed this with the X-axis by connecting the signal pin to ground for the X+ endstop. I just need to find a bunch of jumpers to fully test.

Unfortunately, Repetier's manual mode seems happy to drive the bloody thing past its known maximum for the printer (which is obviously bad).

I suspect I shall have to track down a firmware to reflash my taurino with that knows to ignore the positive endstops (since they do not exist), and plan on installing a few positive endstops (at least for the X, because that is a nasty hit) Good thing I have a bunch of endstops I can drop in as needed. I shudder to think what an unrestrained positive Z seek would do.

I'll see if I can find a few jumpers or jumper wires with female ends to confirm, but seems likely.

Then I get to recalibrate Z. Goodness knows I had to do that anyways, since it showed up out by quite a significant margin, even tho it should be near perfect.

 

Ok, confirmed. I have use of all 3 axis now that I have jumpered all 3 positive endstops to ground (2 years of learning arduino programming have actually paid off! )

Obviously both printers have a firmware that should definitely not be loaded on them. On to that battle. Since I want to convert my personal 3d printer with a Viki that has been sitting here forever, that was an effort I expected to undertake anyways)

Oh, and the fun of a full Z recalibration. yay?

 

Ya know what, it may well be I was hitting the park button instead of the home button, because when I yank out the fake end stops and reboot, the numbers are red, I get the end stop errors, hit the actual home button, I get black and it works.

Wow, is that ever a massive failure for either the firmware or the repetier host to not insist on a home command.

Interesting that it can move negative in that condition.

Thanks. That was frustrating as hell. Aaaaand I even read the manual wrong. Crap, I feel like a moron. Ok, let's chalk this one up in the FAQ as a "press the home button" when it gets seen.

geeze, I feel like a fool. Live and learn I guess. And I definitely have gotten a crash course in the wiring.

Thanks for the help.

 

Reporting end switch errors for switches it presumably knows does not exist because it knows it was not homed should probably be reported as "home required" instead of end stop errors. Since there is room for the VIKI firmware, I would think this little bit of logic and bit of text (which can be stored in the code section) shouldn't be an insane expectation.

But if I can find the firmware source Robo is using (and hopefully can support the VIKI), I will know for sure.