[RC Feedback] Feedback on the 1.3.9rc2 Release Candidate

[foosel]

Please provide general feedback on your experience with the 1.3.9rc2 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".

[ctgreybeard]

Two issues I noticed right away: (likely related)

The Telegram plugin is showing "[Unknown]" for remaining time. A print immediately prior on RC1 reported correctly.

The OctoClient on iOS is showing "Not Printing" during a print. All other displays (elapsed time, temperatures, are OK)

[foosel]

I think I know what's up with the Telegram issue. Apparently I managed to put two lines in the wrong order in the bug fix I did, which can cause the print time estimator not to initialize properly. Which then leaves it disabled. I can fix that easily, but I won't be able to push out another RC until Monday.

Might be that this is also the issue of the OctoClient on iOS - I don't have access to that and hence can't verify.

[foosel]

Created a ticket for the print time estimator issue and already pushed a fix for that. A quick check against the API endpoints that I guess are what the iOS app is using shows nothing out of the ordinary, but since I don't know what that thing is actually using it's hard to judge.

[ctgreybeard]

I'm confident that the print time fix will also correct the client.

[foosel]

I wish I could share this confidence ;)

[tech-rat]

Upgrade was smooth. No issues. Print running now and I don't see any problems.

OctoPrint plugin still does nothing......

Tech-Rat

[foosel]

OctoPrint plugin still does nothing......

You mean Octolapse, right? @FormerLurker, any known issues from your side with 1.3.9rc1 or rc2 so far? Anyone else running Octolapse with 1.3.9rc1 or rc2 that can comment on if it works for them or not?

[tech-rat]

Sorry, yes. OctoLapse.

Tech-Rat

[FormerLurker]

I haven't installed it on my dev box yet, but will do that this weekend. A few ppl said that pip needed to be updated before the plugin would install, but I know that the plugin works for some on the latest RC. Will test this soon.

[foosel]

Thanks! I need to push out another RC anyhow due to the bug above (preferably monday), so if there's something amiss in RC2 I could still take care of that :)

[gege2b]

About octolapse, it didn't work either with 1.4-dev

[tedder]

Just checking in to say that I'm running this RC.

[b-morgan]

I've upgraded my RPi3B, OctoPi 0.14.0, LulzBot TAZ 6 and my RPi3B+, OctoPi 0.15.1, no printer yet systems to rc2 (from rc1).

[JohnOCFII]

I upgraded from 1.3.8 to 1.3.9rc2. Upgrade was smooth. I've only done one 30 minute print so far on my Prusa i3 MK2 running firmware 3.0.12 (older, but rock solid and includes a working Linear Advance). All went fine. OctoPrint plug-in worked as expected. Telegram Plug-in worked as expected other than the previously noted "[Unknown] remaining" time. The Print History Plugin also continues to work as expected. Timelapse also continues to work as expected.

[brandstaetter]

I seem to have some weird issue with the speeds, I think it was present before but with 1.3.9 (skipped rc1 but installed rc2) it makes octoprint unusable. I described it here:
https://discourse.octoprint.org/t/speed-too-fast-when-printing-via-octoprint/2658
What can I provide additionally to help debug this?

update: maybe linked to bradcfisher/OctoPrint-ExcludeRegionPlugin#1

[ejjenkins]

I just finished a 5 hour print with the upgrade and I had no issues on an i3 clone. Printing on my D-Bot (CoreXY) now as well...7 hours in and no issues...3 more to go 👍

[foosel]

@brandstaetter As far as I understand your update on that thread, it indeed was caused by the plugin and vanished when switching to safe mode, right?

As a small update, it looks rather like RC3 won't land today. Yet another ISP outage here has gotten in the way, which will hopefully be the last... So RC3 will be released once I have stable internet that is not backed by a way too expensive mobile uplink again ;)

[brandstaetter]

Yes, sorry forgot to comment here too. Issue totally caused by the plugin, not related to OctoPrint itself.

[JohnOCFII]

I've done an additional 3 prints, including a 7 hours print. No issues.

[kazibole]

@foosel I can confirm that #2715 is resolved and OctoSlack no longer crashes OctoPrint. However I am also encountering the same issue as #2721 on my Prusa MK3 running firmware 3.3.0, still working on gathering more information. As I just recently got the MK3, I do not have any print experience on an earlier firmware.

