Im not sure whybbut its at random points.
Can you give more details?
Connection dropping to what? AstroPrint.com? The Printer? The AstroBox? Local Hotspot?
Any error messages? Screenshots? Is it possible for us to reproduce the error?
1 Like
Sorry of course. Printer to Astrobox (Rpi2) Marlin firmware. mini rambo controller. No messages i can see nor did i think to take shots. I will try to set up the same conditions later. Printer in use connected to pc while i try to figure out why it wouldnāt stay connected. its only been doing so since 8.4
1 Like
Great. Let us know if you figured out a solution to this.
Standard stuff to remedy the problem: Check to make sure your USB connection is good, then reboot the Astrobox.
Iāve had similar issues with the Printerbot 
Iāll just mention I have recently started having a similar problem.
Iām relatively new to astroprint but I notice it happen when I first
got things going. I have it on a RPi2 as well.
Not sure but I currently suspect a recent repeater firmware update loose connection only after completing a printā¦at present it
happens every time a print successfully finishes.
My only recourse is to power the Pi down and back up, which resets the printer and everything reconnects.
1 Like
yes the latest .84, had some initial trouble upgrading it but a full download and wipe and I got it going again. I am also using the latest repetier firmware from their configuration page.
I can now confirm that canceled prints seem to have the same problemā¦Iāve played with post print Gcodesā¦they seem to execute fine but as soon as the last code is sent the astrobox/printer usb connection goes down. I can still send to the astrobox from the browser but nothing happens. About 50% of the time it will show that it is disconnected from the printer, other times the printer icon doesnāt turn color it just acts like commands are being sent but the printer doesnāt respondā¦when shows disconnected if I try to reconnect by clicking the icon (I assume that is what it does) then it seems to connect but really it isnātā¦printer never resets which it does upon connection usually.
I checked the gcode terminal last time it completed a print and it was cycling with a resend (request) I thinkā¦I didnāt see the normal āwaitā signals from the printer so my guess is the printer is requesting a resend (why I donāt know) and the astrobox does not reply but until it does the printer wonāt respondā¦or maybe it is the astro box waiting for a resend that it never gets from the printerā¦not sure how to tell.
wanted to add I tried this using a different slicer to generate the codes from a different printer setup in astrobox (I thought maybe there was some bogus post print code script for that printer config, so I wanted to start fresh) but I got the same results. A quick return to Repeiter host didnāt seem to have the disconnection problem.
Not sure but I currently suspect a recent repeater firmware update loose connection only after completing a printā¦
Ah! So, this is most likely the issue. Weāve done very little testing on Repetier Firmware, so it is reasonable to expect glitches like this. At the moment, most of our focus has been on Marlin & Sailfish firmware.
@Anthony: Any updates on your problem? Is it working fine or are you still running into connection issues?
So some further informationā¦I am not sold it is a new Repetier firmware thing, but I may go back to the previous release and see if it changes things. Anyone else seen this with the latest firmware?
One thing I have found is if I check the Astrobox log files I see them filled with the following:
2016-02-09 16:44:00,621 - astroprint.printer.marlin.comm - WARNING - Printer requested line 69743 but no sufficient history is available, canāt resend [Delta: -69742, History: 0]
This apparently just keeps happening until the log fills which to me suggests something in the Astrobox softwareā¦as presumably it would time out after a while but maybe not.
Of note the line number is close to but not the same as the number of lines in the Gcode file I was printingā¦this is always the case when it fails after a print, the line number is always several counts higher than the max line number in the gcode file.
It is just odd that this happensā¦I can send manual Gcode and it never failsā¦almost like something overruns. ā¦ These are longish prints but not that bigā¦maybe I can watch the gcode terminal as a print finishes up and see what happens there.
1 Like
I think I have confirmed that the latest Repetier firmware has a possible problem with both AstroPrint and octo-print. I rolled back to an earlier firmware build from the end of 2015 and my disconnection problem seems to be gone. Kinda too bad since the new firmware has some good updates Iād like to keep. But for now using AstroPrint is more important.
See this Repetier forum thread:
I havenāt tested this supposed octo-print fix with AstroPrint but the problem very similarā¦I suspect this is what I was seeming with AstroPrintā¦and the fix seems reasonable and straight forwardā¦could be that AstroPrint needs to send line numbers consistently if it isnāt already.
Darren
2 Likes
Just as he described above, and the gent below is correct rolling back is so far the solution.
Hmmmā¦I tried the suggested fix from the Repetier forumā¦That is removing the else statement in the Repetier g-code.cpp file. Strangely it seems a bit better but not reallyā¦
It still disconnects with a resend request at the end of a print jobā¦I find now however if I go to the printer settings and click test connection it will reset and reconnect. I donāt recall being able to get it to do this before but maybe I never tried. I need to see if maybe there is a way to send this from the end g-code, as a temporary fix.
A little new information.
I am now using the latest Repetier Firmware (from 2/19/2016)
I made the above patch so that line numbers are not required every time.
Here is what I get in the Astrobox Log file (there is a full print job after the download and before the error with nothing showing in the log):
2016-02-21 01:30:38,018 - astroprint.printfiles.downloadmanager - INFO - Download started for 4e5b519459064c6693a757b9dd51bb30
2016-02-21 01:30:43,190 - astroprint.printfiles.downloadmanager - INFO - Download completed for 4e5b519459064c6693a757b9dd51bb30
2016-02-21 02:15:15,741 - astroprint.printer.marlin.comm - ERROR - Something crashed inside the serial connection loop, please report this to AstroPrint:
Traceback (most recent call last):
File āplatforms/common/AstroBox/src/astroprint/printer/marlin/comm.pyā, line 951, in _monitor
File āplatforms/common/AstroBox/src/astroprint/printer/marlin/comm.pyā, line 1095, in _handleResendRequest
ValueError: invalid literal for int() with base 10: āfilament:2780.81mā
I note that the last command of my finish code does not executeā¦my code looks like this:
M106 S255
G91
G1 Z20.0 E-5.0 F600
G90
G0 X0 Y0
M104 S0
M140 S0
G28
M106 S0
The printer does everything including the G28 home, but does not execute the M106 S0, which I think is valid to shut down the fanā¦I may try a M107 but the earlier M106 S255 brings the fan on full so I think this should workā¦something seems to cause a failure just before the command is sent or executed. Also I am no longer getting the run away resend errorsā¦
I discovered you can save the serial communications log.
I turned this on and I have discovered something I thinkā¦
My guess is looking at the astrobox log and the serial log that when a G28 command is sent the return from the printer is something that astrobox canāt handle when it tries to convert some of the numbers. (possible the rather large filament counter or print time?)
see serial log where the failure occurs below:
2016-02-22 03:10:46,185 - SERIAL - DEBUG - Send: N11100 G1 F3300 X-49.259 Y21.257 E3237.0148723
2016-02-22 03:10:46,253 - SERIAL - DEBUG - Recv: ok
2016-02-22 03:10:46,255 - SERIAL - DEBUG - Send: N11101 M10737
2016-02-22 03:10:46,324 - SERIAL - DEBUG - Recv: ok
2016-02-22 03:10:46,325 - SERIAL - DEBUG - Send: N11102 G1 F9000 E3231.0148754
2016-02-22 03:10:46,357 - SERIAL - DEBUG - Recv: ok
2016-02-22 03:10:46,359 - SERIAL - DEBUG - Send: N11103 G1 Z5.000123
2016-02-22 03:10:46,361 - SERIAL - DEBUG - Recv: Fanspeed:0
2016-02-22 03:10:46,362 - SERIAL - DEBUG - Recv: ok
2016-02-22 03:10:46,363 - SERIAL - DEBUG - Send: N11104 G0 X-49.259 Y21.257 Z8.00092
2016-02-22 03:10:46,484 - SERIAL - DEBUG - Recv: ok
2016-02-22 03:10:46,485 - SERIAL - DEBUG - Send: N11105 M106 S25597
2016-02-22 03:10:46,523 - SERIAL - DEBUG - Recv: ok
2016-02-22 03:10:46,524 - SERIAL - DEBUG - Send: N11106 G9122
2016-02-22 03:10:46,631 - SERIAL - DEBUG - Recv: ok
2016-02-22 03:10:46,633 - SERIAL - DEBUG - Send: N11107 G1 Z20.0 E-5.0 F600123
2016-02-22 03:10:46,635 - SERIAL - DEBUG - Recv: Fanspeed:255
2016-02-22 03:10:46,636 - SERIAL - DEBUG - Recv: ok
2016-02-22 03:10:46,637 - SERIAL - DEBUG - Send: N11108 G9025
2016-02-22 03:10:46,639 - SERIAL - DEBUG - Recv: ok
2016-02-22 03:10:46,640 - SERIAL - DEBUG - Send: N11109 G0 X0 Y032
2016-02-22 03:10:46,664 - SERIAL - DEBUG - Recv: ok
2016-02-22 03:10:46,666 - SERIAL - DEBUG - Send: N11110 M104 S0101
2016-02-22 03:10:46,667 - SERIAL - DEBUG - Recv: ok
2016-02-22 03:10:46,668 - SERIAL - DEBUG - Send: N11111 M140 S0100
2016-02-22 03:10:49,843 - SERIAL - DEBUG - Recv: ok
2016-02-22 03:10:49,845 - SERIAL - DEBUG - Send: N11112 G28*17
2016-02-22 03:10:54,883 - SERIAL - DEBUG - Recv: TargetExtr0:0
2016-02-22 03:10:54,923 - SERIAL - DEBUG - Recv: Printed filament:2807.53m Printing time:30 days 4 hours 38 min
2016-02-22 03:10:54,929 - SERIAL - DEBUG - See astrobox.log for details
2016-02-22 03:10:54,930 - SERIAL - DEBUG - Changing monitoring state from āPrintingā to āError: See astrobox.log for detailsā
2016-02-22 03:10:58,536 - SERIAL - DEBUG - Recv: ok
2016-02-22 03:10:58,538 - SERIAL - DEBUG - Recv: TargetBed:0
2016-02-22 03:10:58,539 - SERIAL - DEBUG - Recv: ok
2016-02-22 03:11:00,958 - SERIAL - DEBUG - Recv: SelectExtruder:0
2016-02-22 03:11:00,959 - SERIAL - DEBUG - Recv: FlowMultiply:100
2016-02-22 03:11:00,963 - SERIAL - DEBUG - Recv: X:0.00 Y:0.00 Z:307.000 E:3226.0129
2016-02-22 03:11:00,964 - SERIAL - DEBUG - Recv: wait
2016-02-22 03:11:01,964 - SERIAL - DEBUG - Recv: wait
2016-02-22 03:11:02,965 - SERIAL - DEBUG - Recv: wait
Will someone start paying this man already!!! 
1 Like
(Internet Hugs) 
Update:
I think I have narrowed down the disconnection problem to how Repetier Firmware or Astrobox handles the extruder temperature set. Somehow something seems to cause the Astrobox to register an error condition. I have some new end code that seems to solve my issueā¦it is not a real fix but it works for nowā¦I will see if I can find out what if anything has changed in Repetier when get the chanceā¦
Here is my āworkingā finish code:
M106 S255
G91
G1 Z20.0 E-5.0 F600
G90
M140 S5 F1
G1 X0 Y0 F2000
G4 S60
G1 Z300 F100
M85 S1
Note this is probably more complex that most people want, but what it does is crank up the the cooling fan just above the print for a time after completion, in an effort to cool things for removal. Any effort to use M104 or M109 seems to cause the error and the resulting disconnection issue.
I have a similar yet different issue (RPi, FFCP combo) that seems to occur since the last update. When booting up Astrobox, if I start any operation on the printer directly (lets say pre heat), after a minute the printer seems to reset (LCD flickers too), and whatever I was doing is stopped. So I now need to wait for Astrobox to be booted for 2 minutes or so before doing anything. Not a huge issue but quite annoying.
I am also getting similar issues as the OP when cancelling a print on the machine directly - the software seems to think a print is in progress still, until you press cancel 3 or 4 times.