LM 2.5, SLB. Pocket test cut: 9”x3”, 1/4” endmill, 4 passes at 1/8” depth/pass. Practicing Pause/Stop/Restart for an upcoming long job.
gSender says 309 lines for the job, so I would expect about 77 lines per each 1/8” deep pass. Visualizer showed no. of lines cut increasing as the tool made its cuts - all good. Got part way through first depth pass, then Paused then Stopped the job. Back to XY zero. Visualiser (both the rotating image and the Restart function indicated job stopped at line 170. Seemed strange, since I would have expected it stopped at around line 60 or so, but…I restarted at line 160 as per machine info. The ACTUAL cut on restart was much deeper than the first pass depth and seemed to be close to half way through the full 309 line job, but nowhere near where I actually stopped the job. Would appreciate some help. Thanks
@Retiree FWIW, I can’t replicate your problem.
In VCarvePro, I created a 9 x 3 x .5" deep pocket. I used a 1/4" endmill running 4 passes to cut it out. You didn’t state your stepover. I set to 40%. I ended up with 295 lines per gSender.
I ran the job on my test Uno to line 73. I paused, then stopped. I returned to XYZ0. Opening “start from line”, it said that I had stopped at line 73 and recommended that I resume at line 63. I did that and all looked good.
If no one else can replicate your issue, you may want to open a support ticket with Sienci. You can send them your gcode and your gSender diagnostic files. I’m sure that they will be able to help.
Grant - your replication effort worth a lot - thank you for taking the time. Same S/W (VCPro 12.506), same cutter, same S/O. I will attribute difference in no of lines to the fact that my dimensions are actually 3.75”, not 3”. So, we are in sync on this. Your results are what I expected. The other thing I noticed is both V/Pro and gS time estimate for the job at about 24 minutes. I do not believe it. Scaling Factor at 1.0. The gS animated progress bar was also completely out of whack re reality. I will speculate that there is some corruption in my S/W somewhere. I will contact Sienci Tech Support, as you suggest, and will provide an update.
Opened ticket. Tech Support person and I exchanged a number of emails, and finally spoke. They did not understand the problem, provided irrelevant and erroneous information…Finally passed me on their supervisor - MUCH better. Some back and forth constructive emails. Provided info that gwilki not able to replicate problem.
As instructed, upgraded from gS 1.5.0 to 1.5.6. Asked and was told that gS update notification not currently activated. Also, Z probe sequence with earlier version resulted in a Z of 7mm, but with new version it is 15mm. Did anyone get a notification of these changes? Am I missing something?
Back to main issue. Tried a different job and toolpath, with 75 lines - on Start, indicates at line 73 out of 77. Set up an old, successful job with 69515 lines and on Start, indicates at line 135 out of 69515. All test info passed on to Sienci. Their current thinking is a bug in gS. I await next steps from them. Will provide update.
Sienci indicates no S/W corruption since I successfully upgraded the gS version. They were able to replicate my issue (I am reassured). “Typically, it won’t start at line one because there is information at the beginning of the toolpath that isn’t movement-related, that counts as lines of code”. Good to know, but what is the practical approach to manage the situation? Other than restart at zero if a small job, not suggestions.
So, my thinking at this point is that the large discrepancy in lines of code information is most pronounced at the beginning of a job or for a very small one. The discrepancy SEEMS to reduce as one gets into larger jobs, ie., tens of thousands of lines of code. Sienci has not indicated if they will do anything about this.
Also, I raised the issue of the time and time to job completion information displayed on the visualizer screen being significantly different than real time (I had posted a thread on this earlier and some of you folks provided some useful suggestions on the reason and adjusting the scaling factor, however, the level of adjustment is based on experience - which I do not have). I suggested to Sienci that they take the same approach as the ETA on car navigation systems - they continually adjust the ETA based on history and prediction. Again, no indication if Sienci will do anything about this.
I don’t know how the newer gsender indicate times, but my ancient version can, when starting long jobs, indicate days of time, but it will eventually fall down to more reasonable times. On those jobs, vectric and lightburn do a great job at indicating runtimes, and after some movement, gsender gets there too. So I believe it is constantly recalculating runtimes with it being waaaay off at the start of long jobs.
Not that I care much. It takes as long as it takes.
On the other issue, I simply have no idea, I have never started a program from any line other than zero.
My recent experience for a 2.5D job. Vectric and gS both indicated 2hr, 2min estimated time. The Animated Progress Bar (APB) on the gS Visualizer started at 2 hr, 2 min to completion. So far, so good…
As the job progressed, % cut/remaining, and time on the APB were accurate relative to each other, however, REAL time, as per Windows and my wristwatch, was significantly different. At job completion, the APB indicated just over 2 hours, but the REAL time was almost 3 hours. This is the area I have an issue with. I think it would be far better if gS were to use REAL time to calculate cut completion timing after starting and adjust as the job progresses.
On the other issue, I have some long jobs at estimated more than 10 hrs cut for a toolpath. I need my beauty sleep, so must stop the job part way through and restart on the next day. Also useful to have the experience if there is a power outage part way through a job.
@Retiree If you know you will want to break up a long job into smaller ones, there are several techniques you can use other than stopping the job.
Three that come to mind:
Define bounding vectors and then do separate jobs for the area inside those vectors
Use the Tape Splitting feature of vCarve. Search this forum on how to use it.
Use a script that will break a large g-code file into smaller ones. A user in this forum has done that but I’m not sure if he published the script. There are likely plenty of similar apps out there.
With long jobs, you probably don’t want to have too long of a pause between sessions. Any wood movement caused by humidity and temperature changes would become more apparent.
@Retiree Also, when you stop a job and reload the file, there is a “Start from” button that shows up. Clicking that will tell you at what line the job stopped the last time it ran. Not sure how accurate that is. I used it once and it was so-so. But I wasn’t really paying attention.
Agree re wood movement as an issue - have experienced. Will do some research on your suggestions to break a large job up into smaller ones.
“Start from” line INaccuracy is what started this thread. It was WAY off reality, and I would understand (accept) if it was understated but in my case, several tests indicated significantly overstated, and on restart, I was many lines ahead of stop point.
I am getting the sense that the best approach is to do a job completely from start to end, despite Sienci’s features to pause/stop/restart. If they have this feature, surely it should work reasonably accurately.
Inaccuracy of cut line information. In my limited experience, not an issue with large jobs and restarting (with backup of about 10 lines or so) well into the number of lines. No interest in addressing.
Time of cut display. Sienci response is that time estimates are a work in progress. I do not get the sense that they understand that my issue is not the initial estimate, for all the reasons indicated in this forum, (would certainly be nice if they addressed this, but not critical, IMO), but the display of time while cutting is not based on real (Windows and my wristwatch) time.
Based on latest response from Sienci, they do understand the issues I have raised. Given all the other work Sienci has underway, these items are not a high priority at this time. They indicate they have initiated a new series of videos to provide more documentation/explanation on a number of gS features, which I believe is a good thing. “These tutorials will be ongoing releases”. I do not plan on providing any further updates. Thanks to all.