If you already got files: here is the instructions:
Files have small executable and usually two BIN files. Bin files are the same, one named with version and another one just “rom.bin”. Uploader will take later file, long name file I guess in the case you have big collection of versions.
Assuming that driver for CH340 is installed and COM power appeared in Device Manager when JL1 is connected. If you are able to use original software then you are all set.
1- make sure uploader exe is not running, close if it is.
2- make sure board is OFF
3- hold button on the board, the one between power and USB connections and power ON the board
board now in upload mode
4- start the exe, follow prompts.
it is relatively fast process, bin is less than 40K.
5- reboot, start LarerGRBL and got to GRBL settings (that is for the board, not the app). At very least you have to disable hard and soft limits and set table size. If somebody cares - I can post my settings for that cheap Amazon Laser machine.
Just a reminder: there is no easy way back to stock firmware. I found apple app with very generic name “Laser engraving” by " [Dongguan Xinjia Laser Technology Co., Ltd" works pretty well with original firmware, but of course nobody want to do serious work from the phone and this is not a substitute to LightBurn.
Before flashing - read my other post about limitations with this (JL3) GRBL firmware.
Notably: No way to get hard limits/home to work properly, red cross pointer does not work (automatically), WiFi is no more, at least for me. And no easy way back to stock firmware, not like I will ever try.
Maybe some day we can recompile proper firmware for this board/hardware combo? I have started mapping signals to STM32. They do not match any GIT version, and there are a few. Should not be that difficult. Some day. For now this JL3 firmware will let us going.
Flashing: my experience with this board/GRBL firmware, info to consider:
Flashing with JL3 firmware/utility is super easy.
Original firmware has some boot loader. I was not able to match it to any popular firmware loader, just does not talk. Maybe I just did not find the right one?
That original boot loader is gone after GRBL flashing.
I’ve tried to flash provided BIN with ST-LINK to Blue Pill - It loads but does not run. I’ve tried various offsets, including zero and the one that is standard with Arduino (something like 0h08000, do not remember exact) - does not run. Maybe something in configuration? Well, either way, none of my attempts to flash this bin to Blue Pill is talking over serial. I assume it just does not start. I would love to figure it out.
ST has utility for straight serial flashing, no need for other signals. Well, maybe need pulling high R19 and R20. But either way, once another firmware is available - should not be that hard to flash it again.
That ESP12 board there, after flashing, I was not familiar that GRBL by default has safety latch. This is my first experience with Laser and GRBL. It appeared to me that GRBL was latched/locked up randomly, preventing me from changing setting and any operation. I’ve speculated that GRBL cannot talk on two serial ports simultaneously, so I did pull that ESP12 off the JL1 board. Even without ESP board my apparent problem persisted. Then I’ve learned about soft safety latch and there are number of things that can trigger it - once behavior is understood - no problem. When messing with settings - once in a while I have to quit and reset the latch (command “$X”). Once all set - I have zero problems with this machine. It works pretty smooth and has surprisingly good results. But I have no WiFi and I cannot verify if that firmware can support serial and WiFi. But I do not care for WiFi anyway. I think it is better and safer without it.
There is alternative controller you can buy on Amazon: B07RQZGD35. It has no limit switches inputs, and you need to swap some connectors (no need to crimp, just pins swap, same type of connectors, but you need to buy JST-HX of proper size/pin count). That is hardware wise essentially identical to JL1, minus WiFi, minus pointer output, minus limit switches. And none of these peripherals working with discussed GRBL firmware anyway. Just a thought.
Limit switches are working but not matching smaller JL1 frame. The problem is that Lasers working in positive coordinate space. JL3 has Y home at far end and offset hard coded. No matter what settings are - after switch homing it goes Y negative like double the JL1 size. I’ve disabled all offsets and still, after homing with switches it tries to move negative. Check JL3 size. I guess it is possible to extend Y rails and move switch to far end, then it will work properly. As is, JL3 firmware homing with switches does not work properly on this JL1 frame.
In reality, I just home to bottom left by hand, before switching power on. To me - very minor inconvenience.
No idea. None on GIT that I’ve checked is matching default pinout, so cannot use any precompiled version. I also did not find any info if any on GIT support two serial ports simultaneously, but I guess this is not very difficult hack. It is also not a necessity, IMHO.
That JL3 firmware behaves like any other GRBL and report itself on boot as “1.1f” That is recent enough.
Cross pointer sits on dedicated IO. I was not able to toggle it with any g-code. It appeared to me that JL3 does not have pointer, this explains the lack of support. But no harm setting solder blob on board to permanently enable it.
I do not think it is very difficult to recompile from GIT, any of it. Just need some time. I got most of IOs mapped already, but more work is needed. Any volunteers?
With proper settings it homes as expected, then paused for second and then moves negative, that hits hard stop right away.
Well, I was not able to overcome it. Not with that JL3 firmware. If you can - let me know. And I’ve tried. I vent as far as flipping whole frame, milling hole for X home on left plate of gantry, swapping all left to right pretty much like JL3, and I also found that moving Y switch to the left will cause lever to flip, that require change of switch holder, so I’ve printed one. I had both switches at 0:0. I can home. then it moves Y negative. moving that Y switch to far end not good either ans there is not enough length.
As I’ve mentioned, I’m pretty certain that Homing Cycle has hard coded move negative after switch homing complete. There is no settings that I can find for it.
After all I went through with homing - I give up for now and rather focus on recompiling custom from GIT. For now: homing cycle disabled and I home by hand. Easy.
JL3 has home switches at x=0; y=far+. So after finding Y far, it moves to Y=0. That move is too much for any dimension of JL1.
JL1 had home switches at x= far+, Y=0.