Well folks, after some mental exercise of low level code editing for STM32 HAL stuff with Notepad I was able to recompile GRBL 1.1f for JL1 board. It appeared to me that most stuff is working, however Homing still not right and I would advice to keep it disabledfor now and use work origin (soft home) instead. Most do that anyway.
If you successfully upgraded with JL3 firmware - there is little reason to use this one. The only attraction is working cross pointer, mapped to flood and mist (M7,8,9).
Another reason would be botched upgrades with JL3 firmware, but Iām only aware of Jack getting in this trouble. Present firmware is unlocked and can be used with any upload tool. Tested with ST command line uploader and Cube + STLink V2 clones from Amazon.
To upload it you most likely will need STLink dongle. As free alternative - you can learn to use serial over USB, maybe somebody can write guide about it. Two resistor for boot configuration are easily accessible on the board,
Now the legal stuff: I take no responsibility for any trouble this thing can cause. None. I use public domain source and therefore this is a public domain product.
This is very Alpha version. I hope you can find it useful, I also hope to take it further to get full functionality, including proper homing (not yet) from JL1 machine.
Before programming do not forger to set offset to 0x8000000.
I tested it and as stated - hard home/limits still messed up, I think. Otherwise appeared working. But I guarantee nothing. Never will.
I blow original firmware and boot loader long time ago (long time here = 2 weeks). I can only guess that original upgrade did load at default flash offset, because I can no longer activate boot loader with button. There is a chance that original upgrade.exe can take this BIN, but only if you still have original firmware and original boot loader that can be activated with button. If you already use that upgrade - boot loader is no more, I think. If you already upgraded with that utility and JL3 ROM.BIN then I do not think you can use this EXE again.
If your board not bricked yet - Use utility and JL3 firmware and wait for later version of this one. Maybe.
If bricked, or if you are super curious - get STLink and load this one with any of ST programming tools. Will need to solder x4 pin header to the board.
Info/warning: when using STLink, make sure you use 3.3V from the dongle for V+ on JL1 and not +5V.
When flashing - JL1 does not need any other power connection, it gets power from STLink.
When I did the upgrade, I did it twice in a row due to the EXE not having a clear indication of a successful update. Same behavior twice in a row so I think it could be possible to update the board the same way. I am not brave enough to try it. I am happy as it is for now.
You can report to us when youāve tried thisā¦ I tried to load the ROM.bin file with st-link and it never would work. With a .bin file and st-link, you have to enter the load address, I used the standard 0x8000000.
Iām postulating, as others have, that the ROM.bin loads elsewhere and just flashing it doesnāt seem to work.
Most of these generated files have the information for the loader to tell it where to load. Using a .bin file the ācubeā requires you to enter the load location. Not so with the .hex version. Is that information missing in the .bin fileā¦?
Just to clarify Jackās reply: he is talking about attempts to load JL3 firmware with ST link, not the one at the beginning of this post.
BIN is just the content, HEX for the same firmware is like x3 size. For example, my firmware is 45K as BIN and 125K as HEX. Cube loads offset automatically when HEX file is opened.
HEX has line headers and more stuff in it. Intel HEX.
It does store offsets for all spaces (G10 L2) and selected space (G54) in EEPROM, it is persistent and will survive cold reboot.
To check all offsets: $#
To select: G54 to G59
To set: G10 L2 P0 X0 Y0 , (P0 is for G54, P1 is for G55, etc, X and Y are actual desired offsets). For JL1 frame with X home on the right - X offset is minus 225 (-222 to be safe). So the command to properly setup space for JL1 frame is:
G10 L2 P0 X-222 Y0
G54
To check current applied offset just type: ? (yes, just a question mark).
It will show current position and then applied offset. With working homes it should be 222:0:0; -222,0,0
If no plans to use hard homing then better keep it all at zeros. Right now hard home does not work properly anyway. JL3 has hard negative pull, regardless of settings, and my firmware above - hard limits are glitchy. But fun to experiment with!
Stepper driver ICs used on this board, A5988, are 1/32 uStep capable, though for whatever reason hard wired for 1/16th.
After digginā some very high level specs in Chinese, they appeared 1/32th step capable.
After some microsurgery - sure enough, they are. I have to adjust resolution from 80 step/mm to 160.
While pin-out is the same as 4988, they are noticeably quieter, though not as quiet as 2209 but very close.
This might be unnecessary for most, but I can imagine can be big boost for photo dithering.
I have a question for community: Is there a standard g code for laser pointer?
Is there an offset saved in GRBL for it? There is an offset for the probe, but it is different, I think. More for CNC than laser.
JL1 has nice red cross laser pointer that is much easier on the eyes than blue dot when framing work area. Funny thing - It was not working properly with original software.
In my first version Iāve enabled laser pointer with cooling/mist command (M7,8,9). But that usually reserved for laser air assist.
I cannon find any reference to g code for the pointer. Is there any?
In LaserGRBL I can easily code custom button to use any code for the pointer.
I see LightBurn has option for laser pointer but I cannot find g code examples. Is this only for predefined machines? Does it do it for the GRBL?
Iām not aware of anything that would be implemented in GRBL. I suppose this possibly could be done with something like a tool offset.
However, this is typically managed as a pointer offset in LightBurn Device Settings. LightBurn will then adjust all generated g-code to account for the offset.
ya itās just not something most people would ask for since the diode lasers can just be put to low power to āpointā the target and CO2 lasers will have a combiner lens which mixes the red laser pointer dot with the laser path and points through the lens. CNCās have the tool itself so thereās little need for turning a āpointerā laser on/off in special āpointerā gcode. But there are user commands you can create and code into the controller but youād need to control them from a console or macro.
You can also just put a switch on the front panel and manually turn the pointer laser on/off.
@DougLās reply made me realize you might be asking for a g-code command to enable pointer. Iāve never heard of anything like this.
Iām wondering if you potentially repurpose M7 for this as itās available in GRBL if configured. Otherwise M6 for tool change or G82 could be interesting but are not available in standard GRBL as far as I know. It may be implemented in some of the 32-bit forks.
Thanks yāall for reply.
My firmware already has M7 and M8 setup to turn laser ON. and M9 - off.
But progressively upgrading my setup, and planning some form of air assist - I would prefer for codes/commands to be more standard. M7,8,9, already defined as air assist for Laser, so I probably better move pointer to some other commands.
I certainly can make custom M code just for JL1 board, but I thought that maybe there is some kind of convention.
I hear that most do not care about that red pointer. Iāve stated before that this is certainly not essential, but I can tell you that to my eye properly working red cross makes is so much more pleasant to frame. Might be just me, Another reason - I just want to get all stock hardware functions to operate as intended. This maybe just my sport, even if no practical reason.
I guess it is possible to snoop on LightBurn serial talk to see what it send out when configured with pointer.
Iām not sure if this sampling is representative of everyone. Some lasers like xTool D1 come with this standard and on. Most people do use crosshairs for that.
I donāt think LightBurn is involved in the enabling of the LaserLight. I think this is handled in firmware.
Note that Iām not so familiar with GRBL forks so there may things that grblHAL or possibly FluidNC are doing to enable crosshairs if your hope is to align to some de facto convention.
