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

[RC Feedback] Feedback on the 1.3.12rc1 Release Candidate #3268

Closed
foosel opened this issue Sep 10, 2019 · 29 comments

Comments

@foosel
Copy link
Owner

commented Sep 10, 2019

Please provide general feedback on your experience with the 1.3.12rc1 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 not yet listed below the following line, please open a new ticket and follow "How to file a bug report".


Currently known issues

Unreproduced issues

Unreproduced and information for further analysis missing

@b-morgan

This comment has been minimized.

Copy link

commented Sep 10, 2019

I am running OctoPrint 1.3.11 on OctoPi 0.14.0. If I understand correctly, I need to backup, upgrade to a new OctoPi, and restore.

As I follow the links for backing up, I get to the manual method description. Can I not use the backup & restore from OctoPrint 1.3.11?

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Sep 10, 2019

You will still be able to update to 1.3.12rc1, just not back away from it again.

The link tells you to use the built in backup right at the top - I've made that a bit more clear now.

@schnello

This comment has been minimized.

Copy link

commented Sep 11, 2019

Hello.

Printer: i3 mega
FW: Klipper
System: Ubuntu 18 machine
V: Version 1.3.12rc1

Update: done and works without errors
Octoprint is running and works.

First print was sucessfully but (FYI) i had some problems with Cancelling a print. More Information later if i have more time to investigate incl a Ticket.

In German:
Da das ganze rel schwer ist zu beschreiben hier eine Kurzfassung in deutsch;
Nach dem Abbruch des Jobs war es fast unmöglich den Job wieder zu starten. Er meckert im Log ständig das die FW meckert das man zuerst die Axen Homen soll bzw. das die Extr Temp. zu gering war. Ich muss aber zuerst testen ob das reproduzierbar ist. Vielleicht auch einfach ein Hardware defekt. Wenn ich ein klares Problem identifiziert habe werde ich ein Ticket aufmachen. Da du sicher nach einem Log fragen wirst, ;) ist unten verlinkt,

https://nextcloud.service-uplink.de/s/bLGfojcxRCLEwCN

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Sep 11, 2019

@schnello Took a look at the log (thanks, and yes, I would have asked for it ;)) and if the firmware sends errors like this it's correct behaviour from OctoPrint to refuse to print. The question of course is why the firmware sends these errors.

@schnello

This comment has been minimized.

Copy link

commented Sep 11, 2019

Klipper send this type of error messages if the printer is not homed. Looks like after the first manual "Abort Print" by the user... the print server sends furthermore commands to the printer. But.. currently all speculation and I hope to find time today. Is there a possibility to send all printer commands to a seperate log? Or the better question: What type of log file would you recommend?

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Sep 11, 2019

serial.log - enable it, reproduce, share. That will contain all communication between host and printer.

@schnello

This comment has been minimized.

Copy link

commented Sep 11, 2019

Ok i found the problem. I compare the octoprint log again with the klipper log and the timeline is as follows:

  1. User starts print job
  2. Printer heating up
  3. Printer start movement
  4. User abort print job (because the first layer is defekt)
  5. Regarding the Gcode Settings in Octoprint a M84 (Disable Motors) was send to the printer
  6. User starts again the print job...
  7. Printer heating up
  8. User send via LCD a "adjust Z Offset"
  9. Klipper response this action with "Home your Axis first"... (looks like a bug against Klipper because a "SET_GCODE_OFFSET Z Command" works fine in the terminal)
  10. Octoprint abort the print job.
@foosel

This comment has been minimized.

Copy link
Owner Author

commented Sep 11, 2019

That actually sounds reasonable to me - if the motors got disengaged the position got lost and if I was the firmware, I'd also complain.

No homing command in your GCODE files? I always have that in there... Thought it was pretty common O_O

@schnello

This comment has been minimized.

Copy link

commented Sep 11, 2019

Sure but not as first command. Make sense to move it to the first line i guess

@Guilouz

This comment has been minimized.

Copy link

commented Sep 12, 2019

Since I have updated, I have access to Octoprint settings window but only printer section settings are working. When I click on others settings they do not appear.
Tested on Safari and Chrome same issue. And tested in safe mode. Any idea ?

Capture d’écran 2019-09-12 à 19 02 23

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Sep 12, 2019

Try safe mode. If everything works there it's an issue with a third party plugin. Also check the JS error console in your browser, that might give further hints.

@Guilouz

This comment has been minimized.

Copy link

commented Sep 12, 2019

Try safe mode. If everything works there it's an issue with a third party plugin. Also check the JS error console in your browser, that might give further hints.

Already try in safe mode, same issue.

I have this :

Capture d’écran 2019-09-12 à 19 44 45

@Guilouz

This comment has been minimized.

Copy link

commented Sep 12, 2019

How I can uninstall a language pack ? I think it's the problem.

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Sep 12, 2019

I think I agree based on the full stack trace you deleted (the screenshot sadly lacks the most crucial part - the start).

Uploaded translation packs are stored in ~/octoprint/translations. Deleting the folder in question (or the whole translations folder if you only have one) and restarting the server should do it.

I'd love to get my hands on the language pack so I can reproduce and fix this, either in 1.3.12 or - if it's not a regression - later.

@Guilouz

This comment has been minimized.

Copy link

commented Sep 12, 2019

I think I agree based on the full stack trace you deleted (the screenshot sadly lacks the most crucial part - the start).

Uploaded translation packs are stored in ~/octoprint/translations. Deleting the folder in question (or the whole translations folder if you only have one) and restarting the server should do it.

I'd love to get my hands on the language pack so I can reproduce and fix this, either in 1.3.12 or - if it's not a regression - later.

