Just wanted to add that I had the same issue.

Had about 34k lines of code, paused and iosender jumped back to line 1 after starting again. That happen somewhere after line 30000.

But I didn't take any screenshots but could upload the gcode upon request.

I'll try to replicate this.
On your end can you try the latest edge version - it could be that the issue has been fixed already.

grblHAL has also been recently changed related to cycle start signalling, but this is only relevant if a button is connected to the cycle start input and the job is (re)started by pressing it.

I was able to reproduce it right now again with EDGE 2.0445p7 EDGE.

And because you mentioned it - yes, I pause and resume with a button / hardkey that is attached to the flexi (I use drew's button breakout board).

Ok, I was not able to reproduce with the latest grblHAL build with a STM32F7xx board, so this could be a controller issue.
Which grblHAL build are you using (Help > About)?

I am using this one
https://github.com/Expatria-Technologies/STM32F4xx/releases/tag/flexi-hal-v1.0.0.2.

In order to reproduce it, you need to let the gcode run quite a bit. When I reproduced it right now, pause/resume worked fine the first 20min, but then after a while - after several tool changes - it just restarted the whole job.

I let it run to completion and did several feed holds/cycle starts with ioSender buttons. I did not try using buttons connected to the controller.
What could be interesting is the output from the $LEV command (last events) after failure, I suspect that somehow reset is triggered by the cycle start signal.

ok, will try to reproduce it again and then do $LEV .

Actually my pc was still running after I hit STOP (after I reproduced it).

The output of $LEV is:

[MSG:]
[MSG:]
[MSG:]
[MSG:]
[MSG:Stop]
$LEV
[LASTEVENTS:H,,,,]

Update: reproduced it again, but this only happens with the hardkeys / the button breakout board. The Iosender softkeys do not seam to trigger this behaviour.

This time "$LEV" gave me
[LASTEVENTS:S,,,,]

I have uploaded new edge versions (p8) for you to try.
Note that there is a "bug" in the controller as well, but this only affects tool change mode 'Normal', $341=0. A fix for this has just been committed.

I have uploaded new edge versions (p8) for you to try. Note that there is a "bug" in the controller as well, but this only affects tool change mode 'Normal', $341=0. A fix for this has just been committed.

fix pulled in here:
https://github.com/Expatria-Technologies/STM32F4xx/releases/tag/flexi-hal-v1.0.0.4

I downloaded and tested the p8 build, and I could not reproduce THIS issue, but I ran into something else / new:

I was trying to stress the system with several pause/ resume interactions (all with the button breakout board), and after a few attempts the machine would just refuse to resume again (this time I hit pause when it was rapiding to the tool setter)

As you can see in that video, the status is "feed hold", and the "START" button is correctly "read" (according to that red icon), but it just wont resume.

No idea if this is related to the p8 release, but this is the first time I see that.

https://youtube.com/shorts/m2uHNIcC8ac?feature=share

Hello! I was linked this thread by Sebastian and this same thing happened to me today. I had a file with 3 or 4 tool changes (total length of the program was only 3 or 4 minutes) and I hit pause on my Jog2K. I let the program sit paused for about a minute while I verified the next toolpath in Fusion making sure I would clear my fixture. Once I hit play, it continued the cut for about 10 seconds, then raised to zmax, waiting for me to press Cycle Start. Once I pressed Cycle Start, the tool touche off on my tool setter and the program was restarted.

I don't have a screenshot of the incident, however the line that it stopped on was a simple X move command. It didn't show a warning or anything.

Just chiming in to report I found this bug as well, many times this morning.

Versions:
Jog2K FW: 1.0.4
FlexiHAL FW: 0.9.9.8
IOSender Version: 2.044

I was doing an op with four toolchanges this morning and was pausing frequently to doublecheck that my new probe setup was behaving correctly. The first time it happened I didn't realize what was happening - it restarted a facing op partway through. Since it didn't stop to ask for a tool, I just figured it as a fluke of my post-process file. Later on in the op, on a chamfer, it did the same thing.

The behavior seems roughly this: upon pausing and resuming (from the Jog2K), it will execute a few more lines of the code. The amount of code it executes varied by op for me - it did 3 facing stepovers after pausing before restarting, and it did 5 moves (a mix of linear and arc cuts) on the chamfer step before stopping, raising to max Z, and asking for a toolchange, It had started the code over and wanted me to load the flat endmill for the facing op again.

Later on in the recovery op, I was able to recreate the behavior partway through the first chamfer. Like the facing op, since there was no toolchange involved, it just rose to Zmax, and started the program over again.