@DiamondDrake got the logs. There’s seem to be garbage over the line. Are you using the same baud rate as in repetier-host? Also the new release 0.8(1) has a GCODE console app, you could try to send some commands to the printer to see if it responds.
Yes I’m using what the display on the Wanhao says its configured for, 115200, which is the same as I have set in repetier- host.
Did you ever figure this out? I’m seeing the same issue.
Just got my AstroBox in today and am having the exact same issue. I even tried removing the AutoReset jumper and messing with different baud rates (suggestions on the Google Groups page), all to no avail. Has anyone been able to successfully connect a Wanhao i3 to an AstroBox? It would be a shame to have to return my box because they don’t support one of the highest trending / most popular printers on 3D Hubs…
Astrobox has some great features, but the software is essentially a branch of the octoprint with enormous changes. AstroPrint just won’t connect to the WanHao duplicator i3, but the lastes OctoPrint does. If anyone really needs the ease of host control of this type of solution, until the AstroBox team can get the WanHao Duplicator i3 Supported, It looks like OctoPrint is the way to go.
Thanks @DiamondDrake, we will look into the version of Octoprint that supports the i3 and implement the changes. Would you mind to let us know which version of Octoprint we should look into?
The octoprint webui shows “Version: 1.2.8 (master branch)” at the bottom of every page
Hi Guys,
My Duplicator i3 is working fine with my astrobox that I just built.
you can try removing the auto reset jumper on the i3 mbx and see if that work for you.
got this info below from one of the google wanhao user.
“open up the controller box and remove the jumper that says something about Auto Reset. (JP14?) Seen as the jumper on the right side, middle edge of the board here. That is the only thing that would really cause issues. As long as you have the baud rate the same and the same com port (and Repetier host is closed) it should work
http://3dprinterbrain.com/pmwiki.php/DupI3/PrinterBoardInfo?action=dispimg&im=i3board.p.png”
I haven’t tried removing the auto-reset jumper, but I installed a fresh copy of astrobox on my raspberry pi, used a powered usb hub, high quality cables, and nothing. Is there some significance to this jumper? The controller does reset, but octoprint handles that just fine.
Do you guys have the microsd card inserted on the printer?
I has having issues connecting as well, but looking at the serial logs, for some reason the board will give some errors if you don’t have the microsd present. I didn’t have to mess with any jumpers…
Try that and report back.
I’m having a similar issue here. I also have a duplicator i3 (there are different versions out there, and I’m not sure which one I have). I have been using octoprint successfully for a few months, and I decided to try astroprint (for its cloudiness) and I’m not able to connect my printer.
This is from the astroprint serial log:
2015-12-21 17:04:18,948 - SERIAL - DEBUG - Connecting to: /dev/ttyUSB0
2015-12-21 17:04:18,958 - SERIAL - DEBUG - Connected to: Serial<id=0x6cdbf330, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
2015-12-21 17:04:18,963 - SERIAL - DEBUG - Changing monitoring state from 'Opening serial port' to 'Connecting'
2015-12-21 17:04:20,967 - SERIAL - DEBUG - Send: M105
2015-12-21 17:04:22,971 - SERIAL - DEBUG - Send: M105
2015-12-21 17:04:24,975 - SERIAL - DEBUG - Send: M105
2015-12-21 17:04:26,979 - SERIAL - DEBUG - Send: M105
2015-12-21 17:04:28,984 - SERIAL - DEBUG - Send: M105
2015-12-21 17:04:30,988 - SERIAL - DEBUG - Send: M105
2015-12-21 17:04:32,992 - SERIAL - DEBUG - Send: M105
2015-12-21 17:04:34,997 - SERIAL - DEBUG - Send: M105
2015-12-21 17:04:37,001 - SERIAL - DEBUG - Send: M105
2015-12-21 17:04:37,991 - SERIAL - DEBUG - Recv: start
2015-12-21 17:04:39,999 - SERIAL - DEBUG - Send: M105
2015-12-21 17:04:41,809 - SERIAL - DEBUG - Recv: Info: 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000 0.000000
2015-12-21 17:04:41,812 - SERIAL - DEBUG - Changing monitoring state from 'Connecting' to 'Closed'
2015-12-21 17:04:41,818 - SERIAL - DEBUG - Connection closed, closing down monitor
I’m not siting at my printer, but I’m guessing that it’s restarting, which closes the serial port, and then astroprint fails to connect. This is just a guess. I have a microSD installed, and I haven’t removed the jumper. I don’t have a serial log from octoprint, but I do have my configs, and I can get a log if it’s helpful.
I watched it when I hit the “test-connection” button. Sure enough, I got the Rhino screen of death (or rebirth) which happens at startup. I opened it up, and removed that jumper. Things are working (and I’m printing now). This is the snippet from the functioning log:
2015-12-21 17:16:11,889 - SERIAL - DEBUG - Changing monitoring state from 'Offline' to 'Opening serial port'
2015-12-21 17:16:11,900 - SERIAL - DEBUG - Connecting to: /dev/ttyUSB0
2015-12-21 17:16:11,907 - SERIAL - DEBUG - Connected to: Serial<id=0x6cdbf630, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
2015-12-21 17:16:11,910 - SERIAL - DEBUG - Changing monitoring state from 'Opening serial port' to 'Connecting'
2015-12-21 17:16:12,123 - SERIAL - DEBUG - Recv: wait
2015-12-21 17:16:12,125 - SERIAL - DEBUG - Send: M105
2015-12-21 17:16:12,129 - SERIAL - DEBUG - Recv: ok 0
2015-12-21 17:16:12,130 - SERIAL - DEBUG - Changing monitoring state from 'Connecting' to 'Operational'
The remaining open questions are:
- Is the reset functionality desired? I’m not sure. I bet there are two camps, and I’m now forced to live in one of them.
- Can astroprint support a reset? Even if this isn’t the perfect behavior, it’s better to fix it in astroprint than making duplicator owners each fix it.
- Can the error messages be improved? The webpage just sits there spinning, but the serial connection was clearly closed. There was no more action taking place.
That jumper is required In order to flash new firmware, not that you’d necessarily want to do that. But if octoprint handles the reset just fine (it does because I use it everyday) then it stands to reason that astroprint could too. That way users don’t have to open their control box.
Now that we have some confirmation on the reset causing issues maybe the astroprint team can support that
Well, now at the end of the print, I get a different error. Here’s another snippet:
...
2015-12-21 17:41:04,648 - SERIAL - DEBUG - Send: N22430 G1 F1800 X112.754 Y115.576 E1170.34227*56
2015-12-21 17:41:04,702 - SERIAL - DEBUG - Recv: ok 22429
2015-12-21 17:41:04,704 - SERIAL - DEBUG - Send: N22431 G1 X113.131 Y115.671 E1170.35517*83
2015-12-21 17:41:04,726 - SERIAL - DEBUG - Recv: ok 22430
2015-12-21 17:41:04,728 - SERIAL - DEBUG - Send: N22432 M107*32
2015-12-21 17:41:04,754 - SERIAL - DEBUG - Recv: ok 22431
2015-12-21 17:41:04,756 - SERIAL - DEBUG - Send: N22433 G1 F3600 E1166.35517*49
2015-12-21 17:41:04,823 - SERIAL - DEBUG - Recv: ok 22432
2015-12-21 17:41:04,826 - SERIAL - DEBUG - Send: N22434 G0 F6000 X113.131 Y115.671 Z7.579*22
2015-12-21 17:41:04,844 - SERIAL - DEBUG - Recv: ok 22433
2015-12-21 17:41:04,846 - SERIAL - DEBUG - Send: N22435 M107*39
2015-12-21 17:41:04,849 - SERIAL - DEBUG - Recv: Fanspeed:0
2015-12-21 17:41:04,852 - SERIAL - DEBUG - Recv: ok 22434
2015-12-21 17:41:04,854 - SERIAL - DEBUG - Send: N22436 G91*16
2015-12-21 17:41:04,920 - SERIAL - DEBUG - Recv: ok 22435
2015-12-21 17:41:04,922 - SERIAL - DEBUG - Send: N22437 G1 Z0.3 F5000*28
2015-12-21 17:41:04,948 - SERIAL - DEBUG - Recv: ok 22436
2015-12-21 17:41:04,951 - SERIAL - DEBUG - Send: N22438 T0*53
2015-12-21 17:41:04,954 - SERIAL - DEBUG - Recv: ok 22437
2015-12-21 17:41:04,956 - SERIAL - DEBUG - Send: N22439 G1 E-1*95
2015-12-21 17:41:04,959 - SERIAL - DEBUG - Recv: ok 22438
2015-12-21 17:41:04,961 - SERIAL - DEBUG - Send: N22440 M104 T0 S0*33
2015-12-21 17:41:05,038 - SERIAL - DEBUG - Recv: ok 22439
2015-12-21 17:41:05,041 - SERIAL - DEBUG - Send: N22441 G90*17
2015-12-21 17:41:07,045 - SERIAL - DEBUG - Read communication timeout during printing, listen again
2015-12-21 17:41:07,985 - SERIAL - DEBUG - Recv: ok 22440
2015-12-21 17:41:07,992 - SERIAL - DEBUG - Send: N22442 M105*37
2015-12-21 17:41:08,000 - SERIAL - DEBUG - Recv: ok 22441
2015-12-21 17:41:08,003 - SERIAL - DEBUG - Send: N22443 G28 X0*88
2015-12-21 17:41:08,020 - SERIAL - DEBUG - Recv: TargetExtr0:0
2015-12-21 17:41:08,058 - SERIAL - DEBUG - Recv: Printed filament:1393.89m Printing time:10 days 6 hours 36 min
2015-12-21 17:41:08,064 - SERIAL - DEBUG - See astrobox.log for details
2015-12-21 17:41:08,065 - SERIAL - DEBUG - Changing monitoring state from 'Printing' to 'Error: See astrobox.log for details'
2015-12-21 17:41:11,859 - SERIAL - DEBUG - Recv: ok 22442
2015-12-21 17:41:11,864 - SERIAL - DEBUG - Recv: ok 22443
2015-12-21 17:41:11,867 - SERIAL - DEBUG - Recv: T:212.22 /0 B:45.04 /45 B@:0 @:0
2015-12-21 17:41:11,870 - SERIAL - DEBUG - Recv: X:0.00 Y:115.68 Z:7.88 E:1165.35
2015-12-21 17:41:11,871 - SERIAL - DEBUG - Recv: wait
2015-12-21 17:41:12,841 - SERIAL - DEBUG - Recv: wait
2015-12-21 17:41:13,841 - SERIAL - DEBUG - Recv: wait
...
The astrobox.log:
2015-12-21 17:17:13,705 - octoprint.server.util - INFO - New connection from client: 10.0.2.90
2015-12-21 17:41:08,060 - 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 950, in _monitor
File "platforms/common/AstroBox/src/astroprint/printer/marlin/comm.py", line 1094, in _handleResendRequest
ValueError: invalid literal for int() with base 10: 'filament:1393.89m'
The printer was sitting there with the bed on, and the steppers engaged. The hotend was off, thankfully, but that might have just been lucky. The print was fine, FYI.
Looking at it a little more, this might also be helpful:
2015-12-21 17:45:03,706 - SERIAL - DEBUG - Recv: wait
2015-12-21 17:45:04,798 - SERIAL - DEBUG - Recv: wait
2015-12-21 17:45:05,341 - SERIAL - DEBUG - Changing monitoring state from 'Error: See astrobox.log for details' to 'Closed'
2015-12-21 17:45:05,357 - SERIAL - DEBUG - Changing monitoring state from 'Offline' to 'Opening serial port'
2015-12-21 17:45:05,367 - SERIAL - DEBUG - Connecting to: /dev/ttyUSB0
2015-12-21 17:45:05,375 - SERIAL - DEBUG - Connected to: Serial<id=0x6d098090, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
2015-12-21 17:45:05,376 - SERIAL - DEBUG - Changing monitoring state from 'Opening serial port' to 'Connecting'
2015-12-21 17:45:05,798 - SERIAL - DEBUG - Recv: wait
2015-12-21 17:45:05,800 - SERIAL - DEBUG - Send: M105
2015-12-21 17:45:05,803 - SERIAL - DEBUG - Unexpected error while reading serial port: TypeError: 'an integer is required' @ comm.py:_readline:1034
2015-12-21 17:45:05,805 - SERIAL - DEBUG - Connection closed, closing down monitor
2015-12-21 17:45:05,809 - SERIAL - DEBUG - Recv: ok 22443
2015-12-21 17:45:05,810 - SERIAL - DEBUG - Changing monitoring state from 'Connecting' to 'Operational'Thanks for those logs!
It seems that this line
2015-12-21 17:41:08,058 - SERIAL - DEBUG - Recv: Printed filament:1393.89m Printing time:10 days 6 hours 36 min
is causing problems for our software as it’s not a standard Marlin response. I now have some more info to take a look at this problem.
I just setup AstroPrint with my Monoprice Maker Select which is a duplicator i3 rebrand and was having the same problem until I put the sd card in like Carlos suggested it then connected instantly.
1 Like
As of AstroBox version 0.8(4), the i3 is working fine. Please update your software to the latest.
I’ve tried everything suggested in this thread and I am having no luck getting astroprint to work with my Cocoon printer (rebranded Wanhao DI3).
Is the Wanhao still working with Astrobox v0.10(4)?
I don’t believe the firmware is any different (although I have no idea how I can actually confirm that).
How do I export logs from astroprint? That might give me a bit of a clue.