Job summary difference, Windows vs Linux

I’ve been running Sheetcam on my plasma table for about 3 years now. I’d largely given up on the Job Report summary, as it was very inaccurate in the past when I used it (Windows). I’d never used the summary on the Linux box, since I’d lost faith in it with the Windows version.

However, the other day I tried the Job Summary report on the Linux machine, and compared it against actual cut times. It was very, very close!

If I take the same job, run the Job Summary in Window (6.0.28), and then run the same job file in the Linux version (6.1.57), I get two completely different numbers for Job Time! Even if I have the same variable set (4 sec pierce delay, 600ipm rapids).

Here’s a screen shot of a job summary report from Win 6.0.28 version. Note the Job Time of 121.06 seconds, which is completely out of touch with reality. The same file (opened from the network drive) in Sheetcam Linux (6.1.57) Job Report has all the same information, EXCEPT job time. The Linux version lists the job time as 461.06 seconds. That’s VERY close to the 459 seconds (7 minutes 39 seconds) I timed on the ACTUAL cut!

All other information is the same (tool changes, cut distance, cut time, rapid distance, etc). The only difference is the Job Time, which would be cut time + rapid time + pierce time, I would assume.

This has me VERY excited! It seems the job report function in Linux 6.1.57 is accurate! That completely changes my ability to quote cut times, WITHOUT having to cut a test part first!

That being said…why the difference in job time out put in the Job Summary, in Windows vs Linux versions?
sheetcam job summary.JPG

Job reporting was revised in the development version a while back. The Linux version is the dev version.

If the Linux version is the dev version, then why are there two Windows versions? I understand having a stable version and a test version, but why not do this with Linux?

The stable version code won’t build under Linux without considerable modification. It is also a lot of work to maintain and test releases. Having Linux stable would mean maintaining 2 more releases (32 bit and 64 bit).
When the current dev becomes the new stable I’ll look into this again.

I use the Windows version, but it seems like the dev version has quite a few differences that haven’t made it to the stable version yet. I’ve had several new stable updates, but some of the dev stuff that’s been there for a while still isn’t included.

At some point next year dev will become the new stable and I’ll start a new dev. This should have happened months ago but there have been a few hold ups.

Okay. Thanks for the info. Have a Merry Christmas.

Gotcha. What are the (realistic) risks of just jumping into using Dev now, vs stable?

Lots of people use it for production. It has been pretty stable for quite a while now. The next release will have a new path planner though. I have a few people testing it with no issues so far.

I use dev version every day with no problems at all, get it loaded up :laughing: