I just ran the attached file. The time remaining hit 0 when the time cutting was at 85%. This is not the only file that this has happened. I reported some others in the SLB category, but now that I’m more confident that it is a gSender issue and not an SLB one, I thought that I would post this particular file here.
1-.25BN_3D Roughing 1.gcode (199.6 KB)
@gwilki it could be a combination of a gSender and SLB issue, have you tried to run the same file on your test Arduino running grbl?
@chrismakesstuff I wish that I had thought of that. 
I ran the same file on my test Uno using 1.4.1. (The most recent version that I had on my test PC.) I didn’t let it finish. I just wanted to make sure that all was well. I uninstalled 1.4.1 and installed 1.4.4. I tested outline first and it ran fine. I then tried to run the file. The bit rose in Z, moved the right front corner and froze there. I waited. It never moved.
I uninstalled 1.4.4, re-installed 1.4.1 and the file ran fine. I un-installed 1.4.1, re-installed 1.4.4 and the file froze immediately again.
I tried to output the diagnostic file, but that failed, too.
I have not tried 1.4.4 on the SLB yet.
I’m attaching the last 50 lines from console.
50_line.txt (485 Bytes)
Here is a screen cap when it fails
@chrismakesstuff I just ran the same file on the SLB, running 1.4.4 and it ran to completion.
However the run time function is unchanged from 1.4.3, it appears.
Specifically, this file ran for a total of 11:32, running at 200%. At 4 min, it showed 11% complete, but only 4 min remaining. At 6 min, it showed 24% complete, but only 2:30 remaining. With 0 time remaining, it showed only 75% complete, with 2300 lines left to run.
I ran the same file again, with no override. This time, when it was 100% finished, the count down timer showed 8:31 left. It froze that way for a couple of seconds, then changed to 0.
I know that his has been reported before but as the most recent report was closed when @KGN said that this was fixed in 1.4.9, I figured that I would start a new topic.
I am running 1.4.9 on the SLB and a LMv1. CAM is VCarvePro 12. Post is grbl mm
Today’s file was a series of 6 pockets, all the same depth, but different square inch sizes.
At run time of 95%, the job had run for a reported 31 minutes but showed 43 minutes remaining.
At run time of 100% or about 36 minutes, the time remaining was 38 minutes. There was actually only a few minutes left in the file.
The run time kept running after it showed 100%. It stopped at 37 minutes. The time remaining stopped at the same time with 37 minutes still showing.
The actual run time of the job was 40.09 minutes, as reported by gSender at the end of the job.
Same issue. Went back to last working edge version that i was using. Seems to be reliable for me.
Since my previous topic has been closed, I thought it was better to start a new one than to re-open that one.
I am attaching the gcode for the toolpath in question. At 50% run time, gS showed 12:28 cutting time and 23:38 remaining. (I would have thought that, at 50%, those two figures would be the same.) This was at 3:39pm my time. So, if the 23:38 was correct, the job should have finished at 4:02pm. gS reached 100% run time at 30:04 cutting time. The job was still running and gS showed 13:17 remaining. All the counters stopped there. The job kept running until completion at 3:59pm.
The job is a series of profile toolpaths from VCarve Pro 12. There are no 3D toolpaths.
I am running the SLB on a LM Mk1. Firmware is 5.0.3.
2-.25 roughing.gcode (29.5 KB)
Edit: New day, new file
At an indicated 50% , the run time was ~7min. Time left was ~15
It never reached an indicated 100%. It froze at 99%. At that point, the lines run and left to run froze at 754 and 4 respectively. The cutting time was still running up and the time left was running down.
The actual run time was 22:33.
Here is the gcode file.
2-.25DC_finger-pocket.gcode (9.0 KB)
I didn’t touch the feed rate slider on either of these runs.
SLB 5.05b
gSender 1.4.12
At some point in the gSender life cycle, the countdown run time clock ceased to be of any real use. Just now, for example, it showed a 10 minute job 50% finished after about 2 minutes run time. This time, though, I was watching the visualizer and noticed something that I had not remarked on before. When the yellow lines covered the end of the project, the timer showed the job was 100% complete. It was not.
It appears to me that the issue is that the time remaining is reading the “look ahead buffer” or whatever the yellow lines are showing. The timer is not reading the time or percentage remaining from the line that the machine is actually cutting.
Could this be what is going on?
Edit: Here is a screencap of a similar project. You can see that the yellow lines are at the end of the toolpath. The readout shows 100%. In reality, there was more than a full minute’s carve to go.
