Welcome to the SeeMeCNC Community

Hi!

Did anyone figure out how to fix this issue???

I have the same problem. Prints fail. The hot end stays on, but the print job just stops...

It doesn;t matter if I print from SD Card or USB... the Model is roughly 5"x 3", and there's no rhyme or reason to the stopping point... just random, but stops roughly 6-10 hours into a large high resolution print...

Flateric suggested unplugging the LCD display and that worked out for me. He added ferrite chokes to the cables running to the LCD and to introduce the LCD back without issues. I haven't checked but it could be repetier host has less robust error handling than marlin or uses functions marlin doesn't with the LCD.

I'm wondering if the LCD cables aren't attracting enough EMI to crash the CPU if there's no chokes installed on the LCD cabling.

g.

This is my belief, especially with longer cables and the tight confines of our rostock.

Shortened my cables and chokes and everything is peachy now.

Don't even have to force ASCII or use ping pong.

I'm about 20 long prints in now without problems.

I had my LCD cables removed (the adapter still plugged into the Rambo) and doing calibration scripts and the Rambo just locked up. I am using the developer build of the Repetier firmware, although the board would do that occasionally on the release versions with the LCD plugged in (the screen would just sit there reading printing..). The board has plenty of cooling so it is unlikely a heat issue. *shrugs* Tis a mystery, My prints have been going well though.


I have since reconnected my LCD, I went ahead and went for full shielding on the cables. Nothing fancy... really, if I wanted to be patient I'd order a roll of conductive adhesive copper tape and do a real shielding job, but I the other way. I tightly rolled (folded?) aluminum foil around the cables, wrapped some stripped copper wire ( I just used magnet wire because it was in reach) around the aluminum for a crappy just good enough connection and tied those grounding wires to the PSU ground from the conveniently accessible power switch. Cables are insulated with Kapton tape (the foil gives it that shiny yellow space age feel) and I didn't burn off the enamel where the ground wire would be exposed. So far nothing adverse happened, it's hard to show it is working when the problem is sporadic.

ok this has happened to me twice now, the first time i wasnt around to see it happen. The second time just occured today in the middle of printing "Hana" This could be due to my long usb cable. I did not have this problem when I had the short one on it. Im going to try printing from the s/d card fo awhile and see what happens then....

There are flat, fold-able ferrite cores that can put on the wires to the LCD.
They cost $2.70 each and you would need two of them. Here is a link,
http://www.digikey.com/product-detail/e ... ND/2465452

I am seeing this phenomenon now as well.

1. Rostock 3D Max, Rambo Board, Repetier Host V0.90C, Firmware RepetierMax 0.80
2. I have experienced the printer halting and going into Idle mode with hot end and bed still going 4 times on the same part
3. I have experienced the stoppage at or near the same point using both SD card and USB
4. In USB Host mode I switched to ASCII only and turned on logging and echo
5. The problem occurs most often with Cura sliced files but also with Slicer
6. Problem has occurred with different fill settings on same part at roughly the same place
7. When running in echo mode and logging the commands were echoed properly up until the printer halts and then no echo

The last run was a USB host controlled dry run to keep from wasting even more filament and I cranked the speed up to 300%.
It once again stopped at roughly the same place - at least on the same layer and the printer stopped, went into idle mode,unresponsive to further host commands.

The following are the data I collected


Last few commands in the log were:
< 15:29:03.796 : N58286 G1 X-0.3 Y-30.44 E4385.853 F3600 *20
> 15:29:03.922 : Echo:G1 X-7.75 Y-22.57 E4385.7128 F3600.00
> 15:29:03.922 : ok 58286
< 15:29:03.924 : N58287 G0 X-0.35 Y-30.4 F6000 *105
> 15:29:03.987 : Echo:G0 X-8.21 Y-22.53 F6000.00
> 15:29:03.989 : ok 58287
< 15:29:03.998 : N58288 G1 X0.17 Y-30.92 E4385.862 F3600 *11
> 15:29:04.159 : Echo:G1 X-0.30 Y-30.44 E4385.8530 F3600.00
> 15:29:04.163 : ok 58288
< 15:29:04.165 : N58289 G0 X-0.1 Y-3

You can see the echoes are about 2 lines behind.

This corresponds to this section of the gcode file
at about line 57794

G1 F3600 X-7.75 Y-22.57 E4385.71319
G0 F6000 X-8.21 Y-22.53
G1 F3600 X-0.30 Y-30.44 E4385.85271
G0 F6000 X-0.35 Y-30.40
G1 F3600 X0.17 Y-30.92 E4385.86189
G0 F6000 X-0.10 Y-31.07

Now if you only looked at the end of the log file you might be tempted to think the host just quit
sending in midstream - and you would be wrong.

The log differs from the Host console when the printer actually stopped
The host console leading up to the stoppage has the following:

