X axis Stepper only moves one way (Melzi v2 board) - help request

Hi

I had my new built mendel i2 ready to test out but the x axis stepper has stopped working correctly suddenly and I have no idea why.

This morning it was moving manually in both directions, but when I tried it later on it will only move one way (away from the end stop). I have checked the end stop and it is working perfectly so that is not the fault.
I have tried the motor in question on a different terminal/channel and it functions fine both ways so the motor is ok.

So it seems to be some sort of fault with the Melzi controller board has suddenly developed.
I have powered everything on & off, and used the reset button on the Melzi with no effect.

Is there anything I can troubleshoot to fix this problem, or does this in all likeliness mean my controller board is now useless and I have to buy a new one, without even knowing what went wrong?


Appreciate any help, thanks.

The software I'm using is Repetier by the way, if it matters. I plugged in another PC and the problem is there from that too, so it's not a computer fault.

It's quite unlikely that a motor driver has failed in such a manner. It should be possible to identify the problem and fix it or work around, before buying a new board.

Usually a motor only moving away from the endstop means there is a problem with the endstop, so I would check that again.

If one of the motor wires has come loose, it can lead to motor always moving in one direction, but that tends to be a random direction.

Otherwise it could be a config problem, ISTR problems with Melzi losing EEPROM settings, don't know if that applies.

---

What is Open Source?
What is Open Source Hardware?
Open Source in a nutshell: the Four Freedoms
CC BY-NC is not an Open Source license

Thanks for the reply bobc - I agree that it seems odd for a driver to go like this where it still works 50% rather than going up in smoke or completely failing. Especially given that it's had an absolute minimum of use (just a few tests with manual movement) and that all moving parts move freely (ie no undue friction or load).

The end stop when tested is the same as the other 2 - which is open circuit until activated then I get continuity. It's the same as the others which work fine so I can't see it being the cause unless there's another way it could be affecting this?

Not the motor wire I'm sure since it behaves fine when connected to say the extruder output.

It's possible it's an eeprom problem but I wouldn't know where to start with that alas. This board came with firmware installed already and I have no AVR programmer so I'm not sure if I can test anything?
There is an 'auto reset' jumper on the board which I think is to do with loading firmware. Will this wipe the firmware installed if I use it?

Many thanks!
Jim

You may also find that the dir line that runs to the stepper driver has a dodgy solder joint somewhere.

The dir line is pin 14 on the stepper driver chip, and runs to pin 24 on the ATmel chip.

Same could be true of course of the X end stop line (goes to pin 21 on the ATmel).

Thanks for the suggestion Cefiar

I will check the continuity of those tracks and see if they're ok!

Check the endstops with the M119 command, that tells you what the firmware sees.

---

What is Open Source?
What is Open Source Hardware?
Open Source in a nutshell: the Four Freedoms
CC BY-NC is not an Open Source license

Thanks for the suggestion - will try that (edited - found the way to do this as my screen was scrolled such that I couldn't see where to enter these - duh!!)

The line returned is:
11:22:00.703 : x_min:H y_min:L z_min:L

The motor did actually just stop working altogether, after trying to move it in the faulty direction, but clicking the X home button seems to reset this behaviour when it happens. For what it's worth.

As a matter of curiosity, it appears even when the machine is 'doing nothing' that code is constantly being sent to it. What's that all about? Is that to ensure everything stays still unless told otherwise? Or something else?

Edited 4 time(s). Last edit at 02/16/2014 06:33AM by Mr Joshua.

---

Prusa Mendel i2 - Melzi V2

Ok, so that is telling you the firmware thinks the endstop is always triggered. If the switch is good, then the problem is in the wiring or the config.

It's also possible the endstop input on the CPU has been zapped.

---

What is Open Source?
What is Open Source Hardware?
Open Source in a nutshell: the Four Freedoms
CC BY-NC is not an Open Source license

Ahh, I see. So the H on the x stop I guess means high and the other two are showing L for low presumably.
So yeah it's convinced that the stop is activated even though it isn't.
Useful. I'll examine it all carefully when I get back home later.

If the CPU input is affected like you say, is there anything I can do about that or does it render the board useless effectively?

---

Prusa Mendel i2 - Melzi V2