Prusa freezes up

Hi, im having the exact same problem. I agree that the problem is with the RAMPS or adruino electronics. I ended up (under Richrap's recomendation) using an SDRAMPS which fixes the issue completely but its annoying to use and forget about uploading your gcode from pronterface, its WAY too slow.

Like thejollygrimreaper mentions, im sure the difference is in how PC usb ports work vs how Apple does it. I have my printer plugged in a USB 3.0 port that can supply WAY more current than USB standards requires (for charging devices faster). So I'm thinking its not a power issue but rather an interference problem (noise) or something software.

You seem to be able to reproduce the problem more ofthen than I can so if you are interested in helping hunting down the specific cause of this problem, I would really like you try some prints under linux on your computer.

No need to mess with your windows installation, just boot straight to linux usign a Ubuntu Live CD (see http://www.ubuntu.com/download/help/try-ubuntu-before-you-install) follow this guide to install pronterface on it (scroll down, youll see its simple stupid to install in on ubuntu) https://github.com/kliment/Printrun you can also check out http://reprap.org/wiki/Printrun#Debian and run a few prints.

If you do it please let us know what the results are.

I was also wondering how active usb cables work and if they would be better at filtering out the noise over the usb connection... we may also want to add a ferrite on each ends of our usb cable and maybe put a metalic sleve over it to shield the thing. I was thinking of using the mesh found inside a regular coax cable....

Edited 2 time(s). Last edit at 09/13/2012 02:24PM by thecrazy.

I think the weak point in most of the reported "freezing" issues is the USB. I have been dealing a lot with USB at work, where we have a large motor in the same box as USB device connection.

The USB protocol will handle a fair degree of noise, the signals are differential, there is CRC checking and retries, but at some point the USB host throws its hands in the air and stops talking to the device. Then, the recovery is not good, it seems to rely on the user unplugging the cable. At least, the application must close the port and re-open it. In Windows though, the application - drive interface seems to hang, and it is necessary to close the app and restart.

To get USB to work rebustly in all cases requires careful attention to all possible EMI issues, this is mostly electrical design. For the user, it is possible to get USB filters which may help.

In the CNC world, they started moving from parallel port to USB, and quickly found USB unreliable in the sort of noisy environments produced around CNC machines. Ethernet works much better, which is now being adopted. USB probably works fine for 99% of people, unfortunately if you are in the 1% it is too unreliable to use.

My board was freezing due to a nearby fridge turning off/on. I think I have fixed that by putting an RC pair between USB ground and board ground.

@Bobc

What value did you use for the RC pair?

Cheers
Geoff

Hi
The only time I have seen the Arduino freeze is if I have a desk lamp plugged in on same circuit as the Arduino and laptop. When switching lamp off or on the Arduino freezes within 5 seconds. (It varies depending on the globe) If you have fluro lighting in the room this may also make problems. Do you have anything running on a thermostat in the room? Something that may switch on/off randomly...
But I am sure you would have picked this if that was your issue.
Hope you find a fix.
Regards
Jan

---

======================================
[3dprinting4u.wordpress.com]

Is it possible that Printerface itself is too sensitive? I ask, because I have noticed in several cases that Windows Task Manager shows printerface as "Not Responding" and I have to shut down the program to proceed. Although I can close the program by hitting the x in the corner, and usually in a not responding program I have to take other steps to close it out. But if I unplug the USB from the laptop, it doesn't lock up the program the same way, but gives me error messages.
I did load the latest version of Printerface on all three of the laptops that have had issues, perhaps a version that is sensitive to Dell laptop communication. OK, I know, grasping at straws.

To Thecrazy, I may give your Linux suggestion a try, If it crashes under Linux, what will that tell me? that I have to run with Lenux only?

I thought about trying alternative programs, I was recommended to try Repetier.

I have noticed that since I added the external power to the Arduino, I have only crashed at a couple of locations, I haven't locked up in my garage since I added the extra power. But I still crash at work. (OK, no snide comments)

I was thinking about this and, like mentioned earlier in the thread, if there was no crashing while printing on a MAC Im thinking it was probably a laptop and running on battery. This could make a difference. Would be interesting to try with the AC plugged in.


I think I may have a solution to my problems, One solution would be to encase the electronics in a metalic case to shield it and use a shielded usb cable with ferrites and maybe use those USB filters bobc mentioned.. The other solution may be to setup all my software on linux running on a Raspberry PI that I would power from the Ardruino itself. Have the same power source should allready eliminate some problems. Also the USB cable could be EXTREMELY tiny, may even be able to bypass the useb somehow using the GPIO pins but thats too advance for me.

What I was thinking was to connect to the Raspberry Pi via VNC so I can still use the printer from my own computer and use a shared folder to upload the STLs. It could also hook up a wifi adapter to it which could be of interest.

Edited 1 time(s). Last edit at 09/14/2012 11:46AM by thecrazy.

Each time I have crashed, the laptop involved was plugged in to the wall, so in my case, the power was not the issue

Sorry Idaholion, I missread you before, I thought your laptop was not connected to the AC. Mind trying with it disconnected?

The test usign linux, its to figure out if there could be a software solution to our problem or not. I am not saying use linux, its just to pinpoint the problem or a possible solution. Im thinking there might be a difference in how communication errors (cause by interference) over usb are handled in a different OS / driver / software). If you try an alternative to pronterface. Let us know what your find out!

But all this may only be a patch, we might as well go for the source of the problem and try to reduce the inteference thats messing with our electronics.

Edited 4 time(s). Last edit at 09/14/2012 01:28PM by thecrazy.

Dont know if you guys have read that other thread "Aggravating serial issue"

The guy has the same problem when he turns on his ceiling fan. Its really looking like interference in our power source. A ceiling fan, a guy with his refrigirator, a lamp, having less issues when powering the Arduino from a wall adapter and I just realized I have a freezer plugged in the same circuit as my printer AND computer.

I wonder what kind of power supplies all of you guys are using. I am currently setup with a cheap 12v 30a LED power supply.
Im curious if ppl using high quality server or pc power supplies are having these issues. I wouldnt be surprised if they werent. (as long as the pc they are connected to also have a high quality power supply).

The reason Im saying this is that high end PSU have very good filtering to clean the power. I only use the Corsair HX line of psu in my computers cause their power lines (5v, 12v, etc...) are extremely clean compared to everything else out there.

We need more data to figure this out, those who have this problem please post info on your setup.

Edited 5 time(s). Last edit at 09/14/2012 01:30PM by thecrazy.

re: "Aggravating serial issue" It's actually simply looking like inductive spikes from the motor may be at fault in that particular instance of his serial lockup, not necessarily the AC line itself.. It could be either an EM interference issue being coupled into the system via improperly shielded wiring as much as conducted noise through the AC feed. And honestly, I'm not sure if that's the only thing that causes lockups for him, so...

I recommended that he print from SD to reduce and/or isolate the problem. If it continues beyond that, then the next step would be to drop the microcontroller into a shielded case, add power supply filtering, and clean up or even gut and replace the wiring with proper shielded cable (where all the shields are also *properly grounded). Way too many inherent issues in the electrical systems for most of the printers I've seen pictures of to suspect only a singular cause.

I agree xiando, but im thinking we should probably all shield our electronics anyways and use a minimum of filtering. I think there is several causes for the same problem here. Which is that the serial over usb connection is very sensitive.

Does anyone with good electronic knowledge know how we would go about shielding the Arduino/ramps? would lining the inside of an enclosure with aluminium paper be enough? I have the feeling Im thinking too simple here.

Edited 1 time(s). Last edit at 09/14/2012 02:06PM by thecrazy.

No, although a grounded, crude Faraday shield of aluminum foil *might improve the noise immunity a little bit, aluminum foil is not the answer. Use a properly grounded, metal enclosure. But that's just one of many problems in most of the builds I've seen. the basic problems go much deeper.

I'd suggest that any folks having problems with their electronics failing for "magic" reasons start to print using the SD interface to eliminate at least one glaring source of problems. If nothing else, it will help to isolate the issue and perhaps save a few 90% prints and all the time encompassed.

ee/phys, ~30 years prof exp.

I'm glad someone who really understand this stuff is on here.

Personaly I am allready using the SDRAMPS wich does solve the problem but I dont really like that solution. Transfering to the SD card via com port is very slow and I dont really like messing with a micro sd all the time.

Mind sharing with us what you see as the major problems with the RAMPS/Arduino design that affect the serial over usb?

Sorry, with no disrespect intended, I don't really have time to deal with all of the problems in that way. All I can do is forward the point that more needs to be taken into account than guesswork. Condensing 30 years of experience and education into easily digestable soundbites won't do the job and would take me far too long to accomplish in a way that achieves the desired end anyway. See the "Watson" announcement elsewhere in the forums for an example of the evolution in this genre towards use of sound engineering principles. (No, I do't work for them and am not associated with them in any way, aside from perhaps sharing similar insights into the flaws, or "limitations" if you prefer, of present boards) I would also note that I didn't solely point to the boards. there ARE other issues involved, as outlined in that other thread and elsewhere.

I understand the expediency of using the serial communications link for ~direct print control, and I'm not against its use if one can deal with the possible lockups, but this is a problem that long precedes the revamp to USB from RS232 (RS232 lockups were a problem in noisy environs as well). Isolating the issue by printing from SD can help to resolve issues in your electronics. If the problems persist following that maneuver, then you need to look at the other issues I outlined regarding the wiring and so forth. Honestly, it'd be a good idea anyway, at least based on the many images of people's builds I've seen, where there's often more work put into making them look pretty than functionally sound. ("ooh, I found purple wires for my motors!" snore...)

And regardless of the nuisance, IFF disconnecting the printer from your computer resolves the partial prints, you just saved far more time than you lost uploading the print to SD, right?

Here's what I'd suggest. google "electrical electronic noise control". Once you get through the myriad of web-commercials, you may find some very useful info. Use the baseline search and change words as well, adding salient erms as you become educated on the subject, since one search group by itself is often less than perfect these days, what with the swamping of Chinese product advertisements in the past two or three years, and admittedly, those four words are just a starting point.

ok, time to get back to work. best wishes,

x

Edited 1 time(s). Last edit at 09/14/2012 05:00PM by xiando.

The problem is most likely due to the ground loop created by the USB connection between two grounded devices. It makes the USB comms susceptible to noise from ground currents in the machine and the Laptop, conducted noise on the mains ground and radiated noise picked up by the loop. No amount of screening will solve that.

---

[www.hydraraptor.blogspot.com]

I did not read the entire thread so sorry if the problem has already been resolved.

I had the same problem and mine was solved by simply connecting my power supply to a different wall outlet. It took me about 2 weeks to figure it out. Dont ask me why but if i plug it into a certain outlet it will freeze up mid print every time.

No, not solved yet. I have a short term solution, (sdramps), a medium solution(going to try plugging in to a small power conditioner) and I am still looking for a long term solution. I also have another arduino and ramps unit coming, just in case my particular board is succeptible.

I second this. The USB voltage fails over somewhere between 1-3 m in length, and becomes inconsistent. Also USB itself is fairly unreliable as a port (mechanically).

I wonder if this problem is worse with the Mega. Other boards like Sanguinololu use FTDI chips for the USB, but I think the Mega uses a second Atmel chip which presumably runs some firmware. Perhaps that doesn't handle noise as well as the FTDI chips do.

---

[www.hydraraptor.blogspot.com]

Well, I have purchased and connected an SDRAMPS for my system, connected it, and have had no crashes since. I would have liked to have identified the actual root cause of my particular crash scenario, but I needed to be able to print to fine tune my instrument. So, hopefully this will be at least a short term fix. I will go back to the problem later, while I am building my next machine.

Question about running with sdramps. As instructed, I went into configuration file, changed //#define SDSUPPORT to #define SDSUPPORT, (although the wiki actually says define SDSUPPORT 1, but I figure Sprinter may be different by 1 digit.) the system works fine, (although I agree with everyone who says loading a file onto the card through the ramps board is ridiculously slow)
But running printerface, if I load a file into printerface and I want to run it directly, rather than through the sd card, system won't let me. I can load a file, hit print, and the system will print from the sd card the last file I printed. Am I doing something wrong in my setup? Don't I have the ability to print from SD card or from the computer?

You should be able to print from either. However in my experience if you don't reset the board after an SD print, it will restart the SD print.
I usually just exit repetier host, and reconnect, and that seems to do it.

Ah, I didn't reset or shut down, that could cause it. Thanks.
I have been going to shift over to repetier from pronterface, but I wanted to solve one problem at a time. Do you know if repetier runs off of sprinter? I have seen conflicting reports about that.

Try changing the firmware to marlin, i had simular problems and that is what i did to solve it.
It also produces very nice prints.