Hacker News Reader

Comment by mlsu | Hacker News Reader

One thing that surprised me when moving from mechanical CAD to EDA programs is the lack of "relations." I have not used the more professional tools, just KiCad, but it surprised me that there are not more variables, relations, constraints, subassemblies, for things like buck converters and these types of things. KiCad has 'netclasses' which let you set trace widths, but it's all manual, same with the design rules checker. Each vendor seems to have their own design manual for these things, which is nice to have but so tedious -- I have to read a PDF to know what size decoupling cap goes with this IC? Why is that information not encoded in the footprint somehow?

I understand that auto-routing is not a solved problem by any means, but there should be more efficient tools to make it easier. I shudder to imagine laying out some big LED matrix without more advanced tooling.

View on HN

For sure, its a big benefit of using language, it is comparatively very fast and easy to define custom relationships of component values, trace widths etc that would quickly become untenable in a point and click tool. We think the path forward is to be able to encode the governing equations that you would get in say a buck controllers data sheet directly into our source code. That way from a user perspective you can define your circuit simply by importing modules, defining them (for example input voltage, output voltage and current) we can then solve the component values and pick them from our component database for you. One of our early users wrote a plugin to do LED arrays in an afternoon. Our compiler is all open so its pretty easy to add on custom scripts for whatever you might be wanting to do.

look at OpenSCAD, it's a scripting language to generate models. I used this a lot to generate subpieces and build off of that. easy as saying Bolt("M5", 1.5) or something

Ya OpenSCAD is great for in/cross project re-usable components.

The only issues I've had is how it outputs circular things for cutting - it does a series of polygons (configurable number), rather than an arc/circular - places like send-cut-send won't accept it, claiming it causes issues with their machines.

Old issue, but annoying nonetheless. Less of a problem when outputting STL files (for printing) which only support polylines and not arcs/circles. Funnily enough, 3D printers nowadays support arcs natively in G-code, so some slicers support detecting rounded polylines and converting them back into circles or arcs.

Found a script[0] that does this for DXFs in a github issue[1].

[0]: https://github.com/nophead/Mendel90/blob/master/dxf.py [1]: https://github.com/openscad/openscad/issues/4605

I actually opened that issue - I'm ukd1 on github too. I looked at fixing it at some point, but it tbh didn't seem that easy or like they had time to help, I should probably revisit. The script I couldn't get working right last time I tried, but I should give it a re-look!

I have used it, I think its great. I am excited to see whole products defined in code.

I found OpenSCAD's 3d model representation to be very challenging for anything complicated. I used FreeCAD, which is scriptable, but also uses a brep representation instead of CSG, which IME works a jillion times better.

As a regular OpenSCAD user, I wouldn't bring it up as a good solution for anything. It exists, you can solve problems with it, but it isn't a good design. It should just be a library in a real language.

> It should just be a library in a real language

The last thing I want to worry about is having malware in an M5 bolt.

From a security perspective, it does help that ato is not executable!

I've found CadQuery to be a pretty good replacement for my purposes, but I haven't done anything complicated with it yet, just designing 3D printed/laser cut electronics enclosures.

Reply on news.ycombinator.com