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
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
Send: N0 M110 N0*125
Send: N1 G90*17
Changing monitoring state from "Starting" to "Printing"
Send: N2 G21*24
Send: N3 G90*19
Send: N4 M42 P3 S1*16
Send: N5 M117 0% | 09:49*86
Send: N6 G90*22
Send: N7 G0 X0 Y0 F1500*77
Changing monitoring state from "Printing" to "Finishing"
Send: N8 M400*47
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?
Did running in safe mode solve the problem?
octoprint-systeminfo-20211111171037.zip (1.2 MB)
Additional information about your setup
OrangePi Zero LTS,
Orange Pi Bionic with Linux 5.4.27-sunxi
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.
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.
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
You are absolutely right and I will from now on run in safe mode first before yelling for help.
Alles wird gut
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.