I seem to remember finding a thread on this when I wasn’t looking, but every now and then after a job LaserWeb thinks it’s in a different spot and I can’t find the thread again.
Machine is a K40 with Cohesion3DMini running GRBL 1.1. I had this problem now and then when running from a Windows PC, but it’s happening a lot more frequently running it all through a Raspberry Pi and latest LaserWeb version (connecting through Laserweb latest on Windows PC).
It’s not all the time, but I haven’t been able to put my finger on a constant yet. Thankfully this is a personal job for myself, 4x4" slate coaster. I mark the center of the coaster, line up the laser and run it with the graphic centered around 0,0. It’s happened with jobs not encroaching into the negative too.
This one just finished and after the very last part of the burn jumped here. X=-10.04 Y=3.89. Doesn’t seem to jump in the same direction or the same amount either time. The physical laser head is sitting where it should be. Top middle of the design. There’s nothing in my gcode that is causing it. But for now I think I can power down my steppers, tell LaserWeb I’m at the last G0 location and then power the steppers back up for repetitive jobs.
@Ariel_Yahni_UniKpty - I tried changing my offset to a few different values, it really throws my bed off. I don’t think this is it because every time my job is done it decides to send the laser in a random direction it seems. Thanks for the suggestion though!
@Todd_Fleming - Yes, I’m on Frontend: 4.0.989 & Backend: 4.0.115 for both the Raspberry PI and on Windows. Thanks!
@cprezzi - That worked, thank you! Now when a job completes it stays put. However when I stop or cancel a job it must send the M2 and it loses its’ place. Any thought on how I can stop that? I’ve looked in settings and tried finding some sort of a configuration file to no avail.
Why do you think it must send M2 to stop a job? The stop button of LW4 sends ! (hold), clears the gcode queue and sends ctrl-x (reset), so no M2 is needed.
Instead you can add a G0X0Y0 (or whatever location you want to use) or do a homing ($H).
I just figured that taking out the M2 fixed the random movements at the end of a successful job so maybe that’s what a stop might do as well.
When a job ends properly, it stays where it’s supposed to. I can hit “Goto XY Zero” and it goes perfectly back to where I started. If I abort or stop a job early however, let’s say I need to adjust my piece, it sends the laser to a random position in Laserweb while the laser in the machine is where it stopped. If I Goto XY Zero at this point, I’ll usually crash my head because Laserweb thinks the laser is somewhere it’s not - usually +X and +Y but not all the time.
Ooooh. I didn’t notice the part at the top where you said you’re running grbl-lpc. Both M2 and ctrl-x load the work offset from whatever happens to be in Flash, which is a bit hard to predict. When I ported grbl to LPC, I disabled the code which automatically saves the work offset to flash whenever it changes because that would quickly wear out the memory block.
@Todd_Fleming Ah ok, that explains it.
I think we should enable that code (as in Grbl). The work-offset doesn’t change as often, and the LPC176x spec tells a flash endurance of typ. 100’000 write cycles (same as ATmega328P’s EEPROM).
