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.
JL1a.bin.txt (44.4 KB)
This is brilliant. Well done.
Just curious if it has been tested, the upload tool that is used for the original JL3 GRBL ROM.BIN?
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…?
Let us know if you attempt this…
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.
BIN offset must be known, it is not in the file.
Do you suggest I reload the firmware ?
It sat all night with no power, then I power it up, it’s still at -50 and 55 for the x, y location… Should be a negative 220 and 290.
Does it permanently store this offset… I didn’ think that was the case.
No need to reload. These are all EEPROM settings.
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
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!
JL1 board Hardware Easter egg:
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 can guess that tying this chip for 1/16 uStep makes this design compatible with 4988 for some manufacturing flexibility.
Very nice find! Thanks for all the hard work!
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.
Personally I don’t have a use for the laser pointer.
I’m only interested in getting photographic quality pictures on the tiles.
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 pretty sure that I speak for all of us when I say that we appreciate all of your efforts.
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.