MeshCAM 7151

November 13, 2008 · Filed Under MeshCAM Releases 

I just uploaded MeshCAM 7151 to www.grzsoftware.com/files/MeshCAM-Setup.exe .  You will not find it in the check for updates feature of the last few versions because I only want people to try the latest after reading this message.  This is a transition release as I wrap up V2 and begin V3.  I made a number of SIGNIFICANT changes including a new installer and the app is now compiled in Unicode to support multiple languages.  Win98 is now unsupported, even though it was never explicitly supported, since Unicode is not available there.  I made literally thousands of changes to make this possible and I’ve been using it in my shop without errors. There are a good handful of other fixes as well.  I will be curious to hear what your feedback is.  Please tell me if this one worked or didn’t for you.

 

Why should you try this release and not just wait for the next one (other than me begging)?  I really need your help and every bit of feedback I get will make more more sure that I’m ready to call this the final V2 (after some new translation files from my foreign distributors) and move on to V3.  As of right now I have the following items underway on V3:

 

1) The ability to save an image as 3D in either an efficient or fast manner.  Efficient will do the current triangulation method that can take quite a while.  Fast will just use 2 triangles for each pixel and do it quickly and with very high accuracy.

2) Better 3D zoom.  This will zoom into the current mouse position as you spin the mouse wheel.  It should would very closely to Rhino or other CAD programs.

3) Option to calculate the machining time when inspecting the toolpath.

4) Antialiased 3d window.  No special graphics card needed.

5) Ability to save the current job including the STL files after translation/rotation, supports and check surfaces, stock, program zero, stock type, job type.  There are other things hidden in there to support future options as well.

As a reminder, all current users will get a free upgrade to V3.  V3 betas will become available after I can stamp V2 "Done."

Comments

