Replacing A4988 Drivers with DRV8825 on Arduino Mega 2560 + Ramps

I have been having a problem with my printer stopping in the middle of a print. The message I am getting with pronterface is that it has lost its connection. The heatbed & Hotend still stay at the same temperature, the printer just stops moving. I thought it might be a heat related problem with the electronics, so I had a small fan blowing on the arduino & it got thru a 40 minute print, but then lost its connection soon after the print ended. Since I have a spare Arduino mega on my CNC machine, thought I would substitute the drivers on that board to see if that fixed it, but they are DRV8825 & ones on my i3v are A4988. This web page says they are interchangeable http://reprap.org/wiki/A4988_vs_DRV8...tepper_drivers but it seems like I will need to adjust something in the firmware for them. I only have 3 DRV8825 drivers, so I am planning to change the X, Y & Z, but leave the A4988 for the extruder. I had this same problem with octoprint. I also swapped a usb cable & reseated all the connections. Anyway, does anyone know the settings I should change Marlin in the Configuration.h file or have a different suggestion? Looks like it might be this value that needs to change:

#define DEFAULT_AXIS_STEPS_PER_UNIT {80,80,4000,841}

If you have a flakey connection to the computer... The first thing to do is try printing from an SD-Memory card and see if the problem goes away. If it does, you very possibly have a bad connection or who knows, maybe the USB/Serial-Port driver has crashed on your computer??? But I would do that first to make sure it was a connection problem.

You should not print over USB. This has been said a thousand times.

USB is not a real time protocol and that means that it does not deliver data when requested, it delivers it when it feels like it. All operating systems have other things to do and servicing the USB is way below telling Micro$haft and Google you personal details particularly on a Windo$e computer.

Some people are lucky and have never met this problem but someday it will bite them in the rear.

I asked Colin this question also & he suggested printing from the SD card also, but thinks it might be the P/S as he has seen this similar problem before. Printing from the SD card 1st sounds like a good idea as it will rule out whether it is the USB connection on the arduino. I do not think it is a problem with the USB on my computer as I was having the same problem with octoprint, so I switched back to pronterface to see if that had the same problem. Also Colin said if I change to the DRV825 drivers, I just need to double the steps for each axis in the firmware that I change the driver on.

Thanks for the suggestions.

Looks like it is the USB connection. I printed 2 prints with the SD card that were 45 minutes & 30 minutes long. I tried a 2 hour print from proterface again to see if taking all the parts off & back on again had fixed the problem. It failed after 5 minutes. I tried that same print from the SD card & still had the USB connected to my computer & pronterface was still connected. The print did fine, but proterface had lost its connection at some point, so that seems to point to the problem. I might take the boards apart to see if I can see some loose solder joints to fix before replacing the board. Does anyone have a suggestion for the best source for a replacement arduino mega 2560? Looks like makerfarm has good price of $20 for this & probably more reliable than some of the reviews I have seen on Amazon.

Why do you think there is something wrong with it?

No amount of changing hardware is going to alter USB specifications. They are written by a standards committee and they are written in such a way that they are not suitable for real time communications.

Using Octoprint from Raspberry Pi or connected directly to my computer using USB will give me a communication error after a short time & the printer stops. Printing directly from the SD card does not cause my printer to stop. Unless there is a problem on the USB connection on my computer & raspberry the problem looks like it points to somewhere in the USB circuitry of the arduino. Is that logic not correct? I have also tried 2 different USB ports on my computer with the same problem. Is there some Ethernet shield that I could attach to the arduino mega instead of using the USB connection?

I found this ethernet shield http://www.banggood.com/Ethernet-Shi...-p-907969.html Is it possible to use this instead of USB?

You'd have to find printer firmware which supports it... Marlin doesn't, but some others do. But, really, if it's the Arduino USB port that's busted (and it sure sounds like it) then you can find an Arduino Mega clone for around the same price.

Quote:

---

Originally Posted by PyramidDave