[tedder]

Hmm. ~~~I have the mk3, 3.3.0, and am not having a reset on bed leveling.~~~

[foosel]

@kazibole that so far appears to be an issue with the firmware behavior, not OctoPrint - the issue seems to vanish for people after downgrading to firmware 3.2, without any change in OctoPrint version.

[kazibole]

With my workaround (G28 W; G80; G81, adding G80 to the long running commands list), SD card prints are working great! 5 prints so far and OctoPrint 1.3.9-rc2 has been monitoring them like a champ, and OctoSlack notifying as expected.

[Crowlord]

Mk2,5 prusa fw 3.2

All is fine apart from the print estimate already mentioned.

Firmware updater plugin refusing to work for me but that is likely a local issue (or maybe ID10T error) but I am too busy right now to worry about it. Looking at #2721 maybe thats a blessing

TLDR no critical issues noted, print estimate errors confirmed.

[foosel]

Thanks everyone for the feedback so far! ❤

Just FYI, I'm going to belay the release of RC3 until early next week, since I'm still hoping for some more 👍 regarding the debugging of the Octolapse dead locking issue as reported in #2677 - I only managed to find a possible solution for that yesterday (huge thanks to @FormerLurker again for all the debugging legwork!) and I'd rather not rush an RC release now in case that solution turns out to not be a solution after all. Plus there's also still another issue with Octolapse with regards to the current stable version not seeming to do anything with 1.3.9rc* (at least according to some reports including my own observation), which I'd like to get to the bottom too to make sure there are no plugin compatibility issues introduced in 1.3.9.

Thank you all for your patience!

[FormerLurker]

@foosel, I think the problem with 1.3.9 and octolapse 0.3.1 has to do with the gcode tagging mechanism. Here is how Octolapse used to detect the start of a print:

{'trigger:comm.start_print', 'fileline:1'} <= tags

Maybe the trigger:comm.start_print tag has been removed when fileline = 1? I could double check (there is no logging for this portion ATM and I tested on my live machine), but maybe you know off of the top of your head? If trigger:comm.start_print was removed, can you tell me why?

Here is the new detection, which supports start script from OctoPrint:

({'trigger:comm.start_print', 'trigger:comm.reset_line_numbers'} <= tags or {'script:beforePrintStarted', 'trigger:comm.send_gcode_script'} <= tags)

If I'm correct then this is pretty much a fluke, since I happened to change the tags to something that will work with 1.3.9 rc* before it was released.

[FormerLurker]

@foosel, please ignore the above. I had some versioning issues and after uninstall/reinstall things have changed. The tagging issue actually doesn't exist due to some checks I missed, and it appears as though I ran into a deadlock before the logging kicked in. Long story short I need to update to the staging/maintenance build and retest.

[foosel]

Ah, that makes sense. I did indeed have to change some things slightly due to a bug fix (and also this one request regarding being able to block even scripts belonging to a job ;)). beforePrintStarted wasn't necessarily triggered before the print started, so I had to move things around a bit and that meant that the first line of the job is no longer triggered from the start_print method and hence not tagged as such. It should still have source:file and fileline:1 however if I'm not mistaken. See also 688e4d3

Possibly stupid question, but why don't you just trigger on the very first trigger:comm.start_print that you see after state switch to "Printing"? Or just use the state switch (by posing as a PrinterInterfaceListener)?

I'm also now somewhat confused why Octolapse 0.3.1 appeared to work this afternoon against 1.3.9rc3.dev 🤔

[foosel]

Note to self: if you write longer than 5min on a reply, update the page before posting it 😄

[FormerLurker]

I'm glad for your response. It made me rethink what I'm doing! Regarding the printing state, I've found that the event comes too late to be 100% guaranteed to receive the 1st line of the gcode file in the queuing phase, which could be something very important like a home, or hotend temp. Also, it was checking for line 1 to make 100% sure that I wasn't getting octoprint start gcode, which until recently didn't work with job_on_hold. Now Octolapse will happily work with start gocde from octoprint, hooray! Lastly, I added another sanity check to make sure that every line is received sequentially, else there is likely an Octolapse or OctoPrint bug.

Also, I just completed a test print with Octolapse V0.3.1 (latest release) and had no issues on rc3! As you suspected, your issue was likely due to some settings issues (octolapse has no settings downgrade capability). Some required options in 0.3.2 aren't available in 0.3.1, which probably resulted in an unhandled exception somewhere.

