New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Printer goes idle mid print #72

Open
Highcooley opened this Issue Feb 12, 2013 · 92 comments

Comments

Projects
None yet
@Highcooley

Highcooley commented Feb 12, 2013

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.

@repetier

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Feb 12, 2013

Owner

If you have such errors enable logging. So you can check afterwards what happend. If the firmware did a reset you can see a "start" somewhere in the log. But in this case I wouldn't expect the heaters to be still on. After a reset of the board they are off until said by the host. That could be explained if the host received a "start" that didn't come from a reset. Not sure how this could be done.

The log should also show if it executed until the end. It the moment i have no idea what could cause this and leave both connected and still responsive as I understand. If you see something in the log let me know. Also it may take some time til I respond (holiday).

Owner

repetier commented Feb 12, 2013

If you have such errors enable logging. So you can check afterwards what happend. If the firmware did a reset you can see a "start" somewhere in the log. But in this case I wouldn't expect the heaters to be still on. After a reset of the board they are off until said by the host. That could be explained if the host received a "start" that didn't come from a reset. Not sure how this could be done.

The log should also show if it executed until the end. It the moment i have no idea what could cause this and leave both connected and still responsive as I understand. If you see something in the log let me know. Also it may take some time til I respond (holiday).

@Highcooley

This comment has been minimized.

Show comment
Hide comment
@Highcooley

Highcooley Feb 12, 2013

Ok, one last question...where and how to enable logging? Firmware ore just "echo" in host debug options?

Enjoy your hols!!

Highcooley commented Feb 12, 2013

Ok, one last question...where and how to enable logging? Firmware ore just "echo" in host debug options?

Enjoy your hols!!

@repetier

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Feb 12, 2013

Owner

I mean logging in the host. Config- Repetier settings. This stores a log with all communication in the workdir. Every restart of the host deletes the old log, so save it if needed.

Owner

repetier commented Feb 12, 2013

I mean logging in the host. Config- Repetier settings. This stores a log with all communication in the workdir. Every restart of the host deletes the old log, so save it if needed.

@Highcooley

This comment has been minimized.

Show comment
Hide comment
@Highcooley

Highcooley Feb 19, 2013

Ok, last time when printing from the PC, I activated the log. Unfortunately, this only worked after restart of the host. So, I wasn't able to log the fail. However, I checked the last lines of the communication protocol and there is nothing unusual. The host sends the last GCODE lines and waits for the firmware to request the next lines, which never happens. So, the host stays in print mode and keeps counting the time till print end. On the other side, the firmware stops moving the motors, shows idle, keeps the temperatures set and responds to any command through the LCD controller input.

I've got four aborted prints now. Three of them are from the same KISSLICER GCode. All three prints aborted during layer 90.
The last print was from the SD card, so the USB definitely didn't cause this. The PC was off anyway, so there is no possibility, that there was a faulty code sent over USB. Looking at the GCODE, I cannot find any strange commands either. There are only FAN on/off, G1 positioning, extruding, retracting and motor speed setting commands, next to ";" comment lines.

The only explanation which remains is, that it could be some stack overflow problem. The 90th layer starts on line 897'944 in the code. This doesn't ring a bell concerning stack overflow due to max variable ranges. However, this is GCODE including comment lines. I don't know how many lines there would be without empty and comment lines.

The GCODE can be found in this forum post for inspection: http://forum.seemecnc.com/viewtopic.php?f=54&t=1046&start=60#p5501

Highcooley commented Feb 19, 2013

Ok, last time when printing from the PC, I activated the log. Unfortunately, this only worked after restart of the host. So, I wasn't able to log the fail. However, I checked the last lines of the communication protocol and there is nothing unusual. The host sends the last GCODE lines and waits for the firmware to request the next lines, which never happens. So, the host stays in print mode and keeps counting the time till print end. On the other side, the firmware stops moving the motors, shows idle, keeps the temperatures set and responds to any command through the LCD controller input.

I've got four aborted prints now. Three of them are from the same KISSLICER GCode. All three prints aborted during layer 90.
The last print was from the SD card, so the USB definitely didn't cause this. The PC was off anyway, so there is no possibility, that there was a faulty code sent over USB. Looking at the GCODE, I cannot find any strange commands either. There are only FAN on/off, G1 positioning, extruding, retracting and motor speed setting commands, next to ";" comment lines.

The only explanation which remains is, that it could be some stack overflow problem. The 90th layer starts on line 897'944 in the code. This doesn't ring a bell concerning stack overflow due to max variable ranges. However, this is GCODE including comment lines. I don't know how many lines there would be without empty and comment lines.

The GCODE can be found in this forum post for inspection: http://forum.seemecnc.com/viewtopic.php?f=54&t=1046&start=60#p5501

@luke321

This comment has been minimized.

Show comment
Hide comment
@luke321

luke321 Feb 21, 2013

I had the same thing happening yesterday with my Rostock printer with a Megatronics 1.0 board maybe the Delta settings are the cause? I just switched to repetier so I'll need some time to confirm this.

luke321 commented Feb 21, 2013

I had the same thing happening yesterday with my Rostock printer with a Megatronics 1.0 board maybe the Delta settings are the cause? I just switched to repetier so I'll need some time to confirm this.

@luke321

This comment has been minimized.

Show comment
Hide comment
@luke321

luke321 Feb 23, 2013

I succesfully printed some parts now without the printer going idle, but sometimes the print head stops for some milliseconds on edges or when changing the perimiter line, is this buffer related?

luke321 commented Feb 23, 2013

I succesfully printed some parts now without the printer going idle, but sometimes the print head stops for some milliseconds on edges or when changing the perimiter line, is this buffer related?

@repetier

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Feb 23, 2013

Owner

I do not thimk it is an empty buffer. You cannot see that as the next segment is normally send to quick to register. From your description i guess it is the retraction of the extruder that interrupts. This is correct!

Owner

repetier commented Feb 23, 2013

I do not thimk it is an empty buffer. You cannot see that as the next segment is normally send to quick to register. From your description i guess it is the retraction of the extruder that interrupts. This is correct!

@luke321

This comment has been minimized.

Show comment
Hide comment
@luke321

luke321 Feb 24, 2013

It happens when the printer should jump from the first to the second and second to third perimeter, OPS is disabled and minimal retraction travel in slic3r is 2mm, jerk is set to 20mm/s and on Marlin firmware it prints just fine.

luke321 commented Feb 24, 2013

It happens when the printer should jump from the first to the second and second to third perimeter, OPS is disabled and minimal retraction travel in slic3r is 2mm, jerk is set to 20mm/s and on Marlin firmware it prints just fine.

@repetier

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Feb 24, 2013

Owner

@luke321 You are talking about the pauses, right? Between layer swtiches the slicer inserts retractions which take some time. Watch your extruder for retractions in that moment and you see what i mean. Only after retraction is finished the head will go up. Marlin does the same, because the g code contains the commands to do this.

Owner

repetier commented Feb 24, 2013

@luke321 You are talking about the pauses, right? Between layer swtiches the slicer inserts retractions which take some time. Watch your extruder for retractions in that moment and you see what i mean. Only after retraction is finished the head will go up. Marlin does the same, because the g code contains the commands to do this.

@luke321

This comment has been minimized.

Show comment
Hide comment
@luke321

luke321 Feb 24, 2013

No I don't mean retraction pauses, retraction is working fine for me.
It happens when changing the perimeter line sometimes already in the skirt:
stop