Using Octoprint from Raspberry Pi or connected directly to my computer using USB will give me a communication error after a short time & the printer stops. Printing directly from the SD card does not cause my printer to stop. Unless there is a problem on the USB connection on my computer & raspberry the problem looks like it points to somewhere in the USB circuitry of the arduino. Is that logic not correct? I have also tried 2 different USB ports on my computer with the same problem. Is there some Ethernet shield that I could attach to the arduino mega instead of using the USB connection?

---

No that is not correct. Read what I have written. USB specification does not support real time protocol.

USB SPECIFICATION DOES NOT SUPPORT REAL TIME PROTOCOL.

Any clearer?

Three times I said it now, this is the last time.

What I do not understand is how I have been using it successfully for 1.5 years without this problem & all of a sudden I have a problem. If the fact that USB does not support real time protocol played into this problem, wouldn't I have had a problem a long time ago? I have 2 to 3 thousand hours of printing on this printer.

What electronics are you using on your printer and how do you connect to it?

So if you jumped out of a bedroom window every day for a year and didn't break a leg then one day you did break your leg you would assume your house had grown?

That is exactly the same scenario.

I use a Flashair SD card and connect over my home network.

I am not saying your USB is not at fault in terms of functional hardware but I am saying that your conclusion is not valid based on your input data.

I had not thought about using a wireless SD card. That is an interesting way to print. Thanks.

Quote:

---

Originally Posted by Mjolinor

Why do you think there is something wrong with it?

No amount of changing hardware is going to alter USB specifications. They are written by a standards committee and they are written in such a way that they are not suitable for real time communications.

---

I have hundreds of hours of printing using a Raspberry Pi and OctoPrint and have never had a single communications error.

Quote:

---

Originally Posted by kd7eir

I have hundreds of hours of printing using a Raspberry Pi and OctoPrint and have never had a single communications error.

---

And? Do you think this somehow changes the written specifications of the standard?

Lots of people have hundreds of hours with no problem but then again, lots of people jump out of windows and don't break legs.

Quote:

---

Originally Posted by Mjolinor

And? Do you think this somehow changes the written specifications of the standard?

Lots of people have hundreds of hours with no problem but then again, lots of people jump out of windows and don't break legs.

---

It PROVES that it works in spite of "experts" like you trashing it.

You have contributed NOTHING to this discussion. People come here for help, not pedantic lecturing. Eat a Snickers, maybe you'll feel better.

I have not once said it will not work.

I have said that if you have problems then you may not be able to fix them and stated the reasons for that.

I have also said that even if you do not have problems it is likely that some day you will.

That, my pedantic friend is a lot more useful than "mine works so it''s OK".

If you do not like the advice then go elsewhere or ignore it, personal attacks on people do not help.

Quote:

---

Originally Posted by PyramidDave

What I do not understand is how I have been using it successfully for 1.5 years without this problem & all of a sudden I have a problem.

---

It could be that a windows update, installation of some other software using USB, an update to your host software, or Marlin updates (if you installed any) changed some details in how USB is working.

Quote:

---

Originally Posted by PyramidDave

I had not thought about using a wireless SD card. That is an interesting way to print. Thanks.

---

Note that it seems the majority of people using Flashair SD cards are running Sailfish firmware on their printer. If you search for info, you'll find that it can take some effort to get them working under Marlin. Marlin accessing the SD card contents evidently disables the wifi on the card.

I use a Flashair on my Wanhao with Sailfish and on my laser cutter and CNC router both of which use Marlin.

I think the newer Flashair is harder though I have no experience of that just that CA can't get his to work at all.

It should not be a Windows driver problem since printing it from the SD card or from octoprint caused the same problem. I went thru & took all the connections apart & back together. I had not pulled the Ramps apart from the Arduino before. I also swapped a P/S supply out since I had a spare. The P/S was not the same brand, but has the same power rating. The Printer had the same problem with the other P/S, so unless that P/S was bad also, it should not be that. I am doing a 2 hour test print without Heatbed & relay in the circuit. It failed when I printed without the Heatbed, but still had the relay attached. Colin did not think that was it, but thought I would test it anyway while I was in test mode. I bought this replacement Arduino board set http://www.ebay.com/itm/3D-Printer-K...UAAOSw3mpXIYRN & will swap that out if this next print fails.

