Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

1.3.11rc2 disconnect/connect issue #3111

Closed
arhi opened this issue Apr 5, 2019 · 9 comments

Comments

Projects
None yet
3 participants
@arhi
Copy link

commented Apr 5, 2019

the disconnect is ok, every time I "disable motors" the usb drops, that's a bug in electronic on this printer, normally after that I click connect and it connects...

what happens now with this RC2, it disconnects on M84 (as expected) but is totally ignoring my clicks on the "Connect" button :D ..

only thing that happens when I click "connect" is

2019-04-05 18:54:36,328 - tornado.access - WARNING - 400 POST /api/connection (::ffff:192.168.89.6) 96.47ms
2019-04-05 18:54:37,638 - tornado.access - WARNING - 400 POST /api/connection (::ffff:192.168.89.6) 42.77ms
2019-04-05 18:54:38,650 - tornado.access - WARNING - 400 POST /api/connection (::ffff:192.168.89.6) 100.67ms

and iirc 400 is "bad request" ... so I reload the interface

2019-04-05 18:55:43,052 - octoprint.server.util.sockjs - INFO - Client connection closed: ::ffff:192.168.89.6
2019-04-05 18:55:43,686 - octoprint.server.util.flask - INFO - Passively logging in user arhimed from ::ffff:192.168.89.6
2019-04-05 18:55:52,130 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:192.168.89.6
2019-04-05 18:55:52,635 - octoprint.server.util.sockjs - INFO - Client connection closed: ::ffff:192.168.89.6
2019-04-05 18:55:54,267 - octoprint.server.util.sockjs - INFO - New connection from client: ::ffff:192.168.89.6
2019-04-05 18:55:54,476 - octoprint.server.util.flask - INFO - Passively logging in user arhimed from ::ffff:192.168.89.6
2019-04-05 18:55:58,259 - octoprint.server.util.sockjs - INFO - User arhimed logged in on the socket from client ::ffff:192.168.89.6

and click connect again, and now it works

2019-04-05 18:56:29,083 - octoprint.util.comm - INFO - Changing monitoring state from "Offline" to "Detecting serial port"
2019-04-05 18:56:29,169 - octoprint.util.comm - INFO - Changing monitoring state from "Detecting serial port" to "Opening serial port"
2019-04-05 18:56:29,179 - octoprint.util.comm - INFO - Changing monitoring state from "Opening serial port" to "Connecting"
2019-04-05 18:56:29,202 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2019-04-05 18:56:29,212 - octoprint.util.comm - INFO - Changing monitoring state from "Connecting" to "Operational"
2019-04-05 18:56:29,219 - octoprint.util.comm - INFO - M110 detected, setting current line number to 0
2019-04-05 18:56:29,262 - octoprint.util.comm - INFO - Printer reports firmware name "Smoothieware,"
2019-04-05 18:56:30,111 - octoprint.plugins.tracking - INFO - Sent tracking event printer_connected, payload: {u'printer_baudrate': 115200, u'printer_port': u'AUTO', 'firmware_name': u'Smoothieware,'}
@GitIssueBot

This comment has been minimized.

Copy link
Collaborator

commented Apr 5, 2019

Hi @arhi,

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 - that can be found at discourse.octoprint.org. Go there for any kind of issues with network connectivity, webcam functionality, printer detection or any other kind of such support requests or general questions.

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 2019-04-19 19:00 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.

@arhi

This comment has been minimized.

Copy link
Author

commented Apr 5, 2019

I don't even need to print anything, just send M84 for usb connection to drop, click Connect and there it is 400 again :(

shift reload - connect now works
M84 - disconnect
Connect button generates warning 400 post ...
shift reload - now it works again
...

but the problem is - it does not happen like this "every time"

@foosel

This comment has been minimized.

Copy link
Owner

commented Apr 8, 2019

Can you please provide

  • octoprint.log
  • a dump of your JS console
  • the details and especially the response of the bad request from the Network tab in the developer tools? Switch to network tab, click connect button, click on generated request, switch to response tab in details, make screenshot. Example for a different request follows.

image

@foosel

This comment has been minimized.

Copy link
Owner

commented Apr 8, 2019

I have one idea what could be happening.

If you have AUTO selected for the port on connection, in 1.3.11 it will now be set to the port that actually got connected to. If that port now vanishes from the system and another one pops up instead when you issue an M84, it would explain the behaviour you are seeing, because the UI still thinks the formerly connected to port exists, but it doesn't and the server hence throws a 400 when instructed to connect to it. When you refresh the UI, the list of available ports gets fetched again and also the connection default port of AUTO gets set again, so connecting works.

To test this theory, I'd like you to do the following:

  1. open the connection pane and make a screenshot of it with the dropdown open (see below for example)
  2. connect to your printer
  3. issue an M84
  4. open the connection pane and make a screenshot of it with the dropdown open
  5. reload
  6. open the connection pane and make a screenshot of it with the dropdown open

image

@foosel

This comment has been minimized.

Copy link
Owner

commented Apr 8, 2019

And also test what happens if you trigger the issue and - instead of doing a full UI reload - you only click the little refresh link in the top right corner of the connection pane. My money would be on the connect working then since things should be refreshed properly.

foosel added a commit that referenced this issue Apr 9, 2019

🐛 Refresh connection tab on disconnect
That way we'll hopefully notice vanishing/changed ports.

Potential fix for #3111, waiting for test results from @arhi
@foosel

This comment has been minimized.

Copy link
Owner

commented Apr 9, 2019

I pushed a potential fix for this (see above), but I'd still like you @arhi to test the above things which would validate that my potential fix is an actual fix :)

@foosel

This comment has been minimized.

Copy link
Owner

commented Apr 11, 2019

I've pushed what I believe to be the fix out with 1.3.11rc3. If it still isn't working please ping me here and we'll reopen this and dig deeper.

@foosel foosel closed this Apr 11, 2019

@arhi

This comment has been minimized.

Copy link
Author

commented Apr 11, 2019

sorry for not replying earlier I was AFK for few days... just updated my octoprint with rc3, tried and first test show that issue is fixed. running a print now, should finish in 5 hours and I'll retest it then but initial test show the issue was done.

now, wrt ports ... port do go away and then is back with same name, dunno if that makes sense, but that never got to be a problem before and here we see in the octoprint.log the 400 error from http server .. so no errors in octoprint.log, print finishes normally, and then when I click connect I get that "tornado.access - WARNING - 400 POST /api/connection" error in octoprint log

anyhow if I manage to reproduce it with rc3 I'll get all the snapshot of the js console and log and will try other refresh and .. :D . but so far it looks like it's fixed

@arhi

This comment has been minimized.

Copy link
Author

commented Apr 12, 2019

this appears to be solved, can't reproduce it any more :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.