Site Navigation

Your Account

Choose Language

Z-Axis End Stop Behaving Erratically


I am using a Printrbot SImple v2. with Repetier-Host v.95F on Ubuntu 13.10. While I found it difficult to find up-to-date configuration information, I eventually had success printing a 5mm Calibration Cube by following settings recommend in this tutorial- Initially my X-Y-z axis home settings functioned as stated in the linked tutorial and manual control responded in both R-H and on OctoPrint. But after about a week, things started going wrong. The problems began when the printer stopped responding after loading a file in OctoPrint. Then the the manual control for the Z-Axis stopped working. I took it off OctoPrint and connected directly to Repetier-Host and I noticed it would lower the Z-Axis until triggering the end stop, but remained stuck in triggered mode. When attempting to load a file the Z-Axis would lower as if there were no end stop at all.

I have tried reloading repetier-host, and have checked and rechecked the connections. If I turn on the printer without the end stop triggered it will respond as usual, but as soon as I try to home again it gets stuck in triggered mode and remains unresponsive. Is this a problem with Repetier-Host? Is there another G-Code editor that I can use with Ubuntu 13.10? I can try Pronterface, though the only software supported in the package manager is Repsnapper.

I looked into reflashing the firmware but the process didn't look nearly as simple on Linux as I thought it would be.

Answered! View the answer I have this problem too

Is this a good question?

Score 0
Add a comment

4 Answers

Chosen Solution

I am not sure it is really a firmware flash issue, but I guess it could be. I think I can help on the reflash but I'd encourage you to verify the operation of each axis. You could do this by replacing the limit switch with a simple jumper to manually trigger or you could switch a working axis with the bad axis. So if you swap Z and X and then tell the software to home X does it work? Remember to switch the motor and the end stop if you do this.

However, your specific question is flashing the firmware in Linux. I haven't done it yet, but I've been keeping track of how to do so. It isn't that hard.

1. install dfu-programmer (on ubuntu sudo apt-get install dfu-programmer)

2. Get a hex file (see below). Say it is ~/printrboard.hex

3. power and connect printrboard

4. set printrboard into boot mode (remove boot jumper, reps after rev.D add boot jumper)

press the reset button

5. lsusb (should say 'Atmel Corp. at90usb AVR DFU bootloader') if lsusb says 'Van Ooijen Technische Informatica....' you're not in bootloader mode and need to repeat steps 3 and 4.

6. sudo dfu-programmer at90usb1286 erase

7. sudo dfu-programmer at90usb1286 flash ~/printrboard.hex (or wherever you put it)

8. exit boot mode by add/removing (depends on rev.) the boot jumper and press the reset button

9. lsusb should say 'Van Ooijen Technishce Informatica...'

10. connect with your host software and test if the changes have been applied

11. Profit

If you don't have dfu-programmer in your repos (they are there for Ubuntu, don't know about others) you can find it here:

Where to get the hex file. Ian can probably confirm but the last "stock" version I know of is at or you can compile your firmware as usual with the arduino IDE. (only compile not upload)

arduino will create a hex file within the tmp directory. Copy it to someplace like ~/printrboard.hex

If you do recompile (suggest you don't) the source is here:

You need the Arduino software (0022 is the one used by stock--find it here and the teensy add in Follow the instructions there to get the Arduino environment running.

However, two points. 1) I don't think you should recompile. Ask Ian to confirm the link I have is the latest firmware for your printer. 2) I really think you should swap axis or do some other troubleshooting to figure out what's going on. My opinion is that bad firmware flash manifesting after a week of service is very low.

Remember, that the way the firmware works is if it thinks it hit the limit, it won't go further until you rehome. So if an axis only goes one way, that could just mean it thinks the stop has been reached (shorted sensor switch, etc.).

Let us know how you make out.

Was this answer helpful?

Score 1


Do you mean I could've just downloaded a precompiled Hex file instead of going through the whole process of compiling it myself? Well, I guess I learned something new in the process...

As for the end stops... Once I finished with my new firmware I again tried connecting to Repetier-Host. It brought up my old settings (X-Y-Z set to min etc...) and when I went to manual control, all the end stops worked as expected when using the arrows. But once again pushing the home button made everything go haywire... This time, the Y Axis AND the Z Axis seemed to lose all sense of where to stop! The Y Axis kept trying to pull itself back (away from the print bed towards the back) while the Z Axis lowered until it couldn't lower anymore and kept spinning. In both cases, it got stuck in that position and no other buttons could make it stop until I pulled the chord out.

Same happened with Pronterface. Perhaps it has to do with Slic3r?

by Andrew Jawitz

Slic3r should have nothing to do with manual homing.

by Al Williams

OK... I think I solved the Y Axis Problem... I forgot that I recently replaced the fishing line for the Y Axis and I had it spun around the wheel wrong... The Z-Axis still screws up though... Any chance it was related to the Y-Axis string?

by Andrew Jawitz

I just actually did this with Marlin Unified. However, the first time I did the erase/program it didn't boot back up as anything. I was thinking oh *$#*$. I did it again and it took. So you may need to do erase/power cycle/flash. Or you may not. But it did work.

by Al Williams

Add a comment

Hi Andrew

I would certainly think reflashing the firmware would be the answer, looking at those symptoms. Let me see if Al can help, as he's a linux user.


Was this answer helpful?

Score 0


oy... In that case... Does anybody know if its possible to reflash using the Arduino IDE? I took one look at FLIP and had nightmarish visions of reconciling outdated Java dependencies and trying to get Ubuntu and the Oracle JDK to play nice... Somehow I just don't see OpenJDK cutting it in this case. Unless there's a better option in some up-to-date instructions that I've been missing?

by Andrew Jawitz

Add a comment

The Z Axis Belt Line had been wound wrong when replacing with new line. When starting from the front the line needs to be wound counterclockwise twice "off the top". Its odd that it seemed to affect the Z-Axis more than the Y-Axis, but after rewinding and adjusting the wires all works fine.

Was this answer helpful?

Score 0
Add a comment

You might have confused us with your description- something to keep in mind is that the X and Y use the fishing line and X moves the print bed right/left, and Y move the print head toward the front and back of the printer. Z is the threaded rod and moves the print head up and away from the print surface or down toward the print surface. There is no way to wrap the line the wrong way for Z.

Was this answer helpful?

Score 0


Sorry if it was confusing, but I actually did get my Axis names correctly in this case. It was the Z-Axis (up and down) end stop that I first noticed was acting strangely. I noticed the Y Axis had issues too after I submitted my first post. In the process, I noticed I had wound the fishing line on the Y-Axis incorrectly. After fixing this, the end stops on BOTH the Z and Y axis have been functioning as normal. As to why the Y Axis fishing line would have any impact on the Z-Axis baffles me as much as anyone! But as the saying goes "if it aint broke then don't fix it!"...

by Andrew Jawitz

Add a comment

Add your answer

Andrew Jawitz will be eternally grateful.

View Statistics:

Past 24 Hours: 2

Past 7 Days: 4

Past 30 Days: 11

All Time: 668