Printer stalling mid print

My new ormerod has been stalling in mid print. Just stopping and not responding to pause or anything. I am using pronterface. With a particular file, I have to disconnect and reconnect, and then start again and the same thing happens.

1. Which firmware are you using?

2. Does the print stall at exactly the same place each time you attempt it?

3. Is the PC going to sleep shortly before the print stalls? This is a known problem (PC going to sleep resulting in the print hanging) with the official firmware, fixed in my fork.

4. Were any other USB devices connected to or disconnected from the PC shortly before the print stalled? This can have the same effect as the PC going to sleep.

5. Another known cause of (random) print stalling when using a USB connection is ground noise on the mains. The following help to avoid this:

* Power the PC and the Ormerod ATX PSU from the same mains distribution socket strip

* Don't power anything else from that socket strip

* Put a ferrite bead around the USB cable

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I'm using 65e.

It seems to be with a particular file, pronterface stops at the same point each time. I tried a different scale version of the same file and it stalled again but this time at a different place.

PC not going to sleep or anything else connected.

Cheers

It might be worth trying with my firmware fork. See [github.com] for the binary (use the Raw button to download) and [github.com] for the list of differences from RRP 0.65e. Several weeks ago, some users reported having similar problems with RRP 0.57a that went away when they switched to my fork. It may be that RRP 0.65e contains the same issue.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hi
I'm running 0.65e and can report a similar instance. Although it only seems to have happened with one test print. Start print job from SD, printhead moves to middle of bed and system stalls. I can however disconnect from pronterface at this point but have to power printer off and reconnect to move motors again. Printing ol' snowman.g works a charm though. May be my slic3r settings outputting some bad gcode or firmware.

Will give dc42's fork a try and see.

Installed 0.65h and the difference is noticeable. No stalls. Just prints. Will need some recalibration but it's working.
On a side note, has anyone managed to get the autobed compensation working?

I have the auto bed compensation working. However:

1. I have an aluminium bed support and bed levelling screws installed. So the bed is close to being level anyway.

2. I only use the bed compensation for large prints. There is a slight twist in my printer's Y axis that causes the two front corners to be at different heights even when the back corners are level.

3. I use my differential IR z-probe to do the auto bed levelling. I originally had auto bed levelling working with the standard IR probe, but I had to make sure there was no strong sunlight or incandescent artificial light in the room at the time.

4. Running bed compensation resets the Z home position, so you need to do one of the following:

(a) If you do z-homing using an IR sensor and one of the white tapes in the corners of the bed as the target, then edit homex.g and homeall.g so that the XY coordinates used for z-homing are the same as one of the bed compensation coordinates (which you will have set up to be in the middle of the white tape). Then recalibrate your G31 Z height.

(b) If you do z-homing in the centre of the bed like I do, either automatically or manually with the aid of a sheet of paper, then you need to do it after running auto bed compensation.

Edited 2 time(s). Last edit at 06/20/2014 09:12AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Thanks! I do Z home with the IR and have levelled the bed manually plus have created a setbed.g. Have tried to do the G32 auto compensation but it keeps yielding the "at least 3 points are required" error even though I've set 4 points. Either way will follow your suggestions.

Hi EP1, how have you set the 4 points? Please post the config.g of other file that you use to do this.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Will do so on Monday,

A lot to think about, I''l try the fork and see what happens, once I have a couple of other little probs sorted.

Ok so I just down loaded the raw data. I admit I am out of my depth, how do I do anything with it? I am sure this is a stupid question but how do I compile?

Quote
IBDunne
Ok so I just down loaded the raw data. I admit I am out of my depth, how do I do anything with it? I am sure this is a stupid question but how do I compile?

See [reprappro.com] for how to flash the firmware.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hi all,

I have the same problem with prints stalling in the same place each time as above I have checked all the obvious, PC going into sleep mode and wait commands in the Gcode.

You say above you have upgraded to 65h. I am running 65e which is the latest version on Github I have found. Where is 65h?

