Feedback for V1.1.0rc1

[FormerLurker]

As usual, all feedback regarding v1.1.0rc1 is welcome here! I'm interested in what you love, what you hate, what you think is missing, or any general feedback, including just a message saying it installed properly and is working as expected. The more feedback I get, and the better it is, the faster I will push out v1.1.0 for public consumption. THANK YOU so much for taking the time to stop by!

[KenLucke]

Weird behavior... I don't know if it happened under previous versions or not. Very large file. Went crazy, speed wise, first layer. It was set to 20 mm/s for first layers, but started slow, then suddenly kicked up to what looked like 150 mm/s or so, causing massive failures in bed adhesion. Tried it twice, re-processed the file twice, did it consistently. Original file prints normally.

Zip archive contains both original and processed file. May take a while to upload once I post, as even the zip archive is over 128 MB

Settings:

https://www.dropbox.com/s/sjpxljai0zzcch2/Birdhouse%20gcode%20files.zip

[FormerLurker]

@KenLucke, can you create a separate issue for this and include the terminal output for the first layer? I'm looking at the file right now in simplify 3d, and the first layer looks like it should be printing at between 300 and 1170mm/min:

It could be that some overrun happened since G2/G3 can be longer commands than G0/G1 (I have seen this before, but thought it was solved), and the max gcode length in your firmware may have kicked in.

[KenLucke]

I can create the issue separately, but as it's in the middle of a 6 day print, the terminal output will have to wait :)

[DBa2016]

When OctoPrint is starting up (or switching to "Operational" after a finished print), a "M115" followed by "G2" is issued (I guess this is in order to detect firmware features), resulting in an error entry:

2021-02-03 10:13:41,816 - octoprint.util.comm - WARNING - Received an error from the printer's firmware: G2/G3 does not support relative move mode
| Last lines in terminal:
| Trying port /tmp/printer, baudrate 115200
| Connecting to port /tmp/printer, baudrate 115200
| Handshake attempt #1 with timeout 2.0s
| Connected to: Serial<id=0xffff88590070, open=True>(port='/tmp/printer', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=2.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
| Send: N0 M110 N0*125
| Recv: ok
| Changing monitoring state from "Detecting serial connection" to "Operational"
| Send: N0 M110 N0*125
| Recv: ok
| Send: N1 M115*39
| Recv: ok
| Send: N2 M21*18
| Recv: ok FIRMWARE_NAME:Klipper FIRMWARE_VERSION:v0.9.1-168-gc429fbdc-dirty
| Recv: ok
| Send: M115
| Recv: ok FIRMWARE_NAME:Klipper FIRMWARE_VERSION:v0.9.1-168-gc429fbdc-dirty
| Send: M105
| Recv: ok B:25.0 /0.0 T0:25.0 /0.0
| Send: G2
| Recv: !! G2/G3 does not support relative move mode
2021-02-03 10:13:46,752 - octoprint.server.preemptive_cache - INFO - ... done in 6.40s

[FormerLurker]

Klipper doesn't support relative mode when using arcs!?? That's unexpected. What version of Klipper?

[FormerLurker]

@DBa2016, I did locate the code that is generating that message and have submitted a feature request for adding G2/G3 relative move support. I'll have to update the firmware checker to handle this error gracefully and to report the issue to the user.

This is a good find, and one that needs to be handled. Thank you!

[FormerLurker]

Ok, @DBa2016, I decided to close the issue I created in the Klipper github. They are EXTREMELY strict with everything, and completely disallow all feature requests. Since this, strictly speaking, is not a bug, my post violated their submission guidelines. I read their 'first time poster' link, but didn't notice this (I can't see it anymore, so I cannot verify if I missed it, or if it wasn't there).

I understand completely why they handle their issues and discord like this. I get 'flooded' with tech support 'issues' and stuff myself, and it reduces the usefulness overall. However, it does make me far less likely to dig in and actually fix this shortcoming by submitting a pull request. I did submit a question on their discord.

Edits: Got a response from their dev saying I should reopen and submit a PR. Excellent.

[DBa2016]

Klipper doesn't support relative mode when using arcs!?? That's unexpected. What version of Klipper?

I remember when I tried to move by an arc in my laser cutter gcode (same printer, just a different tool mounted to the head), the arc drawn was completely unexpected. My conclusion at that time was that the step calculation within Klipper got mislead by having relative movement switched on somehow. Being a lazy person, I circumvented this by switching to absolute movement before issuing G2 commands :)
I also have to re-test yet, I think the warning is caused by a G2 without further parameters (can't test right now due to a 25h print which will run for another 6 hours or so).

[FormerLurker]

K, thank you SO MUCH folks!

New feedback thread here for V1.1.0rc2. One major bug was fixed, one minor bug, and one enhancement has been added. Were it not for the large issue, I would have promoted this release. Newlines between gcodes that were converted to arcs were causing problems. Rare issue, but not good. I'd appreciate any testing and feedback you can provide. I REALLY want to push the firmware checker out there because disabled G2/G3 is haunting my dreams, lol!