How to "break" a 'simulate toolpath' calculation

[pknvectric]

This is a constant annoyance in Aspire. If I run toolpath PREVIEW it runs fine. However, if I forget to "RESET PREVIEW" before clicking run preview again it goes into a ridiculously slow recalculation of toolpaths. Sometimes it finishes eventually. Sometimes it freezes like today. (No, it's not a hardware issue. I have a brand new MacPro w/ the fastest processors and 256GB of RAM.)

Right now we have a VERY simply toolpath which should take less than 2 seconds to recalculate. Unfortunately, we clicked "run preview" and now it's stuck / frozen on "Simulate Toolpath (4%)".

How can I "break" this operation so I can get back into my file. We have not saved the file yet so if I "END TASK" on Aspire I'm going to lose all the work we've done thus far...

Surely there is a way to cancel a toolpath simulation.? (And, more importantly, this has been doing this in Vectric since I began using the software 4-5 years ago. No one else is aggravated by this behavior???)

[adze_cnc]

First off toolpaths are not "recalculated" while running a simulation. Second there ways to stop the simulation depending on what you are simulating.

If you use the "Preview Selected Toolpath" just below that button are buttons that look like a CD player/cassette deck controls. Click the "pause" one (the two vertical lines) and when the simulation is paused. Click the "eject" one (horizontal line over the triangle).

If you are using "Preview All Toolpaths" or "Preview Visible Toolpaths" then on the bottom of the screen to the right of the advancing blue line is a red circle with a white 'x' in it. Click that to stop the simulation.

You say it's not a hardware issue but you are running Windows based software on a Mac. Are you running Window in Parallels or VMWare or any other virtual machine software? Or are you running Windows via "boot camp"?

[pknvectric]

Yes, clicking the "EJECT" button killed the simulation so we were able to save the file. We tried it again and it repeats the issue every time. Clicking EJECT or the little red "x" seems to allow us to get out of the loop. (Not that I would consider this a solution for most users.)

Ultimately, yes, I'm on a Mac running ParallelsDesktop-14.1.3-45485 (but I've also run into this issue repeatedly on a Windows-only machine I have connected to my CNC.) . And, YES, this was largely a hardware problem. I set up this new Mac a few weeks ago but had not tweaked the resource settings in Parallels. By going from '2 CPUs and 16gb of RAM' allocated to the VM to '8 CPUs and 128gb of RAM' the issue disappeared. (I left GPU memory @ 1gb per Parallels suggestion.) I guess this simulation process is simply extremely resource intensive.?

I am assuming the issue will continue on the low-end PC I have connected to the CNC.?

[Adrian]

You can adjust the simulation quality on the toolpaths menu. Stepping it down might help.

The only time I've seen a really, really slow simulation is when using a very large tool on a comparatively small piece. The more pixels that are affected by the virtual tool the more calculations there are and the slower (more intensive) it is.

[ger21]

By going from '2 CPUs and 16gb of RAM' allocated to the VM to '8 CPUs and 128gb of RAM'

Not sure how the VM works, but I'd bet that 98% of Aspire users have PC's with 16Gb or less RAM.

Does your PC really have 256Gb of RAM? I've tried really hard a few times to get my PC to use a lot of ram, and it's difficult to use more than 10Gb of RAM, even with multiple applications running.

[TReischl]

No one else is aggravated by this behavior???)

Nope. Mine has never acted that way in over 12 years. First time I have seen a post about this in 12 years.

Maybe you have your little speedy slider thingy set to something ridiculously low or as someone else suggested you have the toolpath preview set too high.

My shop computer is a whopping 8Gb running Windows 7. The thing is at least 8 years old.

[mtylerfl]

...Yes, clicking the "EJECT" button killed the simulation so we were able to save the file...

This is confusing - i.e., the "EJECT" button.

Surely you aren't running the simulation from a file on a thumb drive are you?

Could you upload your file here so we can take a look and see if any of us have any issues with it?

[martin54]

...Yes, clicking the "EJECT" button killed the simulation so we were able to save the file...

This is confusing - i.e., the "EJECT" button.

Surely you aren't running the simulation from a file on a thumb drive are you?

Could you upload your file here so we can take a look and see if any of us have any issues with it?

Read adze_cnc post Michael, all will become clear