21 Responses to “MeshCAM 7151”

  1. Gerry on November 14th, 2008 6:10 pm

    The zoom doesn’t seem to work like the CAD programs I use. At first, I didn’t think it was working correctly at all. But after looking carefully, I see what it appears to be doing. It looks like wherever the mouse pointer is, when you zoom in , it pulls the center of the stock towards the mouse pointer. However, it really doesn’t seem to move all that much. Perhaps it’s because when you zoom out, it goes back to where it was?

    With other CAD programs, you can use the zoom as a poor man’s pan, depending on where the pointer is. But the way you’re doing it, it’s still basically a regular zoom. If I try to zoom in to the edge of my model near the edge of the screen, the edge of the model still scrolls off the screen. Perhaps it has to do with model size? I’ll do some more testing to see.

    And while talking about panning, can we have right click panning? Mach3 does it that way, and I kinda like it. :)

    OK, doing some more zooming, and it really doesn’t appear to be working correctly.

    Also, can’t see where to save the job? Save As 3D is greyed out?

  2. Robert on November 14th, 2008 7:04 pm

    I should have been more clear- those V3 beta features are in the code but not activated yet. I don’t want to mix new V3 stuff with the current V2 build. I will add right click panning. I had saved the right click for popup menus but I don’t see a big need for that right now.

    -Robert

  3. Gerry on November 14th, 2008 7:13 pm

    How about Left + Right panning? That would leave the R click free? I’m a huge fan of R click menus.

  4. Robert on November 14th, 2008 7:15 pm

    Maybe I’ll try both. For now I don’t have any popups and the features that I have outlined for V3 don’t really need them. Maybe V4…

  5. Adam on November 17th, 2008 8:28 am

    Cool! The recompile now allows MC to run under wine in a Linux environment.

    For those who care I am running Gentoo Linux with Wine 1.1.8.

  6. Adam on November 17th, 2008 12:36 pm

    I am running the new release on my mac in parallels. I opened the demo stl that you provided, used the standard settings, and created a 1/4″ end mill. I then clicked to generate the code. It did some loading bars, then came up with the menu to save the tool path. But…There is no tool path. I exported it just to check and,, nope nothing. Just some tool change commands and thats it. Hope this helps at all.

    -Adam

  7. Robert on November 17th, 2008 12:44 pm

    Thanks Adam. Can you send a screenshot of the toolpath settings? Are you loading the file in MM or inch?

    -Robert

  8. Randy on November 18th, 2008 11:20 am

    Robert, would you consider adding “RPM” input fields to the Roughing, Finish and Pencil areas please? In lieu of fancy AI to automatically determine RPM’s, it would at least let us enter values for each process and avoid hand-editing the gcode file for that (which in my case is always a risky proposition!)

    Thanks,

    Randy

  9. Adam on November 18th, 2008 11:46 am

    I tried to recreate the problem today, but i was unable to get it to make the messed up code.

    -Adam

  10. meshcam on November 18th, 2008 12:44 pm

    Randy-

    Will do in V3 but I’m not sure if the RPM will be associated with a tool or a process. I need to see if I have room in the UI.

    -Robert

  11. Randy on November 18th, 2008 4:53 pm

    Robert,

    As long as we are entering stepover/stepdown per process (unless we always machine the same material prestored numbers are not too useful…) I would vote for just entering it per process. Heck, even for the same material I’ll alter the stepdown/over depending on the workpiece geometry/stability.

    Thanks,

    Randy

  12. meshcam on November 18th, 2008 5:35 pm

    Step over/down will probably not change- I would like to but I fear the negative feedback. RPM will be per process only if I can get it to fit.

    -Robert

  13. Randy on November 18th, 2008 9:11 pm

    Oh no, Robert, I’m not asking for the current scheme of step over/down to change at all. But if you can find the space for RPM, that would be great. RPM is a pretty basic setting, and it is kind of a drag to routinely hand-edit the MC output…

    There is another item that has (re)appeared. I’m doing 2-sided machining and the roughing process seems to be way too generous in its margins. I load the STL, define the stock and set “Machine geometry plus”, say .27″ for a .250″ diameter cutter. The finishing cutter will make a surrounding kerf that stays within .27″ of the geometry, but the roughing cutter goes at least another cutter diameter beyond that. I enlarged the stock size of a part I’m cutting to stiffen up the “picture frame” but the roughing process just ate farther from the perimeter of the part, making the frame still as weak, with the added side-effect of effectively lengthing the support struts.

    Is there a way to keep the roughing also within the “Machine geometry plus” margin?

    Thanks,

    Randy

  14. meshcam on November 19th, 2008 9:04 am

    Hmm… Odd behavior on the margin.
    1) Does that appear to be a new bug or have you seen that behavior before?
    2) Does the finishing pass not cover the same area as the roughing?
    3) Are you using different roughing and finishing tools?

    -Robert

  15. Randy on November 19th, 2008 9:55 am

    1) I remember seeing the behavior in the past, but haven’t done 2-sided machining for quite a while.

    2) Look at http://www.prototrains.com/misc/margin.jpg I realize what is happening. MC is trying to machine the support struts all the way to the edge of the rawstock, instead of only the portion within the “Machine geometry plus” of the part itself. But yes, the roughing around the part that is not adjacent to the struts is excessive. The part in the picture is the kidney-shaped piece with the central projection. The roughing shouldn’t be wider than the “trench” around the part.

    3) Yes, roughing is .250 flat and finishing is .250 ball.

    Thanks,

    Randy

  16. meshcam on November 19th, 2008 10:25 am

    How were the supports generated- by MeshCAM, as a check surface, or in your main STL?

    -Robert

  17. Randy on November 19th, 2008 2:01 pm

    They are MeshCAM-generated supports, Robert. Solidworks won’t let me save out a surface as an STL (only solids, it appears, and MC won’t load a supplementary STL solid), so check surfaces are not an option for me. The STL is just the part itself.

    Randy

  18. Bob Stack on November 20th, 2008 4:47 am

    Robert,

    Very happy! I use Meshcam Art more than the standard features. Work with a lot of clip art and it seems to be much quicker.

    The STL save is very fast now. I didn’t see the option for fast or efficient so I’m guessing the fast is implemented here, or you have done some optimizaton and the efficient is running much quicker.

    Also, with machine geometry + and don’t machine top of stock selected, I get the correct behavior. I don’t think that was working correctly in the previous version.

    I’m still having problems with larger bmp’s crashing the program, but it seems a little better than it was before. I have to spend a lot of time trying to find the minimum bmp resolution/ toolpath resolution to get it to work.

    Finally, I have a feature request for working with vector images, but I’ll post that to the Meshcam Art forum.

    Thanks,
    Bob Stack

  19. Randy on November 22nd, 2008 12:17 pm

    Robert, do you have a tight tolerance on “Do not machine top of stock” Z0.0000? Because MC won’t build supports on this model, I needed to model the rawstock and supports right in the solid model. Due to the way I had to build the model, I exported the STL with a tilted coordinate system. Even though I have “Do not machine top of stock” checked in the parallel finishing box, MC machines (depending on my tolerance settings) either specific top-surface triangles or the whole top surface. Looking at the STL in MeshLab (a really useful utility, by the way) none of the Z coordinates of the top-surface triangles are 0.0000. They range in the 1E-8 to 1E-9 area, I assume due to rounding errors in the coordinate rotation. If your “top of stock” test tolerance is really tight, could you consider opening it to 1E-6 inches or so? That should still be “down in the noise” of any physical millling operation and not noticable (especially since gcode is conventionally 4 decimal places).

    A similar test STL I built and exported using the native coordinate system does not exhibit this problem.

    Thanks,

    Randy

  20. Robert on November 24th, 2008 8:09 pm

    Randy-

    It’s currently 1e-8 from the top of stock. I just changed it to 1e-6 and made it so you can change the value from Lua. If 1e-6 doesn’t work for you in the next release then let me know and I’ll give you the Lua command to change it.

    -Robert

  21. Randy on November 24th, 2008 10:30 pm

    Robert, thank you. I very much appreciate the time and effort you have spent to bring MeshCAM to the point it is, and it is only getting better at each release. Looking forward to V3! :-)

    Randy

Leave a Reply




Comments for this post will be closed on 23 January 2009.