How I can delete this folder ? in SSH ? What is the procedure ?

This is the language pack :
Octoprint 1.3.12rc1 - Pack Langue FR.zip

@Guilouz

This comment has been minimized.

Copy link

commented Sep 12, 2019

I think I agree based on the full stack trace you deleted (the screenshot sadly lacks the most crucial part - the start).

Uploaded translation packs are stored in ~/octoprint/translations. Deleting the folder in question (or the whole translations folder if you only have one) and restarting the server should do it.

I'd love to get my hands on the language pack so I can reproduce and fix this, either in 1.3.12 or - if it's not a regression - later.

After deleting language pack it's working.
Can you check if language pack is good or not ? But it's not the first time I make a language pack, I update it every time there is a new release without issue. Just with this release candidate.

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Sep 13, 2019

I think the issue doesn't lie with the language pack but rather with the way some translated strings are embedded by OctoPrint. So if there is an issue, it's an issue on my end :)

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Sep 13, 2019

@Guilouz So, the Problem appears to be two fold...

  1. there's an issue with properly escaping translated strings that appear in sections of the HTML code that are single/double quoted - that's the JS stack trace that we saw. Fixing that doesn't solve the settings dialog however, which led me to discovering
  2. You have invalid HTML snippets in your translated strings. Search the .po file for Tout ce que vous mettez ici sera exécuté <em>avant</ em> toute commande de and Tout ce que vous mettez ici sera exécuté <em>après</ em> toute commande de . Those closing em tags are what's causing the mess, they should be </em>, not </ em>. I cannot escape that kind of stuff because HTML is needed in some places within the translated strings (e.g. for highlighting keywords or such).

I'll extend safe mode to also disable installed language packs - makes sense since they can really break things as demonstrated here. I'll also take care of the first point. Neither of those are regressions though, so they don't qualify for triggering an RC2 and I'm also very unsure if I should push them into an RC2 should that be needed for some actual regressions...

@Guilouz

This comment has been minimized.

Copy link

commented Sep 13, 2019

@foosel I have fixed wrong strings in my language file but if I understand that will not correct the problem ?

@schnello

This comment has been minimized.

Copy link

commented Sep 14, 2019

Testet now two "bigger" prints (4h and 12h).... all fine and works well.

@EddyMI3d

This comment has been minimized.

Copy link

commented Sep 14, 2019

There seems to be an issue with the G-Code Viewer, it looks the viewer is one layer ahead. I don_t think the new Prusa firmware got a that huge enlarged input buffer.

@kazibole

This comment has been minimized.

Copy link

commented Sep 15, 2019

A few SD card prints on a Prusa MK3 worked just fine!

@gege2b

This comment has been minimized.

Copy link

commented Sep 16, 2019

Hi there
Just updated and OP cannot connect to my printer (Marlin 1.8)
Here's the terminal content :

Connecting to: /dev/ttyUSB0
Changing monitoring state from "Offline" to "Error: Connection error, see Terminal tab"
Closing serial port due to emergency stop M112.
Unexpected error while connecting to serial port: /dev/ttyUSB0 SerialException: '[Errno 11] Could not exclusively lock port /dev/ttyUSB0: [Errno 11] Resource temporarily unavailable' @ comm.py:_openSerial:2661 (hook default)

Restarting octoprint changed nothing (same error)
Rebooting the PI solved the problem (I guess that un/replug the printer would've had the same effect)

Octoprint.log

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Sep 16, 2019

@Guilouz There were two problems. The settings being completely broken and nothing being clickable anymore was caused by the invalid HTML snippets in the translation which you have fixed on your end. The singular JS error messages however was caused by an issue on my side which I have fixed. Your current language pack should mostly work in 1.3.12rc1, it only triggers a bug in the slicer dialog.

@EddyMI3d Hmm... cannot confirm on old-ish firmware. Currently printing a test piece against 1.3.12rc1 and apart from the usual slight shift due to three buffers on the firmware side of things stuff is in sync 🤔

@gege2b when the serial port cannot be locked exclusively or some other kind of SerialException gets triggered, that usually happens one layer beneath OctoPrint and completely outside of its control. Unless it happens reproducibly I'd chalk this up to a temporary hiccup between the OS and the printer.

@gege2b

This comment has been minimized.

Copy link

commented Sep 16, 2019

it's really rare indeed, I think the only other time it happened to me was on a previous upgrade.
the reason I still post this issue is the presence of the "M112" line, wich seemed weird to me

I made a tiny print and as far as I can tell, all worked fine

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Sep 16, 2019

@gege2b yeah, I think that's a logging error caused by the new "try to send M112 on disconnect due to firmware error" feature. It should only print that when it can actually send something. I'll look into that.

@EddyMI3d I also have to retract my previous statement. Something indeed is fishy there, though I don't know what yet. It still has 3min to go on the current print but the GCODE viewer is convinced it's done.

@EddyMI3d

This comment has been minimized.

Copy link

commented Sep 16, 2019

@foosel : I had a look at the start and saw these results:

- Sidebar                GCode Viewer
- Layer Height        Layer Height
- 1      0.2          4      0.6
- 2      0.4          2      0.3
- 3      0.6          5      0.6
- 4      0.8          6      1.0  
- etc
@foosel

This comment has been minimized.

Copy link
Owner Author

commented Sep 16, 2019

@EddyMI3d Could you share a file? Just want to make sure we are looking at the same thing. Never mind, got it I think.

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Sep 17, 2019

1.3.12rc2 is out, new feedback ticket is here.

@foosel foosel closed this Sep 17, 2019

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