Certainly, but LightBurn must command something (over serial) to turn it ON/OFF. Maybe we can see M or G code?
Or maybe somebody from LightBurnSoftware can just tell us?
Actually in the CO2 world, the pointer is always on and never goes out. The crosshairs could always be wired to a constant power if the user would want it available. There could also be a physical switch if it is desired.
I can enable in firmware constant ON, but then it may be confusing.
Hardware switch IMHO is not elegant, my idea is to keep it all stock as much as possible. I would rather have custom M code and it can be turned ON/OFF from command line, essentially the same effect.
From what Iāve seen LightBurn is not involved in the turning on of the laser. It seems to be purely handled in firmware. There may be a way to toggle this using xTool proprietary software but from my understanding the light is on basically as long as the laser is.
I can see that some machines maybe.
LaserGRBL has exposed code for framing, as a custom button. There offsets can be added to the range of work coordinates. The only intent I can see is offset for laser pointer.
Letās assume it is in the firmware- what triggers firmware to turn cursor ON/OFF? is it inversion of blue laser? Some action? There got to be something, if not direct command then some other commands that caused it.
I was looking special command for āframingā but also came up empty.
Not certain but it could be something as simple as being tied to fan. It may also be something implemented outside of GRBL. For xTool itās also not clear how their GRBL implementation was done. They claim it doesnāt use GRBL source so unclear how it fits together.
framing in LightBurn is just GCode sent to the machine. LightBurn knows the size of the design so it generates a GCode stream to do the framing. If the diode LED Fire Button option is enabled then all it does is enable the diode laser at the low power setting via GCode in the Framing GCode stream. Nothing extra or fancy firmware tricks, just standard GCode.
I ripped mine off it within a month of getting the machineā¦ Still donāt have oneā¦
1 Like
My JL1 board after update with ROM.bin then doesnāt work. So I uesd STLINK to program it. It also doesnāt work.
Where can find the source code for JL1 boardļ¼
thanks.
Didnāt work for me eitherā¦
I believe this is the one I got from @LsrSal and have been using. Havenāt tried homing, place the head at the left/front and power it up. Then you can use āG10 L2 P0 X0 Y0ā to set that as home.
Use at your own risk, itās not commercial @LsrSal modified the original source.
stm32grbl11.hex.txt - remove the .txt extensionā¦ I think the hex file has the load address, but it loads at 0x8000000 if I recall.
Good luck
What did you use to load ROM.BIN? This one only works with original UPDATE.EXE and original firmware/boot loader. You cannot load with STLink because offset is unknown.
stm32grbl11.hex.txt for me only works with ST command line utility, + STLink of course. When used with Cube in Windows - I brick my board (it is recoverable).
Latest, jail-broken way is STLink with JL1a.bin.txt at the beginning of this thread. This is exactly the same as above but in BIN instead of HEX. For whatever reason BIN does not brick the board in Cube,
What did you do?
Please define: ādoesnāt workā. There are many ways.
Thanks your code.
The JL1 board work now. But the config value is wrong.
Which config value for JL1 board?
Now my Laser engraving machine work fine.
Any chance Jl1 board with home function?
Kung, you just generating questions but little explanation of what you actually did.
While I first got my JL1 working with GRBL and struggles with homing - I thought Iām limping. But later if you read threads - there is not much interest in getting it to work, most folks running relative/soft home anyway,
I cannot touch JL3 firmware. I may update mine firmware when I have more time. If I do - I will post it here.
Now, where you are:
JL3 ROM.BIN has homing for longer frame. With hard coded offset it does not work right on JL1 smaller frame. But you may get extension kit and enlarge your to JL3 size and then re-enable it. Just a thought.
My firmware: Homing is there and I believe it is working. But working does not mean usable.
the problem is: X- homing cable on JL1 is crap. it picks up interference from the motor and laser. That results in frequent spurious trips of home signals. Circuit of JL1 has no low pass or any other means to reduce noise. Home switches are normally closed, so it is current mode interference, very hard to get rid of.
I can speculate that shielded X home cable should make it usable on JL1. I have not tried yet.
Additionally: STM32 sources for GRBL do not have software debouching of home switches like Atmel original code does.
So, my firmware has homing working, I believe with proper and noise free home signals it should work just fine, but wiring + normal firmware with no soft debouncing makes it unusable.
I may try to implement homing then block signals form home switches. Then original hardware should work. Maybe. Some day.
1 Like
Thanks for reply. I try to add capacitor for debounce and try it again.
Here it is, one with working homing:
JL1v2.bin.txt (44.3 KB)
-
Homing now works (I think, fingers crossed).
-
GRBL 1.1f not supposed to have āpositive coordinates spaceā. Well, this version now is positive coordinates. So no need to mess with G10 offsets.
-
GRBL settings defaults for JL1 now are in firmware, no need to look for it. You still free to change it. Be aware that homing and limits are custom and may not appear to function the same way as on other GRBL boards.
-
I did my best to set table size and maximize works space. The fact is that with fatter laser I got - I had to move Y home switch, adding longer screws and ~5mm spacers. Otherwise Y axis move will hit front profile with laser body. I can imagine some also have added vertical slides for focusing - you probably will need to work on Y home switch mount to move it farther up on Y and tweak $131 accordingly.
-
Pointer still mapped to M7,8,9, if anybody dare to use it as intended. I certainly will.
For home/limits I found that source code has option to recheck (only once, after pretty short delay) state after limit switch interrupt is generated. It was disabled by default. The problem is that X home cable is really bad and picks up interference form motors and the laser. But blips are short and with state recheck enabled - operational problem completely disappeared. Iām sure it is still generating interrupts, it just checked nicely. In perspective: Atmel original code has soft de-bouncing that is not implemented in STM32 port. I guess that de-bouncing setting $26 is purely cosmetic.
I have to plow through whole homing and limits routines, to set positive space and remove homing pullback distance. I did it purely for my preference. Some may argue that if version is 1.1f - it should behave like one. Reading referenced above article - Iām more assured that exclusively positive space is better for laser.
I think this is it. It feel pretty robust to me and everything works as intended. Unless there are some serious bug there - I have no plans to take it further.
At this point I think this is much better firmware than original JL3.
Feedback is appreciated.
And again, disclaimer: I take no responsibility for what this thing can do, like causing injury, property loss, poisoning, blindness and any other horrible thing. If you not sure - do not use.
3 Likes
What is the best way to load this firmware?
This was already discussed a few times: IMHO, the easiest is with STLink V2, that is ~$10 on Amazon or Ali.
Then use it with command line utility from ST. You also need to solder 4-pin header into the board.
Alternative software is āCubeā (big installation) but nice GUI.
You may download Cube and CMD utility and read more here.
Alternative hardware is no additional hardware, but need to tap couple resistors on board to put micro into Serial Boot loader mode.
Read whole thread carefully and google āSTM32 Blue Pillā, it is exactly the same micro as JL1 board. All info for blue bill is applied here, including all ways of flashing it, through serial or STLink.
Please consider tweaking your motion limits: speed and acceleration.
Defaults I put there 5K for speed and 1K for acceleration. With 1K acceleration āwobbleā become noticeable. Iāve dropped it to 400 and it tight now.
Regarding speed: machine has no problem with 5K speed, but my X axis has some resonance at ~4K. I dropped max to 3K and not hearing that resonance any more.
My board is modded for 32 uSteps, so this maybe unique to me.