Support for Dreammaker Overlord (Pro)

Hi there,

I am new to OctoPrint/OctoPi

I wonder if the Dreammaker Overlord and Overlord Pro can be supported? (
I think back in the past these printers already worked with OctoPrint ( but somehow with the latest version of OctoPi I can't get it to work.
It simply does not connect to the printer via USB - regardless of what baudrate I try.
When trying to connect the printer briefly reboots but no connection is established.

I created a serial.log file where I tried all baudrates one after the other.
Maybe that can help get it working again and fix the problem?
serial.log (20.3 KB)

BTW: Printer has the latest firmware 2.3.5p

Thank you very much!
Best regards

It seems like 250000 is the right baudrate for your printer.
Your last connection in your serial.log almost worked.
Have you tried a different usb cable?

I agree with @PrintedWeezl, manually select 250000.

And also enable "Wait for start on connect" in Settings > Serial Connection > Firmware & Protocol > Protocol fine tuning

@foosel @PrintedWeezl - Thank you very much for your rapid feedback! I am sorry to come back to you a bit late but I had a bad flu that took me out of order.

I tried all your recommendations but sadly to no avail.

  • Set USB Port fixed
  • Set 250000 fixed
  • Set Wait for start on connect
  • Tried with Firmware autodect and without.
  • Set all timeouts to 30sec

Everytime the connection breaks at the very same point:

2019-07-18 23:46:13,295 - Connecting to: /dev/ttyUSB0
2019-07-18 23:46:13,441 - Changing monitoring state from "Offline" to "Opening serial port"
2019-07-18 23:46:13,656 - Connected to: Serial<id=0xb04371d0, open=True>(port='/dev/ttyUSB0', baudrate=250000, bytesize=8, parity='N', stopbits=1, timeout=30.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
2019-07-18 23:46:13,700 - Changing monitoring state from "Opening serial port" to "Connecting"
2019-07-18 23:46:14,367 - Recv: start
2019-07-18 23:46:14,553 - Recv: echo:Marlin 1.0.0
2019-07-18 23:46:14,663 - Send: N0 M110 N0*125
2019-07-18 23:46:14,709 - Recv: echo: Last Updated: Dec 13 2016 11:30:39 | Author: Ver.2.3.5
2019-07-18 23:46:14,826 - Recv: Compiled: Dec 13 2016
2019-07-18 23:46:14,862 - Recv: echo: Free Memory: 1888 PlannerBufferBytes: 1232
2019-07-18 23:46:14,996 - Recv: echo:Stored settings retrieved
2019-07-18 23:46:15,070 - Recv: echo:Steps per unit:
2019-07-18 23:46:15,170 - Recv: echo: M92 X78.74 Y78.74 Z78.74 E73.00
2019-07-18 23:46:15,226 - Recv: echo:Maximum feedrates (mm/s):
2019-07-18 23:46:15,310 - Recv: echo: M203 X300.00 Y300.00 Z300.00 E80.00
2019-07-18 23:46:15,360 - Recv: echo:Maximum Acceleration (mm/s2):
2019-07-18 23:46:15,440 - Recv: echo: M201 X9000 Y9000 Z9000 E10000
2019-07-18 23:46:15,523 - Recv: echo:Acceleration: S=acceleration, T=retract acceleration
2019-07-18 23:46:15,681 - Recv: echo: M204 S1200.00 T3000.00
2019-07-18 23:46:15,787 - Recv: echo:Advanced variables: S=Min feedrate (mm/s), T=Min travel feedrate (mm/s), B=minimum segment time (ms), X=maximum XY jerk (mm/s), Z=maximum Z jerk (mm/s), E=maximum E jerk (mm/s)
2019-07-18 23:46:15,870 - Recv: echo: M205 S0.00 T0.00 B20000 X10.00 Z10.00 E5.00
2019-07-18 23:46:15,938 - Recv: echo:Home offset (mm):
2019-07-18 23:46:16,035 - Recv: echo: M206 X0.00 Y0.00 Z1.17
2019-07-18 23:46:16,108 - Recv: echo:PID settings:
2019-07-18 23:46:16,160 - Recv: echo: M301 P3.61 I0.22 D15.16
2019-07-18 23:46:16,231 - Recv: plainFactor:
2019-07-18 23:46:16,314 - Recv: 36.42
2019-07-18 23:46:16,429 - Recv: 73.69
2019-07-18 23:46:16,521 - Recv: -20734.16
2019-07-18 23:46:16,632 - Recv: plainFactor:
2019-07-18 23:46:16,714 - Recv: -1756.53
2019-07-18 23:46:16,797 - Recv: 3554.10
2019-07-18 23:46:16,857 - Recv: 1.53
2019-07-18 23:46:16,931 - Recv: 6.29
2019-07-18 23:46:16,990 - Recv: PCB VERSION:0
2019-07-18 23:46:17,077 - Recv: lcdVer
2019-07-18 23:46:17,211 - Recv: 10
2019-07-18 23:46:17,336 - Recv: lcdVer
2019-07-18 23:46:17,414 - Recv: 10
> 2019-07-18 23:46:17,480 - Recv: 1
> 2019-07-18 23:46:47,613 - There was a timeout while trying to connect to the printer
2019-07-18 23:46:47,790 - Changing monitoring state from "Connecting" to "Offline"
2019-07-18 23:46:48,020 - Connection closed, closing down monitor

Latest log:
serial.log (8.3 KB)

Your help in hunting this problem down is very much appreciated!

The next thing I would try would be a different usb cable. Preferable a good shielded one with a ferrite core around it.

Also I would check if the usb cable is on or near a interference source.

Maybe @foosel has additional ideas :slight_smile:

That printer never responds to the initial M110 -_-

OctoPrint 1.3.12 will try to repeat that if it times out during initial connect (also to work around corrupted messages right after controller boot), but 1.3.11 doesn't do that yet.

If you feel comfortable with that you could try running the maintenance branch for now.

1 Like

@PrintedWeezl : Thanks! I tried multiple USB cables already... different length and qualities. Same problem every time. It also is quite obvious that the communication breaks always at the same stage.

@foosel : Thank you Gina. Just out of curiosity, what is that M110 command? Can you please gimme a hint how I can switch to the maintenance branch? I am new to OctoPi :wink: I downloaded the latest OctoPi image and performed the online update. Thank you very much! Your help is much appreciated.

It resets the line numbers to 0. OctoPrint uses it as the handshake command with the printer since some printers require a clean slate with regards to line numbering and it's one of the most omnipresent commands.

1 Like

Hi Gina... following your advice and tutorial I get this:

Correct me if I am wrong but it seems like I already have "maintenance" branch installed, have I?

Update: It worked... I am no on 1.3.12.dev160+gee93e25f. Since 3D-Printer is currently doing a job off of a SD-Card I will try to connect with OctoPi tomorrow and report back if the problem still persists!

Good morning Gina :slight_smile: ,
I am sorry to bug you once more... I am on 1.3.12.dev160+gee93e25f now likewise you suggested but the problem still persists. As far as I can tell the serial output is still the same. I will inlcude the logfile anyway just in case:

serial.log (5.8 KB)

Is there anything more that I can do to debug the situation and get my printer going? I feel we are almost there. It would be a pitty not being able to use this great piece of software.

Best regards

Do you still have "Wait for start on connect" enabled? If so, does it work if you turn it off?

I have now tried to disable the " Wait for start on connect" option again and tested it again. Problem persisting... ;./

All out of ideas then for the moment, sorry.

Okay.. thank you nevertheless. Hopefull some day it can be supported. Let me know if I can help any further testing or debugging

I find it interesting that the serial.log you posted shows the printer sending lots of readable information including a "start". It is as if the printer is responding to an "M110" before OctoPrint sends it.

"It is as if the printer is responding to an "M110" before OctoPrint sends it."

I—for one—welcome our new precognizant 3d printing overlords.