Ahh. The obvious answer to a question i should of known. Lol. Makes sense. . Lol
I use it to document revision history of my cd2 files.When I revise a file, I do not overwrite , I save with rev000,rev001, etc in the filename. In the notes, I keep detailed history of corrections / additions I make ( as I make them) to each revision. I now have a convenient record of all modifications I make to cd2 files as I tweak designs, tool paths, material layout etc. The notes feature has already become something I always use.
1 Like
That might be a nice thing to automate if others do it. We could have a “save version” command that increments the file name and then prompts for a comment to append to the notes with a time stamp.
Would others use this?
7 Likes
Not sure I’d leverage it, but I think it’s a great idea and would be a nice addition.
1 Like
716: Simulation seems to be calculating a bit faster. Nice!
Simulation colors… Much, much, better!
What does this mean? How would we test it?
@duexx posted a file that was largely an array of circular pockets of varying size. I figured we should try add a slight bias to the linking behavior so that, where two options we close, we’d prefer to link to the one closer in the X direction.
In most cases you’ll never see this kick in, it’s just a test for people that have suitable files. We could make it more aggressive but that could lead to less optimal linking in normal cases.
1 Like
[DEFECT] 716: Tabs Disappearing when Scaling
Found a sequence that causes some tabs to disappear:
Starting with this design
Note 3 tabs on each rectangle between the two mirrored images:
Now SCALE these (snapshot taken during the drag):
When you release the drag:
and Deselect…check out what happened to the tabs!
The 3 tabs on the right are disproportionately scaled…and I lost the other 9 tabs.
Can you send that file to me?
1 Like
I’m attaching the c2d for this example…because I can’t reproduce the problem using just two rectangles.
Fern Tree Background.c2d (328 KB)
and I now see your request for the file!
Also: More history: This was a traced image originally.
I am not able to reproduce it using rectangles, even with other vectors included within the rectangles. I’m going to keep trying things…but at least you have the file.
OK…It’s because it’s a traced image. I can reproduce it by tracing another image, putting tabs on the perimeter and then scaling.
I traced another busy image to see that…I’m going to try it now with a very simple trace and see if it still happens
I can duplicate it. Rectangles are different objects internally than a path, which is what you have, so the code path would be different. I think we can get it fixed without too much trouble.
1 Like
OK Great. I’ll stop looking then.
You’re referring to optimization (the order of the paths to reduce rapid / non-cutting time) ?
“Link” being the rapid between regions? I do see a difference in a V6 -vs- V7 path. Although
my example is not complex enough to really discern a difference in time.
V6
V7
Also noticed that “Save As V6 File” loses the max cut depths, and results in empty toolpaths.
1 Like
This change might actually cause a slightly longer toolapth in some cases but people think “optimal” means “I understand what it’s doing” rather than the shorter path. We’re hoping this will make very dense toolpaths look more like what users expect.
This is a problem. The save code in CC doesn’t have a parameter for the output version so it’s outputting an expression for the depth, not the number that V6 expects. I don’t think we’ll thrash all of the code in V7 to add support for V6 so we’ll either:
- Leave it as-is
- Do a build of V6 that can deal with the expressions for depth values
- Remove the Save as V6 option in V7 once we’re sure that the V7 saving code isn’t broken.
#3 is the most likely option at this point.
1 Like
This suggests the whole TSP optimization can-o-worms. There are some available open and closed source gcode optimizers in varying states of repair that will divide files into groups (often separated by retracts and rapids) and then do a TSP optimization between those blocks. It’s also a pending feature for md8n’s excellent GCodeClean. However these work on gcode files, and, well, V7.
I don’t think I’ve seen anyone mention it but maybe not looking close enough.
On the circular array, once you put in the size of the radius and the item you want in the array it seems that you can’t get back to that array to either change the radius (unless you just use the std. sizing tool), nor change the number of items in the array.
I’m probably missing where that is located, just not seeing it.
Not just circular array @Frank246 - it seems to be the case on the linear array as well. I don’t recall it being that way
The arrays are not associative objects that can be edited. Once you use them & say, “OK”, you’re back to a bunch of individual vectors. You can however, just delete all the copies & start over to make a change.
2 Likes
Yup. That’s the only way I had found. Does make it time consuming if your using the array and have to keep changing it as the design develops. but that said, I do like the tool.
Thanks