What were you doing?
On Trying to connect with my printer, I encountered a strange behaviour which I wasn't able to trace and eliminate.
Alternate A
Workflow that doesn't lead to a successful connect:
- Click on Connect (once)
- Terminal: USB Port is opened and Connect Command issued (N0 M110 N0*125)
- Connection always times out (having set timeout to 60s)
Alternate B
Workflow that lead to success on connect:
- Click on Connect
- Before Timeout click again (twice in fast sequence)
- Connection gets established
Inbetween these tries, there where no changes to config files.
This behaviour is reproducable with my setup.
What I have tried, chasing the issue:
- Config: Wait for start Option
- Config: Baudrate Auto, Device Auto
- Check device permissions, pi groups (pi adm tty dialout cdrom sudo audio video plugdev games users input netdev gpio i2c spi)
(eventhough there was no hint for an issue in the terminal log)
What did you expect to happen?
I expected a connect with the first try
What happened instead?
A connect was only established with Alternate B
Did the same happen when running OctoPrint in safe mode?
_only tried with the vanilla install, but not in safe mode_
Branch & Commit or Version of OctoPrint
Bundled Version (img) with OctoPi Release (Octoprint 1.3.5)
Operating System running OctoPrint
- RasPi 3
- OctoPi 0.14.0
Printer model & used firmware incl. version
Turnigy Fabrikator II Mini (Malyan M100)
_See the exact Infos in the Terminal Log._
Browser and Version of Browser, Operating System running Browser
Google Chrome (Version 62.0.3202.94 (Offizieller Build) (64-Bit))
OSX 10.13.2
Link to octoprint.log
No Useful information concerning this issue (startup, 404, and later a few client connects)
Link to contents of terminal tab or serial.log
Terminal Log:
Link to contents of Javascript console in the browser
_not recorded_
Screenshot(s)/video(s) showing the problem:
_none_
I have read the FAQ.
lakay
All 44 comments
Hi @lakay,
It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Read the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).
If you did not intend to report a bug but wanted to request a feature or brain storm about some kind of development, please take special note of the title format to use as described in the Contribution Guidelines.
Please do not abuse the bug tracker as a support forum - if you have a question or otherwise need some kind of help or support refer to the Mailinglist or the G+ Community instead of here.
Also make sure you are at the right place - this is the bug tracker of the official version of OctoPrint, not the Raspberry Pi image OctoPi nor any unbundled third party OctoPrint plugins or unofficial versions. Make sure too that you have read through the Frequently Asked Questions and searched the existing tickets for your problem - try multiple search terms please.
I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2017-12-20 00:50 UTC) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!
Best regards,
~ Your friendly GitIssueBot
PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.
GitIssueBot
on 6 Dec 2017
It looks as if your printer isn't responding to M110 N0. If you send it manually does it send anything back?
kantlivelong
on 6 Dec 2017
What i regard as strange is that it seems to acknowledge with ok, but responds after connection close is issued in the terminal:
Changing monitoring state from 'Opening serial port' to 'Connecting'
Send: N0 M110 N0*125
Connection closed, closing down monitor
Recv: ok N0 P15 B15
Changing monitoring state from 'Connecting' to 'Operational'
Can you re-run the test with serial logging enabled and attach the log?
kantlivelong
on 6 Dec 2017
will do ... but might only be able to dump this in the morning (in aprox 7h).
so happy printing after all ... ;)
lakay
on 6 Dec 2017
Print is done ...
please find the serial log here:
https://gist.github.com/lakay/6ac1a9bf6be7e40b048169ab5360a99a
The first test part (connection timeout on single click) is only in the terminal
Again as in the terminal log, you can see that the printer ack's after the log says connection closed ...
Do I need to expand the connect command with special characters? a forced return or the like?
lakay
on 6 Dec 2017
I just wanted to report that I'm experiencing the same issue, and double clicking on the connect resolves my issue. It's a workaround for now, but I'm subscribing here to find a permanent fix.
Iunchbox
on 6 Dec 2017
I've heard about this from various corners around the net now, and all affected printers appear to be Malyan or Monoprice rebrands of them.
About this "connection closed" on ack:
2017-12-06 01:35:18,159 - Connection closed, closing down monitor
I think it still originates from the earlier connection attempt, only delayed due to a read timeout. So it might be misleading here.
What I find interesting is that the printer doesn't seem to react to the single click at all, but a double click makes it respond properly to the initial handshake M110. What does happen on the printer's side when you only click once? Does it visible reset (display goes off and back on or something like that), does it change in some visible way at all, or does it just sit there and do nothing? And how does this differ from when you do the double click shenanigans? Does the printer ever respond on one click if you increase the connection timeout dramatically, or does it sit there indefinitely? What happens when you try to connect to your printer with a regular serial console (e.g. the one bundled with the Arduino IDE)?
I don't have any Malyan printer to test here, so if we want to get to the ground to this and how it might be worked around more permanently (either by a core change or a plugin) I need to ask these annoying questions and also need people willing test some possibly weird stuff or short code snippets.
foosel
on 6 Dec 2017
dear foosel,
i will gladly contribute time and efforts into nailing this down.
Will step through the Tests you proposed, and deliver my findings.
I hope I may find interesting hints while testing.
I had a short look at the malyan github repo, and am not so keen to start forensics on that. ;)
my results will pop up here, will start right away ...
best regards and my kudos (this is a great piece of work)
lakay
on 6 Dec 2017
@foosel I'd be happy to help nail this thing down with your instructions. If there's anything else I can do, let me know.
What does happen on the printer's side when you only click once? Does it visible reset (display goes off and back on or something like that). Does it change in some visible way at all, or does it just sit there and do nothing?
It does absolutely nothing
How does this differ from when you do the double click shenanigans?
There's no visible difference when I do the double click shenanigans. It just consistently connects almost immediately after the second click. Here's a GIF of it. Seconds 1-12 is what happens when I single click . 13-15 you'll see the double click and connects.
Does the printer ever respond on one click if you increase the connection timeout dramatically, or does it sit there indefinitely?
I've set the connection timeout to 60 seconds (hope that's dramatic enough) and it still doesn't connect with one click. The only reason I've been able to print with Octoprint is by finding this thread via google day 1 of owning a printer.
What happens when you try to connect to your printer with a regular serial console (e.g. the one bundled with the Arduino IDE)?
I'm sorry, I can't answer this for you. No idea what exactly I need to do.
Iunchbox
on 12 Dec 2017
@lunchbox
This sounds like a tough nut to crack. So far that doesn't really give me any hints as to what might be up (not your fault).
I'm sorry, I can't answer this for you. No idea what exactly I need to do.
Ok... so... take your printer and connect it via USB to your regular PC. Download Pronterface. Try to connect with THAT to your printer. See if it behaves differently and if so in what way.
foosel
on 13 Dec 2017
Here are my current findings.
I have made in the meantime a few Tests with cu under octopi.
Connection settings as in octoprint.
If my Hello code is accepted, it replies ok, but only in 3 out of 5 tries.
Else, or on any unexpected character sequence the connection hangs, no reply, no error, no hangup.
Any following connection try is not successful, not until either I reset the printer, reconnect the usb, or in fact use octoprint double click magic.
I have used a different Hello Command, which I collected from the Repetier Host console.
Haven't noted that, so I have to recheck it.
My theory with the double click shenanigans is, that your serial implementation does in fact issue a fast sequence of open serial, evtl. the hello, closes connection after ms, because of the second connect command in the queue, which then succeeds ...
The second connect is always successful, so after a hup and reopen, the firmware seems to resets its serial connection (or the handler).
But these are just a few wild guesses.
Because I was not able to emulate this behaviour with cu, just too slow in manual mode ... I would like to write a little test for this.
@foosel, is there eventually a test harness with the code, that i can use to write a test unit for the serial connection?
lakay
on 13 Dec 2017
@foosel i assume test_comm.py would be a good starting point.
When I scrap the ddt import and annotations, and replace the mocked serial connection with a live one ... would I be able to do integration testing under the testframework?
lakay
on 13 Dec 2017
tests/util/test_comm.py? That would be the unit tests for several helper methods used in the comm layer, so not what you are looking for. You could try playing with src/octoprint/util/comm.py instead - it has a main method that you can use to stream a file to the printer's SD and get some stats on the transmission speed. It uses the underlying comm layer. You'll probably want to play around with the function that actually opens the serial port, it's located here. As you can see, it already does some open-close-open magic (there are a bunch of printers out there that otherwise wouldn't work properly). Might be interesting to see if changing up things here might help.
I tried my hand at a plugin that set rtscts flow control on the connection because some people on the mailinglist said they'd read that this would help connecting reliably to the Monoprice Delta Mini (which afaik is also a rebranded Malyan), but that didn't actually work out. Still, might be useful as a reference. Opening the serial port happens here.
foosel
on 14 Dec 2017
I have the Monoprice Select Mini V2 (Malyan M200) and it does the same thing. So I have been doing some investigating and discovered the trick to getting it to work.
open ODD
open NONE
Close ODD
Use NONE
What the octoprint does is:
Open ODD
Close ODD
Open NONE
Use NONE
I do not know if other printers will work as well since I only have the one.
ygator
on 19 Dec 2017
I also tried to connect my Fabrikator Mini V2 (aka Malyan M100) to Octoprint, initially without success.
Fortunately I found this reddit entry where a solution was described by switching serial logging on and off. I did that - afterwards the connection worked instantly.
Update: sometimes I need to apply this change multiple times until the connection works.
LuckyBenni
on 22 Dec 2017
the double click is working on my amd64 pc but not on my odroid u3. any hints?
darul86
on 30 Dec 2017
@foosel
Any luck with what I wrote above?
ygator
on 18 Jan 2018
@ygator I plan to whip up a quick plugin for you guys as soon as I can to test with that changes serial port creation to this pattern. So far haven't found the time though (first a much needed vacation, now catching up on what came in during that plus fighting off a cold).
foosel
on 18 Jan 2018
So... here's something to test with.
It's a minimal plugin that changes the serial opening to what @ygator suggested. Note that a) it doesn't work at all on Windows based systems, b) it doesn't play nice with other printers (so I couldn't really test this) and c) I have absolutely no idea at all if this might actually help or not.
To test, on OctoPi, SSH into your machine, then:
cd ~/.octoprint/plugins
wget https://gist.githubusercontent.com/foosel/73dd83fc723fa164a8e2f88b5d8476e6/raw/dd58f5f6e423a00458b4754a0931e8bffa8ce415/serial_double_open.py
sudo service octoprint restart
Please report back. To uninstall/disable it again, it can be found as "Serial Double Open Plugin" in the Plugin Manager.
foosel
on 22 Jan 2018
hello foosel. i havnt much time this evening but ive added the plugin onto my odroid u3 did a quick test. auto connect is working. i disconnected and connected again. its working. very nice. thank u very much!
darul86
on 22 Jan 2018
@foosel 👍 : Tested on my MP Select Mini v2 and it now works. Previously, I had exactly the same symptoms as everyone else on this issue.
@ygator 👍 : Thanks for determining and sharing the correct order to do the serial opening sequence! How in the world did you ever arrive at that sequnce? Trial and error? Educated guess? Both of the above? In any case, a huge thank you!
petonic
on 23 Jan 2018
I honestly find a bit disturbing that this works. Would love to know what the heck Malyan did to their controller's serial connection that this kind of black magic (and IMHO outright broken - it hurt to implement this) connection voodoo actually makes things work O_O
foosel
on 23 Jan 2018
@foosel - just confirming that the connect plugin fixes this issue for me on my Monoprice Mini as well.
mveinot
on 23 Jan 2018
Works beautifully on my MP Select Mini v2. That's for this!
jbkuma
on 24 Jan 2018
@petonic I was looking into what was not working. I wrote a program to open the device and that worked, but only after octoprint had it open. I then looked at what octoprint was doing when opening and saw the weird open ODD close open NONE sequence. I then tried the same, but that did not work. I then added an extra open and that did not work consistently. I finally left the initial open OFF open and that finally work consistently every time.
@foosel I found the open ODD/close/open NONE weird as well. Where did that come from?
ygator
on 24 Jan 2018
@ygator that was a bug fix for reconnection issues under Debian, from #673. To be honest, I'm not even sure if that would still be needed. Since it boiled down to just opening and closing and opening the serial port though it didn't cause any issues.
Sadly, open-open-close does, otherwise I'd probably just merge that into core, less hassle for end users than having to install a plugin.
foosel
on 24 Jan 2018
@foosel Confirming that the serial_double_open plugin resolves the issue of connecting to the Monoprice Mini Delta 3D printer.
mikedan99
on 27 Jan 2018
Just confirming this works with octopi.
ssh pi@<yourIPaddress>
cd ~/.octoprint/plugins
wget https://gist.githubusercontent.com/foosel/73dd83fc723fa164a8e2f88b5d8476e6/raw/dd58f5f6e423a00458b4754a0931e8bffa8ce415/serial_double_open.py
sudo service octoprint restart
All i did was the above and instantly Auto baud and Auto port worked. nothing else was required. Just ssh into the unit and run that script. Done.
adamoutler
on 1 Feb 2018
Ok, after this very positive feedback, I packaged this up a bit nicer so that it can be registered on the repository: https://github.com/OctoPrint/OctoPrint-MalyanConnectionFix
Could anyone with an affected printer verify that this packaged up version still works fine? Btw, it will log a warning if you have the "Serial Double Open" plugin installed. This new plugin supersedes that, so you can safely uninstall Serial Double Open.
foosel
on 5 Feb 2018
I confirm the packaged version works, thanks a lot!
(Monoprice Select Mini v1)
goebish
on 5 Feb 2018
i can confirm it works on my fabrikator II mini on an odroid u3
darul86
on 5 Feb 2018
I can also confirm it works with:
- Fabrikator II mini
- Raspberry Pi 3 Model B
- OctoPrint 1.3.6 on OctoPi 0.14.0
Thank you 👍
Cyclenerd
on 6 Feb 2018
Ok, thanks everyone! 👍 I just released the plugin on the OctoPrint Plugin Repository as well, so it should be easy to find and install in the future. Closing this :)
foosel
on 7 Feb 2018
The plug-in isn't showing up in Octopi for me.
Will those of us who tested need to update?
Were there changes from the "serial double open" previous version?
I originally heard about this from this will page. Which should probably be updated. https://www.mpselectmini.com/octoprint/serial_double_open_plugin
adamoutler
on 7 Feb 2018
my understanding is that the only change was to package it up as an actual plugin. If it was working before, you can probably just keep using it like that.
mveinot
on 7 Feb 2018
The understanding of @mveinot is correct. I merely renamed it, packaged it up properly and added update functionality just in case.
If "serial double open" is working for you now, perfect, keep it.
As for the plugin not showing up, if you already have it installed then the Plugin Repository browser inside OctoPrint (please don't confuse the operating system image OctoPi with the software that is running on it OctoPrint) will by default not show it to you since you already have it. Otherwise you might just have to refresh manually or click to refresh the repository data from the net - it is cached locally.
foosel
on 8 Feb 2018
Confirmed working with my Mini Fabrikator 2 and Raspberry Pi Zero.
I had found a different workaround than most here: I would click "connect", and the status always got stuck on "detecting baudrate". I'd then click "disconnect" and then "connect", and it'd then work properly. Not a big deal, but the new plugin makes it work properly first try. Thanks!
emilecantin
on 8 Feb 2018
worked first try on Monoprice Mini Delta, Recv: NAME. Malyan VER: 3.7 MODEL: M300 HW: HG01
👍
idcrook
on 9 Feb 2018
Beautiful! Works! Thanks soooo much guys!
farhany
on 18 Apr 2018
Hi,
I understand this is listed as not working on Windows, but I'm trying to get Octoprint working with the Maker Select Mini on Windows and having no luck. I'm wondering if anyone else has attempted something similar.
I can communicate with the printer via a serial console using the same port selected in Octoprint, no problem, so I assume my USB drivers work okay.
I'm also making sure to use a fixed baud rate (115200).
I'd appreciate anyone able to help on this! Thanks in advance.
wormyrocks
on 9 May 2018
I realize this is an old thread. I just updated from 1.3.8 to 1.3.9 and I can no longer connect. While I am on windows and unable to use this plugin, I easily and consistently could connect using the double click connect trick. That no longer works and I cannot connect to my monoprice select mini at all.
steve220
on 29 Sep 2018
I guess I read too much into the “windows” part of this. I'm actually running on a pi 3 and connecting through a windows machine. Installing the plugin worked great.
steve220
on 29 Sep 2018
Confirming - with MP Select Mini v2 this plugin instantly fixed the connection issues - thanks @foosel !
hamiltont
on 10 Jan 2019
Related issues
FormerLurker
·
5Comments
halkeye
·
4Comments
christianh17
·
5Comments
halxinate
·
4Comments
ModischFabrications
·
3Comments
Most helpful comment
So... here's something to test with.
It's a minimal plugin that changes the serial opening to what @ygator suggested. Note that a) it doesn't work at all on Windows based systems, b) it doesn't play nice with other printers (so I couldn't really test this) and c) I have absolutely no idea at all if this might actually help or not.
To test, on OctoPi, SSH into your machine, then:
Please report back. To uninstall/disable it again, it can be found as "Serial Double Open Plugin" in the Plugin Manager.