error : 9 while connecting about octoprint-bettergrblsupport

[synman]

I run GRBL 1.1g on my Eleksmaker with no issues.

Send: $I
Recv: [VER:1.1g.20181112:]
Recv: [OPT:V,15,128]

It may be helpful if you provide a serial log from Octoprint.

What is openbuildcontrols?

[synman]

I suspect root cause lies somewhere within the following:

Changing monitoring state from "Operational" to "Error: error:9" Send: M112 Send: N1 M112*32 Send: N2 M104 T0 S0*35 Send: N3 M140 S0*102

[ouinouin]

hi,
openbuildcontrols is like UGS its a gcode sender i dont get the error 9 whileon openbuildcontrols or UGS
i ll upload the log

[AlligatorFate]

I use synman's octoprint-bettergrblsupport plugin with OpenBuilds Black Box controller. I'm betting that might be what ouinouin is using. Openbuilds has a web-based controller.

So, here's some hope that it can be made to work....

[synman]

I would love to see the raw octoprint serial log. Looks like line #s may be enabled which may be compounding the issue.

[ouinouin]

my machine is a xcarve from 2015 or 2016

[ouinouin]

serial.log

2020-04-20 18:30:57,062 - serial.log is currently not enabled, you can enable it via Settings > Serial Connection > Log communication to serial.log 2020-04-20 19:15:56,021 - Enabling serial logging 2020-04-20 19:16:05,595 - Changing monitoring state from "Offline" to "Detecting serial port" 2020-04-20 19:16:05,630 - Serial port list: [u'/dev/ttyACM0'] 2020-04-20 19:16:05,631 - Connecting to: /dev/ttyACM0 2020-04-20 19:16:05,635 - Changing monitoring state from "Detecting serial port" to "Opening serial port" 2020-04-20 19:16:05,640 - Connected to: Serial<id=0x6962fd70, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor 2020-04-20 19:16:05,640 - Starting baud rate detection... 2020-04-20 19:16:05,641 - Changing monitoring state from "Opening serial port" to "Detecting baudrate" 2020-04-20 19:16:06,649 - Trying baudrate: 115200 2020-04-20 19:16:06,663 - Send: M5 2020-04-20 19:16:06,750 - Recv: 2020-04-20 19:16:06,754 - Baudrate test retry #1 2020-04-20 19:16:06,759 - Send: M5 2020-04-20 19:16:06,760 - Recv: Grbl 1.1g ['$' for help] 2020-04-20 19:16:06,767 - Changing monitoring state from "Detecting baudrate" to "Operational" 2020-04-20 19:16:06,789 - Send: $$ 2020-04-20 19:16:06,790 - Recv: [MSG:'$H'|'$X' to unlock] 2020-04-20 19:16:06,792 - Recv: ok 2020-04-20 19:16:06,798 - Recv: error:9 2020-04-20 19:16:06,813 - Changing monitoring state from "Operational" to "Error: error:9" 2020-04-20 19:16:06,821 - Send: M112 2020-04-20 19:16:06,823 - Send: N1 M112*32 2020-04-20 19:16:06,834 - Send: N2 M104 T0 S0*35 2020-04-20 19:16:06,837 - Send: N3 M140 S0*102 2020-04-20 19:16:06,871 - Changing monitoring state from "Error: error:9" to "Offline (Error: error:9)" 2020-04-20 19:16:06,898 - Connection closed, closing down monitor

[ouinouin]

here is the octoprint.log.
any setting I can alter to try ?
octoprint.log

[synman]

Grbl Error #9 - G-code lock G-code commands are locked out during alarm or jog state.

Check for the following:

[synman]

I'm pretty sure that'll fix it for you.

This is rather interesting. My engraver will accept an M5 as its first command upon connection and respond accordingly:

