GCode not running properly after 1.7.0 update

I have an old Geeetech A10 stripped down and modified to run as a simple laser engraver/cutter.

With a few gcode modifications it has been running really good and reliable until the 1.7.0 update.

Since the update the following code:

; LightBurn 1.0.04
; Marlin device profile, absolute coords
; Bounds: X5 Y5 to X55 Y55
; Cut @ 100 mm/min, 100% power
M42 P3 S0
G0X15.042 Y9.967 F1500
; Layer SnapPap - Cut
M42 P3 S128
G1X14.098 Y10.709 F100
G1X13.191 Y11.495
G1X12.322 Y12.322
G1X11.495 Y13.191
G1X10.709 Y14.098
G1X9.967 Y15.042
G1X9.27 Y16.022
G1X8.619 Y17.037
G1X8.017 Y18.084
G1X7.465 Y19.161
G1X6.965 Y20.269
G1X6.517 Y21.404
G1X6.124 Y22.566
G1X5.787 Y23.752
G1X5.508 Y24.962
G1X5.288 Y26.193
G1X5.129 Y27.444
G1X5.033 Y28.714
G1X5 Y30
G1X5.033 Y31.286
G1X5.129 Y32.556
G1X5.288 Y33.807
G1X5.508 Y35.038
G1X5.787 Y36.248
G1X6.124 Y37.434
G1X6.517 Y38.596
G1X6.965 Y39.731
G1X7.465 Y40.839
G1X8.017 Y41.916
G1X8.619 Y42.963
G1X9.27 Y43.978
G1X9.967 Y44.958
G1X10.709 Y45.902
G1X11.495 Y46.809
G1X12.322 Y47.678
G1X13.191 Y48.505
G1X14.098 Y49.291
G1X15.042 Y50.033
G1X16.022 Y50.73
G1X17.037 Y51.381
G1X18.084 Y51.983
G1X19.161 Y52.535
G1X20.269 Y53.035
G1X21.404 Y53.483
G1X22.566 Y53.876
G1X23.752 Y54.213
G1X24.962 Y54.492
G1X26.193 Y54.712
G1X27.444 Y54.871
G1X28.714 Y54.967
G1X30 Y55
G1X31.286 Y54.967
G1X32.556 Y54.871
G1X33.807 Y54.712
G1X35.038 Y54.492
G1X36.248 Y54.213
G1X37.434 Y53.876
G1X38.596 Y53.483
G1X39.731 Y53.035
G1X40.839 Y52.535
G1X41.916 Y51.983
G1X42.963 Y51.381
G1X43.978 Y50.73
G1X44.958 Y50.033
G1X45.902 Y49.291
G1X46.809 Y48.505
G1X47.678 Y47.678
G1X48.505 Y46.809
G1X49.291 Y45.902
G1X50.033 Y44.958
G1X50.73 Y43.978
G1X51.381 Y42.963
G1X51.983 Y41.916
G1X52.535 Y40.839
G1X53.035 Y39.731
G1X53.483 Y38.596
G1X53.876 Y37.434
G1X54.213 Y36.248
G1X54.492 Y35.038
G1X54.712 Y33.807
G1X54.871 Y32.556
G1X54.967 Y31.286
G1X55 Y30
G1X54.967 Y28.714
G1X54.871 Y27.444
G1X54.712 Y26.193
G1X54.492 Y24.962
G1X54.213 Y23.752
G1X53.876 Y22.566
G1X53.483 Y21.404
G1X53.035 Y20.269
G1X52.535 Y19.161
G1X51.983 Y18.084
G1X51.381 Y17.037
G1X50.73 Y16.022
G1X50.033 Y15.042
G1X49.291 Y14.098
G1X48.505 Y13.191
G1X47.678 Y12.322
G1X46.809 Y11.495
G1X45.902 Y10.709
G1X44.958 Y9.967
G1X43.978 Y9.27
G1X42.963 Y8.619
G1X41.916 Y8.017
G1X40.839 Y7.465
G1X39.731 Y6.965
G1X38.596 Y6.517
G1X37.434 Y6.124
G1X36.248 Y5.787
G1X35.038 Y5.508
G1X33.807 Y5.288
G1X32.556 Y5.129
G1X31.286 Y5.033
G1X30 Y5
G1X28.714 Y5.033
G1X27.444 Y5.129
G1X26.193 Y5.288
G1X24.962 Y5.508
G1X23.752 Y5.787
G1X22.566 Y6.124
G1X21.404 Y6.517
G1X20.269 Y6.965
G1X19.161 Y7.465
G1X18.084 Y8.017
G1X17.037 Y8.619
G1X16.022 Y9.27
G1X15.042 Y9.967
M42 P3 S0
; return to user-defined finish pos
G0 X0 Y0 F1500

Just returns the following output:

