Im very confused and don’t know where to start. I tried googling my issues but got on post and topics that didnt quite seem correct. I’ll give you a rundown of whats going on and would be happy to expand further.
I assembled and got my10W Falcon Engraver about 3 days ago. I ran the 10W Eagle Test Gcode and it printed fine. I installed LB software from the side and wanted to go offline printing to downloaded from the TF card included with the printer the falcon laser profile. I proceeded to make some squares and power test squares on different layers to try and figure out what the power settings need to be on to cut through the 3mm Hardboard i picked up to use. I saved the Gcode from LB and loaded it onto the TF card. It started up normally, auto homed to the front left corner, turned on and cut the first layer and when it went to the second layer location shut off and rebooted it self. From there i tried a few different ways to save the Gcode. I used the drop down menu from “File” as well as the save Gcode function on the right side beside the Frame button. Neither of these worked. Sometimes it would move to the 2nd layer but not all the time.
I just want to iterate that the Sample Gcode file in the TF card worked after the rebooting. So I don’t think its a power issue as it runs the sample Gcode just fine.
After that I plugged it in directly via USB to my laptop. When I went to print from LB directly it would run for a bit longer but would still reboot. So I tried to load a new device by having LB search for it instead of using the provided profile from Creality. This was different so i have tried to use this one. Again it started to cut for longer this time (reaching almost 1m30s) but ultimately rebooted itself again.
I tried again with the TF card and printing from there and I got a few different error messages. The one I get from the TF card is as follows
[0;32mI (2533) sdspi_transaction: cmd=5, R1 response: command not supportede[0m
Name: SD8G
Type: SDHC/SDXC
Speed: 20 MHz
Size: 7680MB
[MSG:Axis count 2]
The error i get when directly plugged in is as follows
[0;31mE (7186) gpio: gpio_isr_handler_remove(480): GPIO isr service is not installed, call gpio_install_isr_service() firste[0m
with various numbers replacing the “7186” at the beginning. It does tell me Connection lost some times but that is only after the machine reboots itself so I am assuming that is the reason for connection lost
I also tried after that to d the LB Material Test option from the “Laser Tools” section. It got as far as printing the 2 title axis but again rebooted itself. This was when it was plugged in directly.
I tried the provided sample Eagle 10W gcode again. It printed fine no reboot or hiccups. Im at my wits end and am ready to call it quits on this machine. Does anyone know what is happening?
Im ok with whatever the issue is as long as i can fix it lol.
Just to confirm the SD card runs perfectly fine when cutting with the sample Gcode file. Also ive been screwing around with it and have been able to print single layer simple squares. It takes 4 passes at 5mm/minute @ 100% power to cut through but it seems to be working, These square test are being run through USB (the same cable i used in all of this)
how can i check the machines firmware? there is no display for it. Is there a report i could run?
Interesting. The sample g-code was also created in LightBurn.
A couple of things on the g-code that I noticed:
Your speed settings are super high for a line engraving. I’d suggest reducing speed by about 10x.
Your device is configured on the wrong device type. Push Devices button in Laser window, then click on the name of your laser, then Edit. Change to “GRBL” and not one of the variants. Then complete the wizard.
Make sure that S Value Max is set to 1000 in Edit->Device Settings
Neither of these things by themselves should cause the issue that you saw, however. If the problem is a power issue then it’s possible that running at high speed could make that issue more apparent.
When you first connect you should get a welcome message that includes the version number.
If you don’t see then you can try running this in Console:
I have redone the focusing and now can cut the squares with the settings at 10mm/s @100% power with 6 passes with MUCH less charring. I still can seem only to do one thing at a time. I loaded 2 images to engrave and it engraved the first one fully but when it tried to go to the second one it rebooted again. The engraving settings are 100mm/s 20% power 1 pass. The S Max is set to 1000 but the GRBL is the setting LB assigned to the printer when it scanned for it. I will try with the new settings and get back to you
I have exactly the same laser, using it with the TF card, and I don’t have these problems.
So the hardware issue is a good track. Perhaps contact Creality?
Note that you should load the LightBurn settings provided on the TF card, it will set the right configuration for this laser.
Also, we generally use mm/min for diode laser (that’s what the LB settings suggest, anyway).
HOWEVER for what ever reason it now reboots itself when attempting to engrave anything. I did get it to engrave 2 things but have no idea what i have changed for it to all of a sudden not want to. the engraving its rebooting on is as follows
For clarification the order of operation was as follows
Engraved successfully the image from the “Test Engrave” gcode while laptop was connected via USB cord.
Save gcode to SD card and attempt to use. Constantly gets about 3 to 4 seconds in and reboots itself.
Reconnect to Laptop via USB. Same thing happens when attempting to engave directly from Laptop. Longest attempt last about 20s. Sometimes the engraver woul reboot but LB would continue streaming as if it was still engraving and I would be forced to exit out of LB to stop it.
Get extremely frustrated from things not working.
Make testplate file in LB and save Gcode and load on SD card
“Testplate” file cuts perfectly off of the SD card no issues
Hi PhiLho, Im using the settings that LB brings up when i connect the Laser directly into it. Also i use mm/s as that is the unit LB gives me when I am changing settings. Have you heard of this issue before?
Is there a reason you configured it as GRBL-M3 instead of GRBL?
As far as the failures, it feels like you’re looking for a configuration or setting that will fix that when the issue is almost certainly in the hardware.
The reason im doing GBRL M3 instead of GBRL is that when i plugged my machine into LB directly i did a fresh decive setup and that is what LB assigned to my machine. I figured to leave it alone as I personally dont knoe what the difference is so i was gonna let the machine do its thing for assignment.
I understand that its most likely a hardware issue i just want to make when i contact Creality that ive done my due diligence in making sure it is the hardware. Ive ordered a new proper cable to make sure its not the cable and order a new SD card to elimate the possibility that the SD card in the box isnt defective.
That being the case are the gcode good? I dont know how to read gcode to look for issues. If its the exact same in terms of setup and just the paths are different due to be different files i can eliminate the software being an issue as it runs fine on one but not the other. The other thing im going to try is to change the standard engraving settings. Or try to convert it over to a .svg file instead of a .png file to load it. Perhaps it just has an issue with it being a “Image” instead of a “Line” for the settings.
Also as far as i can tell i am one the newest fireware version so i believe i can eliminate that reason as well. Sorry for the walls of texts i just want to explain my thought process and the steps im trying to solve these issues. I do appreciate your help and im not trying to dismiss anything youre suggesting. Just want to go through all the steps and motions as anytime ive tried to warrenty electronics they want me to do all these steps first.
The detected hardware is incorrect. I suggest you change.
I encourage you to explore as much as necessary to feel satisfied. It’s possible you discover something new in the process. But note that unless something comes up that’s fundamentally different than what’s already been seen then the answer is not likely to change.
Other than it being tailored for GRBL-M3 it’s fine. And your controller should be perfectly fine processing GRBL-M3 code as it should be a subset of your controller’s capability.
In the end the controller doesn’t know if it’s working with an image or svg as it’s all been converted to g-code motion commands. There are times where firmware bugs will be more obvious under certain circumstances than others though so trying different things isn’t a bad thing.
However, under no circumstances should the g-code force a shutdown of the laser which is why it’s hard to get away from that diagnosis. Also, since it doesn’t occur at the exact moment each time indicates it’s not a specific command that’s causing the issue.
This looks like an internal firmware error to me. Internal code message of a runtime error. I’d suggest re-flashing the firmware again. Nothing that LightBurn or any other tool of gcode file can do about it. Except from causing a buffer overflow or something.
LightBurn just guesses based on the version identification it receives. For modern lasers, this often fails. Changing the type to “grbl” should be fine.
I realized I may not have been entirely clear when I say a hardware issue in this case. More broadly, I mean this is likely to be something outside of the g-code.
So something in the machine itself like electronic component, or the power supply or something machine related. However, it could be something external to the machine as well. For example, if you have a noisy electrical circuit that could cause this issue. Do you have a compressor or fan or anything else on the circuit that’s coming on? Even something like a failing fluorescent light. EMI or static discharge could also cause something like this. Try to identify and eliminate any such potential issues.
From what I’ve seen of these machines, they all have this as part of the bootup process. Likely something that wasn’t configured during firmware compilation. By itself I don’t think this prevents proper function.
Reflashing might still be worthwhile to rule that out, however.