always try moving a directory back if you get an error. On anything.
Actually it is in this thread, post #37.
I’ve being sarcastic. It is x7 screws, takes less than one minute to pull the board out. I usually disconnect everything.
Nice looking Y home switch mount! Please share the STL.
Tweak/reduce $131 accordingly. My value is for 5mm spacer to original home switch mount. I’'m, sure vertical slide (if any) +fatter laser will eat more space. To prevent hard limit on Y $131 need an adjustment.
for some reason URL on GITHUB changed from “… /LsrSal/DEE_JL1/Firmware” to “…/LsrSal/DEE_JL1/tree/main/Firmware”.
I guess that “/tree/main/” has something to do with GITHUB edits.
Jack,
Just a reminder: after new firmware flashed - you have to issue hard home command: “$H” before anything become functional. This is new and different for you vs. GRBL/JL1 with hard homing disabled. Get used to new routine, always hard home first.
$H is also explicitly forbidden in INIT g-code $N, it is impossible to automate on GRBL board level. This is specifically enforced in GRBL firmware as safety measure. (Though original JL1 firmware auto-homing like it is perfectly normal and safe.)
1 Like
Other 32bit grbl forks I’ve run across also did a $h on powerup. Probably saves on support issues.
I guess situation and use cases can be different, but some issues are enforced as general safety, so is auto-homing block. I’m kind of agreed that it is generally safer to be blocked.
The very short time I had to use original firmware - I had no problem with machine auto-home.
My previous message is to alert Jack, and everybody, of another GRBL behavior that can be perceived as odd, while actually intended.
Here is the comment by the developer.
If one desires - it is not hard to remove auto homing limitations from source code.
As we are developing topic of homing further, I would like to bring attention to another related setting, that is already set in V2 by default but some may changed it to different: $1 = 255, will ensure that motors are always have hold current to not loose exact position. It is default in V2 but not in many other forks. Changing it to any other value have risk of bumping (or slipping/drifting) gantry out of position and as a result running into hard limits. Or, if you are running multi-session work, also an alignment between session.
I recommend to make sure that $1 = 255.
Where is Jack?
STLink already connected! How long it may take to flash and test it?
Suspense…
Tonight’s dinner ‘chef’ had to go to work and make dinner … 
Loaded the firmware and found the X limit was about 3mm from making. Cut a spacer and put it in…
The axes were running backwards, had to change the config…
It is homing, but the home location y is in the negative numbers… Y seems to be a -290.
Here’s the stl for the X limit switch…
jl1-y-limit.stl.txt (37.2 KB)
Is your offsets still persists?
Please post your “$#”?
If offsets still there - please reset all to zeros.
When you flash it, did you do Erase Whole Flash or only programmed space? Maybe try to erase whole chip first, then flash?
I am clueless here…
$#
[G54:220.000,290.000,0.000]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
[PRB:0.000,0.000,0.000:0]
ok
Assume g54 needs to be zero?
Yes, correct, V2 firmware do not need any offset.
try full default reset:
“$RST=*”
then check again with $#
$RST=*
[MSG:Restoring defaults]
ok
Grbl 1.1f ['$' for help]
$#
[G54:0.000,0.000,0.000]
[G55:0.000,0.000,0.000]
[G56:0.000,0.000,0.000]
[G57:0.000,0.000,0.000]
[G58:0.000,0.000,0.000]
[G59:0.000,0.000,0.000]
[G28:0.000,0.000,0.000]
[G30:0.000,0.000,0.000]
[G92:0.000,0.000,0.000]
[TLO:0.000]
[PRB:0.000,0.000,0.000:0]
ok
Looks good, number wise …
After the $H, the ‘move’ window shows ?
$# hasn’t changed…
Getting to be bed time for me 
… will be around tomorrow… thanks for the help.
Looks perfect to me. After hard homing it should stay at 220:0, bottom right corner. Unless you have setup $N to go somewhere else after homing, for example sending gantry back, to clear access for loading work piece. If you now command it to go to 0:0 (soft home) - it will move to the bottom left, and whole space is positive. (I see you have 0:0 saved as “back-right”, now 0:0 is front-left.)
It appeared to me that $H completed successfully.
Tweak your $131 to avoid Y hard limit, set speeds to 3000 and accel to 400 and you are done.
Haven’t run a job, but there is some issue with how ‘continuous’ mode is working… I changed the controller to reflect the smaller work area, both in the controller and in Lightburn.
I can jog the head to the rear with no issues when there is a set ‘distance’ in the move window. I have enabled ‘show all’ in the Lightburn console. I think the $J command has 290 instead of 280… I have not power cycled the controller… don’t like doing that, I always lose the usb and have to remove and replace the usb connection.
When I set it for ‘continuous’, it chokes…
Stream completed in 0:00
$J=G21 G90 Y290 F60000
error:15
Jog target exceeds machine travel. Command ignored.
�
ok
?
<Idle|MPos:180.500,52.500,0.000|FS:0,0|Pn:R|WCO:0.000,0.000,0.000>
ok
I’ll power cycle it and see if that changes anything…
Upgraded to the 1.3.0… no ‘continuous’ option… 
Posted the issue…
https://forum.lightburnsoftware.com/t/anomolies-move-window-1-3-0-gui/79825
Hope I didn’t hose something…
Jack,
You are correct about smaller Y target. Also need to change F.
Tweak your continuous jog settings. Feed rate and target position exceed machine capabilities. F should not exceed your maximum velocity for any axis, and target Y should not be beyond work area. That Y290 should be smaller than $131. If you set 280 - I would use 279 as a target.
Your F=60K, with recommended by me settings, F command should not exceed 3K.
I believe these jog settings are in LightBurn machine specific settings. As I do not have one - you have to find it yourself.
Cycling power on JL1 while USB still plugged in will not lose USB connection as USB is powered independently from MCU. You should not fear cycling power of JL1 as long as it stays connected over USB.
I do not believe you need to cycle the power. All these settings effective immediately. You may issue soft reset command, if you are so cautious.
I think you mis understood my point…
I clicked on the move arrow in the Y direction while in ‘continuous’ mode.
This was generated by Lightburn, not me when I pressed the Y arrow button while in continuous mode. Both the controller and Lightburn have the maximum travel for Y set to 280.
Didn’t even think about the speed… it’s limited by the controllers maximums … isn’t it?
Am I? Continuous jog will send gantry to the very limit specified for the machine. It is not not really continuous, it is finite but can be interrupted at any time. Finite target point parameters for continuous jog still need to fit into machine capabilities.
Velocity will be limited by GRBL but as terminal reported - it cannot execute any coordinates outside of work space. You need to assure that Continuous Jog commanded within valid space, that jog command must be Y<280.
(like 279?)
F(eed rate) it is a good practice to keep within reasonable limits. If your machine specified 3.000 max, commanding 60.000 is asking for oddities.
LightBurn take that Y290 and F60000 from somewhere. I believe these are machine specific numbers.That place need to be updated to reflect realistic numbers for your machine. Maybe you need to restart LightBurn, not the GRBL. I can guess that application on start will pull GRBL configuration and use $130 and 131 and targets for continuous jog.
Try to restart LightBurn, after $131 set to 280.
I set the controller via the Machine Settings and apparently ‘spaced’ the device settings.
However the continuous jog generated this code
$J=G21 G90 Y290 F60000 – the Y max limit was set to 290
$J=G21 G90 Y0 F60000 – the Y max limit was 280
As I said it (both) was (were) generated by the same ‘up arrow’ with continuous enabled. The limit max is in the one that failed and the limit max is nowhere once changed… Something isn’t right…
Anyway, it seems to be working, although I’d be surprised if I don’t have some kind of engraving issue initially…
Just happy it homes (quietly) and jogs properly…
Thanks for the assistance.
Jack,
It’s being a few days. How’s this firmware treatin’ ya so far?
Have you discovered any issues?
Have you resolved Continuous Jog problem (not the firmware problem, but anyway)?
Been kind of slow the past few days… I don’t work if I am tired… it never ends well…
I’ll be back asap…