I need a water pistol to shoot myself. The latest vesions have screwed grbl for me

I have wasted too many hours today and since .12 arrived on this and one hell of a migrane is setting in now.

Highlights so far:
Settings will not save correctly.
It is reading/intepreting settings wrong.
workspace settings are totally messed up
on the Move tab the direction arrows now send the head in the wrong direction

When I first power the machine up (after being off overnight) I ask it to home, off it will go then if I check co-ord it is reporting as X0 Y0 instead of X-326 Y-1 (rear left of work bed) so I can not send it to origin at the real X0 Y0 (rear right of bed) I have to load settings and mess about untill it sorts itself out and reports the correct co-ords then I can try and work untill it starts giving me error 2 part out of bounds even tho its well inside the working area. ALL of the other software I use does not do this after a cold power up so this is a Lightburn problem

thats when I noticed that the travel direction is ares over tit. press left arrow and the head moves right press forward and it goes back. ALL of the other software I use is correct so this is a Lightburn problem.

as for saved possitions thats a full on laugh. as far as I am aware cnc routers work in negative area because they remove material so co-ords are X-32Y-54Z-15 etc etc. 3D printers work in positive work area as they add material and their co-ord are mostly positive X32Y54Z15 etc etc but there are a few oddballs like ctc that use pos and neg co-ords, Now we have Lightburn that technicaly should use negative since it is burning/engraving/removing material and it can use neg and pos co-ords that is untill you try and use the - and it refuses point blank to let you enter a co-ord after it so impossible to set a -320 as a saved position on the Move tab. a bug that may get fixed at some point.

There are other things that I can not think of at the moment beause of this brain ache but PLEASE PLEASE PLEASE fix these because if a noob comes up and learns how to use this as it is then they get fixed it will confuse them even more and prob cause them to gve up or slate this (normally great) software to ant future users…

I am going to have to dump and run back to eariler versions that worked correctly

There were a few issues with .12 and have since been resolved with the .14 release. I recommend updating to the .14 release which is the most current. :slight_smile:

LightBurn uses positive workspace coordinates - this is very well documented all over this forum, our documentation, etc. I send this link about a dozen times per day: https://github.com/LightBurnSoftware/Documentation/blob/master/CommonGrblSetups.md#common-grbl-setups

Regarding the settings, LightBurn does not change those unless you edit them, so the travel directions and such should be no different than before. It’s possible that because your origin isn’t correct and the machine is in negative coords that the software is trying to send you back into positive space, and going the “wrong way” to you.

LightBurn was designed for dedicated lasers, not CNC machines, so things might work a little different than you’re used to. I suspect it’s not the software that’s wrong, but something in your machine config. You might have $J jogging enabled, which requires positive workspace to work properly because it is designed to keep you within the travel limits of the machine, and if you are using negative space that would cause trouble. The $J jogging is relatively new (probably 0.9.12) so that might be where some of this started.

