[SOLVED] Support for Wanhao Duplicator i3

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:

  1. 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.
  2. 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.
  3. 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)?

@tanka2d: Yup!

Unless cocoon modified the firmware when they rebranded it…

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.

It’s at /var/log/astrobox/astrobox.log after SSH’ing to the box.

Login is: pi / raspberry

Also, I have closed this topic because it’s very very old – please start a new thread if you have more questions :wink: