Hello Guest it is January 24, 2020, 12:50:20 AM

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

0 Members and 1 Guest are viewing this topic.

Offline Mauri

*
  •  307 307
    • View Profile
Re: Painfully slow path display on large programs.
« Reply #10 on: May 24, 2018, 05:18:57 PM »
Cbyrdtopper,
I have loaded large files 3 million lines of G-Code on an Old XP with 2GB Ram with no Graphics card and yes it take a long time, but it can do it.
I also use 8GB on newer PC's that I run our Machines and it takes a lot less, but still seems a long time, but one it is up you can rotate the display object no no issues.
So to me 8GB is just fine.
On my test M/C that has 32GB with a fast Graphics card and an SSD it is much faster, but who in their right mind spend a fortune running Mach4 and Machines with Fast PC's.
It just the way Mach4 works with PostDisplays.
Mach3 with the same file on my old XP slug can do it much faster, but is not as elegant on accuarte in its display of the G-Code.
If you do not display the Toolpath just add the code which has been wriiten in this forum and it will be fairly instant in loading.
Regards,
Mauri.

Offline smurph

*
  • *
  •  1,187 1,187
  • "That there... that's an RV."
    • View Profile
Re: Painfully slow path display on large programs.
« Reply #11 on: May 24, 2018, 05:39:18 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.

Because a stock Windows 10 installation on a new machine (Dell, etc...) idles at 12GB.  They put all of that bloatware on there.  Plus all of the MS telemetry stuff.  If you are persistent enough to remove all of the crap, then 8GB might be ok.  All it takes is a quick look to the task manager to see how well the machine will perform.  Virt mem vs. Physical mem.  If your virt mem is higher, expect the machine to be sluggish.   My machine is idling at 21GB as we speak!  Now, it is a development machine.  But let's face it, that is the amount of memory my machine REQUIRES to operate like I want it to.  All that is running is Visual Studio, email, web browser, file manager, Skype, and Mach.  The big ones are Skype and the web browser.  Next is the Visual Studio.

Steve
Re: Painfully slow path display on large programs.
« Reply #12 on: May 24, 2018, 05:51:53 PM »
When we purchase computers for a machine we strip them of pretty much everything we can from the "uninstall programs" in the control panel.   All we keep are drivers.   All non essentials are out the door.   Our machines are used for production, so we like to have computers stripped of everything so it won't mess with Mach.   
Chad Byrd
Re: Painfully slow path display on large programs.
« Reply #13 on: May 24, 2018, 06:51:07 PM »
Even in Mach3 I had to hit the "regenerate toolpath" button if I updated my work offset.
I don't use work offsets, I don't home the machine. I just use machine coordinates for everything, and in Mach3, the display always updated.
Re: Painfully slow path display on large programs.
« Reply #14 on: May 24, 2018, 06:57:35 PM »
, but who in their right mind spend a fortune running Mach4 and Machines with Fast PC's.
I do for one! I run everything on the same PC, Mach3/4, my 3D modelling program, listen to Spotify, stream YouTube documentaries etc all the while happily running the machine without ever having an issue.

The PCs we have today bear no resemblance to the old ones that Mach3 had to cope with. With an ESS and a fast computer, you can pretty much run what you like. The advice about running only Mach is way too conservative in my opinion. Sure if you run a slow PC, you may have to take precautions, but I bet it's a lot less of a problem than you imagine. Try it and see. What's the worst that can happen? The buffer empties and it stops.

The benefits are significant if you can process tool paths and directly have them available for Mach to run. You can also have cloud storage to transfer jobs between computers. I have all my workshop 3D models and drawings to hand, all on one PC. Don't knock it until you've tried it!

« Last Edit: May 24, 2018, 07:00:17 PM by striplar »

Offline Stuart

*
  •  204 204
    • View Profile
Re: Painfully slow path display on large programs.
« Reply #15 on: May 25, 2018, 06:31:11 AM »
Mauri

Let me make a point it’s not an expensive pc it is a refurbed one cost with screen keyboard and ne non dell w10 64 bit pro from a ms authorised dealer cost inc taxes shipping £300 pretty cheap wit a one year warrant

It’s the only windoze pc I have and I hate it but it does the jobs it been got for

Oh I wish artsoft would bring out a Linux based m4 yes they would have to supply the os as well to ensure it works then the motion cards company’s need to get there act together then we would have a real time system

Re: Painfully slow path display on large programs.
« Reply #16 on: July 30, 2018, 05:28:49 AM »
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

Is there any progress on this? I'm going to be doing some 3D work soon and the display takes over a minute to display the tool path on even smallish finishing paths.

Mach3 instantly shows the path at the new DRO location when you change it. You don't need to redraw the whole tool path when the DROs change, only the crosshairs that show zero. Why can't this be done for Mach4? I use this a lot when trying to place a profile on a sheet of material. It's a pain to have to keep refreshing and waiting to see where the cutter is currently located.

Offline smurph

*
  • *
  •  1,187 1,187
  • "That there... that's an RV."
    • View Profile
Re: Painfully slow path display on large programs.
« Reply #17 on: July 30, 2018, 07:44:24 PM »
You only need to re-generate the tool path if the work offsets have been changed.  Otherwise, Mach doesn't redraw the whole tool path.  It only draws the entire tool path when you load a file or hit re-gen.  All it draws is the cross hairs and changes the color of the cut path after that.  I fear that there is something wrong with your graphics driver if you think it is trying to re-draw the tool path all of the time. The build on the website (3804) has all of the optimizations I was talking about the you quoted. 

I would:

1. see if there is an updated video driver.
2. make sure you are not swaping to disk (low memory).

Steve