Oz in .11 everything seemed to work as I expected but as you said things have changed a bit with the newer releases and this is where the problems started. I have already pointed out a grbl bug in .13 and have been informed they will try and sort it out, this bug has cropped up in prevoius builds then had to be fixed before. I think this latest one in .14 is related to the reported bug in .13 about how the setting for invert limit pin signal seems to try and set it for individual axis but in grbl it is for ALL axis unless a custom build is hard coded to invert independant signals, so X is marked as inverted but Y is not and this may be why it is confusing itself. both X & Y should be the same but it is not correct on Y & is correct on X if you can see what I am trying to say and no matter what Y is set it just wants to ignore the real setting and use the false setting that it is getting saved and read by LB.(A thought I have just had is maybe as it is true or false for both axis at the same time it might be acting as a toggle ?? X ($5) invert limit signal is setting it to true then Y invert limit signal ($5) is setting to false but I do not think setting $5=1 and then $5=1 again would result in $5=0 ??? I think the Invert setting was mis-interperated as a mask setting instead of a true or false setting by whoever helped on the grbl code.

P.S Sorry for the rant Oz it was just a bad day when it all went in the wrong direction and the K40 started it by going in the wrong direction even tho it worked sweet 2 days earlier and NOTHING was changed. My K40 has it`s own pc setup away from my other machines so I know noting was changed as Only I have access to it.

Grumpy_old_Man I was on .14 thinking that the bug I reported in .13 was fixed but .14 seems even worse and still has the bug I reported in .13. I guess grbl is bottom of the pile when it comes to fixes as support is patchy at best on the good ole internet for anything hacked up grbl related (before anyone raises the pitch forks and wants my head I said the internet NOT here on the forum)

Slap to the head time again.

the 1st bug I reported in .13 was if $20= (soft limits) was set before $23= (homing) is set it fails to write back to the controller. now because of this bug I manually had to reconfig the controller when I changed from Rotary setup (no homing & soft limits) back to the settings for general flat area work, as I just load the saved profile then write to the controller (the easy way to save time but as of .13 bugged up and not working) and since I have only used grbl for a year or so I totaly forgot to adjust the offset to use front left as origin x0 y0 (thanks Oz for the reminder) and $32 laser mode. I was wondering why I burned clean thru a bit of acrylic 3 days ago. I left $32=0

Since there are 2 bugs still to fix grbl related in .13/.14 I am back off to .11 to try and get todays workload done, 6 hours late.

The settings issue for $5 is fixed in 0.9.15. We’re going to change the order of the flags ($20 and $23) so they don’t cause issues too. I’ll actually do that right now.

Thank you Oz
I have been hunting .15 and find no sign so I take it you have not compiled it yet so both grbl bugs should be fixed.

Again thank you for your quick reply and help.

I have a small cnc mill that I make prototype pcb`s on and it has no homing or limits of any sorts and I have used it for years on grbl but this k40 grbl laser with limits and work area sizes has just confused the hell out of me that I am to the point of turning off limits and homing and using it like I do on the cnc mill

Another possible bug.
in Machine settings changing Status Machine Reporting $10 from Mps $10=1 to Wps $10=0 seems to do nothing after a save and a save and reboot/power off the controller it still stays at $10=1

Please get this one verified

Chris

If you enter that command in the console and GRBL says ‘ok’ then the value was accepted. Type $$ to verify that it took. If you reset the controller and the $10=1 value has returned, it’s the controller doing it, not LightBurn. Some companies set their GRBL versions to force a specific set of parameters on startup so things work properly with their stock software, but it messes up others. I hate that they do this, but it’s out of our control.

Yea thats what I had to do to actually get $10 to change and stick, I just though as it was an option in the settings that it would have applied it when written to the controller but it does not write it at all. it says it has done it but alas no apples. only when I entered it manually it make it work.

I’ll double check to make sure this works, but I was in that code last night fixing the other part (the $20 / $22 dependency) and had no issues with any other settings.

I have just tried it again and it will not change from the machine settings. change to mps and write to controller , it reports as written ok then click read and it changes back to wps

I am on .14 again and getting closer to getting it working as expected but now home works fine but origin causes error 2 and locks the controller and in co-ords home is now x0y2 and the y direction arrors are opposite. I am close to turnig homing and soft limits off and using it in chinese cheapo diode laser mode.

My controller board is an MKS DLC v2 cnc controller (Arduino nano based) and I also test with a cheapo chinese controller that had a hacked up grbl 1.1z (hacked and slashed grbl that was crap and crashed like crazy that is also Arduino nano based)

I have been thru my grbl source (& recompiled it, flashed it to the controller and defaulted the settings so it is starting from fresh justin case it had any corrupt data). I need to use a custom flavour of grbl on my k40 as it has a few quirks to work around. there is nothing in the 2 lines of startup code. I have adjusted the homing to only X & Y axis as my K40 has a fixed but user adjustable bed, I have to split pwm from laser on (spindle enable and invert the signal) because the K40 psu needs a 0v signal to enable the laser fire. I have an active door switch to kill the laser if the door is opened. I also need to invert the limit switch signal as my K40 has optical switches and not good ole mechanical ones.

Home is rear left as you look at the bed and is located at x-325 y-219. Origin is at thr rear right and x0 y0 giving me negative work area. when I apply $10=0 (to get into WPos) G10 L2 P1 X-325 Y-218 for the offset to force positive work area home (rear left) is now x0 y0 and Origin crashes the controller so I guess I can no longer press the origin button but it is in positive work area so LB seems to be happier.

I have made 2 custom macro butons for if I need to use other software that uses negative area.
Button 1:
Enable LightBurn Co-ords (with 2 lines of data)
$10=0
G10 L2 P1 X-325 Y-218

and button 2:
Disable LightBurn Co-ords (with 2 lines of data)
$10=1
G10 L2 P1 X0 Y0

Now I can jump between either just as the grbl help file explains.

Whilst reading back thru my grbl source there is a compile time define to force/set home as origin so I was thinking that maybe that would do the same and force it into positive work area but since I seem to have the k40 running as it was and should I will not try it unless it goes all tits up.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.