for example:

G1 X-13.150 Y-11.800 E6.88994
G1 X-12.830 Y-12.150 E6.90891
G1 X-12.382 Y-12.589 E6.93402
G1 X-12.330 Y-12.640 E6.93691

G1 X-12.010 Y-12.290 F18000.000 before doing this short travel move the printer waits and oozes a lot

G1 X-11.290 Y-12.950 F720.000 E6.97598
G1 X-10.580 Y-13.540 E7.01290
G1 X-10.070 Y-13.920 E7.03834
G1 X-9.260 Y-14.470 E7.07751
G1 X-8.770 Y-14.770 E7.10049

luke321 commented Feb 24, 2013

No I don't mean retraction pauses, retraction is working fine for me.
It happens when changing the perimeter line sometimes already in the skirt:
stop

for example:

G1 X-13.150 Y-11.800 E6.88994
G1 X-12.830 Y-12.150 E6.90891
G1 X-12.382 Y-12.589 E6.93402
G1 X-12.330 Y-12.640 E6.93691

G1 X-12.010 Y-12.290 F18000.000 before doing this short travel move the printer waits and oozes a lot

G1 X-11.290 Y-12.950 F720.000 E6.97598
G1 X-10.580 Y-13.540 E7.01290
G1 X-10.070 Y-13.920 E7.03834
G1 X-9.260 Y-14.470 E7.07751
G1 X-8.770 Y-14.770 E7.10049

@luke321

This comment has been minimized.

Show comment
Hide comment
@luke321

luke321 Feb 24, 2013

I tracked it down it only happens if I adjust the Flowrate with Repetier-Host.

luke321 commented Feb 24, 2013

I tracked it down it only happens if I adjust the Flowrate with Repetier-Host.

@polygonhell

This comment has been minimized.

Show comment
Hide comment
@polygonhell

polygonhell Feb 25, 2013

I just verified the same issue as the OP, running his GCode as a dryrun, on my printer it stops around line 802985 which is layer 84.
The firmware doesn't reset, it's still running, but it's unresponsive to comms, it won't even echo commands back.
The LCD is still responsive, so I assume there is an issue where gcode_next_command is retuning NULL or similar.
Since it uses much of the same path I tried writing the GCode to an SDCard that seems to lose the connection much faster as early as line 2700, it looks like there is a comms error and it never correctly recovers, several seconds late in this case the host stops trying to resend.

polygonhell commented Feb 25, 2013

I just verified the same issue as the OP, running his GCode as a dryrun, on my printer it stops around line 802985 which is layer 84.
The firmware doesn't reset, it's still running, but it's unresponsive to comms, it won't even echo commands back.
The LCD is still responsive, so I assume there is an issue where gcode_next_command is retuning NULL or similar.
Since it uses much of the same path I tried writing the GCode to an SDCard that seems to lose the connection much faster as early as line 2700, it looks like there is a comms error and it never correctly recovers, several seconds late in this case the host stops trying to resend.

@polygonhell

This comment has been minimized.

Show comment
Hide comment
@polygonhell

polygonhell Feb 25, 2013

The following is repeated many times at the end of the log, looks like the command has the wrong checksum and it never recovers.

< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:

2:32:59 PM: N2723 G1 X21.11 Y5.32 E135.3127 *113
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:
< 2:32:59 PM: Error:Binary cmd wrong checksum.
< 2:32:59 PM: Resend:2699
2:32:59 PM: Resend: N2699 G1 E133.1223 *68
2:32:59 PM: Resend: N2700 G1 F806.00 *75
2:32:59 PM: Resend: N2701 G1 X24.37 Y10.34 E133.2856 *74
< 2:32:59 PM: ok
2:32:59 PM: Resend: N2702 G1 X23.88 Y10.17 E133.3076 *64
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:
2:32:59 PM: Resend: N2703 G1 X26.00 Y7.00 E133.4699 *116
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:
2:32:59 PM: Resend: N2704 G1 X25.51 Y6.83 E133.4919 *121
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:
2:32:59 PM: Resend: N2705 G1 X23.39 Y10.00 E133.6542 *76
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:G0
< 2:32:59 PM: Echo:G0
2:32:59 PM: Resend: N2706 G1 X22.90 Y9.83 E133.6762 *126
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:
2:32:59 PM: Resend: N2707 G1 X25.02 Y6.67 E133.8384 *116
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:G0 R0.00
< 2:32:59 PM: Echo:G0 R0.00
2:32:59 PM: Resend: N2708 G1 X24.53 Y6.50 E133.8604 *119
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:
2:32:59 PM: Resend: N2709 G1 X22.41 Y9.67 E134.0228 *125
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:G0
< 2:32:59 PM: Echo:G0
2:32:59 PM: Resend: N2710 G1 X21.92 Y9.50 E134.0447 *115
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:
2:32:59 PM: Resend: N2711 G1 X24.05 Y6.33 E134.2071 *112
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo: E0.0000
< 2:32:59 PM: Echo: E0.0000
2:32:59 PM: Resend: N2712 G1 X23.56 Y6.16 E134.2291 *121
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:
2:32:59 PM: Resend: N2713 G1 X21.43 Y9.33 E134.3913 *118
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:
2:32:59 PM: Resend: N2714 G1 X20.95 Y9.16 E134.4133 *113
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:

polygonhell commented Feb 25, 2013

The following is repeated many times at the end of the log, looks like the command has the wrong checksum and it never recovers.

< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:

2:32:59 PM: N2723 G1 X21.11 Y5.32 E135.3127 *113
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:
< 2:32:59 PM: Error:Binary cmd wrong checksum.
< 2:32:59 PM: Resend:2699
2:32:59 PM: Resend: N2699 G1 E133.1223 *68
2:32:59 PM: Resend: N2700 G1 F806.00 *75
2:32:59 PM: Resend: N2701 G1 X24.37 Y10.34 E133.2856 *74
< 2:32:59 PM: ok
2:32:59 PM: Resend: N2702 G1 X23.88 Y10.17 E133.3076 *64
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:
2:32:59 PM: Resend: N2703 G1 X26.00 Y7.00 E133.4699 *116
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:
2:32:59 PM: Resend: N2704 G1 X25.51 Y6.83 E133.4919 *121
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:
2:32:59 PM: Resend: N2705 G1 X23.39 Y10.00 E133.6542 *76
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:G0
< 2:32:59 PM: Echo:G0
2:32:59 PM: Resend: N2706 G1 X22.90 Y9.83 E133.6762 *126
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:
2:32:59 PM: Resend: N2707 G1 X25.02 Y6.67 E133.8384 *116
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:G0 R0.00
< 2:32:59 PM: Echo:G0 R0.00
2:32:59 PM: Resend: N2708 G1 X24.53 Y6.50 E133.8604 *119
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:
2:32:59 PM: Resend: N2709 G1 X22.41 Y9.67 E134.0228 *125
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:G0
< 2:32:59 PM: Echo:G0
2:32:59 PM: Resend: N2710 G1 X21.92 Y9.50 E134.0447 *115
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:
2:32:59 PM: Resend: N2711 G1 X24.05 Y6.33 E134.2071 *112
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo: E0.0000
< 2:32:59 PM: Echo: E0.0000
2:32:59 PM: Resend: N2712 G1 X23.56 Y6.16 E134.2291 *121
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:
2:32:59 PM: Resend: N2713 G1 X21.43 Y9.33 E134.3913 *118
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:
2:32:59 PM: Resend: N2714 G1 X20.95 Y9.16 E134.4133 *113
< 2:32:59 PM: ok 2698
< 2:32:59 PM: Echo:
< 2:32:59 PM: Echo:

