Do any of these look like cold solder joints?

[wingnut1000]

Having issues with my Ramps. Think it may be due to soldering. Small album here
Any of these look like cold solder joints? Issue is after a few prints, or print longer then 15 minutes or so, printer will freeze in spots, stop printing all together, or reset. Video of freezing behavior here.

[printbus]

Without being able to see them in person under light & a glass or scope, I'd say they look pretty good. A good fillet of solder, nice shiny appearance. Cold solder joints would have a dull appearance.

[CaptainObvious]

They look alright to me, the problem must be somewhere else. Are you using a USB cable to a computer or a SD card reader to run the G-Code to the RAMPS board?

I had a similar problem once and it was because of a slightly loose ribbon cable from the Smart Controller to the RAMPS.

[wingnut1000]

Does this if I print via usb, or SD card. Often when I am sending to printer using "Cached" it will freeze during upload. I've swapped USB cables, tried different ports and most recently purchased a new power supply to rule it out.

[Geoff]

Does this if I print via usb, or SD card. Often when I am sending to printer using "Cached" it will freeze during upload. I've swapped USB cables, tried different ports and most recently purchased a new power supply to rule it out.

If your solder joints were an issue, that would be general vibration affecting the board, which would happen at random intervals, not something like you have described. sure, some of the joints look a little bulbous, like a tear drop shape as opposed to connected from the PCB and dragged up the component leg like 99 percent of them, but like I said, if it was dry solder joint, you would be getting random crashes, and sometimes not even at all especially if the RAMPS is firmly based on the printer body - try printing with the ramps detached also.

Something is getting to a critical temperature and shutting it down, very possibly the POTS on the ramps board are too high, are your stepper motors really hot when this happens? have you checked the drivers for heat/heatsinks are ok?

[printbus]

Is it always pausing in the X axis? It's hard to tell from the narrow layer being printed in the video. If it is, try swapping the X stepper driver board with another to see whether the problem moves with the driver board.

[Roxy]

If you don't find the answer with a little bit more work... It should be possible to make a few changes to the Marlin firmware and have it update its status all the time. I don't know what you have available but even a few LED's that can be turned on and off at different times in the code would be valuable. If the firmware is shutting things down because something is too hot, that won't be hard to isolate and report in the firmware. Or if the firmware has run out of GCode commands to do and is sitting there waiting for instructions that won't be too hard to report either.

[printbus]

Roxy's post got me thinking. It now seems to me this has to be firmware pausing for some reason. If a motor or stepper driver started skipping steps, the layers wouldn't continue to line up. The pauses are relatively long - layer shifting should be obvious if we're missing steps.

Looking at the 4988 stepper driver datasheet, the connection with the Arduino is one-way. There's no status feedback that could be used for the stepper driver to report too high of a temp. When it gets hot, it just shuts off the output drivers. There's no buffering of step commands that the driver will execute after the temp cools down. The motors have no monitoring sensors. Maybe there's other issues that could cause the firmware to pause, but it doesn't seem like it could be the stepper driver or motor.

Some sort of errant interrupt eating up most of the Arduino processing bandwidth? Pausing during printing from SD eliminates the computer as a suspect - at least if this occurs with the USB disconnected.

[Roxy]

I would have to double check but I don't believe the firmware knows the temperatures of the stepper driver chips. If one of them shut down independently without reporting it, that axis would be all messed up when things restarted.

It sort of feels to me like the firmware isn't getting enough commands to keep it busy. You can turn on GCode debugging in PronterFace and see if that is pausing. That won't tell you why but it might provide some more information. One caution however: Marlin does buffer up some number of GCode commands. So what you really want to know is if the firmware buffer is empty.

Do you have anything CPU intensive running on that computer? Because some times when I kick off a nasty Slice operation, my printer will stutter.