Octoprint: [RC Feedback] Feedback on the 1.3.7rc2 Release Candidate

[foosel]

Please provide general feedback on your experience with the 1.3.7rc2 Release Candidate here. An "All is working fine" is valuable feedback as well, because it tells me that people in fact are testing the RC and just not finding any problems. Thanks :)

If you run into any obvious bugs, please open a new ticket and follow "How to file a bug report".

[b-morgan]

Upgraded to 1.3.7rc2. Before I try printing I noticed something in the install window about pip.

2018-03-23 09:59:34,617 > Successfully uninstalled OctoPrint-1.3.7rc1
2018-03-23 09:59:34,617 > Running setup.py install for OctoPrint: started
2018-03-23 09:59:38,887 > Running setup.py install for OctoPrint: finished with status 'done'
2018-03-23 09:59:39,803 ! You are using pip version 9.0.1, however version 9.0.2 is available.
2018-03-23 09:59:39,804 ! You should consider upgrading via the 'pip install --upgrade pip' command.
2018-03-23 09:59:39,806 > Successfully installed OctoPrint-1.3.7rc2

Should I do what it suggests?

The entire log file in case you want to look at it:
plugin_firmwareupdater_console.log

[foosel]

@b-morgan to be honest, personally I wouldn't bother for now. What surprises me though is that it's telling you that 9.0.2 is out when in fact 9.0.3 is already out (which btw also fixes a bug in 9.0.2 that already caused me a headache but for which I put in a workaround into 1.3.7rc2).

[chippypilot]

I've upgraded to RC2. Thanks for the quick turnaround.

• PIP is also reporting as 9.0.1 for me.

• The log files are now downloading.

• I have noticed that each gcode send now includes the checksum appended at the end of the line. If I use the Terminal to send M117 "Hello", it gets truncated on the printer display. It is OK on 1.3.6

Here's the Serial.log and screenshot requested:

2018-03-23 19:28:13,005 - serial.log is currently not enabled, you can enable it via Settings > Serial Connection > Log communication to serial.log

[foosel]

@chippypilot

I have noticed that each gcode send now includes the checksum appended at the end of the line. If I use the Terminal to send M117 "Hello", it gets truncated on the printer display. It is OK on 1.3.6

Can I get a serial.log for that please, and a screenshot of your settings under Serial Connection > Firmware & Protocol? The M117 truncation sounds rather like a known firmware issue to be honest, and whether checksums are always sent or not depend on detected firmware/individual settings.

[kantlivelong]

Did a few prints over the weekend. No issues encountered.

[dforsi]

I tested ok #2494 #2501 #2508

[chippypilot]

In addition to the earlier screenshot and default serial log, here is the serial log after enabling logging:

2018-03-27 09:40:39,914 - Changing monitoring state from "Offline" to "Detecting serial port"
2018-03-27 09:40:39,932 - Serial port list: ['/dev/ttyUSB0']
2018-03-27 09:40:39,932 - Connecting to: /dev/ttyUSB0
2018-03-27 09:40:39,938 - Changing monitoring state from "Detecting serial port" to "Opening serial port"
2018-03-27 09:40:39,940 - Connected to: Serial<id=0x6e164b70, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
2018-03-27 09:40:39,941 - Starting baud rate detection
2018-03-27 09:40:39,942 - Changing monitoring state from "Opening serial port" to "Detecting baudrate"
2018-03-27 09:40:39,956 - Trying baudrate: 115200
2018-03-27 09:40:39,958 - Send: N0 M110 N0*125
2018-03-27 09:40:42,436 - Recv: start
2018-03-27 09:40:42,444 - Changing monitoring state from "Detecting baudrate" to "Operational"
2018-03-27 09:40:42,458 - Send: N0 M110 N0*125
2018-03-27 09:40:42,457 - Recv: echo: External Reset
2018-03-27 09:40:42,460 - Recv: ANET2.0.0
2018-03-27 09:40:42,462 - Recv: echo: Last Updated: May 23 2016 16:50:45 | Author: (peyson, 20160523)
2018-03-27 09:40:42,463 - Recv: Compiled: May 23 2016
2018-03-27 09:40:42,465 - Recv: echo: Free Memory: 11499  PlannerBufferBytes: 1232
2018-03-27 09:40:42,466 - Recv: echo:Stored settings retrieved
2018-03-27 09:40:44,937 - Recv: Error:volume.init failed
2018-03-27 09:40:44,947 - Recv: ok
2018-03-27 09:40:44,950 - Send: N1 M115*39
2018-03-27 09:40:44,997 - Recv: ANET; http://www.anet3d.com
2018-03-27 09:40:44,999 - Recv: ok
2018-03-27 09:40:45,001 - Send: N2 M21*18
2018-03-27 09:40:45,236 - Recv: echo:SD init fail
2018-03-27 09:40:45,239 - Recv: ok
2018-03-27 09:40:47,446 - Send: N3 M105*36
2018-03-27 09:40:47,472 - Recv: ok T:18.7 /0.0 B:18.6 /0.0 T0:18.7 /0.0 @:0 B@:0

