V3 Build 5 Performance improvement

V3 Build 5 Performance improvement

Postby ArchieF » Mon Sep 21, 2009 4:25 pm

Hi Robert,

attached you find a file with 42709 Triangles I created just to play with MC.

MC build 7283 did a roughing job in about 7 mins

MC v3 build5 did exactly the same job in about 3 mins.

Great improvement I think

Best regards

Richard

btw : the new “Save Job” command works fine here for me
Attachments
GmaxSample.zip
Sample file to test speed
(942.95 KiB) Downloaded 714 times
AMD Athlon II X2 215 Processor 2.7 GHz

4 GB RAM

Don't waste water - dilute it !
ArchieF
 
Posts: 195
Joined: Wed May 14, 2008 5:03 am
Location: Germany, Rehau

Re: V3 Build 5 Performance improvement

Postby Randy » Tue Nov 03, 2009 8:09 am

Richard, welcome to the forum, and my profuse apologies for letting your post slip by me, and for the shamefully late reply! And when your first post was a constructive and informative one! Consider me chastised. :oops:

I think that your STL is the first "shell" (as opposed to enclosed volume) STL that I've ever seen. And it has a cool shape and lots of nooks and crannies. And it's in mm's too! (To me, MM's are little round chocolate candies that don't melt in my hand...) I have 3build8 plugging away at it with inch tools right now. I'll see if I can break it (probably not since Robert said he's been fixing mixed-unit stuff lately.

Please don't let this moderator's inconsideration discourage you from posting more.

Edit:Richard, I ran your model with 300mm x 300mm x 50mm stock and inch tools, and MC calculated the toolpaths correctly (3D offset contour roughing, parallel X plus waterline finishing) and wrote the output in inches (reasonable since that was the tool measurement units). The worst thing was that the [CUTVIEWERSTOCK] wasn't scaled to inches--it reported in mm so when I ran the gcode through CutViewer the rawstock was enormous compared to the machining envelope, but looked fine when I changed it to 12 x 12 x 2 (inches). By and large, it looks like Robert has a handle on mixed units. /edit

Randy
All opinions in this post are mine alone. I am not a MeshCAM employee, I do not have a financial interest in MeshCAM, nor do I speak for MeshCAM. MeshCAM user since Beta 5 in 2003. viewtopic.php?f=11&t=15333 :ugeek:
Randy
 
Posts: 1812
Joined: Wed May 14, 2008 9:50 am
Location: North Texas, USA

Re: V3 Build 5 Performance improvement

Postby jeffD » Tue Nov 03, 2009 6:26 pm

Randy,

MC has no problems with shell stl files. I think I have made maybe 2 watertight models in 6 years, and only when I needed volumetric information. Closing a model usually takes more care and work than the initial model. I have models which are undulating planes suspended at a +Z and they work just fine for straight 3D milling. Usually I have to put in vertical walls but only for client renders since they have no imagination :) Should also work fine for 2 sided stuff.

Straight down from the top is all that MC sees, closing the back and adding side walls is just extra work.
I admit to being a lazy SOB but you of all people should have figured this out. :mrgreen:


jeffD
I have no financial interests in MeshCam. Nothing I say here has had any approval from MC. Any errors or omissions are mine alone. Use at your own risk.
jeffD
 
Posts: 321
Joined: Wed May 14, 2008 2:55 pm
Location: Vermont

Re: V3 Build 5 Performance improvement

Postby Randy » Wed Nov 04, 2009 3:21 am

jeffD wrote:MC has no problems with shell stl files.

Yes, Jeff, Richard's STL has shown me that. :) The name-brand solid modeling program that I have used doesn't do open shells (only enclosed volumes), and the other one I own doesn't do surfaces at all. So this is a new experience for me. ;) Which is another reason I feel double-plus ungood about letting Richard's post slip by me for so long...

Randy
All opinions in this post are mine alone. I am not a MeshCAM employee, I do not have a financial interest in MeshCAM, nor do I speak for MeshCAM. MeshCAM user since Beta 5 in 2003. viewtopic.php?f=11&t=15333 :ugeek:
Randy
 
Posts: 1812
Joined: Wed May 14, 2008 9:50 am
Location: North Texas, USA

Re: V3 Build 5 Performance improvement

Postby ArchieF » Thu Nov 05, 2009 1:34 pm

Hi Randy,
thanks for the welcome. You don't have to apologize. I'm a patient guy. So if my thread is of interest then someone will reply to it.

