Printer goes idle mid print

[Highcooley]

Sorry, me again :-)

I had this issue twice and another RAMBO / Rostock Max user reported the same. After a couple of hours of printing (2-5 h), the printer stops mid print and goes idle. All heaters stay on and Repetier host considers the job to be done (no errors & idle).

The way I see it, there could be two explanations. One: Neither the firmware nor the host reports any error if the USB connection gets lost. Both just reconnect and the host quits the print job. Two: Somehow, the firmware starts running through the G-Code without executing it at max speed, until the host sent the last line. Then both, the firmware and the host consider the job as done.

[jamesarm97]

I have been having this problem for a few months. I just learned to print from SD only if it is a big print. Always hangs with showing 0 buffers on the LCD.

James Armstrong

On Jul 21, 2013, at 1:21 PM, repetier notifications@github.com wrote:

Ok, during the second run I got the hang even with the latest development version. Very strange. If I move position manually on the printer interface the printer moves and the new coordinates get send to the host and updated. So the connection is in deed running as it should.

I can fake ok, so the host sends new commands, but the firmware does ignore them silently. So it must be an error somewhere from the input queue down to the execution of commands. With the interface still intact I assume the main loop is still running. Will try to add a new menu command to send me some debugging informations to see what variables are set during the hang. I think the problem is on the firmware side, since I can see the host putting commands into the serial connection. Now I have to figure out why the firmware ignores new input.

— Reply to this email directly or view it on GitHub.

[kyrreaa]

If you look at one of my earlier posts you can see that I halted the controller and extracted queue data. On mine it runs the loop but never calls the function to step. Den 21. juli 2013 19:21 skrev "repetier" notifications@github.com følgende:

Ok, during the second run I got the hang even with the latest development version. Very strange. If I move position manually on the printer interface the printer moves and the new coordinates get send to the host and updated. So the connection is in deed running as it should.

I can fake ok, so the host sends new commands, but the firmware does ignore them silently. So it must be an error somewhere from the input queue down to the execution of commands. With the interface still intact I assume the main loop is still running. Will try to add a new menu command to send me some debugging informations to see what variables are set during the hang. I think the problem is on the firmware side, since I can see the host putting commands into the serial connection. Now I have to figure out why the firmware ignores new input.

— Reply to this email directly or view it on GitHubhttps://github.com/repetier/Repetier-Firmware/issues/72#issuecomment-21313444 .

[ellindsey]

I tried printing the same part from my laptop, using Pronterface and communicating through Ascii protocol. It froze up, although not quite at the same point in the print, and to be honest I'm not completely certain that it was the printer at fault rather than my laptop. I had switched to a Raspberry Pi based print server because of reliability problems with controlling the printer from my laptop, but in retrospect some of those crashes I had might have been this bug.

[repetier]

Since I could also get a hang with your file if I force it with 300% it is hard to say. But there was something going wrong, when I got the error and it was not the connection.

[luke321]

I got a hang trying to print the new Julia Vase today: http://www.thingiverse.com/thing:126567