N58303 G0 X-4.54 Y-29.18 F6000 *82
Echo:G1 X-11.97 Y-21.33 F6000
N58304 G1 X-37.41 Y3.69 E4387.188 F3600 *2
Echo:G1 X-4.27 Y-29.02 E4386.6079 F3600
N58305 G0 X-37.35 Y3.63 F6000 *122
Echo: G0 X-4.54 Y-29.18 F6000
N58306 G1 X-38.04 Y4.32 E4387.2 F3600 *4

which corresponds to the following chunk of the gcode file starting at line number 57813

G0 F6000 X-4.54 Y-29.18
G1 F3600 X-37.41 Y3.69 E4387.18797
G0 F6000 X-37.35 Y3.63
G1 F3600 X-38.04 Y4.32 E4387.20015
G0 F6000 X-38.04 Y3.90

So the last command - line 58306 was sent complete to the printer but it never sent a response or echo from the
previous command.

Since it occurs with both the SD and USB host mode and at roughly the same place I'm inclined to believe
it is not USB cable or noise related.

There doesn't seem to be any spurious or extraneous characters in the gcode file

These are the most finely sliced parts and geometrically complex parts we have made to date and the file
lengths are much longer than any previous parts.

I'm inclined to believe it is a firmware problem.

To this point Cura has produced much better results for us than Slicer, however the same part was sliced in Slicer and while the result was much uglier, it also stopped in mid print.

I'm open to suggestions of other things to try. I've tried most of the recommendations in this and other threads. I think I'm abut to try Marlin.

can you post the gcode? I wouldn't mind trying it in dry mode to see if I can replicate it on my machine. I have the same firmware and rephost version...

The code can be downloaded from my web site. It is a replacement head for the Rostock to mount dual E3D extruders. I will eventually post it to thingiverse when complete and working.

http://www.celeritous.com/Public/Rostock_E3D_Head.zip

It contains the .STL file as well as the two sliced gcode files from Cura. One for 0.1mm layers 100% fill and one for 0.1mm thick layers 50% fill.

The head temp is set to 212C for T-Glase and bed to 70C - but you are dry running

it always stops around layer 24-25 about 2.5mm thick

cool. ill give it a shot tomorrow and let you know

lordbinky wrote:I had my LCD cables removed (the adapter still plugged into the Rambo) and doing calibration scripts and the Rambo just locked up. I am using the developer build of the Repetier firmware, although the board would do that occasionally on the release versions with the LCD plugged in (the screen would just sit there reading printing..). The board has plenty of cooling so it is unlikely a heat issue. *shrugs* Tis a mystery, My prints have been going well though.


I have since reconnected my LCD, I went ahead and went for full shielding on the cables. Nothing fancy... really, if I wanted to be patient I'd order a roll of conductive adhesive copper tape and do a real shielding job, but I the other way. I tightly rolled (folded?) aluminum foil around the cables, wrapped some stripped copper wire ( I just used magnet wire because it was in reach) around the aluminum for a crappy just good enough connection and tied those grounding wires to the PSU ground from the conveniently accessible power switch. Cables are insulated with Kapton tape (the foil gives it that shiny yellow space age feel) and I didn't burn off the enamel where the ground wire would be exposed. So far nothing adverse happened, it's hard to show it is working when the problem is sporadic.

Just be really careful with the conductive shielded foils and your wiring. I had an experience in the past shielding things where I carelessly (read, totally my own fault) on a none 3D printer related project where I shorted out my electronics.

Flateric wrote:

lordbinky wrote:I had my LCD cables removed (the adapter still plugged into the Rambo) and doing calibration scripts and the Rambo just locked up. I am using the developer build of the Repetier firmware, although the board would do that occasionally on the release versions with the LCD plugged in (the screen would just sit there reading printing..). The board has plenty of cooling so it is unlikely a heat issue. *shrugs* Tis a mystery, My prints have been going well though.


I have since reconnected my LCD, I went ahead and went for full shielding on the cables. Nothing fancy... really, if I wanted to be patient I'd order a roll of conductive adhesive copper tape and do a real shielding job, but I the other way. I tightly rolled (folded?) aluminum foil around the cables, wrapped some stripped copper wire ( I just used magnet wire because it was in reach) around the aluminum for a crappy just good enough connection and tied those grounding wires to the PSU ground from the conveniently accessible power switch. Cables are insulated with Kapton tape (the foil gives it that shiny yellow space age feel) and I didn't burn off the enamel where the ground wire would be exposed. So far nothing adverse happened, it's hard to show it is working when the problem is sporadic.

Just be really careful with the conductive shielded foils and your wiring. I had an experience in the past shielding things where I carelessly (read, totally my own fault) on a none 3D printer related project where I shorted out my electronics.

Let us know the results of the shielding, here's hoping that it stops the problems.