@repetier

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Feb 26, 2013

Owner

To me it looks like the error hots the firmware out of sync. I guess it detected an ascii command while getting binary data. As you see the line does not increase indicating missing checksum and no resend requests, which is only possible in ascii mode, You also see the echo commands don't reflect the commands send. The big question is how a resend data can cause coming out of sync. I think this requires at least an additional transfer error for the first byte which determines if it is ascii or binary (>128 binary)
Can you mail me the gcode part in question. Woud like to see if this is possible with the binary data and hopefully see a solution to detect that problem. I guess i could inforce checksums, making any non checksummed command invalid causing a resend.

Owner

repetier commented Feb 26, 2013

To me it looks like the error hots the firmware out of sync. I guess it detected an ascii command while getting binary data. As you see the line does not increase indicating missing checksum and no resend requests, which is only possible in ascii mode, You also see the echo commands don't reflect the commands send. The big question is how a resend data can cause coming out of sync. I think this requires at least an additional transfer error for the first byte which determines if it is ascii or binary (>128 binary)
Can you mail me the gcode part in question. Woud like to see if this is possible with the binary data and hopefully see a solution to detect that problem. I guess i could inforce checksums, making any non checksummed command invalid causing a resend.

@Highcooley

This comment has been minimized.

Show comment
Hide comment
@Highcooley

Highcooley Feb 26, 2013

This is the GCODE in question: http://forum.seemecnc.com/download/file.php?id=760
So far, three people tried to run it on different Rostock Max printers with RAMBO boards. They all have the same problem around layer 80-90. However, shortening the GCODE and starting e.g. from layer 79 lets the printer run through these layers without a flaw.

Highcooley commented Feb 26, 2013

This is the GCODE in question: http://forum.seemecnc.com/download/file.php?id=760
So far, three people tried to run it on different Rostock Max printers with RAMBO boards. They all have the same problem around layer 80-90. However, shortening the GCODE and starting e.g. from layer 79 lets the printer run through these layers without a flaw.

@polygonhell

This comment has been minimized.

Show comment
Hide comment
@polygonhell

polygonhell Feb 26, 2013

That makes some sense if it were interpreting a binary command as ASCII.
using a single bit to determine ASCII/Binary seems a little dangerous on an unreliable protocol, one option could be to have some bit pattern that explicitly swaps from Binary to ASCII and back, but then you have state in the protocol and the chance to get out of sync.
It's also a little odd that 3 people get the same issue 800K lines into the same print within about 50K lines of each other, though that could be something odd in the USB Serial stack I guess.

polygonhell commented Feb 26, 2013

That makes some sense if it were interpreting a binary command as ASCII.
using a single bit to determine ASCII/Binary seems a little dangerous on an unreliable protocol, one option could be to have some bit pattern that explicitly swaps from Binary to ASCII and back, but then you have state in the protocol and the chance to get out of sync.
It's also a little odd that 3 people get the same issue 800K lines into the same print within about 50K lines of each other, though that could be something odd in the USB Serial stack I guess.

@polygonhell

This comment has been minimized.

Show comment
Hide comment
@polygonhell

polygonhell Mar 2, 2013

I tried forcing ASCII commands and uploaded the file to the SDCard and it succeeds albeit in a little over 4 and a half hours, so I think it's very likely related to the binary protocol.
It's worth noting that error rates were a lot higher than I expected judging by the red text flying by in the terminal window, and seemed to be fairly clumpy, so perhaps there is something in the data pattern that's makes errors more common at certain points in the GCode, which is causing the failure in close proximity for the 3 of us who've tried it.

polygonhell commented Mar 2, 2013

I tried forcing ASCII commands and uploaded the file to the SDCard and it succeeds albeit in a little over 4 and a half hours, so I think it's very likely related to the binary protocol.
It's worth noting that error rates were a lot higher than I expected judging by the red text flying by in the terminal window, and seemed to be fairly clumpy, so perhaps there is something in the data pattern that's makes errors more common at certain points in the GCode, which is causing the failure in close proximity for the 3 of us who've tried it.

@repetier

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Mar 2, 2013

Owner

More errors in ascii protocol make sense, as it needs the double size making it more likely. From your description I take that you get transfer errors on a quite regular basis. I had a board where I also got many error, but only with 115200 baud. With 250000 the errors were gone. One reason that also could be is the dtr signal being high. You could test a emergency stop after open, which will toggle dtr to low. Perhaps this reduces the error rate, also there should be no connection, but I have a user having this problem since 0.80 and that is where I added the dtr toggle.

Owner

repetier commented Mar 2, 2013

More errors in ascii protocol make sense, as it needs the double size making it more likely. From your description I take that you get transfer errors on a quite regular basis. I had a board where I also got many error, but only with 115200 baud. With 250000 the errors were gone. One reason that also could be is the dtr signal being high. You could test a emergency stop after open, which will toggle dtr to low. Perhaps this reduces the error rate, also there should be no connection, but I have a user having this problem since 0.80 and that is where I added the dtr toggle.

@polygonhell

This comment has been minimized.

Show comment
Hide comment
@polygonhell

polygonhell Mar 5, 2013

I just tried this and yes hitting estop after open appears to reduce the error rate. Bizarre.
It does seem though that since the ASCII upload succeeds, the original issue is probably the Binary protocol not being robust enough to handle a significant error rate

polygonhell commented Mar 5, 2013

I just tried this and yes hitting estop after open appears to reduce the error rate. Bizarre.
It does seem though that since the ASCII upload succeeds, the original issue is probably the Binary protocol not being robust enough to handle a significant error rate

@repetier

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Mar 5, 2013

Owner

Well the dtr thing is really bizarre, but ok. Knowing that I will set it back to low on open in the next version.
The binary protocol is quite stable but has one weak point - detecting of a binary command is based on one bit in the first byte. So if exactly this bit is affected, you get problems. I'm still thinking on how to improve detection. One solution is to require a checksum, except for M117, when previous commands hat a checksum. That way a resend would be triggered even if it is wrongly taken as ascii command. The host always inserts checksums and if someone starts with a simple terminal he will most likely not send checksums.

Owner

repetier commented Mar 5, 2013

Well the dtr thing is really bizarre, but ok. Knowing that I will set it back to low on open in the next version.
The binary protocol is quite stable but has one weak point - detecting of a binary command is based on one bit in the first byte. So if exactly this bit is affected, you get problems. I'm still thinking on how to improve detection. One solution is to require a checksum, except for M117, when previous commands hat a checksum. That way a resend would be triggered even if it is wrongly taken as ascii command. The host always inserts checksums and if someone starts with a simple terminal he will most likely not send checksums.

@polygonhell

This comment has been minimized.

Show comment
Hide comment
@polygonhell

polygonhell Mar 5, 2013

That seems like a reasonable solution, the other option would be to add an MCODE to forcibly set the binary protocol on or off.
You'd have to have some way of still reading the ASCII version of that MCODE, so a user could reset it.

polygonhell commented Mar 5, 2013

That seems like a reasonable solution, the other option would be to add an MCODE to forcibly set the binary protocol on or off.
You'd have to have some way of still reading the ASCII version of that MCODE, so a user could reset it.

@repetier

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Mar 6, 2013

Owner

