Post Clarification
It’s been pointed out to me that my comment a few days ago, “I’ve just ended the dumbest event in MeshCAM development in a long time” sounded like I was criticizing the user for having an older CPU and expecting it to work forever. This is absolutely not what I meant. The dumb part was that I did not take the time to read the change log or this blog earlier in the debugging process. If I had, the whole thing could have been cleared up very quickly. Sorry for any misunderstanding.
I Need 2D DXF Files
The title says it all. I’m adding some features that will require the loading of 2D DXF files and I need to get an assortment to be able to test my code. All CAD programs tend to do things a little differently and DXF files are really a pain in my experience as a CAD user. Ideally, I would like the following:
- A small file with some lines, arcs, circles, and maybe a freeform curve.
- The files should only have a few entities so I can debug it manually if I have to.
- The curves should be converted to polylines on save.
- Please name with file something based on the name of the CAD program and the settings used to generate it. For instance rhino4-acad2004polylines.dxf if it were from Rhino with the “Autocad 2004 Polylines” save option.
You can send them to me or post them in the DXF thread in the Development forum.
Thanks in advance.
Build 10 Released
I’ve just ended the one of the more humbling events in MeshCAM development in a long time. I got an email from Richard in Germany saying that he recently applied a WinXP update and MeshCAM now crashes immediately upon startup. Build 5 worked but the later ones failed. This is one of the most difficult cases to debug since it’s impossible to reproduce and I don’t have access to the machine. Also, the change from Build 5 to Build 6 coincided with me getting a new laptop so I immediately assumed it was a problem with my build environment or related to the XP update.
Richard and I spent about a month trying various updates and tests to find the root cause. By the second week of testing I was contacted by another user with similar problems so I began to get really worried. Along the way I found a similar problem caused by a missing manifest file for the tbb.dll file that MeshCAM depends on, although this didn’t help Richard at all. I was just about to have him dig into Dr Watson to get me a dump file when I though, “I should check out the blog to see what I was talking about near Build 5.” Sure enough, I saw that I made the change to SSE2-only CPUs at this time and, sure enough, Richard had an Athlon XP CPU that lacked the necessary SSE2 support.
By now, I’ve wasted enough time with this (because I didn’t bother to read the blog) and I never want to deal with this again. The new installer includes both SSE2 and non-SSE2 builds and will automatically install the right one when the installer is run. I should have done this at the start but I really didn’t think that old CPUs would be commonly in use for higher-end applications like CAD/CAM. My assumptions have failed me again but hopefully this will solve the problem for good.
Build 10 also include updated translations for Spanish, Japanese, and Russian. The German translation is not ready yet so that will be build 11 which, if no bugs are reported, will become the “release version” of MeshCAM 3.
It would help if users could check the about dialog after install to see if there is the phrase, “No SSE2” is there. It should not be there for Pentium 4 or Athlon 64 and newer chips. P3, Athlon XP and older should show “No SSE2.”
As always, let me know what you find in this release.
http://www.grzsoftware.com/v2dl.php
Customer Experience Program
And now something that I expect to cause controversy… The Customer Experience Program. Users of many programs, including WinZIP, MS Office, and Solid Works, have probably seen the installers ask for permission to share your usage data with the company. Until the last few weeks I considered this an imposition and generally didn’t participate.
Now that I’ve seen evidence that my development efforts are not exactly aligned with the day-to-day behavior of my users, I see the point of these feedback programs. Very few users give feedback so it’s difficult to get a information about what they want. In retrospect I see lots of wasted development time that could have gone into more desirable features.
Moving forward, MeshCAM will give you the option of participating in a program to send usage data back up to my server so I can see what functions and commands are used most often. Development on V4 development should be much quicker if I can focus my efforts only on what people actually use- and maybe phase out the features that are not.
The data sent back is a list of commands used and some file data like the number of triangles an STL when it’s loaded- there is NO personal data and nothing that can be mapped back to a particular user. There is nothing sent that contains any part of your name or registration code. Further, all data is held in an “analytics” directory in plain text so it can be reviewed. It is transmitted as plain text so someone could confirm that the transmitted data matches the recorded data. Transmission takes about 1-2 seconds on shutdown.
You will be able to opt out of the program but I would hope that everyone would choose not to- this is the best way to collect the data that I need to make the program more relevant to it’s users.
So my question for you all, does the brief text in the installer pane below give enough information to encourage someone to opt it? If you are the type that would generally not participate in these, would the text below sway you? If not, what would?
V3 Build 8 Uploaded
I just uploaded build 8 to the standard location. It fixes a bug that Randy found and adds the option to drag and drop a 3D file onto an already-open 3D file. This will give you the option of opening the new file or inserting it into the current file as a check surface. This is good for times when you want to define your own supports in a CAD program of if you want to add a shut-off surface to an open area. This capability has been available via scripting but it was never a first-class function so I don’t think anybody ever used it. Hopefully this will be better.
I’m still eager to get any bug reports as you play with this build or build 7.
V3 Build 7 Posted
I just posted build 7 to the normal location, http://www.grzsoftware.com/v2dl.php . It includes a bunch of fixes and major performance improvements. It is also a nearly-complete build of V3. The only changes from here will be bug fixes, documentation updates, and translation updates.
I had not expected to call V3 “done” this quickly but I started reading back through the postings here last week and I saw that V3 has been underway for the better part of the year. Somehow I thought it had only been a few months but it looks like my horrible sense of time has struck again.
Version 3 has diverged from where I though it would go but I think the improvements are significant enough to make this a major update even if I didn’t get everything done that I wanted to. I also want to get V2 removed from the site completely and this is the only way I can do it.
Please download the latest release and let me know what you think.
In the past few months I’ve made some big changes that inadvertently broke features that have been in MeshCAM for a long time and nobody noticed (or they didn’t let me know about it), and I found a couple of bugs that have existed for years but have never been found. Based on this, I think I’ve misjudged the importance of some of the features I’ve put in there, because nobody seems to be using them. Version 4 will begin development near then end of the year and the priorities will have to be adjusted to reflect my new understanding of the average user. I’m thinking development will be focused more on solidifying the core and only adding a few new features. I’ll probably ask for more feedback at that point so start paying attention to the features that you actually use on a day-to-day basis.
Need Some Help
I’m trying to get V3 R7 ready for release on Friday and I need some help on a dialog. I’ve added an option to save reliefs as STL files quickly rather than using the painful, and somewhat broken, polygon reduction code that I have now. I have the dialog below as a placeholder but the text is not good and I’m out of ideas. Any suggestions on how to label everything?
Also, I haven’t gotten many bug reports on the last version and I’m sure there are bunches of bugs lurking. Please let me know what you’re finding with the last release.
Anybody Still Using a Pentium 3?
I’m going to assume that few users are still using anything older than a Pentium 4/Celeron ( which were released in 2000) and make a few changes to MeshCAM. Starting with the P4, Intel/AMD made the SSE2 instructions available. Enabling them in Visual Studio gives MeshCAM a 6% boost in my test case without doing anything else. I expect that I can do better if I make changes to target these new instructions more explicitly.
Between this and some other changes MeshCAM is running about 15-20% faster than the last release.
UPDATE: I just made another small change and it’s now about 44% faster in my benchmark.
V3 Build 6
I just uploaded the latest V3 build to http://www.grzsoftware.com/v2dl.php . It contains a couple of bug fixes and some new features.
1) I fixed some bugs where the gcode what wrong if the program zero was not at the top of the stock. This was introduced in the last update when adding the ability to save whole jobs.
2) Fixed bug where the unit were not converted to the proper units if the post processor units don’t match the geometry units.
3) Added a recent files option under the “File” menu
4) Added a spindle speed parameter to the “Edit Tool” dialog. The mach 3 post processor has been updated to automatically turn the spindle on and set the right speed after the tool change. If feedback is OK I will update more as needed. As a result of this change, the tools file format has changed. The old file will be converted but will not be backward compatible with any release before this one.
Items 1 and 2 above shocked me because I got no warning from anyone that they were a problem- I ended up finding them when machining a part that I needed. I take this to mean that most people use the very straightforward approach of keeping the zero on top and not mixing units so the bugs would only appear for the few users doing something a little more nonstandard. If you try this release I would like to ask you to try something different than you normally would- try moving the zero, max depth, stock, tools, units, retract height to something other than your standard values and let me know if anything strange happens. This would really help me stabilize this branch of code.
Found an Old Bug
I had a case today, one one of the few times I get to use MeshCAM for a real project, where I had a metric STL file and I was using my normal Mach 3-Inch post processor. The intention all along had been that MeshCAM would have done the mm-to-inch conversion work without user intervention when saving the gcode. I was surprised when my mill tried to jog the X axis 185 inches to the right- this was obviously broken.
I ended up finding a bug that eliminated the units read from the post processor config file and just set them to match the geometry. I think this has probably been broken for a while and I’m surprised that nobody noticed this when it occurred. I assumed that more people would be working in a mixed-unit workflow but I guess I assumed wrong. Maybe they found it to be broken but just assumed this was the intended behavior. I’m always shocked when a fundamental bug goes unnoticed- especially when it means I may have spent time building a feature that nobody appears to be using.