Hello Guest it is March 28, 2024, 09:30:20 AM

Author Topic: Painfully slow path display on large programs.  (Read 3660 times)

0 Members and 1 Guest are viewing this topic.

Painfully slow path display on large programs.
« on: May 24, 2018, 06:02:31 AM »
As soon as I saw how slowly Mach4 processed my smaller profiles, I could see that there was a serious performance issue looming for more complex 3D machining.

I've just loaded a program that takes about 15 seconds to display on Mach3 and it's just finished after 3 minutes on Mach4

When you're finish machining anything in 3D, you're going to have massive tool paths because the overlap between cuts needs to be very small in order to get a decent finish.

The same issue occurs in the speed of response when starting part way through a very long program. To be fair, this isn't as important, it's something to be avoided because it's frankly dangerous in my experience. However, there's no indication that it's doing anything while you're waiting, I thought the system had crashed. It would be a good idea to at least add a progress bar or something to indicate it hasn't died during these operations.

Can someone take a look at how the video is optimised and speed it up?
« Last Edit: May 24, 2018, 06:10:54 AM by striplar »
Re: Painfully slow path display on large programs.
« Reply #1 on: May 24, 2018, 06:35:06 AM »
Hi,
I use a copy of wx4.set and that does have a progress bar. There is an API that would allow you to have a progress bar:

Quote
percent, rc = mc.mcToolPathGeneratedPercent(
      number mInst)

I have a very low powered PC as my machine controller, a dual core Atom MiniITX board. It can take several minutes to load and display a tool path for a largish file, 5MB.
If I understand a lot of 3d finishing paths could be tens or even hundreds of MB, my little Atom would be hopelessly outclassed. smurph has made the comment that the load an
initial draw are very processor power dependent.

With Mach3 I always found that my machine would stall, often wrecking the job in progress, when or if a screen redraw was required. I have not found this to be the case with Mach4,
even my little Atom seems to keep up with machining despite redraws.

Craig
'I enjoy sex at 73.....I live at 71 so its not too far to walk.'

Offline Stuart

*
  •  311 311
    • View Profile
Re: Painfully slow path display on large programs.
« Reply #2 on: May 24, 2018, 07:27:49 AM »
To Op

What other programs were you using while mach4 was loading ir file

I have read elsewhere that you like to stream vidieo and generate large 3D toolpaths whist mach4 is running your sub micron res mill

Could that be the reason for the poor load times due to the pc resources spread to thin

IMHO 8 gig of ram is to small for a win 10 pc , and yes I do know a little bit about computers having designed and built on in 1975 era
Re: Painfully slow path display on large programs.
« Reply #3 on: May 24, 2018, 08:06:25 AM »
Stuart,
You think 8 gigs of ram is to small for Windows 10? 
Chad Byrd

Offline Stuart

*
  •  311 311
    • View Profile
Re: Painfully slow path display on large programs.
« Reply #4 on: May 24, 2018, 09:45:23 AM »
Yes

I have a dell optiplex as my mill controller with all the unused bits removed eg cortana,update functions , and ssd sleep disabled , infact all energy saving sleep functions are disabled , though Gpedit as it a 64bit pro w10 , yes I think I am correct that Mach 4 is a single thread 32bit program ,but I will stand corrected on that.

Now my take on 16gb af ram
I had 8gb installed it was sluggish on startup and load times increasing the ram to 16gb reduced the boot time by half mach4 loads in 4 secs that includes getting the Ethernet SS up and running .

I did notice I was getting some page outs at 8 but not at 16

But note that’s all the dell does is control the mill ,

I use a iMac for the CAD/CAM stuff and that’s in the house , but note I am a hobbiest and do not earn my living from my workshop
Re: Painfully slow path display on large programs.
« Reply #5 on: May 24, 2018, 10:07:16 AM »
I generally have pretty decent luck with computers I put 8 GB Ram in.  I was having issues with a lathe that kept crashing Mach4, switched out computers to a new processor and 8GB Ram and it seemed to fixed the problem. 
We are trying to find a reliable set up to use Mach4.  I will try 16 GB Ram in a mill we have that runs a little slow and see if that helps.
Chad Byrd
Re: Painfully slow path display on large programs.
« Reply #6 on: May 24, 2018, 03:36:54 PM »
The program I tested it on was nowhere near the biggest one I have, but even this one has 265268 lines of G-Code.
My PC is a Quad Core 3GHz AMD Athlon 640 processor with 8GB of RAM so it's pretty fast really. The 3D modelling program takes about 15 seconds to load the same program and display the tool path, compared with 3 minutes for Mach4, so there's clearly plenty of room for improvement in Mach4 with the same processor.

Maybe a 64bit version of Mach4 would be quicker but I doubt it would make much difference unless it's multi-threading. I think the biggest gains are likely to be in interpreting the raw G-Code file more efficiently.

Another think I've noticed about the MachMill screen set is that it doesn't update the tool path if you change the DRO
Re: Painfully slow path display on large programs.
« Reply #7 on: May 24, 2018, 04:40:12 PM »
Even in Mach3 I had to hit the "regenerate toolpath" button if I updated my work offset.
Chad Byrd

Offline smurph

*
  • *
  •  1,544 1,544
  • "That there... that's an RV."
    • View Profile
Re: Painfully slow path display on large programs.
« Reply #8 on: May 24, 2018, 04:53:06 PM »
It is not a 32 vs. 64 bit thing.  It is a processor/memory thing.  Mach 4 does things differently than Mach 3 did on the file loads.  The capabilities of the interpreter are far more advanced and requires a LOT more switch code.  Thus it does take more processor power to generate the tool path.  The newer builds will be an improvement in this regard, as I optimized it as much as I could.  

With the latest build, on my desktop machine, I can process 1000 lines of G code per second or 1 G code line per millisecond.  Now, my Atom board WILL NOT do this.  :)

The files are memory mapped.  This enables files that are far larger than the 32 bit address space.  However, if your machine is swapping memory to disk, well...  it is GOING TO BE SLOW.  I agree that 8GB of RAM is not sufficient for a Windows 10 machine.  Anything less than 16GB is uncivilized.  

If you change an offset, you MUST regenerate the tool path.  We don't auto regenerate because you may need to change several offsets and would then have to wait on each offset to regenerate the tool path.  

Steve
Re: Painfully slow path display on large programs.
« Reply #9 on: May 24, 2018, 05:05:36 PM »
Thanks for the input Steve,

Just curious, why is anything under 16 GB bad for windows 10? 

When it comes to regenerating my toolpath, I've gotten in this cycle start habit of Regen --> Cycle Start.  Just to be safe.
Chad Byrd