Now, since Octolapse V0.3.2 will NOT be compatible with any Octoprint version < 1.3.9 rc3, is there any way I can inform the plugin manager of this so that the upgrade ( octolapse version < 0.3.2) is only available to users who have upgraded Octoprint >= 1.3.9? If not I will probably add some additional version checking to OctoLapse startup or install for the future. Better still would be some dynamic checking on the plugin update page that could prompt users to upgrade OctoPrint first. One can dream right? LOL!

[foosel]

Regarding the printing state, I've found that the event comes too late

Not the event, the actual state switch, as bubbled up from the comm layer to the printer object into which you can hook as a listener which then actually does get processed synchronously. But I guess now that you can block anything belonging to a print job via job_on_hold there's no need to make it more complicated anyhow :)

[compatibility woes]

I fear you'll have to add some additional checks into your plugin, currently the software update plugin doesn't support stuff like this (and to be fair I'm also not sure how I could add this without opening a horribly wiggly can of worms). You should be able to deny installation though by declaring a dependency on OctoPrint 1.3.9rc3 or later in your setup.py, then we can also update the plugin repository listing accordingly (so it won't be offered to install on older versions) and finally we can push a notice via the plugin manager for any older versions on any older OctoPrint versions that people first need to update OctoPrint to 1.3.9 before they can update Octolapse to 0.3.2 (thankfully I built in that mechanism for situations like this).

[FormerLurker]

@foosel, UGH... I should double test before I write a long response! My original message regarding the tagging WAS correct. Somehow when I reinstalled I pulled from the wrong branch, but browser caching led to an incorrect version number. Octolapse 0.3.1 is NOT compatible with any version of OctoPrint > 1.3.8 because of the start tags.....

But I guess now that you can block anything belonging to a print job via job_on_hold there's no need to make it more complicated anyhow

Yeah, I agree. Will you take a look at this and let me know if it should be altered in any way to avoid future issues with my start print checks:

({'trigger:comm.start_print', 'trigger:comm.reset_line_numbers'} <= tags or {'script:beforePrintStarted', 'trigger:comm.send_gcode_script'} <= tags) and
            self.OctoprintPrinter.is_printing()

Regarding the compatibility checks, it is a huge can of worms. Your suggested method is much more reasonable. I'll start updating the setup.py and work on the plugin repo updates as you suggested.

[foosel]

@FormerLurker Should work fine for local prints, but might cause issues for SD prints if no start GCODE script is defined since then no M110 will be sent by OctoPrint and also no script. Then again, job_on_hold doesn't work for SD prints anyhow for obvious reasons (and I don't think you could reliably get it to work either since some printers do stuff when you pause SD prints that would make position recording or print head positioning impossible).

You could hook into just the first trigger:comm.start_print or script:beforePrintStarted that you see (small heads-up: the trigger stuff is more for debugging purposes and might change if I have to move around calls), that would simplify things slightly.

That would still leave out one very specific scenario though: SD print started from the printer controller and no before script. In that case there would be nothing send by OctoPrint that you could reliably hook into since control would lie with the printer, but then again as already mentioned that's probably out of scope anyhow (and a horrible mess to begin with).

Re the updating scenario, best just give me a ping when you are ready to push the 0.3.2 release and then we can coordinate further. Just keep in mind that I try to keep away from the computer during the weekends - would be willing to make an exception though if that's the only option.

[FormerLurker]

I'm going to create an issue in the Octolapse repo and will tag you for the print start detection. I'll probably look into PrinterInterfaceListener, since it will eliminate any issue with the gcode tagging.

Regarding the update scenario, I'll be able to get it to you during the weekdays :)

[jneilliii]

Just noticed an error with virtual printer and canceling a print in browser console produces this error. Not sure if this is a plugin I have installed, will test in safe mode when I can. Doesn't seem to cause any undo harm. Error shows as the modal confirmation prompt is dismissed.

[tedder]

I wrote this:

Hmm. I have the mk3, 3.3.0, and am not having a reset on bed leveling.

I'm wrong. I'm still on 3.2. I struck my comment above and am noting it here too.

[larp-welt]

RC2 works just fine for me, using many plugins! :-)

[foosel]

1.3.9rc3 was just released, new feedback ticket is at #2736