Mine has recently been doing this quite a lot. However it only does it when I need to use support material....Very strange. No idea why it is doing it, however it has done well when printing models that do not need the support. I am using Slic3r.

My quick and dirty shielding has been working so far. Ferrites are still cheaper/simpler solution. I didn't cover the cables 100% , but you can see the red enamel wire in one of the pictures. I just did this quickly (and lazily ) so I burned off 2 inches of the enamel, cleaned the wire and wrapped it around the foil. It'd be better if it was copper foil instead of aluminum foil, and I soldered it to the copper. I then attached the other end of the wire to the ground (ok, it wasn't the ground wire itself, but circuit wise it's the same point). Yes this needs some TLC, I keep telling myself I'll clean up the wiring. Little do I know, I'm a good liar .

Thats interesting that the shielding would make a difference. Why would the addition of support material cause it to " freeze" 2/3 way through ? Anyone else had this issue exclusively with models that have support?

chbeckdb9 wrote:Thats interesting that the shielding would make a difference. Why would the addition of support material cause it to " freeze" 2/3 way through ? Anyone else had this issue exclusively with models that have support?

A lot of people have been experiencing the freezing problem and it appears to happen at random times depending on what each individual is doing with his printing.
The shielding helps because it stops a lot of the spurious EMF or other electronic "noise". It can usually can be solved with the addition of ferrite cores on the cables
to the LCD but the Lord prefers the Gold look.

Since I have now switched and intend to stay with the 32microstep drivers I have for now totally ditched the LCD completely from my printer. The lost overhead to the LCD and it's functions along with the increase in noise (possibly anyways, still speculation with growing proof positive anyways) related hangups made it not worth the benefits of having a LCD. I do miss it's features during every single print too however. But prefer my porints to complete more often over these features.

Noise is a random process and I would expect a noise based problem to occur most any time from seconds after starting to seconds before finishing. I used to create large amounts of noise for a living building big lasers and have spent a lot of time dealing with noise shielding and mitigation in control electronics.

Likewise with heat. My print stops about the same place whether the bed is heated on not so I don't think the heat contribution of the bed to the electronics compartment is a big factor. I will instrument it next time I do a run but I've never noticed it very warm in there even after a long run.

This seems more deterministic than noise, occurring only after some minimum amount of time into a print and beyond.

I'm trying an experiment today and would be interested in anybody else that has a good idea of where in the code the print stops to try it.

I'm taking the various files that halt printing, finding roughly where they halt printing and truncating the gcode file there and saving it to see if there is any correlation between file size or number of command lines and where the print halts.

Most people report a similar amount of time before halting with the exceptions being far into the print at 6-8 hours or so. If the problem is related to processing a certain number of commands or lines of code then the halt times would be similar. The halts experienced longer in time into a print may be simply functions of slower printing speed.

Certainly taking a model that had previously printed and adding support would make the file size much larger. If this is a factor it would cause the print to halt.

As a point of reference - the main file I've been having problems with is about 6,126 KB in length
When I truncate it where the code stops processing it is 1,684 KB.

Looking at most of my files that have printed without halting they are typically much smaller than that.

A couple of other files I've had problems with I went back and checked and they were around 2,000 KB.

One was a pair of end caps I tried to print together with a file size of 2,255 KB and the printer would halt about 3/4 of the way through. When I split them up into separate files they printed just fine.

I'm going to do some more dummy runs on other files I've had problems with and see if there is any correlation between the file size or number of command lines at the point the code halts.

I'd be interested in anyone else's numbers on this.

Ok so I did some experimenting. I tried both gcodes you provided (100fill and 50 fill) and got it to freeze on both.

Then i took the stl, sliced it myself with cura and got it to freeze both through usb and through sd card.

When on USB, I got these error messages in the console right before it froze...
Tried it 3 different times, same result. It starts to bog down on the buffer and then freezes but keeps temps on and is unresponsive to anything except a hard reset.

Then, I tried slicer. No issue. Printed (dry run) straight through.

So then I tried to slice some STLs that I know print fine when sliced with slicer. Same result - froze up in exactly the same way. SD card made no difference - still froze.

I can 100% guarantee there is no noise on my machine. All stepper wires were wrapped in aluminum foil and secured with heatshrink, as were all endstop wires.

Very strange, but it seems like there's something in Cura that isn't working correctly. Gonna try to use an older version of Cura...

Not sure what that does to the conversation as I haven't been following the whole thread, but hopefully it helps in some way.

Thanks cope413! It proves (to me at least) the problem is deterministic and repeatable, therefore solvable!

Did you happen to notice the file sizes of the sliced files that worked vs the ones that quit?

Most of the files with equivalent settings I have done have come out about the same or larger for Slicer over Cura.