Same as Ted, this isn't something I have seen either, my design computer at home has a reasonable spec because of the graphic files I work with as a signmaker but the machine at the workshop only has 8 gig ram & is about 10 years old. Seems to work OK for me

[mtylerfl]

Thank you, Martin. I see now that Steven labeled the “stop” icon as “eject”.

[pknvectric]

Hmmm... I've dealt with this issue consistently since I started using Vectric 4-5 years ago. This was one of the prime reasons I upgraded my 6-year-old MacbookPro - I would tell Vectric to simulate or recalculate toolpaths and it would slow to a crawl. I'd be forced to walk away for several minutes (which would turn into an hour because I'd get busy on something else - killed my CNC productivity.)

I lied / forgot. My Mac only has 128gb of RAM but it's upgradeable to 256gb. (Personal rant: When in doubt... Buy all the RAM you can afford... This has been the most important factor in computer speed for all of my 30+ years in computers. (Yes, I'm old. I was a beta tester for Windows95.))

As someone stated - most of the machines out there have 16gb or less of RAM and 1-2 CPUs. But I've always dealt with this problem - across 4 different computers. (2 Camaster CNCs (Stinger and Cobra) and their associated dedicated (slow) PCs and my old laptop and now this new desktop Mac.

Attached is the CRVD3 file, etc. It a tiny, simple file... I cannot imagine why it was so slow... Again, in this particular instance this did not happen when I first told it to simulate. It was only AFTER the toolpath was previewed once (and we did not apply "Reset Preview) and then my son (who is just learning Vectric) clicked "Preview All Toolpaths". I'm tempted to back off on the Parallels settings so I can recreate the problem exactly but I simply don't have time. If Vectric wants me to prove/confirm/verify later I will do so...

[mtylerfl]

The toolpath preview completes in 20 seconds when starting "fresh" by clicking on Preview Selected Toolpath (animate preview and draw tool are ON and my preview simulation quality setting is at Extremely High)


If I then click on Preview All Toolpaths (without resetting the preview), the toolpath preview completes in less time - about 13 seconds.

That's 7 seconds FASTER than starting from "scratch" to do the preview. I think that's because the screen doesn't need to re-draw as much because the bulk of the preview process is actually displayed already.

I keep thinking there is "more to the story" at your end somehow. No one as far as I know has experienced exactly what you describe has been happening for you over the last several years. So, I conclude it must have "something" to do with running a PC program via your Mac. I'm guessing a slow video display/redraw issue?? I don't know how much Vectric would be able to help with this.

[Adrian]

I agree with Michael that it is something at your end of things as if it was a general problem there would be far more people mentioning it. The file simulates fine for me with no slowdowns etc.

The toolpath simulation is CPU intensive not RAM or GPU intensive as far as I'm aware.

[LittleGreyMan]

Hello,

Are your files located in a directory of the Windows virtual machine or in a shared directory on the Mac OS side? A shared directory is probably managed as a network directory by the virtual machine (at least it's the case with Vmware, I don't know for Parallels), which slows down the vm.

[Jim_in_PA]

I do not experience this issue at all...not on my current 2019 MBP 15" with 16gb of RAM nor with the 2012 MBPr13 with "only" 8gb of RAM. There is never a recalculation when I run the simulations. Recalculation only happens when I change the tool path.

For anyone not familiar with running Windows in a VM, there's essentially no difference from running it on a dedicated machine...as long as it's tuned properly for the task with enough assigned memory, etc. The single anomaly on the Mac platform for the Vectric software that Iv'e experienced and others have confirmed is relative to "rodent sensitivity"...especially with the MagicMouse which is essentially a touch pad in rodent format. It's naturally sensitive to finger movement and that can make things jump a round if one doesn't "calm down their finger". Maybe we'll get lucky one of these days and get a native version that helps mitigate that little feature.

[pknvectric]

The files are typically saved on a "synced" directory - not a shared directory. (So, each computer is working with a local version of the file.)

To test this theory I loaded a different file (also extremely slow to calculate) the following file 3 ways. 1) . Mac running Parallels - file accessed through GoogleSynced drive. 2) . Parallels using a file copied directly to the Parallels C:/ drive. and 3) . An entirely different Windows PC (slow dedicated machine connected to CNC) running a local version.

The "Recalculate All" option required the following corresponding times: 1) 3'08" 2) 3'04" and 3) 3'33" . (So, yes, CPU speed matters.)

Regardless, all of them seem to be slow...