Installer Fixed
March 30, 2008 · Filed Under MeshCAM Development
With the help of a handful of dedicated users I now think I’ve gotten tot he bottom of the "Can’t save registration information" problem. It turned out to be an installer mistake a few releases ago that left bad data behind. A new release at http://www.grzsoftware.com/files/MeshCAM2-6901.exe should fix the problem. There are several other fixes so try it and let me know what you think.
Comments
13 Responses to “Installer Fixed”
The licensing is fixed for me, did not have to redo the registration process. Now something different. The finishing in the X now does the whole stock not just the model geometry like it use to. And it seems to cut deeper on the finish pass compared to the roughing. At least outside the model.
Robert, would it be possible for you to make setup variables (tolerance, roughing quality) available to write into the gcode file? If I could add a comment line into the postprocessor it would make the diagnostics a lot clearer (rather than me scribbling on little bits of paper…)
And yes, it does look like you have the installer fix nailed. Thank you for your persistance.
Seeing that it was me who badgered you into changing the install location, I feel responsible for the trouble.
Randy
Robert,
Still trying really hard but have failed to break anything. Reasonable speed on my “normal” models but slow linking finish when I can’t always avoid dense meshes. It seems that the linking is still only using 1 core. Any plans to add multi core here… it is depressing to see the progress bars really slow as they approach the finish line.
Trying to Cancel a tool path takes a Loooong time (or forever
and then some, task manager is faster but destroys the original set-up
Look at the Zmap size, 6738 produces >1/2 the size as 6901.
Jeff
PS: The above are all limited Beta comments, compiled over an afternoon of testing. And I am really good at making mistakes.
Robert. A new (beta) release every day! You are good. I cant even get software companies that I have support contracts with to respond that fast.
Pencil Cleanup bug? Not sure if this is a bug or expected. Just take a quick look.
http://www.batbuilds.com/~adam/bug2.JPG
-Adam
Adam- Can you post a shot of your toolpath settings? That’s not a toolpath that I would expect to see.
Tool path
Nothing special
http://www.batbuilds.com/~adam/tool_path.PNG
Robert, I’m seeing the same type of thing on my workpiece:
http://www.prototrains.com/misc/pencil1.jpg
http://www.prototrains.com/misc/pencil2.jpg
But I don’t use penciling so it’s not a bother for me yet.
I’m also going to wait a couple of days on further testing until my new 2Gb of memory arrives–I just noticed today that I’m deep into virtual memory with my current 1Gb of physical memory–during toolpath calculations, my HD light is on like a pilot light!
For parallel finishing on my workpiece, it is looking like .001″ tolerance on 6901 is pretty equivalent to .0001″ tolerance on 6715 in terms of cut quality on sharp toolpath corners.
Randy
Jeff-
Jeff-
The Zmap for roughing should be double what it was before at a given tolerance. I moved the quality up since the recent changes to the toolpath encourage the use of a larger tolerance and therefore a lower quality roughing toolpath. My though was that raising the roughing quality internally would bring the roughing and finishing more on par with one another.
I think refining can be made multithreaded after I’m sure there are no bugs. The linking time is mainly due, from what I can tell, to the toolpaths having to be copied internally at that stage. I can eliminate this without a great deal of new code but, like the refinement changes, it has to be changed in dozens of places and the effects would ripple all through the toolpath code. I’m going to make the change but I need to make sure everything is stable before biting off another chunk of work.
Randy-
I can probably add post processor variable for a lot of things but it may be easier to just dump the whole thing as a text comment at the start of each toolpath. If I forget to do that in the next month or two then be sure and remind me. It’s not too much work but, like the changes above, I want to get everything stable and released before doing anything optional.
Robert
Randy- I’d be curious to see that pencil path with a .001″ tolerance as well. I’ll keep digging here.
Oops, forgot the last two screenshots:
http://www.prototrains.com/misc/6715-0001tol-cutviewer.jpg
http://www.prototrains.com/misc/6901-001tol.jpg
Randy
Robert,
I’ll try cutting back on the roughing settings and experimenting lots more. Life is much more exciting when the rules keep changing (thanks to to you usually for the better)
OK on the linking, it does sound like more bug food. I’ll be patient.
Jeff
[Star Trek "Scotty" voice] Och, ma poor wee hard drive! [/Star Trek "Scotty" voice]
http://www.prototrains.com/misc/pencil-6901-001tol-1.jpg
http://www.prototrains.com/misc/pencil-6901-001tol-2.jpg
That is quite a bit better, Robert, but not in the same class as the .001″ parallel toolpaths. I’ll try .0005″ tolerance yet, but might need new HD head bearings after that…
Randy
Well I was wrong about the finish pass cutting deeper than the roughing pass, it cuts the same depth as the roughing. But the finish pass is diffidently different than it was before. What happens now is, say you rough with a half inch end mill, and finish with a quarter inch end mill; the quarter inch end mill cuts the entire shape that the rougher cut meaning that there is a quarter inch of air that is cut with the finish pass. This did not happen before this version, 6901. Before the finish would only cut the outline of the part, now it cuts the outline of the roughing pass. If you use the same size tool for roughing and finishing there is no difference, but I usually use a ¾ rougher and a ¼ finisher so there is lots of wasted air cutting now. I hope this makes since, what I’m trying to say.