Sorry, I just re-read my post and I wasn't super clear about what I found. Cura was the only common thread in the freezes. Nothing I sliced with slic3r froze... I tried a file that's 28mb and 1 that's 1.8mb. I tried a few different settings on each too. Haven't had time to look for an older version of cura.

Interesting......Thanks for the clarification. I'll go back and re-run some tests with Slicer. I've liked the results from Cura better overall - much cleaner, less stringy prints. I'll try a dry run on a Slicer file I just generated today that was about 5MB.

After moving the printer to its final location, attaching it to a new computer, setting Repetier up all over again and recalibrating the bed height and leveling I got a chance to run some more tests with Cura.

My first test was to generate identical setting files under all of the Cura versions back to 12.10 and start trying dry runds working backwards from 13.04

The 13.04 dry run made it well past the layers where 13.06 halted, but I didn't get to run to completion - wife wanted to go home.

I saw 13.10 was out so I tried it yesterday. It made it about 75% through the print and halted. So things haven't improved.

Today I'm retrying the 13.04 and working backwards again.

I did a dry run with a Cura 13.03 sliced file. It also stopped about 25% of the way in on a dry run but I captured the following when it halted.

13:26:53.689 : N128146 G1 F2400 *80
13:26:53.689 : N128147 G1 E176.2913 *67
13:26:53.720 : Echo:G1 X-16.85 Y-15.16 E176.2490
13:26:53.720 : ok 62603
13:26:53.720 : N128148 G1 F9000 *81 <--------------------------- Last Command RamBo Echoed
13:26:53.767 : Echo:G1 X-16.35 Y-14.86 E176.2654
13:26:53.767 : ok 62604
13:26:53.798 : Echo:G1 X-16.42 Y-13.94 E176.2913
13:26:53.798 : ok 62605
13:26:53.798 : Echo:G1 F2400.00
13:26:53.798 : N128149 G1 X-42.275 Y-15.625 Z2.95 E176.3631 F1800 *68 <--------- Apparently the command line RamBo choked on
13:26:53.798 : ok 62606
13:26:53.798 : Echo:G1 E171.7913
13:26:53.798 : ok 62607
13:26:53.798 : Echo:G1 F1800.00
13:26:53.798 : N128150 G1 X-42.275 Y-20.175 E176.4908 *79
13:26:53.798 : ok 62608
13:26:53.798 : N128151 G1 X-39.716 Y-20.175 E176.5626 *64
13:26:53.829 : Echo:G1 X-35.02 Y-16.04 Z2.95 F9000.00
13:26:53.829 : ok 62609
13:26:53.829 : N128152 G1 X-39.716 Y-15.625 E176.6903 *76
13:26:53.861 : Echo:G1 X-41.94 Y-16.04
13:26:53.861 : ok 62610
13:26:53.861 : N128153 G1 X-40.291 Y-16.037 F9000 *87
13:26:53.892 : Echo:G1 X-39.72 Y-15.63
13:26:53.892 : ok 62611
13:26:53.892 : Echo:G1 F2400.00
13:26:53.892 : ok 62612
13:26:53.892 : Echo:G1 E176.2913
13:26:53.892 : ok 62612
13:26:53.892 : N128154 G1 X-40.081 Y-16.322 E176.7002 F1800 *42
13:26:53.892 : N128155 G1 X-40.081 Y-16.817 E176.7141 *79
13:26:53.892 : Echo:G1 F9000.00 <---------------------------------- Last Command RamBo Echoed
13:26:53.892 : ok 62612
13:26:53.892 : Unknown command:
13:26:53.892 : Echo:
13:26:53.907 : Error:Binary cmd wrong checksum.
13:26:53.907 : Resend:62613
13:26:53.907 : N128156 G1 X-40.9 Y-16.847 E176.7371 *72
13:26:53.939 : ok
13:26:53.939 : Unknown command:
13:26:53.939 : Echo:
13:26:53.939 : Error:Binary cmd wrong checksum.
13:26:53.939 : Resend:62613
13:26:53.939 : ok
13:26:53.939 : Resend: N128149 G1 X-42.275 Y-15.625 Z2.95 E176.3631 F1800 *68 <---- Repetier tries to re-send line but Rambo is already locked up

13:26:53.939 : Resend: N128150 G1 X-42.275 Y-20.175 E176.4908 *79
13:26:53.939 : Resend: N128151 G1 X-39.716 Y-20.175 E176.5626 *64
13:26:53.939 : Resend: N128152 G1 X-39.716 Y-15.625 E176.6903 *76
13:26:53.939 : Resend: N128153 G1 X-40.291 Y-16.037 F9000 *87
13:26:53.939 : Resend: N128154 G1 X-40.081 Y-16.322 E176.7002 F1800 *42

This is the first time I've seen this. I'm going to have my software guy look at the checksum and error handling routine in the firmware