Stop switch on z rod wire unattached

I received my printer today and it seems that one of the wires on the left threaded rod is disconnected.

I don't know much about these sorts of things, but could this be the cause of the following problem:

When the printer moves around (including when it goes 'home'), it will crash into the print bed and the threaded rod nuts will come out of their carriage. I have a feeling that since the one wire is disconnected, the print head doesn't know when it has made contact with the bed.

Is this what is happening?

How do I fix this?

Please see attached photo:

 

If you're up to soldering you just need to solder the wire back on.

Otherwise submit a replacement part request here: http://www.robo3dprinter.com/pages/replacement-part-request

 

I got my local computer store to solder the wire.

I turned it back on homed the unit, the head hit into the bed again and came off the carriage. The carriage started to spin and ripped the other wire. . . So does that mean the little sensor thing isn't working?

 

Possibly. What firmware does it say you are running?

If you send M119 in terminal what's the response. Make sure nothing is homed.

 

How do I check these two items?

Thanks!
-Dave

 

You're using MatterControl?

Control Page > Firmware Updates

it will say here what your firmware is

for terminal:
Configuration > Show Terminal > Check filter output

Also please try giving this stuff a search. I've typed this out probably 50 times by now and it's starting to wear on me.

 

Firmware:
Robo3dR1AutoV4

Terminal:
Reporting endstop status
x min: open
v minpen
z minpen

If I lift up the print head, on both sides at once, it says z min: triggered

So that seems to be working right? But then why does it allow the print head to be disengaged completely from the carriage/nuts when the print head hits the bed? (thus allowing the nuts to go 'nuts' and spin around and break wires)

Thanks for all the help so far by the way!

 

The switches should work unique from one another. If you lift one side of the carriage, so one switch is activated, and send the m119 you'll be able to tell if one side is bad or not. Do this for both sides.

It seems to be working, yes. Not sure why you're getting thrown out. Do you have a hexagon hot end with a cooling fan (not the parts fan) or a black body j-head? Might be worth trying a reflash.


As for homing, let's try this. Raise your carriage up a lot and then tell it to home. While it's homing get in front of your printer and manually stop the carriage as if it was on the bed. Watch what happens to the nuts. If they don't stop after you hear the switches click off drop the carriage back down and hit the power switch in the back and reload MC.

 

Update:

Before your last message Mike, I did some tinkering.

First, I noticed that the nuts only get thrown out during a print, not during homing. When I clicked home, the printer head didn't want to go past the bed. So the switchs were working. (well the one that had both wires still attached anyways)

Second, I noticed that the problem only happened when I started a print.

Third, I loaded up Cura and actually sort of got it to print the test cube (well a few layers of it, until something happened with the filament). Cura never caused the nuts to get thrown out of their carriage. It, too, seemed to be getting the signal from the switches.

So I think it is a calibration/MatterControl issue. I know that I've never been able to get the calibration to work quite right in MatterControl (it stops before allowing me to do the third point with the paper test) so that's probably what's going on.

Since fiddling more in MatterControl after semi success in Cura, I've ripped off three of the four wires.

I won't have much time in the next week to do anything, but does this seem like a reasonable path forward:
1. Resolder/reattach the switchs (do I just need to eyeball when I put the switches back on? or do they have to be exactly the same on each side)
2. Uninstall MC and clear it out of the local folder
3. Reinstall the latest MC and try to do the calibration all the way through
4. If I can't get the calibration to go through completely, don't tell it to print or it'll rip more wires likely.
5. If I can't get MC to work, try repetier host or Cura or another program.

 

Is it possible to see what mattercontrol is going to send to the printer before doing a print? Maybe then I could see if it's sending bad data before 'testing it' once I fix the switchs. (I say this because the 'test' could wreck them again...)

 

I explained a means of testing it in a way to prevent damaging failure in my previous post

If you export the g-code and open it in a reader like repetier or notepad++ you'll be able to look at what commands are being sent.