Ok, as a first solution I have added the forced checksum part to the current version. Simply add

/** If a checksum is send, all future comamnds must also contain a checksum. Increases reliability especially for binary protocol. */
#define FEATURE_CHECKSUM_FORCED true

in the config. With true it is enabled. Hope that it helps, but my printer have rarely errors, so only time can tell.

Owner

repetier commented Mar 6, 2013

Ok, as a first solution I have added the forced checksum part to the current version. Simply add

/** If a checksum is send, all future comamnds must also contain a checksum. Increases reliability especially for binary protocol. */
#define FEATURE_CHECKSUM_FORCED true

in the config. With true it is enabled. Hope that it helps, but my printer have rarely errors, so only time can tell.

@polygonhell

This comment has been minimized.

Show comment
Hide comment
@polygonhell

polygonhell Mar 6, 2013

I'll need to merge this into my branch, I'll try and do it later today and let you know.
FWIW with the DTE held low fix I transferred >2Million lines of GCode to the SDCard without a single error, so I can see how this could be hard to repro.

polygonhell commented Mar 6, 2013

I'll need to merge this into my branch, I'll try and do it later today and let you know.
FWIW with the DTE held low fix I transferred >2Million lines of GCode to the SDCard without a single error, so I can see how this could be hard to repro.

@repetier

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Mar 7, 2013

Owner

So the DTR signal seems to have a real effect. For the next release I already changed DTR to low after connect hoping there are no boards getting more errors on a low signal.

Owner

repetier commented Mar 7, 2013

So the DTR signal seems to have a real effect. For the next release I already changed DTR to low after connect hoping there are no boards getting more errors on a low signal.

@TinHead

This comment has been minimized.

Show comment
Hide comment
@TinHead

TinHead Mar 10, 2013

Hi,

I'm the one who had problems on all versions since 0.74, I tried the DTR switch and by magic the bad checksums and resends are gone. :)

Can't reply on the reprap forums as it's down currently.

TinHead commented Mar 10, 2013

Hi,

I'm the one who had problems on all versions since 0.74, I tried the DTR switch and by magic the bad checksums and resends are gone. :)

Can't reply on the reprap forums as it's down currently.

@repetier

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Mar 10, 2013

Owner

I have already changed the sinal to off for the next release. That way no one needs to kill on connect :-) I would still like to know why this makes a difference, but at the end the result counts.

Owner

repetier commented Mar 10, 2013

I have already changed the sinal to off for the next release. That way no one needs to kill on connect :-) I would still like to know why this makes a difference, but at the end the result counts.

@artbotterell

This comment has been minimized.

Show comment
Hide comment
@artbotterell

artbotterell Apr 9, 2013

Hi...

OK, I just developed what seems like this same problem. I'm using Firmware 0.82, freshly downloaded, which appears to have the DTR-ignore function pre-set... and Host 0.85b on Win 7. Our Leapfrog Creatr goes through the usual start-of-job moves, proceeds to the location where it would start extruding the skirt, and then comes quietly to a halt.

EXCEPT... it doesn't do that if I'm in dry run mode. Almost as though the first command to the extruder is triggering the problem. However, I can manually extrude without causing any problem.

Once the printer freezes I can hit the Kill Job button, which seems to change color as expected, but the printer doesn't respond by parking as it should, and the temperature chart is also frozen. And I can't get back manual control without disconnecting and reconnecting. When I reconnect, the temp charts show a linear drop to zero across the time since the freeze, but then rebound to more believable numbers on the next update.

Log file likewise halts abruptly:

21:45:29.372 : FIRMWARE_NAME:Repetier_0.82 FIRMWARE_URL:https://github.com/repetier/Repetier-Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:2 REPETIER_PROTOCOL:2
< 21:45:29.372 : N5 M105 *2
< 21:45:29.373 : N6 M220 S100 *71
21:45:29.381 : Printed filament:14.22 m
21:45:29.381 : Printing time:0 days 4 hours 44 min
21:45:29.381 : ok 2
21:45:29.381 : ok 3
21:45:29.381 : T:0.00 B:0.00 @:0 T0:0.00 @0:0 T1:0.00 @1:0
< 21:45:29.381 : N7 M221 S100 *71
< 21:45:29.382 : N8 M111 S6 *79
21:45

Same behavior on three different objects, none of which are particularly complex.

Any guidance would be greatly appreciated! Thanks!

artbotterell commented Apr 9, 2013

Hi...

OK, I just developed what seems like this same problem. I'm using Firmware 0.82, freshly downloaded, which appears to have the DTR-ignore function pre-set... and Host 0.85b on Win 7. Our Leapfrog Creatr goes through the usual start-of-job moves, proceeds to the location where it would start extruding the skirt, and then comes quietly to a halt.

EXCEPT... it doesn't do that if I'm in dry run mode. Almost as though the first command to the extruder is triggering the problem. However, I can manually extrude without causing any problem.

Once the printer freezes I can hit the Kill Job button, which seems to change color as expected, but the printer doesn't respond by parking as it should, and the temperature chart is also frozen. And I can't get back manual control without disconnecting and reconnecting. When I reconnect, the temp charts show a linear drop to zero across the time since the freeze, but then rebound to more believable numbers on the next update.

Log file likewise halts abruptly:

21:45:29.372 : FIRMWARE_NAME:Repetier_0.82 FIRMWARE_URL:https://github.com/repetier/Repetier-Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:2 REPETIER_PROTOCOL:2
< 21:45:29.372 : N5 M105 *2
< 21:45:29.373 : N6 M220 S100 *71
21:45:29.381 : Printed filament:14.22 m
21:45:29.381 : Printing time:0 days 4 hours 44 min
21:45:29.381 : ok 2
21:45:29.381 : ok 3
21:45:29.381 : T:0.00 B:0.00 @:0 T0:0.00 @0:0 T1:0.00 @1:0
< 21:45:29.381 : N7 M221 S100 *71
< 21:45:29.382 : N8 M111 S6 *79
21:45

Same behavior on three different objects, none of which are particularly complex.

Any guidance would be greatly appreciated! Thanks!

@repetier

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Apr 9, 2013

Owner

Looks like a very repeatable problem for you. Can you mail me the zipped firmware with your configuration. Perhaps I can reproduce it too, which would help finding the problem.

Owner

repetier commented Apr 9, 2013

Looks like a very repeatable problem for you. Can you mail me the zipped firmware with your configuration. Perhaps I can reproduce it too, which would help finding the problem.

@artbotterell

This comment has been minimized.

Show comment
Hide comment
@artbotterell

artbotterell Apr 9, 2013

