Prusa freezes up

I finally have our Prusa spitting plastic.and have run in to a repeating problem.
Have my RAMPS 1.4 based system running splinter hooked up to my Dell Latitude D630 laptop. Running Printerface latest version. About one print in 4 the printing will go along fine for 10 to 25 minutes, then just stop. Prusa nozzle frozen in place. program not responsive to any commands, the only way to proceed is to unplug RAMPS, close program, then start over again. Computer running Windows System 7. I have reloaded software and drivers, same problem. Have tried a different Dell Latitude computer, same problem. The other 3 out of 4 times, parts finish fine.
This has happened with multiple files.

I have turned off hibernate and disk stop in the laptops, checked power requirements, everything set up like it is supposed to be.

My friend's Apple book, plugs in, runs fine, no crashes. (please no responses saying " the solution is simple, buy an apple laptop.:" I would like serious help)

One additional quirk, I cannot load firmware with either of the Dell laptops. The applebook loads it fine, but not either of the dells. have replaced usb cables, reloaded software, loaded new copies of drivers, all for nothing. can see the board fine with dells, can run Printerface system, it sees it in com 4 port.

I am looking at getting a sdramps to minimize the impact of frozen parts, thought it might help. But that still will not help the other problem of loading new firmware when we recalibrate, or updates.
Any suggestions? My system is finally making parts, but the reliability is not good at all

Ouch. 23 views, no one has a hint

Do you have D2 installed on the ramps?
Since the apple works fine, it's likely that the USB voltage on the Dell is marginal, all apples deliver way move power over USB than the standard requires because they are designed to charge IPads.
This would also explain why you can't program on the Dell but can on the apple.
If D2 is installed the power is drawn from the 12V line not the USB port, so that would rule out this as an issue.
If it is possiibly the issue, make sure you have no other USB devices connected to the laptop and you can also try a powered USB hub.

Thank you so much. I don't know if d2 is populated, but lower power would make sense why it locks up, and especially why I couldn't program. I will double check and post results. I can always pick up a powered USB hub at rat shack

Rats. D2 was populated. But I am not certain that I had the external power on when I was trying to load firmware, so that could still be the solution for half the problem. Still don't know what causes the frequent freeze ups

It is probably something else, as I can easily install firmware with only the USB cable attached. What exactly do you mean when you say you can't load firmware? Does the Arduino IDE not see it? On a side note, the newest version produces errors when compiling, but the old 0.23 works perfectly.

Please be as descriptive as you can with these issues, so you have the most change of being aided!

---

--

Charles S.
Software Engineer
Prusa Mendel I2, RAMPS 1.4, Marlin 1.0 R2, Pronterface, Slic3r

When I tried to load firmware with the Dells, it would say "loading" for several minutes, then say loading completed with several errors and the firmware had not changed. Sorry, don't recall the errors, didn't write them down. We took the RAMPS board off to watch the connection light, it never flashed. With my friends apple, as soon as we started the firmware loading, the connection lights started flashing. The Dell can see the instrument, as evidenced by the fact that the printerface software can control the machine, but couldn't successfully load firmware.

The lack of ability to load firmware was frustrating, but my primary question was the Printerface software locking up, since that I see every four or five runs. I mentioned the firmware issue in case the two were related. Has anyone else had the printerface software lock up in the middle of a run, requiring a shut down of the program and a restart of the instrument and software to continue?

If the board is maintaining temperature of the hotend and bed when it "locks up", it's likely just a comms error, pronterface, just loses communication with the board, is there anything shown in the error stream?
If everything is off when it "locks up", it's more likely the ramps board reset.

According to this
[reprap.org]

"D1 should only be installed if the 5A rail is powered by 12V. It can be omitted and the Arduino will be powered from USB. "
I can't find D1 marked on the board, still hunting. Could it have been d1 instead of D2?

I realize I am grasping at straws, I just want the machine to stop freezing up

