Update
Development has been pretty slow for the last few weeks. I’ve added code to drop the process priority of MeshCAM just before it starts the finishing operations. This should help keep the system interactive during the potentially long and multithreaded operation. The priority is restored when the task is done. On an unloaded system this should not make anything take longer since Windows will keep giving it processor time as long as nothing else is running.
I’ve also been working on how to make a reliable progress bar for the finishing path. This is such a hard thing to work out because it’s all running on different cores and there are so many subtasks that need to be completed. This is a problem I’ve tried to solve before but I’ve never done it to my satisfaction because I can’t just use the same code every time without changes. This time I’m trying to spend the time to do it right because I never want to think about this again.
Comments
9 Responses to “Update”
Robert,
Lowering the process priority is a really good idea, my system sure got sluggish when trying to do anything with the finishing pass in the background. Everything still worked but it reminded me of working with just a dual floppy machine.
The progress bar is nice but not essential. One thought for handling multiple cores is a bar for each core, optional betting on the first to finish
Jeff
The geek in me loves the progress bar for each core but the part of me that has to answer support email cringed a little when I read that. I did get the basics of the new progress system working last night and I think it will now come together quickly. A side effect is that I can now see the timings taken by each phase and I’m seeing that some simple parts that copy a lot of objects are taking longer than the heavy math. This may be the core of the speed problem that you’ve seen in the latest release.
The short term goal will be to make the entire progress very smooth and then I may apply some of the theories mentioned in a paper I read at: http://www.chrisharrison.net/projects/progressbars/ . The gist of it is that if you make the progress bar appear to speed up the further it goes people perceive it as faster. I’ll take any edge I can get.
Robert,
A very interesting read on progress bars, and it makes perfect sense. Your last fractional bar always seems to take too long, reminds me of watching the clock in grade school slowing as it approached 3:00.
Jeff
Progress bars? We don’t need no stinking progress bars! Just make a little animation to loop, like the Windows piece of paper flying from one folder to the next, except this one is a finishing toolpath… Given the fact that probably 90% of users are going to sit there and watch their machine machine anyway (I’m a 90% kind of guy myself) watching a simulation will give 90% of the actual machining experience while they’re waiting.
Randy (yes, I do know that I’m probably certifiably crazy…)
-Robert
If it is not to hard to add; a little more granularity in the progress bars. The bar, made of 10~12 boxes does not give much info on a big hour job. Keep the same bar concept for the simple users, just add a X/(out of N processes) to the bottom of the box, like (57/9476). If you already know how may process it is going to take. I happen to be a Linux geek and like to know what EXACTLY things are doing.
Adam - The big problem that I’ve had to get over is that you don’t know ahead of time how many individual items need to be completed. Once you layout the toolpath you find the number of points to be calculated against the geometry. After you project to the geometry you find out how many have to be refined. After you refine them you trim the points using the max angle and top-of-stock settings. The amount of work in each step depends on the last so it’s near impossible to show a numerical value- although I would really like to. Internally I use 1000 steps but I think that’s probably too much to show on a standard windows progress bar.
Randy- How about a little animation of an endmill crashing into a vise and then plunging into the table. Do you think people would get the joke?
-Robert
O, ya. That would be a great animation!
How about compleated processes number, under the progress bar, so the end user can at least see that MC is still progressing.
Robert, I think that folks would get the joke. It’s like the hand-lettered squirt bottle of “Screech-Lube” (water-soluable coolant) in the machine shop at work…
Randy
Robert,
In the end I don’t really need a progress bar, animated crashes (real ones are far more fun !!!) or even an animation of Randy desparately trying to find the E-stop while the mill attempts to change the local geography
( sorry Randy, I couldn’t resist. I use little machines which are confined by travel limits and mere walls, you have moved up to at least the next containment level 
Just some thing really dumb and simple to indicate the MC is still working would suffice. Damned Task Manager just says “Not Responding” ; when I know that a bit more patience is all that is required. The geek in me really likes the flashing lights and fan fare but all of that uses overhead (my main computer already almost qualifies as a space heater). I have a pretty good gut feeling for how long a given MC build should take, what the file size should be, and the rough mill time. Any funny un-expected numbers and I re-run everything, twice.
Jeff