New Update cannot connect to laser

[mbt45]

The new upgrade is not able to connect the the laser anymore. (Laser engraver Neje).

How can I reverse to the previous version?

"Connected to: Serial(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor Send: M110 N0 No answer from the printer within the connection timeout, trying another hello Send: M110 N0 There was a timeout while trying to connect to the printer Changing monitoring state from "Connecting" to "Offline" Connection closed, closing down monitor"

[synman]

Please ensure you are on the latest version (2.1.3)

Additionally, if you have verified you are on 2.1.3, I'm going to need to see your octoprint.log file. This looks to me like there is an error being thrown and I need to see the stacktrace.

[synman]

See #69 and #71

[mbt45]

It is on version 2.1.3

[synman]

I deciphered your wall of text there.... nothing to glean from it. I would be nice if you could just upload the file, or at the least parse it with proper carriage return / line feeds. My eyes still hurt.

Let's set the logging level for the plugin to debug and try again.

[synman]

you can find the above in Settings --> Octoprint --> Logging

[mbt45]

Sorry for the wall of text, I couldn't find a way to attach files, but I got it now octoprint(6).log .

[synman]

According to the log (assuming your printer is connected to ttyUSB0 @ 115200) this error is happening at an OS level when BGS tries to inject the initial handshake. Behind the scenes I replace the M110 with a ?.

2022-01-21 11:08:42,122 - octoprint.util.comm - INFO - Serial detection: Trying port /dev/ttyUSB0, baudrate 115200
2022-01-21 11:08:42,122 - octoprint.util.comm - INFO - Connecting to port /dev/ttyUSB0, baudrate 115200
2022-01-21 11:08:42,132 - octoprint.plugins.bettergrblsupport - DEBUG - __init__: on_event event=[PrinterStateChanged] payload=[{'state_id': 'DETECT_SERIAL', 'state_string': 'Detecting serial connection'}]
2022-01-21 11:08:42,166 - octoprint.server.util.watchdog - INFO - Running initial scan on watched folder...
2022-01-21 11:08:42,211 - octoprint.server.util.watchdog - INFO - ... initial scan done.
2022-01-21 11:08:42,243 - octoprint.util.comm - INFO - Serial detection: Handshake attempt #1 with timeout 2.0s
2022-01-21 11:08:42,270 - octoprint.plugins.bettergrblsupport - DEBUG - __init__: hook_gcode_sending phase=[sending] cmd=[M110 N0] cmd_type=[None] gcode=[M110]
2022-01-21 11:08:42,271 - octoprint.plugins.bettergrblsupport - DEBUG - Ignoring M110 N0
2022-01-21 11:08:42,309 - zeroconf - WARNING - Error with socket 5 (('10.0.10.1', 5353))): [Errno 126] Required key not available
Traceback (most recent call last):
  File "/usr/lib/python3.7/asyncio/selector_events.py", line 987, in sendto
    self._sock.sendto(data, addr)
OSError: [Errno 126] Required key not available

I'll do a little bit of research into what error 126 is. It is happening at an intrinsic level so I'm a bit curious as to what is going on. It's also getting logged by zeroconf which I believe is mDNS so it may be a false positive too. I see it with every attempt to send on ttyUSB0 at 115200 baud so I dunno (yet).

Please confirm your machine is connected to ttyUSB0 (it likely is). As I'm researching this, if you could also disable auto detection, set your com port and baud to ttyUSB0 / 115200, try again, and send me the log snippet that would be awesome.

[synman]

I think this more accurately captures what is happening specific to auto detection. I've ruled out the zeroconf 129 error as root cause... that's mdns like I thought, unrelated to auto negotiation of a USB connection.

2022-01-21 11:08:42,122 - octoprint.util.comm - INFO - Serial detection: Trying port /dev/ttyUSB0, baudrate 115200
2022-01-21 11:08:42,122 - octoprint.util.comm - INFO - Connecting to port /dev/ttyUSB0, baudrate 115200
2022-01-21 11:08:42,132 - octoprint.plugins.bettergrblsupport - DEBUG - __init__: on_event event=[PrinterStateChanged] payload=[{'state_id': 'DETECT_SERIAL', 'state_string': 'Detecting serial connection'}]
2022-01-21 11:08:42,243 - octoprint.util.comm - INFO - Serial detection: Handshake attempt #1 with timeout 2.0s
2022-01-21 11:08:42,270 - octoprint.plugins.bettergrblsupport - DEBUG - __init__: hook_gcode_sending phase=[sending] cmd=[M110 N0] cmd_type=[None] gcode=[M110]
2022-01-21 11:08:42,271 - octoprint.plugins.bettergrblsupport - DEBUG - Ignoring M110 N0
2022-01-21 11:08:44,268 - octoprint.plugins.bettergrblsupport - DEBUG - __init__: hook_gcode_received line=[]
2022-01-21 11:08:44,321 - octoprint.util.comm - INFO - Serial detection: Handshake attempt #2 with timeout 2.0s
2022-01-21 11:08:44,336 - octoprint.plugins.bettergrblsupport - DEBUG - __init__: hook_gcode_sending phase=[sending] cmd=[M110 N0] cmd_type=[None] gcode=[M110]
2022-01-21 11:08:44,337 - octoprint.plugins.bettergrblsupport - DEBUG - Ignoring M110 N0
2022-01-21 11:08:46,331 - octoprint.plugins.bettergrblsupport - DEBUG - __init__: hook_gcode_received line=[]
2022-01-21 11:08:46,347 - octoprint.util.comm - INFO - Serial detection: Handshake attempt #3 with timeout 2.0s
2022-01-21 11:08:46,363 - octoprint.plugins.bettergrblsupport - DEBUG - __init__: hook_gcode_sending phase=[sending] cmd=[M110 N0] cmd_type=[None] gcode=[M110]
2022-01-21 11:08:46,365 - octoprint.plugins.bettergrblsupport - DEBUG - Ignoring M110 N0