I am using slic3r and suspect the problem is in the Gcode somewhere but can not see anything in the code.

Does anyone know how to get Pronterface to display the Gcode being executed in real time so that I can identify exactly where in the Gcode the stall occurs?

Dave M

There is at least one Slic3r setting that causes problems, and a couple of bugs in 65e that cause pausing:

1. Slic3r - Wipe while retracting: this tends to run the extruder at high speed in reverse, that the firmware generally doesn't like. Turn it off here: Printer settings > Extruder 1 > Retraction >
2. Bug - set the extruder retraction speed to 30mm/s in Slic3r 'Printer Settings > Extruder 1 > Retraction'. The printer can pause indefinitely if this is set higher.
3. Bug - set the travel feedrate to 60mm/s in Slic3r 'Print Settings > Speed > Speed for non-printing moves'. Slic3r applies this speed to the Z axis moves, so the Z will skip if set higher than this.

Let me know if the above helps. All of the above have been addressed already in firmware updates, which we are currently testing. We'll be releasing the updated version, 0.78, very soon.

Ian
RepRapPro tech support

Hi davem,

65h is a build of my firmware fork, which you can find at [github.com]. My current release is 0.65j-dc42. It fixes the known issues with prints pausing on certain gcodes. If you use the web interface, then you also need to use my build of that at [github.com].

Hi Ian, I don't understand your point 3. I've not seen slic3r generate combined XY and Z moves ('spiral vase' excepted), and unless a Z move is combined with an XY move, surely the firmware will limit the Z speed anyway, unless you use M203 to set a stupidly high Z feed rate, or you set a huge amount of axis compensation?

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hi dc42,

I have installed your firmware and been doing some prints today until disaster struck:

I termporarily misplaced my Kingston 2GB micro sd card on Sunday so today I purchased a new Sandisk 8GB Ultra card. After the 3rd test print today there was a puff of smoke from the Duet board and then the sd card could not be read.

The new SanDisk sd card was fried

With my original (rediscovered) Kingston 2GB card installed, the Duet will not communicate with the sd card anymore so the Duet looks to be damaged as well.

I must say the prints with your firmware were looking good and there were no pauses mid print. More impressively I was able to print a file which previously kept jumping the X axis causing a skewed print.

Has anyone had any problems with sd cards overheating?

Dave M

Edited 2 time(s). Last edit at 07/01/2014 04:42PM by davem.

davem, I'm sorry to hear about your Duet board. Are there any scorch marks on the Duet board or its components that would indicate which component overheated? Or does the SD card itself look scorched?

I suggest you contact RepRapPro support. I believe RRP have seen several instances of Duet boards failing.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

dc42 - it's not a combined move, it's that the travel feedrate is applied by Slic3r to the Z axis. I think the planner mistakenly applies a proportion of the speed to the Z axis, and moves it too fast if it's over 60mm/s. The planner seems to ignore a lot of the axis speed and acceleration limits anyway! Much of this is fixed in 0.78. XYZ combined moves, where Z is large in proportion to the other two (not normal during printing) are still problematic at times, though, which Adrian is still working on.

Ian
RepRapPro tech support

Quote
droftarts
dc42 - it's not a combined move, it's that the travel feedrate is applied by Slic3r to the Z axis. I think the planner mistakenly applies a proportion of the speed to the Z axis, and moves it too fast if it's over 60mm/s. The planner seems to ignore a lot of the axis speed and acceleration limits anyway! Much of this is fixed in 0.78. XYZ combined moves, where Z is large in proportion to the other two (not normal during printing) are still problematic at times, though, which Adrian is still working on.

Ian
RepRapPro tech support

Surely the firmware should limit a standalone Z move to whatever speed has been set with the last M203 command, so it should not matter if the G-code contains a stupidly high Z move speed?

Dave
(#106)

Dave - yes it *should*! And now it does, in 0.78.

Ian
RepRapPro tech support