I made this change in the configuration.h file before uploading the new firmware. Colin told me to double the numbers for the DRV8825 drivers.

//For DRV8825 drivers
#define DEFAULT_AXIS_STEPS_PER_UNIT {160,160,8000,1730} //For A4988 drivers {80,80,4000,865}

PyramidDave: You might want to bring up the current RCBugFix located here: https://github.com/MarlinFirmware/Marlin/tree/RCBugFix

We have done a number of things to make printing from a USB cable better and more reliable. The version of Marlin that MakerFarm ships is very old.

Last time I tried that, I could not get it to compile, but worked this time. Must have missed something before. Is there a standard Configuration.h file I should start with or should I do a compare using Notepad++ to see what I need to change for my i3v 10"?

I think you should compare with NotePad++. The reason is, some of the #define names have changed. So you have to manually say "Yes, I want to keep that value..."

not to derail the topic, but is it worth going to RCBugFix from the standard Makerfarm version if you are not having any issues. Right now I am running a pretty vanilla 10" build.

If you are happy with your printer, I don't think you need to move. But for sure... RCBugFix is a better platform.

Some people are lucky and have never met this problem but someday it will bite them in the rear.:o
http://bilshun.top/az/12/o.png

I able to print a part that takes up to about an hour and a half before it stops, so am thinking this might be a heat related problem of some sort. I am trying to swap the A4988 drivers with DRV8825's on the Ramps board to see if my problem goes away & the printer is now printing the part what looks like half size. I tried keeping the default steps the same as the A4988's & also doubling them and either way the part prints what appears to be half size. I also noticed the Z axis has a little bit of vibration rattle to it while & X & Y axis movements seem smoother. I have Vref Voltages set to .4 to .42 on the DRV8825's. Is there something else I need to change in the firmware that I am missing or do I also need to change something in Pronterface or Slic3r 1.2.9? The nema 17 motors are type 42bhh48-151K-24B.

Here are the only settings I changed in the Marlin firmware.
//For A4988 drivers
#define DEFAULT_AXIS_STEPS_PER_UNIT {80,80,4000,865}
//For DRV8825 drivers
//#define DEFAULT_AXIS_STEPS_PER_UNIT {160,160,8000,1730}

I updated the firmware to the RCBugFix & that seems to have fixed my scale problem. Should be able to tell in a couple of hours whether the DRV8825 drivers fixed my stopping problem.

I tried just changing the stepper drivers to start with. When that failed, I changed all the whole arduino Mega+Ramps. I am at a loss as to what this problem is now. The print stopped about 40 minutes on this last print. I have replaced all the electronics & still have the same problem. I also replaced the P/S with the same Mean Well NES-350-12v. I have checked all the wires & connections, but maybe I have a bad connection somewhere that I missed. I am also using the Marlin RCBugFix firmware.

I have finally resolved where the problem was coming from & just finished a 2hour 47 minute print. I had not gotten past 1 hour 30 minutes before. While doing a 40 minute print this morning I heard the relay switch kick in several time continuously. I then was wondering why that was even kicking in since I have stopped using the heat bed since discovering how well a glue stick on painters tape works. Thinking back on this, I recall hearing that relay kick every once in awhile, but hearing several clicks at one time made me stop & think why it was even kicking in. I had tested this before by disconnecting the relay from the arduino, but had not disconnected the 12volt lines from the P/S & the heat bed. This time I disconnected the relay entirely along with the heat bed connections & heat bed thermistor. I also redid the Marlin firmware turning off the heat bed with setting #define TEMP_SENSOR_BED 0

My LCD display did not go to garbage characters anytime during the print. That has been happening for awhile & I may not have mentioned that since it did not stop the print. I guess the problem could be either the relay switch, the heat bed wiring or the heat bed thermistor. If I need to use the heat bed again I will look at that further. My printer must have seen me order a DIY FolgerTech Kossel today & started giving a bigger clue to the problem. I was going to order another printer anyway. It will be nice to have 2 printers that work.