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

Is this the correct disconnect message? #492

Closed
cakeller98 opened this issue Jun 6, 2014 · 9 comments
Closed

Is this the correct disconnect message? #492

cakeller98 opened this issue Jun 6, 2014 · 9 comments

Comments

@cakeller98
Copy link

Changing monitoring state from 'Operational' to 'Closed'
Unexpected error while reading serial port: SerialException: 'Attempting to use a port that is not open' @ comm.py:_readline:1001
Connection closed, closing down monitor

it's the "Unexpected error while reading serial port: SerialException: 'Attempting to use a port that is not open' @ comm.py:_readline:1001" that has me wondering.

This is non-critical. Only asking because the part about it being unexpected leaves me wondering if I have my configuration set up correctly (is my firmware giving the wrong response to a disconnect? or something else?)

thanks and my apologies if this is a stupid question.

@cakeller98
Copy link
Author

Hmm... still wondering the question... and a ping.

@foosel
Copy link
Member

foosel commented Jun 20, 2014

When exactly does this happen? => https://github.com/foosel/OctoPrint/wiki/How-to-file-a-bug-report

@cakeller98
Copy link
Author

I'm so sorry - I thought this was just a stupid simple question... and thought you could answer without a thought. But here's the report.

1. What were you doing?

connecting and/or disconnecting

2. What did you expect to happen?

a clean informative message that tells me the connection opened or closed without throwing exceptions or expressing that an "error" occurred... but if that is expected behavior then fine - that's what I wanted to know

3. What happened instead?

see below under "contents of terminal tab" it should be self explanatory what happened.

4. Branch & Commit:

branch: devel
commit: ec508f5

5. Link to octoprint.log on gist.github.com or pastebin.com:

octoprint log
serial log

let me know if you want me to run with the --debug option.

6. Contents of terminal tab:

_printer off press connect button_

Changing monitoring state from 'Offline' to 'Opening serial port'
Connecting to: COM3
Unexpected error while connecting to serial port: COM3 SerialException: 'could not open port 'COM3': WindowsError(2, 'The system cannot find the file specified.')' @ comm.py:_openSerial:964
Changing monitoring state from 'Opening serial port' to 'Error: Failed to open seria...'

_printer on and connected and operational... press disconnect_

Changing monitoring state from 'Operational' to 'Closed'
Send: N8 M105*47
Unexpected error while writing serial port: AttributeError: ''NoneType' object has no attribute 'write'' @ comm.py:_doSendWithoutChecksum:1124
Connection closed, closing down monitor

@foosel
Copy link
Member

foosel commented Jun 20, 2014

Thanks. It's not a stupid question :)

It's probably some weird timing issue (which I can't reproduce right now,
but I'll see what I can do)

@cakeller98
Copy link
Author

no worries - I just wanted to know if it was worth mentioning or expected behavior. It seems it might be the cause of me having to, on occasion, hit the disconnect/connect button a few times to straighten things out and/or cycle printer power or restart the server. It's a minor inconvenience and minimal hassle more than anything.

BUT if I can provide any other help tracking it down - let me know.

One note - I'm on windows 8.1 (tablet), and doing the
python setup.py install
then running the exe from the scripts directory

in case that makes a difference.

@cakeller98
Copy link
Author

I updated to the latest devel commit: d8f1387
Messages are the same as they were with the commit mentioned before.

@nophead
Copy link
Contributor

nophead commented Jun 20, 2014

I get similar errors on connect and disconnect and when I turn the power to the machine off. I think it is a race condition where one thread uses the port after another has closed it.

foosel added a commit that referenced this issue Aug 7, 2014
Depending on what was happening in the monitoring thread this could lead to an attempt to write to the already closed port, logging an error and killing the interface in the process. Also fixed a timing issue in the state reporting towards the frontend, state updates and readings for clients are now wrapped in a mutex

Closes #492
@foosel
Copy link
Member

foosel commented Aug 7, 2014

I think I killed it with fire

@foosel foosel closed this as completed Aug 7, 2014
@foosel
Copy link
Member

foosel commented Aug 7, 2014

In the devel branch that is. See the above commit.

foosel added a commit that referenced this issue Aug 8, 2014
Depending on what was happening in the monitoring thread this could lead to an attempt to write to the already closed port, logging an error and killing the interface in the process. Also fixed a timing issue in the state reporting towards the frontend, state updates and readings for clients are now wrapped in a mutex

Closes #492
(cherry picked from commit 11fb18f)
@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 30, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants