Short version:
Pausing + abort causes the G92 to reset but preserves G28.1
Long version:
Atomstack A5 M40 has no homing switches, it turns on and the origin is defined. I created a grid with offset and run a macro to set everything as soon as I turn it on:
G92 X-5.9 Y-6.7
G90 X0 Y0
G28.1 X0.0 Y0.0
Everything runs as desired until there is a soft (pause first) OR hard abort. The position immediately loses the G92 offset and reset to where the device was turned on (-5.9, -6.7). The screenshot below was immediately after a soft abort cutting a line at (10, 10). The last position is reading Y:+6.7 above where it should be!
Using “Go to Origin” will cause the position to return to starting location (-5.9, -6.7), NOT the macro defined G92 position. G92 always reverts back to what is was when the device was turned on. Here’s where it gets odd, G28 sends the laser back to the modified origin that was defined in the macro.
I created another macro to reset the G92 position using G28 after a reset, but I can’t believe that it was intended to have the G92 flashed but preserve the G28.1 position on abort. Perhaps this isn’t a Lightburn issue, but it might be a bug? - pretty please don’t patch out my G28 hack on abort because it’s the only way I can guarantee proper positioning without a full restart of the device.
PS I keep saying soft abort because the only other reports of something like this was resulting from aborting in motion and soft limits: Alarm: 3 Reset while in motion
LightBurn is in no way involved in the functioning of the GRBL firmware. A LightBurn bug would come into play if it was sending the wrong g-code commands for a given operation. Doesn’t sound like that’s the case here.
I’m curious what you’re trying to achieve that’s having you use this setup. There may be a different setup that’s less fragile than what you’re doing.
Incidentally, I’m not sure if G92 is expected to survive a pause->stop. I can see it for sure not working on a hard reset.
That would make sense if a G92 is not expected to survive an abort because it definitely does not. I guess I’ll just consider myself lucky that the G28.1 position remains after an abort with this controller.
I appreciate the help with setup, but I doubt there is a less complex option given the actual complexity of the layout and junk laser. Without homing switches, this Atomstack uses the start position as origin - for consistency, I always use the same corner. I used a honeycomb grid to easily coordinate my workspace, so I had to mount and align it to a position that the laser could reach with tolerance for over scan - that’s the G92 X-5.9 Y-6.7. The rest is making sure I can use absolute coordinates and return to (the new) origin - the 0,0 on grid - with ease and 1/10 mm precision.
It was a pain to initially setup, but now I’ll never need to manually align my laser to anything that fits on the grid. The only problem with this setup was learning that an abort resets the origin, so I ended up zapping my honeycomb frame a few times until I figured out the problem.
Unless there’s a way to override G28 and G92 in machine settings, I can stick to using one macro when first turning on, and now another macro to reset for any aborts.
I’m not sure if I follow. Do you mean setting user origin in the move tab by pushing the “Set Origin” button? If so, that doesn’t survive a device reset so I have to manually jog & set origin every time where the macro is just one click.
You could do this as a Saved Position or even a macro. The workflow would be similar with what you’re doing now and would not depend on controller function.
This would allow you to use the workflow of pause->stop that’s not working today.