My firmware source and settings (I've done some in the EEPROM from Host)
are attached. Hope that helps, and thanks for the great packages!

  • Art

On Tue, Apr 9, 2013 at 12:02 AM, repetier notifications@github.com wrote:

Looks like a very repeatable problem for you. Can you mail me the zipped
firmware with your configuration. Perhaps I can reproduce it too, which
would help finding the problem.


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

Art Botterell
Disaster Management Consultant
Associate Director, Disaster Management Initiative
Carnegie Mellon University Silicon Valley
NASA Research Park, Building 23 (MS 23-11)
Moffett Field, CA 94035-0001
office (650) 335-2875
09:34:47.599 : FIRMWARE_NAME:Repetier_0.82 FIRMWARE_URL:https://github.com/repetier/Repetier-Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:2 REPETIER_PROTOCOL:2
09:34:47.599 : Printed filament:14.22 m
09:34:47.599 : Printing time:0 days 4 hours 44 min
artbotterell EEPROM settings 9 Apr 2013

09:35:20.703 : EPR:2 75 115200 Baudrate
09:35:20.703 : EPR:3 129 14.22 Filament printed [m]
09:35:20.718 : EPR:2 125 17062 Printer active [s]
09:35:20.718 : EPR:2 79 0 Max. inactive time [ms,0=off]
09:35:20.734 : EPR:2 83 120000 Stop stepper after inactivity [ms,0=off]
09:35:20.749 : EPR:3 3 33.60 X-axis steps per mm
09:35:20.749 : EPR:3 7 33.60 Y-axis steps per mm
09:35:20.765 : EPR:3 11 1070.50 Z-axis steps per mm
09:35:20.781 : EPR:3 15 200.00 X-axis max. feedrate [mm/s]
09:35:20.796 : EPR:3 19 200.00 Y-axis max. feedrate [mm/s]
09:35:20.812 : EPR:3 23 5.00 Z-axis max. feedrate [mm/s]
09:35:20.827 : EPR:3 27 80.00 X-axis homing feedrate [mm/s]
09:35:20.843 : EPR:3 31 80.00 Y-axis homing feedrate [mm/s]
09:35:20.859 : EPR:3 35 3.00 Z-axis homing feedrate [mm/s]
09:35:20.890 : EPR:3 39 20.00 Max. jerk [mm/s]
09:35:20.905 : EPR:3 47 0.50 Max. Z-jerk [mm/s]
09:35:20.937 : EPR:3 133 0.00 X home pos [mm]
09:35:20.968 : EPR:3 137 0.00 Y home pos [mm]
09:35:20.983 : EPR:3 141 0.00 Z home pos [mm]
09:35:21.015 : EPR:3 145 230.00 X max length [mm]
09:35:21.046 : EPR:3 149 270.00 Y max length [mm]
09:35:21.077 : EPR:3 153 180.00 Z max length [mm]
09:35:21.108 : EPR:3 157 0.00 X backlash [mm]
09:35:21.139 : EPR:3 161 0.00 Y backlash [mm]
09:35:21.139 : EPR:3 165 0.00 Z backlash [mm]
09:35:21.139 : EPR:3 51 500.00 X-axis acceleration [mm/s^2]
09:35:21.139 : EPR:3 55 500.00 Y-axis acceleration [mm/s^2]
09:35:21.155 : EPR:3 59 100.00 Z-axis acceleration [mm/s^2]
09:35:21.155 : EPR:3 63 500.00 X-axis travel acceleration [mm/s^2]
09:35:21.155 : EPR:3 67 500.00 Y-axis travel acceleration [mm/s^2]
09:35:21.155 : EPR:3 71 100.00 Z-axis travel acceleration [mm/s^2]
09:35:21.155 : EPR:0 103 1 OPS operation mode [0=Off,1=Classic,2=Fast]
09:35:21.171 : EPR:3 99 50.00 OPS move after x% retract [%]
09:35:21.171 : EPR:3 43 0.80 OPS min. distance for fil. retraction [mm]
09:35:21.171 : EPR:3 87 1.50 OPS retraction length [mm]
09:35:21.171 : EPR:3 91 0.00 OPS retraction backlash [mm]
09:35:21.171 : EPR:0 106 0 Bed Heat Manager [0-2]
09:35:21.171 : EPR:0 107 255 Bed PID drive max
09:35:21.171 : EPR:0 124 255 Bed PID drive min
09:35:21.171 : EPR:3 108 196.00 Bed PID P-gain
09:35:21.171 : EPR:3 112 33.02 Bed PID I-gain
09:35:21.171 : EPR:3 116 290.00 Bed PID D-gain
09:35:21.171 : EPR:0 120 255 Bed PID max value [0-255]
09:35:21.171 : EPR:3 200 50.00 Extr.1 steps per mm
09:35:21.171 : EPR:3 204 15.00 Extr.1 max. feedrate [mm/s]
09:35:21.171 : EPR:3 208 10.00 Extr.1 start feedrate [mm/s]
09:35:21.171 : EPR:3 212 4000.00 Extr.1 acceleration [mm/s^2]
09:35:21.171 : EPR:0 216 1 Extr.1 heat manager [0-1]
09:35:21.171 : EPR:0 217 140 Extr.1 PID drive max
09:35:21.171 : EPR:0 245 60 Extr.1 PID drive min
09:35:21.171 : EPR:3 218 6.16 Extr.1 PID P-gain
09:35:21.171 : EPR:3 222 0.37 Extr.1 PID I-gain
09:35:21.171 : EPR:3 226 25.58 Extr.1 PID D-gain
09:35:21.171 : EPR:0 230 255 Extr.1 PID max value [0-255]
09:35:21.171 : EPR:2 231 0 Extr.1 X-offset [steps]
09:35:21.171 : EPR:2 235 0 Extr.1 Y-offset [steps]
09:35:21.186 : EPR:1 239 1 Extr.1 temp. stabilize time [s]
09:35:21.186 : EPR:1 250 150 Extr.1 temp. for retraction when heating [C]
09:35:21.186 : EPR:1 252 0 Extr.1 distance to retract when heating [mm]
09:35:21.186 : EPR:0 254 255 Extr.1 extruder cooler speed [0-255]
09:35:21.186 : EPR:3 246 0.00 Extr.1 advance L [0=off]
09:35:21.186 : EPR:3 300 50.00 Extr.2 steps per mm
09:35:21.186 : EPR:3 304 15.00 Extr.2 max. feedrate [mm/s]
09:35:21.186 : EPR:3 308 10.00 Extr.2 start feedrate [mm/s]
09:35:21.186 : EPR:3 312 4000.00 Extr.2 acceleration [mm/s^2]
09:35:21.186 : EPR:0 316 1 Extr.2 heat manager [0-1]
09:35:21.186 : EPR:0 317 130 Extr.2 PID drive max
09:35:21.186 : EPR:0 345 60 Extr.2 PID drive min
09:35:21.186 : EPR:3 318 6.16 Extr.2 PID P-gain
09:35:21.186 : EPR:3 322 0.37 Extr.2 PID I-gain
09:35:21.186 : EPR:3 326 25.58 Extr.2 PID D-gain
09:35:21.186 : EPR:0 330 255 Extr.2 PID max value [0-255]
09:35:21.186 : EPR:2 331 10 Extr.2 X-offset [steps]
09:35:21.186 : EPR:2 335 0 Extr.2 Y-offset [steps]
09:35:21.186 : EPR:1 339 1 Extr.2 temp. stabilize time [s]
09:35:21.186 : EPR:1 350 150 Extr.2 temp. for retraction when heating [C]
09:35:21.186 : EPR:1 352 40 Extr.2 distance to retract when heating [mm]
09:35:21.186 : EPR:0 354 255 Extr.2 extruder cooler speed [0-255]
09:35:21.186 : EPR:3 346 0.00 Extr.2 advance L [0=off]

artbotterell commented Apr 9, 2013

My firmware source and settings (I've done some in the EEPROM from Host)
are attached. Hope that helps, and thanks for the great packages!

  • Art

On Tue, Apr 9, 2013 at 12:02 AM, repetier notifications@github.com wrote:

Looks like a very repeatable problem for you. Can you mail me the zipped
firmware with your configuration. Perhaps I can reproduce it too, which
would help finding the problem.


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

Art Botterell
Disaster Management Consultant
Associate Director, Disaster Management Initiative
Carnegie Mellon University Silicon Valley
NASA Research Park, Building 23 (MS 23-11)
Moffett Field, CA 94035-0001
office (650) 335-2875
09:34:47.599 : FIRMWARE_NAME:Repetier_0.82 FIRMWARE_URL:https://github.com/repetier/Repetier-Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Mendel EXTRUDER_COUNT:2 REPETIER_PROTOCOL:2
09:34:47.599 : Printed filament:14.22 m
09:34:47.599 : Printing time:0 days 4 hours 44 min
artbotterell EEPROM settings 9 Apr 2013

09:35:20.703 : EPR:2 75 115200 Baudrate
09:35:20.703 : EPR:3 129 14.22 Filament printed [m]
09:35:20.718 : EPR:2 125 17062 Printer active [s]
09:35:20.718 : EPR:2 79 0 Max. inactive time [ms,0=off]
09:35:20.734 : EPR:2 83 120000 Stop stepper after inactivity [ms,0=off]
09:35:20.749 : EPR:3 3 33.60 X-axis steps per mm
09:35:20.749 : EPR:3 7 33.60 Y-axis steps per mm
09:35:20.765 : EPR:3 11 1070.50 Z-axis steps per mm
09:35:20.781 : EPR:3 15 200.00 X-axis max. feedrate [mm/s]
09:35:20.796 : EPR:3 19 200.00 Y-axis max. feedrate [mm/s]
09:35:20.812 : EPR:3 23 5.00 Z-axis max. feedrate [mm/s]
09:35:20.827 : EPR:3 27 80.00 X-axis homing feedrate [mm/s]
09:35:20.843 : EPR:3 31 80.00 Y-axis homing feedrate [mm/s]
09:35:20.859 : EPR:3 35 3.00 Z-axis homing feedrate [mm/s]
09:35:20.890 : EPR:3 39 20.00 Max. jerk [mm/s]
09:35:20.905 : EPR:3 47 0.50 Max. Z-jerk [mm/s]
09:35:20.937 : EPR:3 133 0.00 X home pos [mm]
09:35:20.968 : EPR:3 137 0.00 Y home pos [mm]
09:35:20.983 : EPR:3 141 0.00 Z home pos [mm]
09:35:21.015 : EPR:3 145 230.00 X max length [mm]
09:35:21.046 : EPR:3 149 270.00 Y max length [mm]
09:35:21.077 : EPR:3 153 180.00 Z max length [mm]
09:35:21.108 : EPR:3 157 0.00 X backlash [mm]
09:35:21.139 : EPR:3 161 0.00 Y backlash [mm]
09:35:21.139 : EPR:3 165 0.00 Z backlash [mm]
09:35:21.139 : EPR:3 51 500.00 X-axis acceleration [mm/s^2]
09:35:21.139 : EPR:3 55 500.00 Y-axis acceleration [mm/s^2]
09:35:21.155 : EPR:3 59 100.00 Z-axis acceleration [mm/s^2]
09:35:21.155 : EPR:3 63 500.00 X-axis travel acceleration [mm/s^2]
09:35:21.155 : EPR:3 67 500.00 Y-axis travel acceleration [mm/s^2]
09:35:21.155 : EPR:3 71 100.00 Z-axis travel acceleration [mm/s^2]
09:35:21.155 : EPR:0 103 1 OPS operation mode [0=Off,1=Classic,2=Fast]
09:35:21.171 : EPR:3 99 50.00 OPS move after x% retract [%]
09:35:21.171 : EPR:3 43 0.80 OPS min. distance for fil. retraction [mm]
09:35:21.171 : EPR:3 87 1.50 OPS retraction length [mm]
09:35:21.171 : EPR:3 91 0.00 OPS retraction backlash [mm]
09:35:21.171 : EPR:0 106 0 Bed Heat Manager [0-2]
09:35:21.171 : EPR:0 107 255 Bed PID drive max
09:35:21.171 : EPR:0 124 255 Bed PID drive min
09:35:21.171 : EPR:3 108 196.00 Bed PID P-gain
09:35:21.171 : EPR:3 112 33.02 Bed PID I-gain
09:35:21.171 : EPR:3 116 290.00 Bed PID D-gain
09:35:21.171 : EPR:0 120 255 Bed PID max value [0-255]
09:35:21.171 : EPR:3 200 50.00 Extr.1 steps per mm
09:35:21.171 : EPR:3 204 15.00 Extr.1 max. feedrate [mm/s]
09:35:21.171 : EPR:3 208 10.00 Extr.1 start feedrate [mm/s]
09:35:21.171 : EPR:3 212 4000.00 Extr.1 acceleration [mm/s^2]
09:35:21.171 : EPR:0 216 1 Extr.1 heat manager [0-1]
09:35:21.171 : EPR:0 217 140 Extr.1 PID drive max
09:35:21.171 : EPR:0 245 60 Extr.1 PID drive min
09:35:21.171 : EPR:3 218 6.16 Extr.1 PID P-gain
09:35:21.171 : EPR:3 222 0.37 Extr.1 PID I-gain
09:35:21.171 : EPR:3 226 25.58 Extr.1 PID D-gain
09:35:21.171 : EPR:0 230 255 Extr.1 PID max value [0-255]
09:35:21.171 : EPR:2 231 0 Extr.1 X-offset [steps]
09:35:21.171 : EPR:2 235 0 Extr.1 Y-offset [steps]
09:35:21.186 : EPR:1 239 1 Extr.1 temp. stabilize time [s]
09:35:21.186 : EPR:1 250 150 Extr.1 temp. for retraction when heating [C]
09:35:21.186 : EPR:1 252 0 Extr.1 distance to retract when heating [mm]
09:35:21.186 : EPR:0 254 255 Extr.1 extruder cooler speed [0-255]
09:35:21.186 : EPR:3 246 0.00 Extr.1 advance L [0=off]
09:35:21.186 : EPR:3 300 50.00 Extr.2 steps per mm
09:35:21.186 : EPR:3 304 15.00 Extr.2 max. feedrate [mm/s]
09:35:21.186 : EPR:3 308 10.00 Extr.2 start feedrate [mm/s]
09:35:21.186 : EPR:3 312 4000.00 Extr.2 acceleration [mm/s^2]
09:35:21.186 : EPR:0 316 1 Extr.2 heat manager [0-1]
09:35:21.186 : EPR:0 317 130 Extr.2 PID drive max
09:35:21.186 : EPR:0 345 60 Extr.2 PID drive min
09:35:21.186 : EPR:3 318 6.16 Extr.2 PID P-gain
09:35:21.186 : EPR:3 322 0.37 Extr.2 PID I-gain
09:35:21.186 : EPR:3 326 25.58 Extr.2 PID D-gain
09:35:21.186 : EPR:0 330 255 Extr.2 PID max value [0-255]
09:35:21.186 : EPR:2 331 10 Extr.2 X-offset [steps]
09:35:21.186 : EPR:2 335 0 Extr.2 Y-offset [steps]
09:35:21.186 : EPR:1 339 1 Extr.2 temp. stabilize time [s]
09:35:21.186 : EPR:1 350 150 Extr.2 temp. for retraction when heating [C]
09:35:21.186 : EPR:1 352 40 Extr.2 distance to retract when heating [mm]
09:35:21.186 : EPR:0 354 255 Extr.2 extruder cooler speed [0-255]
09:35:21.186 : EPR:3 346 0.00 Extr.2 advance L [0=off]

@repetier

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Apr 9, 2013

Owner

Looks like the source is still missing. You can send it via email to me. Not sure if you can attach files in github issues.

Owner

repetier commented Apr 9, 2013

Looks like the source is still missing. You can send it via email to me. Not sure if you can attach files in github issues.

@artbotterell

This comment has been minimized.

Show comment
Hide comment
@artbotterell

artbotterell Apr 9, 2013

What's an alternative email for you?

On Tue, Apr 9, 2013 at 10:01 AM, repetier notifications@github.com wrote:

Looks like the source is still missing. You can send it via email to me.
Not sure if you can attach files in github issues.


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

Art Botterell
Disaster Management Consultant
Associate Director, Disaster Management Initiative
Carnegie Mellon University Silicon Valley
NASA Research Park, Building 23 (MS 23-11)
Moffett Field, CA 94035-0001
office (650) 335-2875

artbotterell commented Apr 9, 2013

What's an alternative email for you?

On Tue, Apr 9, 2013 at 10:01 AM, repetier notifications@github.com wrote:

Looks like the source is still missing. You can send it via email to me.
Not sure if you can attach files in github issues.


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

Art Botterell
Disaster Management Consultant
Associate Director, Disaster Management Initiative
Carnegie Mellon University Silicon Valley
NASA Research Park, Building 23 (MS 23-11)
Moffett Field, CA 94035-0001
office (650) 335-2875

@repetier

This comment has been minimized.

Show comment
Hide comment
Owner

repetier commented Apr 9, 2013

@limited660

This comment has been minimized.

Show comment
Hide comment
@limited660

limited660 May 9, 2013

I have having this same issue but with printing from SD using an LCD and no computer. Sometimes it stops right after starting the print (seconds) and goes idle, I restarted and it made it 96% into the print and went idle. It stops wherever it was sitting and all heaters stay on. This has happened about 4 times since I turned on sdcard support last night.

limited660 commented May 9, 2013

I have having this same issue but with printing from SD using an LCD and no computer. Sometimes it stops right after starting the print (seconds) and goes idle, I restarted and it made it 96% into the print and went idle. It stops wherever it was sitting and all heaters stay on. This has happened about 4 times since I turned on sdcard support last night.

@repetier

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier May 9, 2013

Owner

@limited660 This talk was about printing from host. Printing from sd card is a completely different issue and normally has a hardware reason. You could try different sd cards as a start.

Owner

repetier commented May 9, 2013

@limited660 This talk was about printing from host. Printing from sd card is a completely different issue and normally has a hardware reason. You could try different sd cards as a start.

@limited660

This comment has been minimized.

Show comment
Hide comment
@limited660

limited660 May 9, 2013

I will give another SD card a try, if problem persists I will open a different issue for that.

limited660 commented May 9, 2013

I will give another SD card a try, if problem persists I will open a different issue for that.

@kyrreaa

This comment has been minimized.

Show comment
Hide comment
@kyrreaa

kyrreaa May 9, 2013

Contributor

I get random lockups too.
I thought it was related to my usb->serial dongle, however pressing reset on my avr controller makes it respond again. It's happened quite far into a print which is really annoying.

Wish repetier had a "start from layer n" option where it would read the gcode up to first layer and then skip down to the n'th layer. That would allow restarting jobs after such crash and saving hours of printing.

Contributor

kyrreaa commented May 9, 2013

I get random lockups too.
I thought it was related to my usb->serial dongle, however pressing reset on my avr controller makes it respond again. It's happened quite far into a print which is really annoying.

Wish repetier had a "start from layer n" option where it would read the gcode up to first layer and then skip down to the n'th layer. That would allow restarting jobs after such crash and saving hours of printing.

@luke321

This comment has been minimized.

Show comment
Hide comment
@luke321

luke321 May 9, 2013

@kyrreaa I had such lockups twice in an 12 hour print, it was with an older firmware version altough...
I went trough the log, searched for the last line of gcode and the last z height.
Than simply removed everything else and resumed printing.
altough this could be problematic with none rostock printers, because of the home positions.

luke321 commented May 9, 2013

@kyrreaa I had such lockups twice in an 12 hour print, it was with an older firmware version altough...
I went trough the log, searched for the last line of gcode and the last z height.
Than simply removed everything else and resumed printing.
altough this could be problematic with none rostock printers, because of the home positions.

@ellindsey

This comment has been minimized.

Show comment
Hide comment
@ellindsey

ellindsey Jul 21, 2013

I am having this problem repeatably.

I an running Repetier 0.83 on a RAMPS 1.4 board, and Repetier-server on a Raspberry Pi as my print server. The printer is a delta, custom made Rostock derived design.

I have a file which consistently locks up at 73% completion. I have run the same print three times now and it fails at about the same point, although not at the exact same line on the G-code. Checking the log (shown on the repetier-server browser window) the last line sent isn't exactly the same each time it fails.

When it fails, the printer LCD shows the printer to be in idle mode. The heaters are on and maintaining temperature, but the temperature is not being reported to the server. I can cancel the print on the server, but the RAMPS board doesn't respond to any commands through the USB port. I need to do a hardware reset to get it talking again.

Communication is through binary mode. I have tried to force it to ascii mode, but changing the mode in the repetier-server config file has no effect, it always goes to binary mode no matter what I set.

I haven't yet tried printing this file from my laptop instead of the Raspberry Pi. I don't have Repetier-host installed yet, but I can try that tomorrow.

I don't have a SDcard reader attached to the RAMPS board, so I can't try printing from the card.

I can upload the gcode file if it will help.

This problem first appeared after I tore down and rebuilt the hot end to use a 0.35mm nozzle. That shouldn't cause any problems itself, but I did significantly change my slicer settings at about the same time, reducing layer height and enabling microlayering. I can try slicing the same part without microlayering and see if it works then.

ellindsey commented Jul 21, 2013

I am having this problem repeatably.

I an running Repetier 0.83 on a RAMPS 1.4 board, and Repetier-server on a Raspberry Pi as my print server. The printer is a delta, custom made Rostock derived design.

I have a file which consistently locks up at 73% completion. I have run the same print three times now and it fails at about the same point, although not at the exact same line on the G-code. Checking the log (shown on the repetier-server browser window) the last line sent isn't exactly the same each time it fails.

When it fails, the printer LCD shows the printer to be in idle mode. The heaters are on and maintaining temperature, but the temperature is not being reported to the server. I can cancel the print on the server, but the RAMPS board doesn't respond to any commands through the USB port. I need to do a hardware reset to get it talking again.

Communication is through binary mode. I have tried to force it to ascii mode, but changing the mode in the repetier-server config file has no effect, it always goes to binary mode no matter what I set.

I haven't yet tried printing this file from my laptop instead of the Raspberry Pi. I don't have Repetier-host installed yet, but I can try that tomorrow.

I don't have a SDcard reader attached to the RAMPS board, so I can't try printing from the card.

I can upload the gcode file if it will help.

This problem first appeared after I tore down and rebuilt the hot end to use a 0.35mm nozzle. That shouldn't cause any problems itself, but I did significantly change my slicer settings at about the same time, reducing layer height and enabling microlayering. I can try slicing the same part without microlayering and see if it works then.

@repetier

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Jul 21, 2013

Owner

That error is always hard to detect. Looks like it is no firmware issue if it is still running. It is only getting no more data. This is often enough a problem with the usb connection. I have by now several usb cables. I know which one to select if I need communication errors and which to use errorless printing. So maybe a different usb cable might help. You want at least shielded usb cables, also there are good and bad shielded cables.
You can test the communication itself if you activate debug communication:
M111 S20
If it is a Server issue this should already fail, as it has to send the same data.If it is caused by a crashed usb connection due to noise it will most probably work, as the printer has no extra load causing troubles.
Then only the receive of a command with correct checksum is tested. No motors/heaters producing noise. Next level would be to increase noise by running in dry mode. Motor noise but no large voltage dropdowns from heater/heated bed.

An other test would be to run it from a laptop/pc. Different usb connectors can also make a difference.

Owner

repetier commented Jul 21, 2013

That error is always hard to detect. Looks like it is no firmware issue if it is still running. It is only getting no more data. This is often enough a problem with the usb connection. I have by now several usb cables. I know which one to select if I need communication errors and which to use errorless printing. So maybe a different usb cable might help. You want at least shielded usb cables, also there are good and bad shielded cables.
You can test the communication itself if you activate debug communication:
M111 S20
If it is a Server issue this should already fail, as it has to send the same data.If it is caused by a crashed usb connection due to noise it will most probably work, as the printer has no extra load causing troubles.
Then only the receive of a command with correct checksum is tested. No motors/heaters producing noise. Next level would be to increase noise by running in dry mode. Motor noise but no large voltage dropdowns from heater/heated bed.

An other test would be to run it from a laptop/pc. Different usb connectors can also make a difference.

@ellindsey

This comment has been minimized.

Show comment
Hide comment
@ellindsey

ellindsey Jul 23, 2013

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.

ellindsey commented Jul 23, 2013

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

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Jul 24, 2013

Owner

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.

Owner

repetier commented Jul 24, 2013

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

This comment has been minimized.

Show comment
Hide comment
@luke321

luke321 Aug 3, 2013

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

luke321 commented Aug 3, 2013

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

This comment has been minimized.

Show comment
Hide comment
@bassrock

bassrock Oct 21, 2013

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

bassrock commented Oct 21, 2013

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

@repetier

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Oct 21, 2013

Owner

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.

Owner

repetier commented Oct 21, 2013

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

This comment has been minimized.

Show comment
Hide comment
@luke321

luke321 Oct 21, 2013

it finished without me doing anything!

luke321 commented Oct 21, 2013

it finished without me doing anything!

@bassrock

This comment has been minimized.

Show comment
Hide comment
@bassrock

bassrock Oct 21, 2013

@repetier Is development stable enough to use?

bassrock commented Oct 21, 2013

@repetier Is development stable enough to use?

@repetier

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Oct 21, 2013

Owner

@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.

Owner

repetier commented Oct 21, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@bassrock

bassrock Oct 21, 2013

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.

bassrock commented Oct 21, 2013

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

This comment has been minimized.

Show comment
Hide comment
@daftscience

daftscience Nov 3, 2013

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?

daftscience commented Nov 3, 2013

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

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Nov 3, 2013

Owner

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.

Owner

repetier commented Nov 3, 2013

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

This comment has been minimized.

Show comment
Hide comment
@kyrreaa

kyrreaa Nov 3, 2013

Contributor

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.

Contributor

kyrreaa commented Nov 3, 2013

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

This comment has been minimized.

Show comment
Hide comment
@daftscience

daftscience Nov 6, 2013

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?

daftscience commented Nov 6, 2013

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

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Nov 6, 2013

Owner

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.

Owner

repetier commented Nov 6, 2013

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

This comment has been minimized.

Show comment
Hide comment
@ellindsey

ellindsey Nov 6, 2013

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.

ellindsey commented Nov 6, 2013

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

This comment has been minimized.

Show comment
Hide comment
@daftscience

daftscience Nov 6, 2013

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.

daftscience commented Nov 6, 2013

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

This comment has been minimized.

Show comment
Hide comment
@kyrreaa

kyrreaa Nov 6, 2013

Contributor

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
.

Contributor

kyrreaa commented Nov 6, 2013

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

This comment has been minimized.

Show comment
Hide comment
@daftscience

daftscience Nov 6, 2013

@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.

daftscience commented Nov 6, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@kyrreaa

kyrreaa Nov 6, 2013

Contributor

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
.

Contributor

kyrreaa commented Nov 6, 2013

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

This comment has been minimized.

Show comment
Hide comment
@daftscience

daftscience Nov 6, 2013

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

daftscience commented Nov 6, 2013

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

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Nov 6, 2013

Owner

@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.

Owner

repetier commented Nov 6, 2013

@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

This comment has been minimized.

Show comment
Hide comment
@kyrreaa

kyrreaa Nov 6, 2013

Contributor

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.

Contributor

kyrreaa commented Nov 6, 2013

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

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Nov 6, 2013

Owner

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?

Owner

repetier commented Nov 6, 2013

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

This comment has been minimized.

Show comment
Hide comment
@ivanpope

ivanpope Nov 7, 2013

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?

ivanpope commented Nov 7, 2013

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

This comment has been minimized.

Show comment
Hide comment
@kyrreaa

kyrreaa Nov 7, 2013

Contributor

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
.

Contributor

kyrreaa commented Nov 7, 2013

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

This comment has been minimized.

Show comment
Hide comment
@3Dconfused

3Dconfused Dec 23, 2013

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?

3Dconfused commented Dec 23, 2013

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

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Dec 23, 2013

Owner

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.

Owner

repetier commented Dec 23, 2013

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

This comment has been minimized.

Show comment
Hide comment
@3Dconfused

3Dconfused Dec 23, 2013

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

3Dconfused commented Dec 23, 2013

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

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Dec 23, 2013

Owner

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.

Owner

repetier commented Dec 23, 2013

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

This comment has been minimized.

Show comment
Hide comment
@3Dconfused

3Dconfused Dec 23, 2013

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 commented Dec 23, 2013

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

This comment has been minimized.

Show comment
Hide comment
@3Dconfused

3Dconfused Dec 23, 2013

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 commented Dec 23, 2013

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

This comment has been minimized.

Show comment
Hide comment
@3Dconfused

3Dconfused Dec 24, 2013

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 commented Dec 24, 2013

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

This comment has been minimized.

Show comment
Hide comment
@3Dconfused

3Dconfused Dec 24, 2013

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

3Dconfused commented Dec 24, 2013

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

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Dec 24, 2013

Owner

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.

Owner

repetier commented Dec 24, 2013

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

This comment has been minimized.

Show comment
Hide comment
@3Dconfused

3Dconfused Dec 24, 2013

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

3Dconfused commented Dec 24, 2013

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

This comment has been minimized.

Show comment
Hide comment
@repetier

repetier Dec 24, 2013

Owner

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.

Owner

repetier commented Dec 24, 2013

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

This comment has been minimized.

Show comment
Hide comment
@3Dconfused

3Dconfused Dec 24, 2013

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

3Dconfused commented Dec 24, 2013

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 comment has been minimized.

Show comment
Hide comment
@kyrreaa

kyrreaa Dec 24, 2013

Contributor

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
.

Contributor

kyrreaa commented Dec 24, 2013

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

This comment has been minimized.

Show comment
Hide comment
@nixta78

nixta78 Dec 18, 2015

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!

nixta78 commented Dec 18, 2015

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

This comment has been minimized.

Show comment
Hide comment
@frank16

frank16 Apr 4, 2016

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.

frank16 commented Apr 4, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment