2D Drawings with Dimensions

[shrekuntu]

This is an awesome project and huge improvement over FreeCAD python API. Chainable methods makes it so compact. Excellent work.

However, for me 2D drawings with dimensions are more important then 3D models.
I my organization we have lots of relatively simple configurable products and sales cycle is very short, sales guys don't have time to ask Engineering for every customization which are mostly dimensional changes. I understand CQ can be used as a library and possibly from the web app like flask, Web app would interact with user via form data input and return 2D SVG as a result. This can be converted to pdf. STEP model would be offered if needed.
But, what is missing are DIMENSIONS. Without dimensions, two similar shape models would look the same, and this is a communication between non-engineers

I read comments in your source code about FreeCAD's SVG Export and wondering if that could be improved with dimensions added and if you have any ideas in that direction.

Thanks

[jmwright]

@shrekuntu I think the work to do autogenerated dimensions would be fairly involved. I don't think there's any plan to add that feature at this time to CadQuery, but we're always willing to accept PRs.

There was also some work done on importing 2D geometry from DXF. Not sure if that helps.

[dcowden]

@shrekuntu

From the very early days, I've hoped we could add 2d parametric behavior into cq.

As Jeremy mentioned there has been a lot of talk about importing dxf and svg. But as you know, these would not produce a parametric design. Retrofitting dimensionality onto a static sketch will not work well.

The best solution is to have a true 2d constraint solver for 2d. This allows building variables in that are automatically computed to suit the others, which may be what you are after.

If you are the simpler ability to allow a user to give values for variables that have designed into a model, so that it can be easily modified, you might have a look at cq parts, which does a much better job than stock cq in this regard.

[adam-urbanczyk]

@shrekuntu good to hear that you like CadQuery! Indeed our SVG export is rather rudimentary. There are no specific plans to include dimensions, although that would certainly be very useful. I agree with @jmwright that adding full-blown dimension generation would be a project in itself and would probably require adding some kind of optimization solver for laying out everything.

Could you share more about your use case? Do you need dimensions for everything or would a simple scale bar suffice?

[shrekuntu]

Here is an example. We are making shafts for power transmission equipment. Shaft has a main diameter, turn down diameter, length, length of turndown, keyways and distance from end to keyway.
Only predetermined dimensions would be shown on 2D. User would only fill out an html form with
D = 2.4375" (shaft diameter)
d = 1.9375" (turn down diameter)
L = 44" (shaft length)
TD = 9" (turndown length)
K = 11" (keyway dist. from end)

User submits this form to a flask app, which in turn sends this to a shaft method with CQ instructions. Once model is done, exports it to svg, add these predetermined dimensions to it and flask app returns svg with dimensions to user. User wouldn't be adding any dimensions on their own, all dims would be predetermined for a type of part

Thanks

[dcowden]

Hah! yes, what you're looking for here was previously implemented on a site I had running for a while called 'parametricparts.com' The flow was <i think> what you want: (1) user 1 uploads a CQ script, and identifies the metadata for variables that should be exposed to the user. a url is created for that object. The author can change anything. Other users see the view were inputs can be changed (1a) user 1 optionally provides validation logic for the inputs. (2) user #2 visits, and updates the variables. the model is re-created in real time based on the new values, and sees the new model in a window. the result can be downloaded. The existing CQGI interfaces came from the use case above-- the need to separate the parameters and the metadata associated with it ( friendly names, bounaries, validation logic) from the model was pretty key. There wasnt a lot of interest, but i thought it worked well. The main reason for lack of interest is that there were very few people who are good at both CAD and programing, so very few people on the planet can make models with CQ. When I shutdown the platform, I think there were about 1000 users, but only about 200 had created models.

…

On Fri, Apr 26, 2019 at 8:37 AM Shreko ***@***.***> wrote: Here is an example. We are making shafts for power transmission equipment. Shaft has a main diameter, turn down diameter, length, length of turndown, keyways and distance from end to keyway. Only predetermined dimensions would be shown on 2D. User would only fill out an html form with D = 2.4375" (shaft diameter) d = 1.9375" (turn down diameter) L = 44" (shaft length) TD = 9" (turndown length) K = 11" (keyway dist. from end) User submits this form to a flask app, which in turn sends this to a shaft method with CQ instructions. Once model is done, exports it to svg, add these predetermined dimensions to it and flask app returns svg with dimensions to user. User wouldn't be adding any dimensions on their own, all dims would be predetermined for a type of part Thanks — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#122 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJ44A5ABBXHRCTJUWWO6SLPSLZPLANCNFSM4HINAE7Q> .

