Position Wrong on version 9.21, 9.22, 9.23 but works on 9.20

[JTechPhotonics (Jay Johnson)]

We are running into a problem on getting our GRBL controllers to work for positioning on any version above 9.20.

Here is our GRBL version:

Settings:

If the machine potion is at the bottom left home and I restart LightBurn, it should show it at 0,0.
It instead shows:

In the console it shows:

Like there is an offset. If you look at the offset table it is all zero:

If I load 9.20 and repeat the same thing.
Load lightburn up and it is at position 0,0.
\

And it says work position is at all zeros.

I can get it to work in 9.20 but not in any after 9.21.

Is there something missing in my lightburn setup for getting this to work in 9.21 and above?

Jay

[LightBurn (Oz)]

That’s bizarre. In Edit > Device Settings, can you check the ‘Enable DTR signal’ setting? It should be off for anything Arduino based.

I can’t think of any reason why the two versions would report differently - that text is coming directly from the board itself, unfiltered, so that’s … confusing.

[JTechPhotonics (Jay Johnson)]

It is super bizarre. We are using the newest HEX file from the GRBL github site. Tried it with 1.1f as well and it still does it. I noticed this as well on some other customer machines when remoting in.

We have the enable DTR off.

If you want to take this offline, let me know.

Jay

[DougL (Doug LaRue)]

I’m running LightBurn v0.9.23(Linux) and have my Ortur sitting next to me running GRBL so I tested it for the problem and it looks ok. I still have the device controller set to GRBL.

@JTechPhotonics
You do not have Auto-Home enabled in LightBurn but $22=1 is set so I wonder if you’ve seeing the machine home properly on start yet still see those position numbers in LightBurn?

Waiting for connection…
ok
[AUTHOR: RenShen]
[BUILD: Ortur Laser v1.2]
[DATE:22:23:00 - Feb 6 2020]
[VER:1.1f.20170801:]
[OPT:VZD,35,254]
Target buffer size found
ok
Homing
ok
ok
<Idle|MPos:0.000,0.000,0.000|FS:0,0|WCO:0.000,0.000,0.000>
ok
<Idle|MPos:0.000,0.000,0.000|FS:0,0|Ov:100,100,100>
ok

[JTechPhotonics (Jay Johnson)]

Hi Doug-

We are using the versions off the github GRBL site here for the Arduino UNO:

Releases · gnea/grbl

The Ortur build might be different as it is the 32bit LPC version.

Jay

[DougL (Doug LaRue)]

Hi Jay, just so you know, I don’t work for OZ and just trying to help out as he and his guys are swamped now with bugs which showed up in the latest releases. I don’t know the details of how LightBurn gets its position information from the firmware but I wouldn’t think that would have changed much so I’m hoping we can pinpoint where things go wrong and if something can be repeated so they can test and fix if it’s in the software.

I would imagine they are probing GRBL for position information and displaying it so maybe we can find out what’s showing up differently in versions after 0.9.20. Using LightBurn v0.9.23, when you see the incorrect position in the GUI can you go to the Console tab and enter $H and be sure it moves and triggers the homing switches? Then enter ? and check to see if you see something like this or some other coordinates:

$H
ok
?
<Idle|MPos:0.000,0.000,0.000|FS:0,0|WCO:0.000,0.000,0.000>
ok
<Idle|MPos:0.000,0.000,0.000|FS:0,0|Ov:100,100,100>
ok

[JTechPhotonics (Jay Johnson)]

Hi Doug. Appreciate you trying to help out here.

When we do the homing sequence the position doesn’t change the output.
I have it set to $10=0 which will be work position. If I press the get position it shows.

Just sending $H will home the machine and say:

Not sure what it is. I’ll try some different Arduinos on Monday.

Jay

[LightBurn (Oz)]

Jay - The difference between 0.9.20 and subsequent releases is that 0.9.20 had a bug in the handling of the DTR - it was always enabled. I can’t understand how / why that would cause what you’re seeing, but it’s about the only thing I can think of that’s changed.

Arduino based boards use the DTR line to reset them, so having it on will reset the chip. Some boards use the rising signal edge as the reset trigger, and some just hold reset until it’s released (Arduino Mega does this).

I don’t understand how that would affect the reporting from the board though - that feels like a GRBL bug.

Having said that, you should actually be showing a WCO equivalent to the $130, $131 values, which would move the origin from rear-right to front-left.

If your “Get Position” report is happening from the front-left of the machine, and you don’t have a WCO programmed, that output is actually correct.