Support for Dreammaker Overlord (Pro)

careyer · July 10, 2019, 10:26pm

Hi there,

I am new to OctoPrint/OctoPi

I wonder if the Dreammaker Overlord and Overlord Pro can be supported? (www.dreammaker.cc)
I think back in the past these printers already worked with OctoPrint (http://docs.lattepanda.com/content/1st_edition/3d_printer_server/) 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
Thomas

PrintedWeezl · July 11, 2019, 10:19am

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?

foosel · July 11, 2019, 10:26am

I agree with @PrintedWeezl, manually select 250000.

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

careyer · July 18, 2019, 10:14pm

@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
additionally:
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!
Cheers!
Thomas

PrintedWeezl · July 19, 2019, 12:06am

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

foosel · July 19, 2019, 7:42am

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.

careyer · July 19, 2019, 9:18am

@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 I downloaded the latest OctoPi image and performed the online update. Thank you very much! Your help is much appreciated.

foosel · July 19, 2019, 9:21am

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.

careyer · July 19, 2019, 9:56pm

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

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!

careyer · July 20, 2019, 7:35am

Good morning Gina ,
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
Thomas

foosel · July 22, 2019, 10:42am

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

careyer · July 24, 2019, 8:46am

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

foosel · July 25, 2019, 12:45pm

All out of ideas then for the moment, sorry.

careyer · July 31, 2019, 9:28am

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

b-morgan · August 3, 2019, 7:26pm

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.

OutsourcedGuru · August 5, 2019, 4:59pm

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

Sergh_JSL · February 9, 2020, 6:57pm

Hi Careyer,

Did you solve the problem with your OverLord Pro yet? If so, please, let me know how. I have same issue with mine.

Thanks in advance.

haku73 · October 21, 2020, 4:36pm

Hi Careyer,
news? I have the same problem

Bye
A

careyer · October 22, 2020, 7:14am

@haku73 sadly the problem still persists. The Dreammaker Overlord Pro obviously has a slightly different firmeware. Gina (@foosel) was kind enough to help me and try to analysze the problem but since then sadly no news or bugfixes that I know of.
My printer still has to work standalone without octorpint

Sooner or later I had give up because of time constraints I had back at the time. Maye you want to to have a try figuring it out with the devs?

Best regards

haku73 · October 22, 2020, 8:55am

I am also printing stand alone. I have an old distribution of octoprint that works but obviously with all the limitations (for example it doesn't run on a Raspberry 3 B +) If you have any news, let's update. Bye