Octoprint 1.9 - Bettergrbl wont work at all?

[Nachtwind85]

Describe the bug
Today I installed a fresh Octopi on my RPI3 to test Bettergrbl for my Atomstack Engraver. After installation of the plugin i noticed no changes to the UI (despite the settings being active) or any other part of octoprint to the point that not even a connection to the engraver was possible.
I reflashed three times today - each with the same result.

To Reproduce
Steps to reproduce the behavior:
Install Octopi with Octoprint 1.9, Install the plugin.

Expected behavior
The plugin should work

Screenshots

Logs
octoprint.log
serial.log

As seen in the octoprint log there is some... problem with the _bgs.profile so i checked it through SSH:

And it wont turn up on the UI:

Additional context
Cant think of any. Sorry.

[synman]

Seems legit, as in legit broke.

I'll poke around and see what changed with 1.9 to trigger this.

Basically bgs is fighting with Octoprint to get its profile loaded. Since that operation is failing, bgs is falling back thinking it's disabled.

[Nachtwind85]

Ok, Thank you for poking into it :)

[AlexonCNC]

Hi guys, experiencing a similar issue here. Cannot connect to my CNC machine since I updated Octoprint to 1.9.0.
The system returns an error 9 rather than 20 in my case, but for the rest, seems very similar.
Send: N0 M110 N0*125
Recv: error:9
looking forward to see if there are solutions available
Best regards
Alex

[synman]

I have a fix for this I haven't committed yet. It boils down to some compatibility changes introduced in OctoPrint 1.9.0 that have caused the printer profile handler to regress.

I'll push out a fix in the next day or two. In the meantime, if you want to hack around this, here's the problem.

in .octoprint/printerProfiles/_bgs.profile, change the extruder section to look like so:

extruder:
  count: 1
  defaultExtrusionLength: 5
  nozzleDiameter: 0.4
  offsets:
  - - 0.0
    - 0.0
  sharedNozzle: false

[rsteckler]

Verifying this worked and I can connect to the CNC. Some artifacts still, like the temperature tab is still there even though the setting to hide it is checked, but overall it works

[AlexonCNC]

Hi Synman,
I’ve found the file and edited it as you described, but the issue remains as follows. Is there going to be a new BGS version I can update to, to resolve this ?

Here is the Terminal content
Changing monitoring state from "Offline" to "Opening serial connection"
Connecting to port /dev/ttyACM0, baudrate 115200
Changing monitoring state from "Opening serial connection" to "Connecting"
Connected to: Serial<id=0x6e0f5450, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Send: N0 M110 N0125
Recv: error:9
No answer from the printer within the connection timeout, trying another hello
Send: N0 M110 N0125
Recv: error:9
There was a timeout while trying to connect to the printer
Changing monitoring state from "Connecting" to "Offline"
Connection closed, closing down monitor

[synman]

the fix is currently available in the dev channel

https://github.com/synman/Octoprint-Bettergrblsupport/wiki/Bleeding-Edge-Updates

[AlexonCNC]

Thanks for your support Synman !
I’m really having a hard time though…
When I tick the Subscribe to DEVEL branch checkbox as described in your link, and save the form, it closes but the setting is never recorded. When I go back right after, the box is unchecked again, so I’m not able to get any DEV update. ( I’ve tried to reboot, and to restart octoprint or do nothing but the setting is never kept enabled)
Wondering if this links to rsteckler comment above, saying that the temperature tab is there wether it’s checkbox is ticked or not… it definitely seems like all these checkboxes don’t work any longer (at least none of them work for me and all of them are in the same window)
Tomorrow I’ll try to manually edit the init.Py file the way I’ve seen in bdd98e2 to see if this resolves the issue. As I already made the changes you described above, also found under a143837, it may work… what do you think ? Am I missing something else ?

[JunghaJungha]

Hi,

I installed the dev version but I am still not able to connect.
I need to change (empty) the Hello Command to connect, but it does not save the changes (it is always: $$).

[mrhasbean]

Hi,

Same issue here. I had my laser in storage for a while after moving house, just pulled it out and without thinking to check anything, allowed Octoprint to install all of the updates, now it won't connect to the laser.

Atomstack A5, same error reported above.

I've switched to release candidates and installed that version, but I'm having the same issue as @AlexonCNC, being that it won't save the setting for the Dev version. Could this be some permissions issue on a file? I am running a standard RPi imager install of Octoprint that has been upgraded since I first set it up early last year.

Not sure where to go from here.

Cheers.

Edit: I managed to manually apply the updates from the workaround but the issue persists.

[Belott]

Same problem here. This PlugIn doesn't work with Octoprint 1.9 anymore:

• No USB Connection to the printer
• It's not possible to save changed parameters

Is there any plan to fix that?

[synman]

the (manual) fix is documented in this very thread. I'll get around to fixing this properly one of these days. I agree it was a PITA due to a breaking change in the OctoPrint 1.9 release. It's even harder to undo / hop to the dev channel for the hot fix I released because it basically kills the plug-in and you can't get into it's settings to flip the switch for the dev channel.

[synman]

last, don't come here making posts about jumping to other software / etc. I don't need that kind of hate. If you're going to go away, just go away.

[foosel]

@synman

I agree it was a PITA due to a breaking change in the OctoPrint 1.9 release

It would have been nice to have received a report that a simple validation of printer profiles to make sure their values stay within sane ranges caused a breaking change for this plugin, best during the several months long release candidate phase. Finding stuff like this early is of the things the RC phase if for, and plugin authors are strongly encouraged to test their plugins against RCs so that any breaking changes can be identified and ideally resolved one way or the other BEFORE they hit users.

As things are, what do you need from me here so this can get resolved? I should add that removing the validation logic again is NOT an option, as that opens up OctoPrint to issues due to corrupted/broken profiles in general.

[synman]

I didn't catch it until after 1.9 went out and decided I want to refactor my own code anyway.

Life has gotten in the way sinse.

I'm actually embarrassed to share the profile I was managing as it enumerated 99 nozzles (unnecessarily).

Basically, I got this on my end @foosel . I just need to actually get to it.

[foosel]

Gotcha. If in the end I can give you a helping hand on something after all, feel free to reach out.

In the meantime, I think you would make some people happy by just providing a release with the change, and/or telling them to install the devel zip directly via the plugin manager's URL option 😉

[synman]

Should have shared this much sooner and a special thanks to @foosel for making the suggestion for how to install my work-around version while I have the development and master branches out of sync.

To work-around this issue for the time being, please go into Plug-in Manager and install Better Grbl Support using the following URL: https://github.com/synman/Octoprint-Bettergrblsupport/archive/refs/heads/devel.zip

[overlordt]

@synman, could it be that the devel.zip you linked no longer provides a workaround for this bug?
I'm trying it on a fresh Octoprint install and as soon as I add a stable, RC or this dev version of Bettergrbl it stop's connecting to the laser.

Looking forward to using Bettergrbl!

[X15AC]

I just used the link and it is working.

Thank you, Thank you, Thank you, Thank you, Thank you, Thank you, Thank you,

[synman]

I'm going to fix this in the main branch very soon.... possibly right now ;)

[synman]

This should now be resolved with the latest release (2.3.1).