Add support for QCAD/CAM

[madebymccoy]

Hi,

Does the library skip elements that don't have the "c" attribute?

I've just tried adding CAM data from QCAD/CAM, and getting an error (line 142; xdata parsing).

I've not properly gone through the code, but cursory glance, doesn't seem to be a reason to intentionally fail when elements don't have the "c" attribute? It seems like a nice potential feature, that elements that don't have "c" are not constrained and should be ignored altogether and left alone.

I can see quite a few potential benefits, the biggest is being able to have CAM prepared, so that the rendered file just needs the CAM exporting (it'll regenerate the new path positions), vs having to start from scratch, setting up config, tools, paths and then generating. As I assume paths are moved, but not replaced (so they have their original ID's), anything referencing elements will continue to work after rendering. Another is to have a frame, or other finished elements on different layers... using a point reference, or even graph elements, you could then lay out parametric elements on a finished CAD drawing etc, without ever having to touch the non-parametric elements.

[MadScrewdriver]

Thank you for bringing this to my attention! Currently, elements without the "c" attribute are treated as errors by QSketchMetric Validator. I understand your point about potentially treating these elements not as errors but as parts of the drawing to be simply moved and ignored.

I must admit that I have never worked with QCAD/CAM, but I am open to gaining a better understanding of what you're suggesting.

I can look into adding an option to ignore such elements. Perhaps something like a flag ignore_empty_entities=True could be implemented in the coming few days. This would allow users the flexibility to choose - how they want these elements to be handled by the renderer (as error or not).

I appreciate your input and look forward to exploring this further!

[madebymccoy]

Hi,

With QCAD/CAM, it saves config info (much like normal config) in the DXF.

It also creates layers with a set of entities that mirror the paths you want to cut. They're organised on layers for rapid movements, normal paths etc. There may also be objects imported from an optional template. Potentially a lot of entities!

The CAM processor uses the entityId of the source entity (as I understand), as an attribute on the corresponding CAM entities. That then means if you move any entities around - so long as the entityId isn't changed - the CAM will "follow" the new position, and update the paths accordingly.

I wouldn't want any empty entities moved; just ignored and left where they are. It works well to use a point as an anchor, or adding additional graph elements to align parametric entities to page frames, or 0,0 etc. I see the "c" attribute as being the opt-in, which QSketchMetric processes; ignoring the rest.

Thanks!

[MadScrewdriver]

I've been exploring QCAD/CAM and now understand the complexity of the issue. It's not just about the "c" attribute; the problem is more complex. Let me break it down step by step:

1. The CAM processor, when applied to an entity or entities, duplicates
   them into a block and then inserts this block into the drawing.
   Interestingly, it retains the original entity IDs in the block's
   custom data, labeled as CamSourceHandle.

2. When QSketchMetric encounters such a block, it treats it like a
   standard INSERT entity and searches for the "c" attribute. This is
   why we encounter an Error when an entity doesn't have a "c"
   attribute.

3. The architecture of QSketchMetric analyzes the current drawing and
   generates an entirely new drawing based on this analysis. This means
   that the entity handlers do change.

In summary, the CAM processor in QCAD uses a proprietary data structure based on DXF native blocks and layers. While not complex, integrating support for it requires more than just ignoring entities without a "c" attribute.

To implement support for the CAM data structure, we need to:

1. During the drawing analysis, identify the INSERT as a CAM block.
2. Iterate through all entities in the block, recording the linkage between the block copy and the original entity, as well as its LAYER and custom data (such as CamIgnore, CamSourceHandle, etc.).
3. Render the drawing and recreate the CAM data structure. Specifically, we need to create copies of rendered entities in their corresponding CAM blocks and layers.

I plan to change the issue title from "Error when an entity doesn't have a 'c' attribute" to "Add support for QCAD/CAM." This revision more accurately reflects our discussion.

[MadScrewdriver]

I've never had the need to use QCAD/CAM, as the CNC machine operator in our setup approached similar challenges differently. In the original CNC software, he would assign specific tools and their properties to designated layers (colors). We had various layers like 'cutting', 'slow_cutting', 'perforation', etc., which made the process quite straightforward with QSketchMetric. Moreover, with the use of QSketchMetric Validator, even non-coders could easily parametrize DXF drawings, eliminating the need for a developer's involvement in this aspect.

[madebymccoy]

Okay, so QSketchMetric creates a new document and draws new elements there? I thought it updated the original file, and then deleted the "VIRTUAL_LAYER" layer at the end... Would it be easier to use the original document and update positions of entities marked "c", then creating a new document?

[MadScrewdriver]

As of now, this is the architecture: Reading → Processing Graph → Rendering New Document. So, the answer to your first question is 'yes.' Regarding the second question, that approach might indeed be easier to add CAM support (saying this off the top of my head). It would require some refactoring. Additionally, there is another method we could consider: simply overwriting handlers in the newly rendered drawing