To the model : it is not closed coz I cut the lower half with a boolean operation.

@Jeff :
MC has no problems with shell stl files
I don't think so. I tried with previous versions of MC some shell stl files and what happened was : after more than 1.5 hours analysing the model I killed MC with the taskmanager. The newer versions of MC seem to be able to work with shell stl files.
Of course it makes no sense to close the bottom and it's wasted time if you don't want or don't need to mill the other side of the model.


Richard
ArchieF
 
Posts: 195
Joined: Wed May 14, 2008 5:03 am
Location: Germany, Rehau

Re: V3 Build 5 Performance improvement

Postby jeffD » Thu Nov 05, 2009 9:23 pm

Richard,

I'll admit that you might be right. I looked through old models and my weirdest one predates my MC use by a year. Possibly you had a bad stl, it does happen. :twisted:

Still, starting with V2.0 I don't bother closing models, too much work I don't enjoy unless I really need volumetric info or a milled back.

jeffD
I have no financial interests in MeshCam. Nothing I say here has had any approval from MC. Any errors or omissions are mine alone. Use at your own risk.
jeffD
 
Posts: 321
Joined: Wed May 14, 2008 2:55 pm
Location: Vermont

Mixed units, lithophanes, BMP's and top of stock (not) machi

Postby Randy » Fri Dec 25, 2009 3:25 am

I'm doing a lithophane for my wife for Christmas (shhh, don't let on... :)) and have run solidly into several issues.

MeshCAM in its current form doesn't respect "Don't machine top of stock" where bitmap files are concerned. It lawnmows the whole bitmap area, even if 80% of the bitmap is solid black (on a lithophane black is full thickness).

To get around the massive increased machining time, I located a neat freeware called BMP2IGES ( http://www.ba-bautzen.de/~geisel/bmp2iges.htm ). Besides converting a bitmap to IGES surface, it also saves as an STL file--a surface, not a closed solid--which MeshCAM accepts, as you experienced guys pointed out to me. :) And importing the resultant STL into MeshCAM, I can effectively employ "Don't machine top of stock" to save beaucoup finishing time.

However, being a German software, the units are mm only. Not a problem per se, but I did discover that while MC outputs the gcode in inches through my postprocessor, both the [cutviewerstock] and feedrates are still in mm and mm/min. Easily fixed in a text editor, but it would be nice if MC handled the mixed units natively.

I'm guessing that Robert's new "quick and dirty" bitmap to STL conversion that trades off calculation time for increased STL size is similar to the algorithm that BMP2IGES employs--taking two succsive rows of the bitmap, converting the pixels to heights, and making STL faces for each pixel trio going down the road. BMP2IGES does have an optimization in that it will consolodate triangles that are at exactly the same height--useful for a solid black (or white) bitmap background.

Gotta go and tend the mill (no rest for Santa's elves)! Merry and blessed Christmas and the best in the new year to you all!

Randy
All opinions in this post are mine alone. I am not a MeshCAM employee, I do not have a financial interest in MeshCAM, nor do I speak for MeshCAM. MeshCAM user since Beta 5 in 2003. viewtopic.php?f=11&t=15333 :ugeek:
Randy
 
Posts: 1812
Joined: Wed May 14, 2008 9:50 am
Location: North Texas, USA

Re: V3 Build 5 Performance improvement

Postby robgrz » Sat Feb 06, 2010 6:04 am

I just went through the code to find the problem on the "Don't machine top of stock" and images. After digging through the bitmap code I remembered this problem from a year or two ago. Jpeg files have lots of compression that, while imperceptible to the eye, leads to surfaces that are not quite touching the top of the stock. You have two options for this- 1) Use BMP instead of JPG to get rid of the compression artifacts or, 2) Shift the top of stock a couple of thousandths below the top of the model. There is a parameter that can be changed from Lua that defines the tolerance for how close the surface has to be to the stock before it's considered to be "touching." If you're interested I can look it up but it would be no different than shifting the top of stock down by a tiny amount.

Unfortunately this is a case where I have to choose between being "mathematically correct" or try to judge the intent of the user. JPG files happen to be the one case where the decision I made causes a conflict between the two options.

-Robert
robgrz
Site Admin
 
Posts: 181
Joined: Tue May 13, 2008 6:06 pm
Location: Southern California


Return to Fixed Bugs

cron