Import designs from another CC file

I am not sure if this is me not knowing the software well enough or if this is just something Carbide Create does not do. I have common components that I use in projects like my logo, keyhole hangers, hold downs, and others.

Right now, I start my projects using a copy of my hold down file so I can have a grid of where my hold down bolts would go on my waste board. I then start designing my project and know where my limits are and where my project can be held with bolts if possible. As I need, I will import the SVG of the keyholes or logo for example but then have to recreate all the paths for those. I guess I could have all of them in the main starter file and remove the ones I don’t need but it would be really handy to import these as needed. It would be nice to have a collection of these common components and just be able to bring them in as an object with their own tool path group and grouping as setup in their original fine.

This seems somewhat similar to this request that was made earlier and I really think it would be great to have this built into the software instead of using a third party script to merge cc files. Since c2d files can change and I think there was a slight change recently, relying on a third party tools seems less reliable.
https://community.carbide3d.com/t/a-method-for-appending-components-to-the-existing-file/31524

If this is possible already I would love to know how to do it. If it is not, we can move this to the feature request category on the forum instead.

At this time, directly using a second Carbide Create file is not supported.

One can instead open the second Carbide Create file, export the geometry you wish to use as an SVG, then import that SVG into a Carbide Create file.

Thanks @WillAdams. I assumed that was the case but wanted to make sure that I was not missing something. I think that exporting and importing components could be a very useful feature in the future. I also think this is similar to what @jepho was requesting in the linked forum post above. It would basically be exporting the path details when exporting the SVG details. It would probably require an additional file format type since it is not really the whole c2d file that we need since the project details don’t need to come across just the objects. I don’t know if others see the need for this but I know it would save me large amounts of time when designing projects.

I edited the post to move it to the feature request section.

@rnicolson But beware, exporting to SVG does not carry the toolpaths.

I have found it necessary to save common components into their own file and then copy the file to a new project and open it under the new name…take what I want…and discard the rest before continuing with the new project design. It’s kind of kludge.

  • Gary
1 Like

@GJM Yeah that is basically what the problem is. We need another Carbide Create file type essentially that exports the details of the object including the tool paths.

I am kind of using your method already but did not put all common components in one file, only some. I guess I will go that route moving forward but I agree it is kind of a kludge.

I guess the problem is that there is no real link between a design component and the toolpath(s) that touch it. Multiple toolpaths could use parts of components, components might not have any toolpaths that use them, etc.

If you could bring in a toolpath, how would you connect it to existing objects in your new design? What would happen if the expected object(s) for a toolpath aren’t all in your target design, etc. I think this is why it hasn’t already happened!

EDIT: I could see it work if you loaded the entire c2d into a new file…design components and their toolpaths…all put together and linked. Then you can unlink what you need. This would be less complicated than a cut and paste that included paths

Interestingly, there is an SVG-variant which does this, PartKam/MakerCAM — it’s even supported by LibreCAD when writing out an SVG from that.

Another option would be support for one of the colour-coding options where different colours have different meanings in the SVG — just map the Toolpaths to the appropriate linetypes in the SVG, and use the coding on import.

1 Like

That is interesting. I assumed there was some linkage between the two but thinking about it now it makes sense that there is not. I have removed objects but the tool path still exists. Bringing the tool path and the object together is really the only way that makes sense.

I think your edit makes the most sense then. Bring the whole file in and remove what is not needed. It would likely be much easier to implement than the copy paste or creating a new file type.

1 Like

@rnicolson OK…so I slept on this last night (sick, right?) and I came to the conclusion that we’re thinking about this backwards. The thing we CAN’T copy today is not the design of the component (because we can create an SVG, as @WillAdams said)…what we really want to copy is the TOOLPATH and its ASSOICATED COMPONENTS.

This would actually solve the problem AND work around the issues I stated above.

If we could point to a toolpath (or better, a GROUP of toolpaths) and “Copy it”, then go to another design and “Paste” it into the toolpaths of a target design - and have all of the associated objects get copied into the design with it - it would fill the gap of what we can do.

When you double-click on a toolpath, the objects in the design are highlighted, so CC knows the linkage from the toolpath to the objects — so copying all of the objects associated with a toolpath would seem possible.

The Paste function would either be “a brute” and automatically create all of the objects into the target design along with the connected Toolpath, or it could be “Intelligent” and only copy those that aren’t already in the design. I’d settle for the Brute!

That would be a VERY useful feature…particularly if you could keep a GROUP of Toolpaths for any object that you want to copy.

Thoughts? If we like it, we can put it into the Feature Requests discussion thread.

@GJM I think the brute is exactly what we need. Thanks for spending the extra time thinking about it. That feature addition would help a lot of people I expect.