Machsupport Forum
Mach Discussion => Mach4 General Discussion => Topic started by: striplar 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?
-
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:
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
-
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
-
Stuart,
You think 8 gigs of ram is to small for Windows 10?
-
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
-
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.
-
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
-
Even in Mach3 I had to hit the "regenerate toolpath" button if I updated my work offset.
-
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
-
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.
-
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.
-
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
-
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.
-
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.
-
, 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!
-
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
-
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.
-
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