[foosel]

@chippypilot Hm, can you also provide octoprint.log and include a problematic M117 in your serial log? I'm trying to figure out why it's apparently switching to "always use checksums" mode here (or rather, if that's actually the case, which octoprint.log would tell me) and also if the M117 is in fact sent untruncated (in which case the truncation would be a firmware issue as mentioned above which you should definitely report to your firmware vendor). Just to make sure, could you also uncheck automatic firmware detection and check what "Send a checksum with the command" is set to there?

Default should look like this:

edit as a side note:

2018-03-27 09:40:44,950 - Send: N1 M115*39
2018-03-27 09:40:44,997 - Recv: ANET; http://www.anet3d.com

I really wish firmware vendors would stop inventing their own responds formats to an M115. FFS! 😡

[foosel]

Hah, never mind... the reason OctoPrint sticks to enabling checksums is Anet being a special snowflake here and fscking up the M115 response, making OctoPrint not able to find it.

For reference, this is how an M115 response should look like:

FIRMWARE_NAME:Marlin V1.0.2; Sprinter/grbl mashup for gen6 FIRMWARE_URL:https://github.com/prusa3d/Prusa-i3-Plus/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Prusa i3 MK3 EXTRUDER_COUNT:1 UUID:00000000-0000-0000-0000-000000000000

Note the FIRMWARE_NAME: there. What your printer produces there however does not match that and in fact just looks like a more or less arbitrary line:

ANET; http://www.anet3d.com

OctoPrint behaves correctly here in sticking to "leave checksum on" since it can't successfully identify the firmware its talking to, and since some firmware variants out there require checksums it sticks to the least dangerous setting and sends them with all commands. Combine that with another bug in your printer's firmware that makes M117 get its parameters truncated if a checksum is applied and you get this result. So in a nutshell: Your printer's firmware is broken. What printer model is that btw? A6, A8, ...?

BTW: I also get the exact same behaviour under 1.3.6, so this isn't even a change in behaviour between 1.3.6 and 1.3.7

[chippypilot]

OK. Thanks for investigating. Sorry to have wasted your time with a non-compliant printer. Another reason for me to consider another printer or a change of firmware.

In the meantime, I'll disable automatic detection

[foosel]

No need to be sorry. It's not your fault that Anet is (once again I might add) cutting corners here. Just one additional reason to keep ones hands off of that brand.

Could you still tell me what exact printer model that is? Might help me down the road.

[chippypilot]

Thanks. It is an Anet A6 with the default board.

[wescrockett]

Seems good on Maker Select Plus running on Pi 3 (OctoPi build) behind reverse proxy.

[mmotley999]

1.3.7rc2 seems to be working just fine for me. Creality CR-10S with Marlin 1.1.8 firmware compiled from source. Upgraded from 1.3.6, which I originally manually installed on a RPI 3 with Raspbian Stretch.

Several prints, no issues and stable. All the plugins I use seem to be working fine as well.

[tdub415]

1.3.7rc2 is working fairly well for me. I am getting inconsistant results with it detecting a print starting on my prusa i3 mk3 though. It seems half the time when starting a print via the printer, it detects it just fine, tracks the print, and records the timelapse, but other times it detects that a print starts, and then times out:

I have not played with any of the settings to increase the window for timeouts or the number of consecutive timeouts yet

[koenkooi]

After upgrading octoprint to 0070349d6646f2a8bd3c120530feab0990017770 and python-tornado to 5.0.1 I get a lot of these in the log:

Mar 28 08:35:16 blackbox octoprint[22291]: 2018-03-28 08:35:16,640 - octoprint.server.util.sockjs - INFO - New connection from client: fe80::18ac:280:2c0c:cb56
Mar 28 08:35:25 blackbox octoprint[22291]: 2018-03-28 08:35:25,312 - octoprint.server.heartbeat - INFO - Server heartbeat <3
Mar 28 08:36:17 blackbox octoprint[22291]: 2018-03-28 08:36:17,526 - octoprint.server.util.sockjs - INFO - Client connection closed: fe80::18ac:280:2c0c:cb56
Mar 28 08:36:17 blackbox octoprint[22291]: 2018-03-28 08:36:17,638 - tornado.application - ERROR - Uncaught exception in /sockjs/697/s4kh2fhd/websocket
Mar 28 08:36:17 blackbox octoprint[22291]: Traceback (most recent call last):
Mar 28 08:36:17 blackbox octoprint[22291]:   File "/usr/lib/python2.7/site-packages/tornado/websocket.py", line 498, in _run_callback
Mar 28 08:36:17 blackbox octoprint[22291]:     result = callback(*args, **kwargs)
Mar 28 08:36:17 blackbox octoprint[22291]:   File "/usr/lib/python2.7/site-packages/sockjs/tornado/transports/websocket.py", line 41, in open
Mar 28 08:36:17 blackbox octoprint[22291]:     self.session.verify_state()
Mar 28 08:36:17 blackbox octoprint[22291]:   File "/usr/lib/python2.7/site-packages/sockjs/tornado/session.py", line 298, in verify_state
Mar 28 08:36:17 blackbox octoprint[22291]:     self.handler.send_pack(proto.CONNECT)
Mar 28 08:36:17 blackbox octoprint[22291]:   File "/usr/lib/python2.7/site-packages/octoprint/server/util/sockjs.py", line 136, in send_pack
Mar 28 08:36:17 blackbox octoprint[22291]:     return orig_send_pack(*args, **kwargs)
Mar 28 08:36:17 blackbox octoprint[22291]:   File "/usr/lib/python2.7/site-packages/sockjs/tornado/transports/websocket.py", line 86, in send_pack
Mar 28 08:36:17 blackbox octoprint[22291]:     self.write_message(message, binary)
Mar 28 08:36:17 blackbox octoprint[22291]:   File "/usr/lib/python2.7/site-packages/tornado/websocket.py", line 256, in write_message
Mar 28 08:36:17 blackbox octoprint[22291]:     return self.ws_connection.write_message(message, binary=binary)
Mar 28 08:36:17 blackbox octoprint[22291]:   File "/usr/lib/python2.7/site-packages/tornado/websocket.py", line 803, in write_message
Mar 28 08:36:17 blackbox octoprint[22291]:     raise WebSocketClosedError()
Mar 28 08:36:17 blackbox octoprint[22291]: WebSocketClosedError

Octoprint is running on a beaglebone behind nginx and the browser is safari on OSX.

[foosel]

@koenkooi that would be the maintenance branch and hence 1.3.8.dev though, not 1.3.7rc2 ;)

@tdub415 The MK3 doesn't yet support this since its firmware doesn't fulfill the requirements for this working as stated in the changelog. Couldn't get it to work reliably in my own tests here either, it simply started blocking comms from time to time, which is why I jotted down those requirements for firmware in the first place.

[foosel]

@koenkooi I created a new ticket for the tornado issues under 1.3.8.dev/maintenance, see #2526. Please share your nginx config in that ticket. I have similar issues, but only with nginx, haproxy works flawlessly, and to narrow down what's happening there the more info the better.

[foosel]

1.3.7rc3 is out, new feedback ticket is here: #2529