Your machine is responding with a blank response, that's what this is:

2022-01-21 11:08:44,268 - octoprint.plugins.bettergrblsupport - DEBUG - __init__: hook_gcode_received line=[]

I may have changed some code to ignore blank / empty responses. I'm curious if this empty response is your machine's way of saying, "hey, I'm here".

What is the specific manufacturer / brand / model of your machine?

[synman]

Here's the gcode sending handling logic I had prior to "cleaning" things up in 2.1.0:

        # suppress reset line #s
        if self.suppressM110 and cmd.upper().startswith('M110'):
            self._logger.debug('Ignoring %s', cmd)
            return ("$I", )

and here it is in 2.1.0+:

        if self.suppressM110 and cmd.upper().startswith('M110'):
            self._logger.debug('Ignoring %s', cmd)
            return ("?", )

I'm thinking through how I want to accommodate this for you. My gut tells me if I return a $ command like $I (grbl version info) you'll be back in business.

[synman]

@mbt45 I think I have a fix for this but would like to do some validation before elevating it to the release candidate channel. Are you up for trying the dev channel? If so, I'll push a commit to GitHub and we can see if it solves your problem.

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

[synman]

opening this back up pending confirmation of resolution

[mbt45]

I am updating. I'll let you know the result ASAP

[mbt45]

Ok it solved the issue Thank you

[synman]

nice... I'll have this in RC likely later tonight and stable probably by the end of the weekend.

[synman]

also, thanks for getting me the data I needed to get to the bottom of it. Be sure set your logging level back to INFO too. BGS can generate some decent log data at DEBUG level.

[mbt45]

Hi I think I talked too fast.

Although it is saying connected it seem the controls don't work. And I am getting a lot of " Send: ?" in the console

Send: ?

[mbt45]

octoprint(8).log

[synman]

I had a couple questions / callouts. Let's get those answered.

Confirmation of port machine is plugged into Disable auto-detection Brand/model of machine

You mentioned other programs (lightburn maybe?) Are able to connect. Can you share it's terminal / console output? I'm curious to see how it is negotiating a connection.

Some other thoughts...

Have you tried sending a soft reset? What happens if you type $$ in the terminal tab?

[mbt45]

Port ttyUSB0 Autodetection off Model NEJE Master 2S. Before last update I had no problem engraving with octopi better grlb

I'll be able to try Lightbrun tomorrow only.

I tried soft reset but no response I tried $$ but not response.

It is getting pretty late here so I'll be able to see your next message tomorrow only.

Thank you again for your help

[synman]

Opening this back up. Am hopeful seeing your lightburn console output will shed some light on this.

[synman]

@mbt45 I pushed out a new update to the dev channel tonight that initializes the connection with two linefeeds. I was looking over code from other open source grbl gcode senders and this seems to be a predominant pattern.

I had to fake out Octoprint to make it work. Octoprint intentionally filters out "blank" commands but I came up with a creative work around that consistently generates the Grbl welcome message on my two machines.

Let me know how it goes.

[mbt45]

Here is the console of lightburn.

I am now reinstalling a fresh new octopi session and will download the plugin

soon.

[synman]

yeah, I fired up Lightburn last night as well and noted it doesn't share anything about its negotiation phase. Before you rebuild octopi, the latest dev build of bgs.

[mbt45]

Hi the last update seem to work.

Strangely I setup a fresh new instance of octopi on a new SD card with your "stable" release of Better GRLB and it worked. I am now a little baffled. Was it is your plugin that was in cause or a conflict between an old octopi and your plugin during upgrade.

Never the less your stable release works on a fresh octopi, as well as your 4fcd97d022db261ea343293325f9b4d8dbeed603 Maybe just a warning to reinstall octopi in case they someone else the same issue as I did would be sufficient.

Thank you for your invaluable help and work. Is there a place I can pay you a coffee ;) ?

[synman]

I should have asked for a copy of your config.yaml.

You are the second person to have a weird condition that was resolved with a rebuild.

One gent had a phantom M876 firing out of nowhere.

I would've loved to have known if my /n/n fix would have made a difference here.