Connecting to: /dev/ttyUSB0
Changing monitoring state from "Offline" to "Opening serial port"
Connected to: Serial<id=0x68215c30, open=True>(port='/dev/ttyUSB0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor
Changing monitoring state from "Opening serial port" to "Connecting"
Send: M5
Send: M5
Recv: 
Recv: Grbl 1.1g ['$' for help]
Changing monitoring state from "Connecting" to "Operational"
Send: $$
Recv: [MSG:Check Limits]
Recv: [MSG:'$H'|'$X' to unlock]
Recv: $0=10
Recv: $1=25
Recv: $2=0
Recv: $3=0
...

But if I try to send the M5 again later (with "Disconnect from the printer" enabled via Serial Conn / Behaviors) it blows up if it is in an alarm state:

Anyway, set "What to do on a firmware error" to "Cancel print but stay connected" and you should be fine.

[synman]

hmm... I need to figure out why M5 was ever chosen as an announce / hello command... possibly goes all the way back to the original GRBL plugin.

At some point along the way it looks like I short-circuited the M115 to M5 translation. For the life of me I can't remember why, but perhaps I realized this previously.

        # rewrite M115 as M5 (hello)
        if self.suppressM115 and cmd.upper().startswith('M115'):
            self._logger.debug('Rewriting M115 as %s' % self.helloCommand)
            # return (self.helloCommand, )
            return "$$"

Let me compare branches of code and dig a little more. At this point I'm not sure where the M5 is even coming from.

[synman]

Ok, so M5 as HELLO goes all the way back to mic159's implementation. I must have realized at some point that there are better commands ($$) than M5 to send as HELLO.

https://github.com/mic159/octoprint-grbl-plugin/blob/master/README.md

Please check this setting and let me know the value you have set:

It's in Serial Connection --> Firmware & Protocol --> Advanced

[ouinouin]

hi,
did the test, cleared the M5 hello command, and got directly connected to the CNC, so I think you can discard the M5 command at startup , as it seems no command is required to get the parameters listing
:
Connection closed, closing down monitor Changing monitoring state from "Offline" to "Detecting serial port" Serial port list: [u'/dev/ttyACM0'] Connecting to: /dev/ttyACM0 Changing monitoring state from "Detecting serial port" to "Opening serial port" Connected to: Serial<id=0x7297e170, open=True>(port='/dev/ttyACM0', baudrate=115200, bytesize=8, parity='N', stopbits=1, timeout=10.0, xonxoff=False, rtscts=False, dsrdtr=False), starting monitor Starting baud rate detection... Changing monitoring state from "Opening serial port" to "Detecting baudrate" Trying baudrate: 115200 Recv: Baudrate test retry #1 Recv: Grbl 1.1g ['$' for help] Changing monitoring state from "Detecting baudrate" to "Operational" Send: $$ Recv: [MSG:'$H'|'$X' to unlock] Recv: ok Recv: $0=10 Recv: $1=255 Recv: $2=0 Recv: $3=3 Recv: $4=0 Recv: $5=0 Recv: $6=0 Recv: $10=1 Recv: $11=0.020 Recv: $12=0.002 Recv: $13=0 Recv: $20=0 Recv: $21=0 Recv: $22=1 Recv: $23=3 Recv: $24=25.000 Recv: $25=750.000 Recv: $26=250 Recv: $27=1.000 Recv: $30=12000 Recv: $31=0 Recv: $32=0 Recv: $100=40.000 Recv: $101=40.000 Recv: $102=188.947 Recv: $110=8000.000 Recv: $111=8000.000 Recv: $112=500.000 Recv: $120=500.000 Recv: $121=500.000 Recv: $122=50.000 Recv: $130=740.000 Recv: $131=790.000 Recv: $132=100.000 Recv: ok

[ouinouin]

I can confirm the CNC is moving and operational now :-).
some remarks about the plugin :

• In openbuildcontrols, there is a continuous jog command : you set a displacement speed and the cnc moves when you clic the arrows, and keeps moving until you release the click. this is a great idea to my mind.
• I hestitate to click the crosshair button wich i suppose is the zeroing of the axis of the CNC ?, maybe a tooltip on each button would be nice ?
• same for the draw frame button, wich i clicked on it first thinking it would display something... but its REALLY drawing the frame on the CNC :-D so a tooltip would be nice.
• adding the buttons to zero each axis independently would be nice.
• on my octoprint, i disabled the webcam plugin, but I still have the logo for the missing image on top of the grbl control tab, maybe your code is not inspecting the status of this plugin ?

indeed your plugin is a very good starting point to get remote control of the CNC.
dont hesitate to mention me in case you need testing as I could see you re very reactive :-).

[synman]

Octoprint itself uses the hello command to wake up the port.

I suggest you leave that field blank as the plugin will simply send $$ given its built in printer gcode to grbl gcode conversion.

It would be good to know what values you previously had (go back to my screenshots) as they'll answer some questions I still have about your specific implementation.

Glad you got it working. I'll convert your suggestions above to individual feature requests.

Also, I still have an open "bug" from about 4 months back related to spindle control. I haven't looked at it but acknowledge it needs to get fixed for CNC.

I don't have an actual router/CNC so I'm relying on feedback to figure out how best to support it.

Shell