As far as I can tell, it maintains temperature with the hotend, (bed is independently controlled as of right now)
I don't think i have seen any error messages on printerface. It locks up printerface, and nothing responds . I can press pause then try to move z axis, nothing happens. The only way I can get communication restored to the printer is by closing down the printerface program and unplugging and replugging the USB cable on RAMPS.

OK, now this is interesting. from the Arduino site,
"The Arduino Mega can be powered via the USB connection or with an external power supply. The power source is selected automatically.
External (non-US power can come either from an AC-to-DC adapter (wall-wart) or battery. The adapter can be connected by plugging a 2.1mm center-positive plug into the board's power jack. Leads from a battery can be inserted in the Gnd and Vin pin headers of the POWER connector.
The board can operate on an external supply of 6 to 20 volts. If supplied with less than 7V, however, the 5V pin may supply less than five volts and the board may be unstable. If using more than 12V, the voltage regulator may overheat and damage the board. The recommended range is 7 to 12 volts."

If my Dell USB is giving me anything less than 5 v, this could be causing lockups. I can find out with a simple wall wort from wall mart (or dig through my boneyard of interesting crap) and a 2.1mm plug, maybe even just run a line from my 12v supply on the machine to a 2.1mm plug. that way i have flexibility, plugging and unplugging

It's probably easier to go to Best Buy or Walmart and buy an externally-powered USB hub instead of trying to hack together a power supply on your own.

I had a small issue with lockups on longer (2+ hour) prints at random intervals. I bought an externally powered USB hub and the problem went away. Before I bought the hub I was powering the arduino from the USB plug on a netbook (which like your Dell probably does not have the most robust USB power supply built in).

DI is under the X and Y stepper drivers, I meant D1 when I said D2 above doh!

Anything peculiar in your G-Code at that moment?

Can you setup the ability to print form an SD card to see if it still happens?

This way you could narrow down if it is a PC problem or not...

No, nothing peculiar in g-code, I have printed the same item more than once and had it crash in different places, then the next time it made it all the way through fine. I am looking at buying a SDramps card to add to the unit to minimize this sort of problem.
If I am running on SD card, is there any info going back to the computer? Lines completed, temperatures, anything? or is it isolated completely?
I know there are LCD screens that will let me run independent, but mostly I just want it more crash proof

Just had my friend running a third Windows based laptop crash at 92% completion on a part that should have taken about 45 minutes. We are trying the external power route next.

What Baud rate are you using?

If you are using 250000, drop to 115200 and see if that does not fix you up.

You will need to make this change in the Config.h file of your firmware and the within the host program you are using to run the printer (you mentioned pronterface, you should give Repetier a shot if you PC is powerful)

Bet ya a buck that fixes your problem

Also, be sure that your gcode keeps the nozzel inside the printer area defined in your firmware.

If it ever leaves that Pre-defined area, your firmware (depending on what you got) might say "NO!"

the program is running at 115200 baud rate connection.

I'll have to check out Repetier

The nozzle freezes up in the middle of a run, stuck in the center of the part, and it isn't on an edge or close to the outer envelope. The next time I run the program, it will run the part fine

Life keeps being silly

OK, no guarantees, but we have been running for the last 3 days with the arduino board powered by a wall wort 12v power supply, I haven't had any crashes in 8 builds. I haven't tried loading the firmware, to see if that was the root, but it is looking promising for the biggest problem I had. I will let you know if it also solves the firmware loading problem

Dagnabbit. I jinks myself by responding on the forum. My system just froze up again, in the middle of a 2 hour run, (which I had successfully printed out twice in the last week). Still freezing up, even when externally powering the sanguino. Just loses connection, and cannot reestablish the connection. One answer is the sdramps attachment, which will be my next order, but dash it all, why has it happened on 3 different laptops?

Unfortunately it could be almost anything.
It could be environmental, someone turning on something with an electric motor or a fluorescent light.
You can try a shorter USB cable, preferably one with filters on it.
Short of a loose wire I'd be surprised if the board itself had an issue because it runs fro such prolonged periods.

The unit has frozen up in 3 different locations, so I don't think environmental. Driving me crazy

Try to avoid ground current flowing down the USB cable. I.e. make sure the ground from the board to the PSU is as short and fat as possible. Any voltage dropped across that will be superimposed on the USB signal and will cause current in the USB cable.

Plug the PC into the same wall socket as the printer so they both see the same ground.

---

[www.hydraraptor.blogspot.com]

You can try -

Change your USB cable - keep it 1M or less

Check your PC is not putting the USB ports into sleep mode

Try another USB port / powered hub

Print from an SD card - you should do that regardless.

And just as an advice point - Make sure your RAMPS stack is well clamped together - I use long M3 bolts to provide slight pressure to clamp the RAMPS to the Arduino, it's amazing how many issues that resolves - don't underestimate vibration

---

[richrap.blogspot.com]

Yes, the printer is plugged in to the same outlet as the laptop. Just had 2nd crash in a row,

I have tried 3 different USB cables, all of them under 1M
I confirmed the laptop is not going in to hibernation, locking out USB, or any other power saving setting issues
I have tried a total of 7 different USB ports, I haven't tried a powered USB hub yet, don't have one
I just ordered an SDRAMPS unit to attach onto my RAMPS, should have it in a week or so
Good suggestion on bolting the RAMPS to Arduino, worth doing.

what you have here is another example of what i've been going on about for ages, now,

i feel sorry for you , you've spent quite a bit of money on something that isn't working properly, and quite honestly it's more about design than anything,

the source of this problem is actually all over the place, starting with the stepper drivers, these pololus produce quite a bit of noise on the 12v line and in some cases on the GND line, it varies with different drivers, most of that noise the Arduino can live with, however the usb side of things has a few issues,

depending on your version of windows, this happens so fast you don't notice it, and the comm port may actually be staying the same which makes the problem all the more undetectable, Linux and macos handle these problems very differently which might explain why your friends apple laptop has it going ok, the apple usb hardware also has much better noise protection built in on the usb side of things,

short of rearranging pololus and trying new ones,

I would suggest sacrificing a usb cable and severing the V+ line so now power is being drawn from the usb port and noise comming down the cable is limited to the GND and D- and D+ lines,

the other thing and is fairly unlikely but can be the source is your limit switches , are you using mechanical ones or opto?
if you're using mechanical ones depending on how they are wired, the design of the circuit can actually have this input floating during operation, until it is switched,

if none of this helps, short of trying different firmware eg teacup, I would considering sending the board back to your supplier, and try one of the other ones, not that many of them are much better,sanguinololu especially

I personally gave up on the sanguinololu and ramps boards after a lot of wasted money on them and switched to optically isolated tb6560 based drivers with an Arduino uno and a couple of relays and i now have a bullet proof machine which still has a top speed of over 250mm/sec, however suggesting people using this setup instead seems to be akin to suggest to the religious crowd that God doesn't exist

Thank you so much for the input. I am afraid at this point, I am somewhat stuck with the RAMPS system, Believe it or not, the RAMPS system is what we went to because the previous system was so unreliable. I am interested in the details of your system, though, and if you have a minute to share the bare bones of your setup (did you build the wiring interface on top of the uno, or is it all component level, how are you handling the wiring interface to the instrument?) I would love to see your setup

I am using mechanical switches, could be the problem

I had 8 runs in a row work perfectly, then I had 4 fails in a row. Frustrating

On severing the USB cable +5 v, I assume you meant that power is NOT drawn from the USB line? In any case, I have no problem sacrificing the cord if it will help the reliability. I do have separate power to the arduino board now.

I have a sdcard unit coming in a week, hopefully that will minimize the problem, since the freezup apparently is happening due to a communication loss to the system, freezing up Printerface. (although it doesn't SAY lost communication, it just locks up the program on Windows and locks the machine in place)
I have thought about trying out Marlin instead of sprinter, but I probably would trade one devil for another

I also have a new unit (arduino, RAMPS, etc) coming from a different supplier, I will try that out and see if it is a board issue