i set gap fill in Slic3r to 0 and I am currently trying the print it another time (it's already way further than the last time). The last print I had trouble with hang ups also had very small wall wides so slic3r used gap fill to fill the space between the perimeters. Maybe this very fast vibrating moves are to problem?

edit: the print finished without problems

[bassrock]

@luke321 Did the print finish on its own or did you do something to make it finish?

[repetier]

Last week I discovered, that some communication errors between host and firmware could cause a hang in the firmware. The same error could cause a hang on sd files written over serial interface. These problems are solved in the latest development version.

[luke321]

it finished without me doing anything!

[bassrock]

@repetier Is development stable enough to use?

[repetier]

@bassrock Yes it is. It has less bugs then the stable version. Only the config file may change until final release a bit depending on the final feature set. But all functions working in 0.83 work at least as good.

[bassrock]

Ok thats good to know. Thank you! On Oct 21, 2013, at 9:18 AM, repetier notifications@github.com wrote:

@bassrock Yes it is. It has less bugs then the stable version. Only the config file may change until final release a bit depending on the final feature set. But all functions working in 0.83 work at least as good.

— Reply to this email directly or view it on GitHub.

[daftscience]

Last week I discovered, that some communication errors between host and firmware could cause a hang in the firmware. The same error could cause a hang on sd files written over serial interface. These problems are solved in the latest development version.

Would the log show this communication error if it occurred?

[repetier]

If you are using the latest dev version it will write FormatError instead of ChecksumError for normal transmission errors. The problem was that on that printer the first bit of a command was often lost. But that bit determines if it is a binary command and that caused much confusion, because the binary command in ascii made no real sense.

[kyrreaa]

I blame arduino.

From: repetier Sent: Sunday, November 03, 2013 5:26 PM To: repetier/Repetier-Firmware Cc: kyrreaa Subject: Re: [Repetier-Firmware] Printer goes idle mid print (#72)

If you are using the latest dev version it will write FormatError instead of ChecksumError for normal transmission errors. The problem was that on that printer the first bit of a command was often lost. But that bit determines if it is a binary command and that caused much confusion, because the binary command in ascii made no real sense.

— Reply to this email directly or view it on GitHub.

[daftscience]

I'm not actually getting any communication errors. I thought that had been ruled out in the comments above. The host just stops receiving acks from the printer. This thread had died down, I'm not too sure if people are still getting it or I have a different issue. For me the errors aren't as repeatable as they used to be.

I blame arduino.

If it is arduino could it be a board issue?

[repetier]

In some cases I think the USB-USB connection is the part, that crashes. If the firmware gets nothing it will usually ask for resends or send a wait every second to make the host detect an empty queue. So if nothing comes you could hit reset, which I think only resets the avr not the usb part (might be wrong here). If that still does nothing unplug usb cord. Normally it should start working again as the avr has no power and windows restarts the connection completely. The only question is what part causes this - the arduino board has a good chance. Sometime a better usb cable already helps.

[ellindsey]

I doubt that communication errors have anything to do with the problems I've seen. I would expect communications errors to occur at a random rate regardless of what was being printed. Instead, I see that certain files always hang, and other ones never do. Furthermore, the files that cause the printer to hang will do so whether I am printing from my laptop or from the Raspberry Pi print server.

[daftscience]

In some cases I think the USB-USB connection is the part, that crashes. If the firmware gets nothing it will usually ask for resends or send a wait every second to make the host detect an empty queue. So if nothing comes you could hit reset, which I think only resets the avr not the usb part (might be wrong here). If that still does nothing unplug usb cord. Normally it should start working again as the avr has no power and windows restarts the connection completely. The only question is what part causes this - the arduino board has a good chance. Sometime a better usb cable already helps.

Right, I've had that in the past and have resolved by switching usb cables. But, in the case of this ticket, the firmware is not sending requests. Hitting reset works, but it aborts the print. Unfortunately, at this point I can't trust the firmware with any large prints.

Edit: I wish I knew more about how the firmware works to either give better/more information or to help find the cause of it.

[kyrreaa]

I ment the arduino framework and way of coding leads to issues that may cause this. However, here it may be a never ending sun issue due to 0-value/effect increment. When command-queue is full and current buffered command is never finished the effect is exactly what we experience. I have earlier ran Atmel Studio debugger on this and found the buffers to be full and steps to lead nowhere. To do this I had to use the arduino core as a lib in studio. Without arduino anyone with a cheap debugger could have found this out without a million print statements stuffed in the code. Den 6. nov. 2013 06:14 skrev "Tom" notifications@github.com følgende:

I'm not actually getting any communication errors. I thought that had been ruled out in the comments above. The host just stops receiving acks from the printer. This thread had died down, I'm not too sure if people are still getting it or I have a different issue. For me the errors aren't as repeatable as they used to be.

I blame arduino.

If it is arduino could it be a board issue?

— Reply to this email directly or view it on GitHubhttps://github.com/repetier/Repetier-Firmware/issues/72#issuecomment-27843581 .

[daftscience]

@kyrreaa Do you think the way the code is compiled play into that? Right now I am compiling it using arduino-mk on my beaglebone black.

[kyrreaa]

No. I see no or minor differences. It is however a lot faster and easier to debug in studio. Also studios editor gives fast and accurate overview when working on the code. Arduino editor is a horrible substitute IMHO. Den 6. nov. 2013 15:32 skrev "Tom" notifications@github.com følgende:

@kyrreaa https://github.com/kyrreaa Do you think the way the code is compiled play into that? Right now I am compiling it using arduino-mk on my beaglebone black.

— Reply to this email directly or view it on GitHubhttps://github.com/repetier/Repetier-Firmware/issues/72#issuecomment-27877475 .

[daftscience]

I don't know if this is of interest. This file failed to print the first time ran it. I had the multiplier set to 80%. I did a dry run at 300% and it finished without an issue. I just tried it again, 80% dry run, and it failed around the same place as before.

Right now I am printing it a fourth time but with 80%, dry run and echo comms.

https://www.dropbox.com/s/u3l8jmsyyjb44rn/pins.gcode

[repetier]

@daftscience That sounds like the gcode itself is ok and the processing in general is also ok. But with some bad timing I guess a variable gets changed that better should be interrupt protected and causes the endless loop. Looks like I have to recheck the code again. Biggest problem is that I have no quick or slow test failing for me. I will give your new file a run, but I doubt that with my settings I will get the same stall.

[kyrreaa]

My original testcode does not fail? Speed setting is important though. I notice it can fail at 130 and succeed at 131%. Adding print/echos etch will change everything as then more IO is performed. That is why I am so adamant that this be debugged properly.

I recommend the ICE3 that just came out as it is very cheap.

When I have some time I can go through the code again to see if I can find it but from what I see so far it is calculations relating to accelleration/decelleration vs speed that goes wrong and causes it to never finish. How about adding a check in the code to catch situations where the code/increment will never finish and see if that triggers?

From: repetier Sent: Wednesday, November 06, 2013 6:09 PM To: repetier/Repetier-Firmware Cc: kyrreaa Subject: Re: [Repetier-Firmware] Printer goes idle mid print (#72)

@daftscience That sounds like the gcode itself is ok and the processing in general is also ok. But with some bad timing I guess a variable gets changed that better should be interrupt protected and causes the endless loop. Looks like I have to recheck the code again. Biggest problem is that I have no quick or slow test failing for me. I will give your new file a run, but I doubt that with my settings I will get the same stall.

— Reply to this email directly or view it on GitHub.

[repetier]

I have a JTAG ICE but never managed to get it working:-( And I was so glad that my Rumba boards have a jtag interface. When I get enough time I will try again to get it running.

To your error analysis. As I understand you, bresenhamStep is called repeatedly without ever finishing the current line, right? I checked the code and I can't see how acceleration/deceleration code can influence this. These parts only return different timings. Only reason never to finish a move is stepsRemaining stays > 0. This value is decremented by uint8_t maxLoops = (Printer::stepsPerTimerCall<=cur->stepsRemaining ? Printer::stepsPerTimerCall : cur->stepsRemaining);

All computations of stepsPerTimerCall return 1,2 or 4.

Do you see what path I'm missing to get an infinite loop here? Or do you remember which variable had totally wrong values making it take nearly forever?

[ivanpope]

I am also getting this problem. Reading this board I assumed it was because I was using an older version of Repetier (for Leapfrog Creatr), so I upgraded today to Repetier 0.9, but I'm still having prints fail towards the top on a depressingly regular basis. Everything above seems to apply to me, i.e. there is no logic or precise repeatability to the fail, it doesn't happen at the same point in the Gcode. I had a fail at line 243 of 360 today and then on a different model at 256/394. This is running out of the box settings. Any ideas? Is the Leapfrog version of Repetier upgraded in the same way?

[kyrreaa]

I remember that we could not see any used variables change per iteration so the loop was infinite. Maybe it is a result of a decision thinking there is work vs the worker thinking there is not? Den 6. nov. 2013 18:55 skrev "repetier" notifications@github.com følgende:

I have a JTAG ICE but never managed to get it working:-( And I was so glad that my Rumba boards have a jtag interface. When I get enough time I will try again to get it running.

To your error analysis. As I understand you, bresenhamStep is called repeatedly without ever finishing the current line, right? I checked the code and I can't see how acceleration/deceleration code can influence this. These parts only return different timings. Only reason never to finish a move is stepsRemaining stays > 0. This value is decremented by uint8_t maxLoops = (Printer::stepsPerTimerCall<=cur->stepsRemaining ? Printer::stepsPerTimerCall : cur->stepsRemaining);

All computations of stepsPerTimerCall return 1,2 or 4.

Do you see what path I'm missing to get an infinite loop here? Or do you remember which variable had totally wrong values making it take nearly forever?

— Reply to this email directly or view it on GitHubhttps://github.com/repetier/Repetier-Firmware/issues/72#issuecomment-27896827 .

[3Dconfused]

Would like to add my expieriences as a new Leapfrog/Repetier user to this thread. Have managed only 1 completion from 4 starts with what appear to be failures of communication, but basically the printer just goes idle, heaters on but no commands getting through. Two have been at close to same stage, one earlier. Do not understand the error log well enough to get a listing to follow yet, will have to work on that. Getting very frustrating with 6 hour prints being scrapped half way through.Is there alternative sortware combinations?

[repetier]

That is a bad quote of success. There are many reasons for this, but you are giving no informations to help sorting it out. Did the host close the connection due to too many errors, did it only stop sending data (and did hitting ok next to debug buttons a few times restart it). Or does the host not respond any more, which is aften due to usb hangs.

[3Dconfused]

I thank you for your reply and agree it is a bad success rate, terrible actually.

I cannot give the information that some of the others give because I am not yet sufficiently familiar with the software to have any idea how to attempt to get a restart.

I can say, that in the button in the top LH corner still indicates that the computer is connected, it showed ‘Disconnect’ on each occasion. The bottom bar display in green indicating progress, was still pulsating on the last occasion at least, the display in the Gcode editor of the code was at the top line, just don’t know if it progresses down the code. I haven’t looked. I have been too busy trying to make sure that the print was stuck to the printer bed, and to stop filament tangling. Now that those issues seem to be resolved, I can concentrate on this one. I have contacted my IT person re testing my USB, I am using a new 5m USB 2, cable. I will move the printer closer if I can, but this is an office and the noise is a major problem at 2m. It may take a dedicated new computer if a 2m lead is needed.

The printing has been progressing seemingly without problems , I have everything ticked in the log, I have just worked out how to view it, and I will set another print running. Then I will have the log to send to you I hope. I am still looking for the debug buttons. As I said, I do not have the expertise at that level as many of the people on the group. This has been one enormous learning experience, not what I expected. But I intend to prevail, I have the printer, I reckon I could now build one of the blasted things, certainly know how to improve specific parts of the printer I have from a mechanical engineering point of view. Seems it is now this software that I have to be come familiar with, and once again I thank you for your very speedy reply. Bob Luttrell

From: repetier Sent: Monday, December 23, 2013 9:39 PM To: repetier/Repetier-Firmware Cc: 3Dconfused Subject: Re: [Repetier-Firmware] Printer goes idle mid print (#72)

That is a bad quote of success. There are many reasons for this, but you are giving no informations to help sorting it out. Did the host close the connection due to too many errors, did it only stop sending data (and did hitting ok next to debug buttons a few times restart it). Or does the host not respond any more, which is aften due to usb hangs.

— Reply to this email directly or view it on GitHub.

No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3658/6942 - Release Date: 12/22/13

[repetier]

5m usb can be the problem. Some work good some not. In the host there is window in Printer->Printer Information you see a summary of lines send and errors. Some errors at connection is normal, but after that a good hardware would hold the errors at that value. At least on my printers I can print 100MB without additional error, also I have cable/baudrate combination where errors keep comming. There it is only a question of time until it gets hung completely. But that is a hardware problem caused by unshielded usb cables, long cables, noise etc. If you see errors you will get them with other software too. You could test with a powered usb hub in between and use shorter cables.

[3Dconfused]

Thank you for that information, I have found the window, fantastic to have real visible information. At this early stage of the new print it is 2435 lines, 45088 bytes, 0 errors. I will try a different cable perhaps if the error rate shows it, but having something to show a cause is a start. I have 6 hrs to go, if it completes at a time when the computer is largely not used. It is nighttime here. Bob

From: repetier Sent: Monday, December 23, 2013 10:40 PM To: repetier/Repetier-Firmware Cc: 3Dconfused Subject: Re: [Repetier-Firmware] Printer goes idle mid print (#72)

5m usb can be the problem. Some work good some not. In the host there is window in Printer->Printer Information you see a summary of lines send and errors. Some errors at connection is normal, but after that a good hardware would hold the errors at that value. At least on my printers I can print 100MB without additional error, also I have cable/baudrate combination where errors keep comming. There it is only a question of time until it gets hung completely. But that is a hardware problem caused by unshielded usb cables, long cables, noise etc. If you see errors you will get them with other software too. You could test with a powered usb hub in between and use shorter cables.

— Reply to this email directly or view it on GitHub.

No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3658/6942 - Release Date: 12/22/13

[3Dconfused]

Well that was a surprise. An overnight run, and it went to completion. Printer info 160383 lines, 6026278 bytes, and zero errors. I will immediately run again. This was a slightly different version of the same object, both put through Netfabb. Repetier is saying Idle, heaters have been turned off on completion Not much point sending this log I would think, will see what happens during the day. I think I can exclude the cable, not sure about thinks like power variations, computer misbehaviour, even problems with the code in the other version Bob

From: repetier Sent: Monday, December 23, 2013 10:40 PM To: repetier/Repetier-Firmware Cc: 3Dconfused Subject: Re: [Repetier-Firmware] Printer goes idle mid print (#72)

5m usb can be the problem. Some work good some not. In the host there is window in Printer->Printer Information you see a summary of lines send and errors. Some errors at connection is normal, but after that a good hardware would hold the errors at that value. At least on my printers I can print 100MB without additional error, also I have cable/baudrate combination where errors keep comming. There it is only a question of time until it gets hung completely. But that is a hardware problem caused by unshielded usb cables, long cables, noise etc. If you see errors you will get them with other software too. You could test with a powered usb hub in between and use shorter cables.

— Reply to this email directly or view it on GitHub.

No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3658/6942 - Release Date: 12/22/13

[3Dconfused]

Hello again I have had one print run complete overnight without problem, slightly different version of the same object, and still no errors in the Printer report so it would seem that the cable is not the issue. I decided to set up for a more precise version print, rather than the fast that I did, predicted time 10 hours, but the support structure is also very fine and difficult to get right. It does not stick to itself on the settings that i was using, Extruder first layer 240, then 230, and bed 80. It has failed twice at that point so I have increased the settings in SliCer to 260/240 and 82. There seems to be some difference of opinion on temperatures with ABS. When I attempted to preheat the Printbed and extruder using Manual Control, initially the temperatures started rising, then plateaued and fell. Then I noticed that the log was not ticking over as it does, just a series of Oks to close it for some reason. I now have a copy of this session attached. While it s at a different stage, it seems to be the same process. The LH button still displays a green ‘Disconnect’ and the Blue filed display in the Manual Control screen where I normally monitor things, showed ‘Disconnected’ which has appeared before. There was no error message as the total was still showing 0. The log stopped showing changes, but after i pressed that OK button in the Debug section, it did resume with some basic version information. For what it is worth. About to go again, at least I have a recording, and am sending this to make sure that I am sending the correct information to you to work for a resolution. Bob Luttrell

From: repetier Sent: Monday, December 23, 2013 10:40 PM To: repetier/Repetier-Firmware Cc: 3Dconfused Subject: Re: [Repetier-Firmware] Printer goes idle mid print (#72)

5m usb can be the problem. Some work good some not. In the host there is window in Printer->Printer Information you see a summary of lines send and errors. Some errors at connection is normal, but after that a good hardware would hold the errors at that value. At least on my printers I can print 100MB without additional error, also I have cable/baudrate combination where errors keep comming. There it is only a question of time until it gets hung completely. But that is a hardware problem caused by unshielded usb cables, long cables, noise etc. If you see errors you will get them with other software too. You could test with a powered usb hub in between and use shorter cables.

— Reply to this email directly or view it on GitHub.

No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3658/6942 - Release Date: 12/22/13

[3Dconfused]

Just a quick addition to my previous emails, I have had a frustrating morning and am re-installing Repetier. I found the chart below on Leapfrog and the comment in the bottom LH corner worried me. One print stop happened when I turned on a light to illuminated the work better, it was plugged into the same power board, but just a small room light. A second stoppage happened with the simple movement of a cordless mouse. Is that really possible? We are really grasping at straws to find that sort of problem, I will fire up an old laptop and install Repetier on that, if it will. https://www.lpfrg.com/wp-content/uploads/2012/03/8-Printer-loses-connection-during-print-Troubleshootingtree.pdf Bob

From: repetier Sent: Monday, December 23, 2013 10:40 PM To: repetier/Repetier-Firmware Cc: 3Dconfused Subject: Re: [Repetier-Firmware] Printer goes idle mid print (#72)

5m usb can be the problem. Some work good some not. In the host there is window in Printer->Printer Information you see a summary of lines send and errors. Some errors at connection is normal, but after that a good hardware would hold the errors at that value. At least on my printers I can print 100MB without additional error, also I have cable/baudrate combination where errors keep comming. There it is only a question of time until it gets hung completely. But that is a hardware problem caused by unshielded usb cables, long cables, noise etc. If you see errors you will get them with other software too. You could test with a powered usb hub in between and use shorter cables.

— Reply to this email directly or view it on GitHub.

No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3658/6942 - Release Date: 12/22/13

[repetier]

Yes, it is known that switching lights on/off can be enough to break communication for some light types. A move with a cordless mouse should not suffice, except perhaps if it also enabled a monitor from sleep mode dragging more power. Never had this in my house, but I have a stable power there and not too much load on it. I think it also depends much on the power unit leapfrog uses. In that case a PSU could help shielding your printer from drops. I'm no electrician so these are only guesses, but I heard that light problem before.

[3Dconfused]

Thanks for the confirmation, the light is already out of the system as I had linked it as too strong a coincidence. I would never have thought, and it makes me start to think about the electrical effects involved. Our power is urban, classed as pretty good really, but there will be variations around those situations. As well I think the so called energy saving bulbs are perhaps worse. I will plan another type of lighting.

I am finding an amazing long series of problems, and as I get through one, I hit another. I am starting to feel that 3D printing is just not for me. Some of these are between Repetier and Leapfrog. For example, Leapfrog only have version 0.90 on their site , not 0.95. I would like to get the most up to date version in view of all the issues, but yours doesn’t come set up for the Leapfrog and I am not about to try to do that at this stage.

I have found a control issue, I try to set extruder temperatures higher and as they heat they overshoot and trigger an alarm and shut them down. That seems strange. I am looking to get a higher first layer temperature for my ABS of 260, but it has failed every time. I am using High Quality with Breakaway setting, but am yet to get it to stick properly. Beautifully efficient structure if I can get it to work with ABS. It just is not hot enough to stick to the first layer in my view. I need the high quality print for my output. The fast print is just not good enough. Clearly my target of 260 deg is near the limit for the extruders, but I cannot find that specification anywhere yet. I am going to have to ask. The overrun as they heat up is as much as 20 deg. I am seeking to use 260 first layer and 240 for the rest set in Slicer. I opted to try lower levels, 250, but it ended up running at 220, way too low and the print failed as they all have before. Setting slicer to 0 and adjusting manually is the next option. I always stay on hand for the first layer.

Beginning to think that I am an OCD for keeping going, but something is not right in there. My power will never be like in a big commercial business. Each circuit in the house will have around 15 outlets, and an unknown number of devices. That is a big challenge to smooth.

Bob

From: repetier Sent: Tuesday, December 24, 2013 6:24 PM To: repetier/Repetier-Firmware Cc: 3Dconfused Subject: Re: [Repetier-Firmware] Printer goes idle mid print (#72)

Yes, it is known that switching lights on/off can be enough to break communication for some light types. A move with a cordless mouse should not suffice, except perhaps if it also enabled a monitor from sleep mode dragging more power. Never had this in my house, but I have a stable power there and not too much load on it. I think it also depends much on the power unit leapfrog uses. In that case a PSU could help shielding your printer from drops. I'm no electrician so these are only guesses, but I heard that light problem before.

— Reply to this email directly or view it on GitHub.

No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3658/6945 - Release Date: 12/23/13

[repetier]

I just see you are posting this in the repetier-firmware issue tracking. Are you sure leapfrog uses that firmware? I'm quite sure they use Marlin. They did for sure, when I visited them. The overshoot is quite normal for PID control and depends on your firmware settings, but I'm no marlin expert. Do they say leapfrog is able to handle ABS officially? In that case 260°C is bit low as maximum concerning the overshoot problem.

Concerning 0.95. It is very new and as soon as I get the new slic3r profiles for the SLic3r RC1 they will also update to 0.95.

[3Dconfused]

Hi Repetier I was supplied with Repetier and Arduino and have just today re-installed Repetier it from their site in view of all the difficulties I am having, to use the word nightmare would not be an overstatement as I struggle to get consistent. Seems power fluctuations could be involved in my issues of discontinued prints, or at least a couple. I know one is likely to be from the printer end. The others seem less easy to explain. ABS is the base material that has been suggested for use as I understand it, but I am seeking to venture to others. Certainly the Australian site selling the unit, sold me the ABS and lists it among a series of plastics. The list is ABS, PLA, PVA, HIPS, PET, NYLON If Marlin is a comparable product, it may dodge some of the issues that i am having, just by chance. I see many things that I am trying to control as happening by chance, the flick of a power switch certainly is, and it could be elsewhere in the house. Some power protection device seems needed for my situation. I have an old unit, but it is noisy.

I am pleased to see that you are working to get the 0.95 version to the Leapfrog website download/update.

Regarding the temperatures, I am having trouble getting support structure to stick so am gradually taking temperatures up. That is why I am looking for the 260 for the first layer, then 240. I watched the temps, and it peaked at 279 in the overrun past 260. I have just found that max temp for the extruders is 275 deg, so this is my problem. Getting the maximum temperature possible for the second layer actually as that is where the failure is happening. I clearly have to avoid that overrun, I will next just try setting both at 250. I have tried unsuccessfully to do this control from within Repetier which seemed logical. Thanks for the interest, all suggestions help at a frustrating time. I will check Marlin out. Bob Luttrell

From: repetier Sent: Tuesday, December 24, 2013 10:43 PM To: repetier/Repetier-Firmware Cc: 3Dconfused Subject: Re: [Repetier-Firmware] Printer goes idle mid print (#72)

I just see you are posting this in the repetier-firmware issue tracking. Are you sure leapfrog uses that firmware? I'm quite sure they use Marlin. They did for sure, when I visited them. The overshoot is quite normal for PID control and depends on your firmware settings, but I'm no marlin expert. Do they say leapfrog is able to handle ABS officially? In that case 260°C is bit low as maximum concerning the overshoot problem.

Concerning 0.95. It is very new and as soon as I get the new slic3r profiles for the SLic3r RC1 they will also update to 0.95.

— Reply to this email directly or view it on GitHub.

No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3658/6945 - Release Date: 12/23/13

[kyrreaa]

This is almost definitely the same issue I found earlier. You should run beta or dev to avoid it. It is not a com error but a problem with the job queue etc that apparently is fixed in dev.

Even slight changes in printer acc settings could make this issue appear and disappear. Run a later dev and it appears gone. Den 24. des. 2013 14:21 skrev "3Dconfused" notifications@github.com følgende:

Hi Repetier I was supplied with Repetier and Arduino and have just today re-installed Repetier it from their site in view of all the difficulties I am having, to use the word nightmare would not be an overstatement as I struggle to get consistent. Seems power fluctuations could be involved in my issues of discontinued prints, or at least a couple. I know one is likely to be from the printer end. The others seem less easy to explain. ABS is the base material that has been suggested for use as I understand it, but I am seeking to venture to others. Certainly the Australian site selling the unit, sold me the ABS and lists it among a series of plastics. The list is ABS, PLA, PVA, HIPS, PET, NYLON If Marlin is a comparable product, it may dodge some of the issues that i am having, just by chance. I see many things that I am trying to control as happening by chance, the flick of a power switch certainly is, and it could be elsewhere in the house. Some power protection device seems needed for my situation. I have an old unit, but it is noisy.

I am pleased to see that you are working to get the 0.95 version to the Leapfrog website download/update.

Regarding the temperatures, I am having trouble getting support structure to stick so am gradually taking temperatures up. That is why I am looking for the 260 for the first layer, then 240. I watched the temps, and it peaked at 279 in the overrun past 260. I have just found that max temp for the extruders is 275 deg, so this is my problem. Getting the maximum temperature possible for the second layer actually as that is where the failure is happening. I clearly have to avoid that overrun, I will next just try setting both at 250. I have tried unsuccessfully to do this control from within Repetier which seemed logical. Thanks for the interest, all suggestions help at a frustrating time. I will check Marlin out. Bob Luttrell

From: repetier Sent: Tuesday, December 24, 2013 10:43 PM To: repetier/Repetier-Firmware Cc: 3Dconfused Subject: Re: [Repetier-Firmware] Printer goes idle mid print (#72)

I just see you are posting this in the repetier-firmware issue tracking. Are you sure leapfrog uses that firmware? I'm quite sure they use Marlin. They did for sure, when I visited them. The overshoot is quite normal for PID control and depends on your firmware settings, but I'm no marlin expert. Do they say leapfrog is able to handle ABS officially? In that case 260°C is bit low as maximum concerning the overshoot problem.

Concerning 0.95. It is very new and as soon as I get the new slic3r profiles for the SLic3r RC1 they will also update to 0.95.

— Reply to this email directly or view it on GitHub.

No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3658/6945 - Release Date: 12/23/13

— Reply to this email directly or view it on GitHubhttps://github.com/repetier/Repetier-Firmware/issues/72#issuecomment-31171350 .

[nixta78]

Here I am, two years late to this thread's party! But it actually helped me tremendously, so I wanted to post what I found. I just bought a Boots Industries BI V2.5 printer (a cool delta printer from Kickstarter; now they are out of business basically) and had a similar issue described in this thread. The firmware it has is a custom copy of Repetier 0.91. I haven't spent the time to see if it's the newest flavor of 0.91, but I did do a lot of experimentation and came up with a workaround for the bug described above.

Symptoms: I hit Print and it runs about 27 lines of code and just sits there waiting. The LCD says "Buf: 3" and the laptop shows no communication from the firmware. So the firmware is just waiting for something to happen, but never does. When the steppers finally timeout, communication resumes. This happens either with SD card prints or from the laptop.

What I had changed: I had re-calibrated the horizontal offset and the rod length, so I wondered if the EEPROM had been screwed up. I restored to factory defaults, and it started printing again!

So, I began changing EEPROM settings one by one until I found what caused it. Turns out it isn't one particular thing, it's likely a geometry calculation that gets out of bounds or something. So by altering the horizontal radius and rod length, it caused the firmware to hang up.

Ideal fix: Firmware update (maybe already fixed in 0.91.7 or whatever).

Workaround: I found that if I set Extruder 2's X and Y offsets to 1 (instead of the zeros I had), and also set the tower offsets for X, Y, and Z to 1 (instead of the default zeros) that got me back printing with my custom settings!

Perhaps this will help somebody in a similar boat. These delta printers can be really frustrating to calibrate, not to mention repairing broken parts and eliminating slop, but they are pretty rewarding when they work well. Good luck everybody!

[frank16]

I had the issue for quite a while on a K8200 with several different design electronics boards. It is solved now, this is what I did, I hope it helps someone: 1- my computer was a mini pc with a laptop supply. So, it had no earth connection. Nor did the laptop supply of my printer. Your whole printer + pc setup does need one though, not just to fight electrical noise but also for electrical safety. If a supply fails its mains isolation you would appreciate its current going to mains earth via a wire instead of your body. In electrical design a good grounding system always has a single common mounting point for all the minus and earth wires (called star point). In our case this common point is the electronics board of the printer. From this point the grounds go out via the circuit board terminals, then via the minus wires of my new 12V and 24V supplies to the mains earth (internally via the supplies themselves) and via the USB connector and the shielding of the USB cable to my PC. Looks like a star, hence the name... If both your PC and Printer have earth terminals on their supplies make sure to plug them into the same mains terminal block!!!

2- My PC had a USB3.0 connection to my printer's USB2.0 chip. BIG NO NO. Should work in theory, but the FTDI chip used in the printer control board doesn't seem to like it much (different protocol negotiations that are only supposedly backwards compatible, I think). I used a nice new shielded 3m long USB2 cable into a USB2 socket in my computer.

1. Windows has a power setting for USB that allows it to drop power after a while if it thinks USB is not used. It will start that up again if the driver has new data to send, but who knows how quickly and if the protocol re-negotiations mess with the rather simple serial connection between FTDI chip and printer controller board. I turned that off in the advanced power settings. Not sure that helps, didn't hurt either...

After this I NEVER had an another mid-print stoppage.

So, in short: Use a printer power supply with earth connection if your computer doesn't have one. Use a shielded USB2 cable of no more than 3 meter. DO NOT USE A USB3 output of your computer. Turn of the USB power setting control in Windows advanced power settings.