Changing monitoring state from "Operational" to "Starting"
Send: N10 M117 0% | -*113
Recv: ok
Send: N0 M110 N0*125
Recv: ok
Send: N1 G90*17
Recv: ok
Changing monitoring state from "Starting" to "Printing"
Send: N2 G21*24
Recv: ok
Send: N3 G90*19
Recv: ok
Send: N4 M42 P3 S1*16
Recv: ok
Send: N5 M117 0% | 09:49*86
Recv: ok
Send: N6 G90*22
Recv: ok
Send: N7 G0 X0 Y0 F1500*77
Recv: ok
Changing monitoring state from "Printing" to "Finishing"
Send: N8 M400*47
Recv: ok
Changing monitoring state from "Finishing" to "Operational"

The code worked properly before but not anymore.

Nothing else has changed.

I've moved your topic into the Get Help sub forum because this is actually the better place.

Alas, because you opened it in General you failed to fill out the template, so please do so now:

<!-- ~~~~~ Filling this out properly makes it WAY more likely to get help quickly ~~~~~ -->

### What is the problem?


### What did you already try to solve it?

### Have you tried running in safe mode?

### Did running in safe mode solve the problem?

### Systeminfo Bundle
<small>You can download this in OctoPrint's System Information dialog ... **no bundle, no support!**)</small>


### Additional information about your setup
<small>OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... **as much data as possible**</small>


What I can tell you is that I just ran your GCODE through OctoPrint's virtual printer and I didn't see any weirdness, so I'd strongly suggest you try safe mode.


I use Octo for some years and I was in 1.6 and I update to 1.7.2, and I have exactly the same problem , but not with all Gcode, nealy uploaded on Octo refuse to print, olders prints.
On the terminal, I can send some gcode, like G28, M140, G92, but G0 and G1 are not sended.

After many test, I couldn't not identify what made Octo to refuse G0 and G1, but once restarted I can send this Gs for a short time.

Please help, I have lost all my SD card, I can't print.

Congratulation for this your job


Hi @Joachim, same thing for you, please test safe mode and fill out the above template.

Thanks for your rapidity,

First filling, my printer is running I can't test safe mode

What is the problem?

Movement G-codes are not sended by Octo, neither in terminal, neither by file

What did you already try to solve it?

Multiple reboot, test many files, after restart octopi a few Gcodes movement are sended but after it stops

Have you tried running in safe mode?

Not yet

Did running in safe mode solve the problem?

will see

Systeminfo Bundle

octoprint-systeminfo-20211111171037.zip (1.2 MB)


Additional information about your setup

OrangePi Zero LTS,
Orange Pi Bionic with Linux 5.4.27-sunxi
OctoPrint 1.7.2
Marlin 2.0.... lastest on Atmega2560
Windows 10, Android 11

I hope this help

There's a ton of errors in there from the dashboard plugin, so you really should first test in safe mode if the issue persists. If it does, please enable serial.log, reproduce the problem and then create another systeminfo bundle.

edit On closer look, this is most definitely the dashboard plugin as it crashes with a division by zero whenever a command is to be sent to the printer.

Thank you foosel,

Dashboard plugin removed, also, it's not the same problem but I never succeed to made layerdisplay work. I tested patterns on the web site and they were ok.

As soon my printer finish its job I'll test without the plugin

Just did a quick test in safe mode and apparently it seems to work fine.
I just read that the dashboard plugin might be the reason!?

Yep, at least the log of @Joachim is littered with:

2021-11-11 15:08:01,790 - octoprint.util.comm - ERROR - Error while processing hook dashboard for phase sending and command G1 X86.208 Y70.466 E0.0407:
Traceback (most recent call last):
  File "/home/pi/OctoPrint/venv/lib/python3.6/site-packages/octoprint/util/comm.py", line 4611, in _process_command_phase
  File "/home/pi/OctoPrint/venv/lib/python3.6/site-packages/octoprint/util/__init__.py", line 1737, in wrapper
    return f(*args, **kwargs)
  File "/home/pi/OctoPrint/venv/lib/python3.6/site-packages/octoprint_dashboard/__init__.py", line 792, in process_gcode
    current_layer_progress = int((self.layer_moves / self.layer_move_array[self.current_layer]) * 100)
ZeroDivisionError: division by zero

This is btw why we always want y'all to test if a problem persists in safe mode first. Safe mode disables all third party plugins, and believe it or not, a third party plugin is surprisingly often the culprit.

1 Like

So how do I proceed? Contact the plug-in developer for a solution request?

Yep, best open a ticket on the plugin's issue tracker. I don't know if they are active on this forum here and I for one cannot solve this, that's for the plugin author to do.

What I have however just added to my TODO list is to make OctoPrint more resilient in this particular part of the code against issues like this one, in 1.8.0.


That would be @j7126/@Willmac16

Hi Foosel,

Just to tell you that I didn't test in safe mode because as soon I removed the dashboard plugin, Octo re-worked fine.

Thanks for your help

My point was that the reporting template explicitly asks to test in safe mode because that will already unveil if it is an issue caused by a third party plugin. Sadly a lot of people don't (or - even worse - say they tested in safe mode but actually didn't) and that costs their time and ours and frankly is a bit frustrating when it happens so often. Be kind, test in safe mode :wink:

1 Like

You are absolutely right and I will from now on run in safe mode first before yelling for help.

Alles wird gut :upside_down_face:

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.