Welcome to the SeeMeCNC Community

Okay, so after some tweaking and ordering an E3D, I was finally able to get my Rostock up and running and begin the calibration tasks. I have some issues with the delta arms and so the Trick Laser arms are going to be ordered soon, but I have a much more pressing issue. I generally use the Yoda Head as a filament calibration print to see surface quality and overhangs to check my filament settings, however, twice now the printer has flat stalled out mid print leaving the printhead just sitting on the object as if it's waiting for information. It's printing from the USB and I have adjusted the baudrate to 250000. I have really no idea as to what's causing the problem as it has happened with two separate computers. Thoughts?

http://forum.seemecnc.com/viewtopic.php ... it=ferrite

Check this thread.

After quickly skimming that, it looks like that's interference related transmission errors from the ribbon controller cables on the SD display controller. I don't have one of those, I'm printing directly from the computer over USB.

I was doing a long print job the other day (here http://forum.seemecnc.com/viewtopic.php?f=41&t=2616) and about 5 hours into it, the print head started just stopping. Then it would start going and then stop again. I was getting these "BLK 1" and "BLK 3" lines output in Repetier Host in between the indicator which which layer it was working on. I *assumed* it was the ribbon cable interference and so I opened the door and tried moving cables around -- nothing changed. Then I started blowing a fan into the RAMBo area because I thought perhaps it was overheating. That's when I noticed that the "FPS" (Frames per second) of the rendering window in Repetier Host was really low (like 2). I had had RH on the "Print" tab and I was zoomed in pretty close to the model. Turns out the computer was taking so long to draw the rendering that it was slowing down communication with the printer. I switched over to the "Temperature" view and everything went back to normal.

This was running on a 2011 Mac Book Pro (13") which uses the Intel HD 3000 graphics which couldn't keep up with all the drawing. Depending on your platform, something similar may be possible.

My bad, I read the "stalled print" and sort of lept to the interference conclusion. I do agree with dpmacri-I try to turn everything off on my pc while it is printing. IMO the more processor power thrown at the print the better. I do remember something about this sort of thing in the past, I can't locate anything in the search? (which surprises me?) Hopefully someone will chime in with some answers.

Just found this: http://forum.seemecnc.com/viewtopic.php ... rint+stops
Sounds like a major pain to solve this one! Good luck.

There is a known issue with the RepetierMAX firmware. It will get up to a certain elevation and then freeze forever as the interrupt scans for instructions that never arrive. If you run the same G-code twice, it will freeze in exactly the same point both times. If you print with a layer height that's a multiple of the original one, the failure may occur at the same elevation.

It happens to me printing things over a few centimeters tall. I solve the problem by putting in a weird layer height, e.g. if it stalls at 0.1 I will try printing at 0.127.

Hopefully it will be fixed (or already is) in Repetier 0.9. I submitted G-code to a ticket about the issue, so the team has a reproduction case if they want it.

626Pilot wrote: Hopefully it will be fixed (or already is) in Repetier 0.9. I submitted G-code to a ticket about the issue, so the team has a reproduction case if they want it.

It's not fixed in the 0.9 version :/

Just a quick question on this. I havn't ever been able to duplicate this randomness

Are you printing from SD or USB? If from SD, is your USB cable still attached to your computer, even if it's not being used?

Are your LCD cables running near/around any stepper motor/usb cables?


Trying to nail down what exactly is causing this one?

I've had it happen over USB, and then again exactly the same way with an SD card with the same G-code. It always happens in exactly the same place (same position, same layers remaining to be printed.) It stops printing, leaves the heaters on, and doesn't turn them off due to inactivity like it would ordinarily. So you can just have your hot end frozen in place, still hot, for hours and hours. There's a ticket open for it.

My theory is that there are certain coordinate ranges that the Repetier firmware doesn't like, possibly a machine epsilon issue. If you slice the same .stl file with a weird layer height, it will often fix the problem. But, not always. If you use a multiple (e.g. try 0.1, doesn't work, try 0.2, still doesn't work) you often run into the same issue.

So I read somewhere that this was caused when slicing with cura and using gap fill. That didn't really apply to me because I am using Kisslicer. Also, I've clocked well over 30 days worth of printing and never had this issue.

I just realized that somewhere along the way the "Crowning Threshold" got changed from -1 to 1 in kisslicer. I think that is similar to gap fill, and I'm wondering if it's the cause.

I've only sliced two things since changing it back to -1, but so far so good.

Okay, so I had the printer down a couple of days while I got the arms on and did some other things in the classroom, so sorry for the delay. First, I am printing directly from the USB, but I did place an order for the SD reader to hopefully eliminate any communication errors. My biggest question right now is what's the most stable option right now? Listening to some of the posts here, it sounds like the Repetier Firmware that appears to have some major benefits freaks out when it's not using g-code directly created in Repetier Host? And is there an alternative host that others are using? It just seems frustratingly odd that the machine needs to be slicer specific in code generation and that we are semi-forced to use a frankly bloated host with two slicers natively built into it (neither of which being the slicers that most of the rep rap community are using) and a visualization system that you apparently cannot fully disable?

Repetier Host doesn't generate G-code and the firmware wouldn't be able to distinguish it even if it did. As near as I can tell the problem is specific to coordinates.

Repetier Host and Firmware are optional. You can use Pronterface and the Marlin firmware, or anything else that will work. The printer doesn't particularly care how it gets the G-code. If you want to shut off the visualization, you can just switch to the G-Code Editor tab. I usually do that to cut down on unnecessary position updates being sent over the wire, and also because I'm more interested in the temperature than what the piece looks like.

Can you post the gcode that's stalling out?

I understand that RH doesn't generate the G-code and I also understand that RFW is merely interpreting G-code. I am a veteran 3D printing user, but my other machine is an Ultimaker that isn't nearly as fussy on which slicer I'm using. I've seen several people comment on the RFW stalling out during prints where the g-code was generated with Cura, which is what I'm using for a number of reasons. With regards to RH, it does proxy out the g-code generation to other slicers which it includes in the install package. So while you may not even be using them, they are there and they increase the total application's space required on the hard disk. Not generally a huge deal, but IMHO completely unnecessary when the two slicers aren't generally viewed as the top slicers. Further, even if you switch the tabs, there is still a process running in the background that is tracking the moves of the print head to produce the visualization again when you switch back tabs. The best way to minimize the effect of that is turning down the tracking values as much as possible to lower the processor draw. It's still there though. As a programmer, this is not the most effective software. NOW, having said all of that, if it best option for running the RFW that eveyone seems to say has better motion control than Marlin, I guess I'll live with it. I'm simply asking if there is a more stable option available, or if the RFW is every bit the better firmware for the Rostock than Marlin. Marlin seems to run my Ultimaker completely fine and has a much smaller footprint on the Arduino board with regards to variable space usage, and thus would seem to be a more "stable" option, but if the RFW is actually better then again, I'll live with it. I'm simply asking for I guess the group's collective opinion because I have spent a substantial amount of time trying to level the bed and calibrate height and delta radius and acceleration and jerk and ..... that I don't really want to switch firmware on a whim.

Unfortunately I think I deleted the g-code I was having stall out. I turned down every setting I could and that seemed to help with a different object I printed so maybe there was too much going on and it stalled out on the computer side, which I find frustrating and surprising given it is on a brand new MacBook Pro with an i5 and 4 Gb's of RAM. That's why I'm wondering if there is a better Host than RH if running the RFW.

I heard you can get CURA working with it. Also Octoprint works well although I haven't tried it myself.

Not sure if it helps, but I had stall outs with Cura too, but only if I adjusted the flow rate in RepHost during printing.

I like Cura (really just a pretty UI on skeinforge slicing engine), but obviously stall outs don't cut it, so I gave up on it for the time being.

All of the newer Cura's (13+) ditch Skeinforge back end and utilize the slicer that Diad created, and is continually improving. The biggest plus is that it is faster than KS and it has that nice user interface. I have high school students running the printers and I am living for the day I can have them simply load their model and slice then start the print and walk away like we can on the UM. I don't want to have to devote extensive amounts of time teaching them how to manipulate the slicer, the focus is on the parts they are creating and I don't want to change that. That's why I'm not a big fan of RH. I will try Octoprint next I guess...