[shrekuntu]

I think it's even simpler than that. Users (our sales guys) can't make their own models outside what I would program fro them. For example, we may offer plain shaft with no turndowns and shaft with turndown. That's it. I would program model creating in CQ based on their html from input and they would get back 2d view with dimensions.

Thanks

[dcowden]

yeah, i see. you need the same functionality, but it doesnt need to be as generalized. What if we worked towards getting a docker image that produces the ability to run as a server and provide REST endpoints to build models and give results? then , the steps to do what you want would be to run the cq docker image, and run another nginx server with your static frontend....

…

On Fri, Apr 26, 2019 at 10:25 AM Shreko ***@***.***> wrote: I think it's even simpler than that. Users (our sales guys) can't make their own models outside what I would program fro them. For example, we may offer plain shaft with no turndowns and shaft with turndown. That's it. I would program model creating in CQ based on their html from input and they would get back 2d view with dimensions. Thanks — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#122 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAJ44AYAZ22EB7GJBEZ7LB3PSMGGLANCNFSM4HINAE7Q> .

[shrekuntu]

Setting up nginx, flask, validation is not a problem. Question is what is the best way to add dimensions to an svg?
Something like, we need to know where reference center point of the model is on the svg and what is the scale, so we can find bottom left points of the shaft ends so we can add shaft length dimension below the shaft if that was predetermined location of the shaft length dim.

Or even better, if we could name some points in in the model, for example for shaft 3" dia x 44" long, "bottom left" would be (-22,-1.5) in XY, and then if SVG export could somehow mark these points, it would be easier to add dimension entities.

[jmwright]

@shrekuntu Marking of features is something that we've discussed in the past, but CQ is not capable of it currently. The move away from FreeCAD to PythonOCC should enable it though. Our SVG exporter already adds an origin marker to the SVG text in the file.

If you are able to figure out a way to translate between the model coordinates and the SVG coordinates, the SVG exporter could be modified to append arbitrary SVG strings, allowing you to add generated dimensions. I suspect that this region of code is a good place to start poking around with this idea:

https://github.com/CadQuery/cadquery/blob/master/cadquery/occ_impl/exporters.py#L364

[SamuelReynolds]

Thinking aloud here...

A 2-D engineering drawing (front/top/left views) can be seen as simply a projection of a 3-D component onto X-Z, X-Y, and Y-Z planes. An isometric drawing is a view from a specific angle.

An approach for generating these from a model has occurred to me (while I was trying to get plugins to work on a rotated workplane--different issue). Note that this is a rough description (brain dump), and I don't have a handle on the CadQuery internals.

The approach is to (1) add annotations at the point where they apply, then (2) render them to "3-D" text at a later point using an annotation "context" tag. The 2-D planar projections would take care of flattening the text appropriately, or it could be "floated" in an isometric or other "3-D" projection.

A new method CQ.annotate accepts the following parameters and stores them on the current CQ object...

• context - label or list of labels to be referenced at rendering/presentation time
• atype - annotation type (dimension, note, centerline, ???)
• label - label text
  'context' would be one or more user-defined labels, such as "view.front", "view.left", "view.isometric".

Another new method CQ.render_annotations (or a function render_with_annotations) accepts one or more context labels (e.g., "front_view", "motor_notes"). It walks the stack and finds only the objects that are tagged with the specified annotation context(s). It computes and adds any necessary extension, center, and dimension lines and the corresponding labels and renders them into the model.

If .render_annotations(...) is not called, exporters ignore/discard the annotation information.

For a top/front/side 2-D engineering drawing, one would create the model, then call .render_annotations(...) (or .render_with_annotations(...)) three times, once for each view.

Rendering annotations into the model means that only one layout "engine" is required.
However, instead of rendering annotations into the model, it could be left up to the exporter(s) how to render the annotations.