hckrnws

Wish I could comment on the routing like others but the render is stuck at 96.2% for me. Nothing else on the page shows it on my phone so I assume that's the problem. (And of course nothing in the log of error tabs).

I think just looking at the first code example you can already see the problem. A lot of duplication and hand written or auto generated code. I thought the point was to define it in the code. Put an array of pin functions. For loop the footprint. That kinda thing. This looks like a mess to get started with and even worse is at higher point count parts it looks like it'll balloon in maintainability. Altium has very solid footprint generators with a nice menu. This looks like it's missing an overarching API for creating these long lists of parameters. Doesn't feel like the juice is worth the squeeze on this one. If it's a simple schematic, just do it by hand. If it's complicated, this feels harder to wrangle.

Another example of weird code is the previousLedName. Like like really that variable isn't used and the first term of the && should be that indeed check. But even more so, it should be an if statement not rely on remembering short circuiting (lazy evaluation) tricks. Because that's what you mean. You mean if it's not the first one, connect to the previous one. So, the code should say that. I find it hard to believe such a high level language would prevent it.

I think the pin label lists don't make sense. They're maps where the value is an array where the first element is the key? Why is this not just a list of pin numbers to names or a map of they're not contiguous whole numbers?

And then the icing on the cake: you still have to define where in XY everything is.

So really, in thinking about this, this looks more like a file format than a tool. And maybe that's fine. But I'll stick to the native formats of the tools.

Looking back on this, lots of typos. I must've been really tired. I hope the point still came across.

Interesting, reminds me of a project my colleague has just been working on: using KiCad + python to auto-place LEDs at specific coordinates on a PCB. Instead of positioning them as a regular matrix, the LED locations are derived from the shape of a racing circuit: https://ledsrace.at/zandvoort (routing and non-LED part of the layout was still done manually)

I don't think 100% auto-placement/routing will be able to take over manual layout, but there is definitely lots of potential for further automation!

This is a really good use case, though I'd be surprised if there aren't macros to do simple grid layout already in Altium or KiCad. It's the sort of thing you'd find in a badly documented Eagle userscript. I recently made a smaller PCB with 30 LEDs in a specific colour arrangement and even that was a pain by hand.

Jlcpcb, the manufacturer mentioned in the article, has a graphical editor with grid functionality and they even have a JS API if you want to automate PCB changes like arranging LEDs or renaming components.

Yeah I'm not surprised this is a feature in other EDA packages, it's something I'd like to explore more, in combination with OpenSCAD. I've been pretty happy with the few things I've tried from JL, though I'm a longtime supporter of OSHPark and I think their finish/price ratio is still excellent.

i scaned the article but didn't see this. declarative netlist is probably ultimately the right thing. but one place where I got alot of leverage was writing generators for footprints. its so much nicer to say 'this pad is 0.8 x 0.3" and i'd like two rows of them separated by 4mm with a 1mm pitch than to draw little rectangles with the mouse and getting them all to line up. i dont know if more professional tools do this, but integrating that into kicad made me much happier about the whole process.

Honestly? I want a footprint editor with constraint-based modeling.

The datasheets often show measurements like the horizontal distance between the leftmost side of the left-row pads and the rightmost side of the right-most pad, and the distance between the rightmost side of the left-row pads and the leftmost side of the right-row pads.

Converting that into the stuff you need to enter in the editor (width of pad, distance between center of pad and center of footprint) isn't hard, but it is cumbersome and error-prone. Being able to directly enter it as constraints[0] would make it literally an order of magnitude easier to input, and it would allow for a simple 1:1 comparison with the datasheet for verification.

[0]: Something like https://wiki.freecad.org/images/thumb/7/71/FC_ConstrainedSke...

tscircuit maintainer here, we actually do support constraint-based modeling for footprints, although we don't use it often because we also support "short string" footprints which are often faster

https://docs.tscircuit.com/footprints/constraint

What I'm missing is something like <pinheader>, just for generic connectors - say, <connector variant="[microusb,miniusb,usba-female,usba-male,vga-male,vga-female]">.

Also, for resistors, is there a chance for PTCs and NTCs? And <diode> would benefit IMHO from a variant="[zener, schottky, photo]" plus associated parameters for them.

We think that intuitive element names should be added to the tscircuit spec, even if they're redundant/there are multiple ways to do something. Right now you would probably use a <chip /> (very general purpose), but <connector /> is a great proposal for an element.

Yes diodes should have variants, I was surprised this wasn't already in the spec and created an issue to add it: https://github.com/tscircuit/props/issues/211

Yes we would support PTCs and NTCs for resistors, in general anything that helps with simulation, part selection, design intent, functionality, placement or appearance is in scope.

> We think that intuitive element names should be added to the tscircuit spec, even if they're redundant/there are multiple ways to do something.

Definitely makes sense, the question IMHO is what is the best way to interface with existing parts libraries. Making up individual names for each of the probably hundreds of thousands of connector types is going to be a looot of work.

And then, to add insult to injury, for some connectors there are so many different sub-variants as well. RJ45 with and without magnetics (I see inductors and (auto)transformers aren't present at the moment either) and LEDs, USB-C with some connectors being flush with the PCB and others that are designed to be placed in a PCB cutout... or PCIe connectors which can be had in physically closed and cutout variants (aka, an x1 socket that accepts x4/8/16 cards).

I hate connectors, in case it isn't apparent :'D

> Yes diodes should have variants, I was surprised this wasn't already in the spec and created an issue to add it

Thanks!

I took a stab at something like this. My intent was that you’d be sitting at a Common Lisp REPL, and start entering commands.

As you did this, a graphical window would show your components and traces. I considered similar to a legacy AutoCAD, way back before pointing devices were commonplace.

I had a whole simple dialect to easily identify traces, which you would continuously split with points, then nudge them around or anchor next to other points.

I honestly felt, especially for the small board project I was working on that writing this from scratch would have been faster than fighting KiCAD or any of the similar tools.

But I was stymied with finding a good way to get graphics out of CL on my Mac. I even considered doing it all in SVG with some kind of auto reloading file, and just rewriting it each time.

Obviously I did not put a lot of effort into it, had enough friction to move on to something else.

You could use AI to build this, I believe, in a few days. Especially having thought about it, oneself, for a few years ..

If I understand this correctly, in the end, JS/TS is being used only as a template language (similar to React, Lit, ...) to render out XML that is then picked up by a router and rendered out into something a PCB fab shop can use?

Nice idea.

Atopile is another thing in the circuits-as-code space: https://github.com/atopile/atopile

As a half EE/half SWE I think there are significant benefits to circuits as code but I'm not impressed with this one. Atopile has a narrower focus (autorouters are really really hard) and doesn't use as many buzzwords. Like why on earth does a "web first approach" matter at all for hardware development?

But also, GUI tools are getting better, Kicad 9 had a lot of changes that made templating / reusing blocks easier. And it works fine if not great with version control.

I don't see circuit-as-code taking off with humans anytime soon, it's much better but not enough better to convince EEs many of which don't code much or at all. But I can see it becoming much more common as LLMs get better at complex circuits.

I don't know why anyone wants to shove big heavy applications into browsers. Are they imagining you'd use your phone for this?

Are we not teaching kids how to publish desktop applications these days or what?

It's just not that we are imagining that people will be using phone to build PCB's, we also have a cli which perform better than the browser playground!

https://docs.tscircuit.com/intro/quickstart-cli

My guess is the cross platform story.

For cross platform development we barely have any decent, free development tools. It's a lot easier to find JavaScript developers in most places than c++/c# developers.

It's probably a simple economics thing. You can hire out a contract PCB design for a reasonable cost and the long poll is getting back physical prototypes. Contrast to HDLs displacing schematic based designs for ASICs and programmable logic, where simulation allows for rapid development.

I'd say it's significantly different because you can get a physical PCB prototype in days for a few dollars while an ASIC prototype takes months and millions.

I'm not sure if you missed the point. HDL design work is done by simulation for countless iterations before ever making it to a physical prototype. ASIC prototypes come very late in the cycle and are usually a low digit number of revs. So the point is simulation carries you through most of the design feedback cycle, and a significant economic and technical effort went into industry automatic place and route, DRC/LVS, etc. I am also ignoring the human heavy side of layout especially around analog and RF which is more like PCB design still.

A PCB can be reworked by hand on site. And those revs can be incorporated cheaply as you say. So the need to do all this programmatically is lowered below the economic threshold to make it all plausible in most cases. This presupposes that modern PCB tooling is itself semi-automated and includes simulation capabilities, but an expert operator is doing a lot of the decision making.

> I don't see circuit-as-code taking off with humans anytime soon

I don't agree with this. Circuits aren't really anything more complex than anything else humanity has had to figure out. Most knowledge in this area seems solvable.

Maxwell's equations have been known for a century.

For whatever reason, Software Engineering and Hardware Engineering even though they rely upon the same fundamental physics, are so very different? And apparently can't be reconciled? No. I don't believe it.

PCB layout is as much art and black magic as it is science. I'm not sure why you dismiss the complexity so easily, this definitely is not just a matter of applying Maxwell's equations.

Layout is a puzzle, especially with particularly high density layouts, but some of this is ameliorated by high layer count and fine trace/space boards becoming cheaper. Definitely not black magic. RF layout is black magic, let's not steal their thunder here.

High speed PCBs are RF. At high enough frequencies, traces become waveguides, and the result cannot be predicted analytically. Simulation is your only light in this mess.

I have been lucky to not have to lay out anything that had frequencies of interest over 1Ghz or so. What's your experience been? E.g. types of signals, frequency range, issues you ran into?

Signals that arrive faster than what the speed of light should physically allow for that trace length because you made the corners too sharp and then instead of flowing along your path the electricity creates a magnetic field which then induces a current and that allows the signal to tunnel through non-conductive walls.

High speed boards cannot be simulated well. Because they are far from deterministic. That's what makes them so different from coding.

What was the context you had that issue in? RAM bus?

It's just across-modal. The list of components are linear list, connections between components are graphs, placements are geometrically constrained, and overall shape is both geometric and external to the board. So you can't just mechanically derive the board from mere linear textual descriptions of it.

A lot of automagic "AGI achieved" LLM projects has this same problem, that it is assumed that brief literal prompt shall fully constrain the end result so long it is well thought out. And it's just not how it - the reality, or animal brains - works.

You need a LOT of context about what the components are and how they're being used in order to route them. Extreme case is an FPGA where a GPIO might be a DAC output or one half of a SERDES diff pair.

Doesn't even have to be that extreme: there is no way port placements of a Mac Mini can be mathematically derived from a plain English natural language prompt, and yet that's what they're trying to do. It's just the reality that not everything happen or could be done in literal languages. I guess it takes few more years before everyone accepts that.

There's nothing new in EE under the sun. Hasn't been for 40 years really. EE's min/max a bunch of mathematical equations. There's a lot of them, but it's not nearly as difficult as people think it is. They end up being design constraints, which can be coded, measured, and fed back into the AI.

It's not even been three years since Github Copilot was released to developers. And now we're all complaining about "vibe-coding".

Design constraints that have so many factors that people still don't use autorouters for most stuff. You're not getting it, drawing the wires isn't the hard part, understanding the constraints is.

I think we agree with that part.

I once thought software constraints were so hard a machine would never be able to program it.

But on the other hand, there are tons of circuit boards designed day after day. If it was super hard, we'd not be able to have the tens of thousands of high speed motherboards that come out year after year.

Are you in HW design by chance?

Software and hardware are fundamentally different in the ability of the engineer to isolate working segments. You can take a piece of code and set up unit tests for it, and if you feel good about your test suite, you can be fairly certain that it will serve your engineering and product goals.

In hardware engineering, that kind of isolation is a liability. As a billing electrical design engineer, you should be working tightly with your mechanical and SW/FW/GW teams to optimize what you're building. The massive context and knowledge base you collectively synthesize a design from is a huge benefit, and things like your phone or laptop, or any piece of spaceflight hardware, would not be possible without it.

Example - you can take something like a motor controller. Easy peasy, you say. Grab the best stocked and reasonably priced TI IC off of Digikey and slap its reference design into your copy of Altium Designer. If you give it its own power, thermal, and packaging solution, you can absolutely silo that component and hand it off to an AI agent that builds that piece for you.

Congrats, you've built a standalone motor control module, which you can also buy off of Digikey for a reasonable price that is much cheaper than the time you spent thinking about this.

Also congrats, systems engineering wants your head on a pike and mechanical engineering has taped a picture of your face to a football and is kicking it around in the parking lot.

If you're designing into a product, you're working with the mech and systems teams to create an integrated product that meets the systems/module requirements. The context for this includes not just circuit function, thermal performance, what the EMI situation is, whether there's some room to push back on systems and product as you weigh thermal performance and device longevity against module volume, global industrial geopolitics and the effect on part availability (there's a tariff tickbox in Digi-key now, and during COVID I had to redesign parts several times before being able to actually build them because parts became unavailable overnight due to panic buying).... the list is huge.

The cost of "compiling and running against the test suite" is also huge, because it involves typically weeks of answering questions/issues from the fab/assy, waiting for them to build and ship it, doing electrical bring up, actually running the tests you care about...

It is also hard to catch design issues in schematic or layout reviews. We don't have comprehensive and ubiquitous models for electronic devices, so we can't economically simulate this stuff.

This huge cost means "mashing GO until LLM spits out the right code" can't work, at all.

If you really do want to apply AI to EDA software, I think there's actually a really good use case in being able to catch small issues in a board, things that are too small to address in design reviews but have a meaningful impact on bring-up timelines for R&D test articles - stupid things like having a footprint flipped, or drawing the schematic symbol for a slightly different version of the part that has subtly different power pin configurations (my latest fuck-up). That is a fairly tightly containable problem, because our schematics all have links to vendor data and PDF datasheets that should be easily ingestible, and in practice there's often a lot of EDA users copying pins configs into their tools. I think AI would actually be good at catching the "dumb" errors that are sort of hard to see for humans.

So "not everything happen or could be done in literal languages" is the part that got you?

18ghz circuits were around since 1973 was the part that got me.

Your response doesn't really add to the conversation so I'll stop here.

> For whatever reason, Software Engineering and Hardware Engineering even though they rely upon the same fundamental physics

Software engineering isn't a thing besides being an ego title.

Software is "ship now, patch later"

Hardware is engineered, it must be correctly designed from the beginning and cannot be easily modified in the field

[dead]

> For whatever reason, Software Engineering and Hardware Engineering even though they rely upon the same fundamental physics

They are completely different. Software is pure mathematics: you know exactly what goes in, you know exactly what operations it is going to do, and you know exactly what will come out. There are no surprises here, it's just a mechanical translation. If you want to, you can even prove that your code is doing the right thing.

Hardware is physical. Your components don't neatly follow mathematical models - the model is just a rough approximation. Everything interacts with everything else: a signal in one trace will impact a signal in the next trace over - or even on the other side of the board. Your PCB will behave differently if you hold your hand above it - without even touching it. Worst of all, most of your components are black boxes, and you don't have accurate models describing them! What good are Maxwell's equations if there's no way you're ever going to solve them?

You can make a reasonable estimate of how a PCB is going to behave, and you can occasionally do a reasonably-close simulation of some part of your circuit-to-be in isolation. But you need to physically manufacture it to find out whether it behaves the same in practice, and it takes weeks of time and thousands of dollars to manufacture a single prototype. You can't "move fast and break things". You can't afford to do the usual "hit a bug, change tiny thing, recompile, check" cycle you're used to from software programming, and some fancy tooling isn't going to change that reality.

Slightly tangential, but what's the state of the art in auto routing and placement these days? I haven't tried any since I used EAGLE a few years ago.

I know routing is one of those really hard problems, and for a long time they were all pretty bad at even moderately complex or constrained designs. Have things gotten better recently with the rise of machine learning? (Specifically not 'AI')

Most routers (including humans) haven't even figured out that you can run traces in more than just 8 directions :) I quite like autorouted boards in TopoR for this reason, but it's hardly cutting edge; been around for decades.

I hear Altium has some pretty decent autorouting. The problem here is that by the time you've set up all the grouping, constraints and settings to get an auto route that works well, you probably could have just routed the board yourself. So I've never used it once. There's still no magic button you can click once to make a full routed board. As far as I know, autorouting for all the big players is still based on tried and true algorithms like A-star. They might be getting a little better year over year, but not so much so that anyone noticed.

I have seen quite a few improvements in manual routing though. It seems like the manual routing tool has gotten better at pushing traces out of the way, and if you move a routed component you might not need to redraw all the traces going to it anymore.

> Slightly tangential, but what's the state of the art in auto routing and placement these days?

I always recommend quilter.ai: https://www.quilter.ai/ - they "eat" Kicad or Altium files, and produce autorouting and/or autoplacement. I tried them about 9 months ago and made a couple of boards that worked well.

I've been working on CircuitPainter, a Python-based system for generating PCBs. Some examples are here: https://circuitpainter.blinkinlabs.com/examples.html .

It uses KiCad as a backend, so you are able to take advantage of the design rule checker and other niceties that come from the traditional CAD world. We've been using it successfully to automate very repetitive design jobs at our studio.

I'm genuinely surprised by how awful the resulting PCB is. A trivial LED matrix like this is pretty much the best-case scenario for tooling like this. Not being able to handle this is a pretty damning - although a decent bunch of the blame should probably be placed on whatever third-party autorouter they are calling out to.

Even with better results, the big issue with tools like these is that they simply don't match with the kind of development style that's needed for the problems at hand. You see the same issue with those drag-and-drop visual programming languages, or scripted modeling like OpenSCAD: they end up making fairly trivial details slightly easier, while significantly complicating the meat-and-potatoes. Nobody cares about a neat little part placement for-loop if it generates a living hell of autorouted spaghetti you can't possibly interpret and fix manually.

In reality the low-hanging fruit has already been covered by existing tooling. Automatically generating symbols and footprints from textual descriptions is routine practice, and software like KiCad already has a reasonably usable scripting API and a well-documented file format. A lack of code-based code-based EDA hasn't stopped projects like Ergogen[0] from popping up. The main limitation for additional automation is a lack of reliable input data, and user-side tooling can't fix that.

[0]: https://docs.ergogen.xyz/

(tscircuit maintainer here) It might be easier to think of tscircuit as an electronics CAD kernel. We're MIT licensed and web-compatible, so we would make a great foundation for people building new EDA tools or people who would like to generate electronics (think domain-specific tools, e.g. a website that allows you to quickly build a custom keyboard)

FWIW In this case I think this board called out to freerouting for the routing. Companies have reached out to us with autorouting APIs, so we'll support different vendors and hopefully allow enough constraint-specification for people to get good results. Autorouting is important for reusability, even if it's routing between manually-routed sections (e.g. fanouts)

I guess it kind of works, but why would you? I find it quite therapeutic designing PCCB's. My last try at getting AI to draw a circuit diagram was actually quite hilarious: https://rodyne.com/?attachment_id=1753

SVG PCB is a similiar concept. The nice thing is that it allows both code and gui manipulation of the design.

https://leomcelroy.com/svg-pcb-website/#/home

Thanks for the shout-out.

See also https://github.com/atopile/atopile

Horrendous routing

The author aims at developing their own autorouter and has a few blogposts on the topic. I guess the board is autorouted, hence the ugly-looking routing.

A lot of deserved criticism in the comments here tonight, but more generally, I have to ask - what's the deal with all these code/text to CAD/PCB things?

There's a half dozen of them in any category, they are all different, they all seem to struggle badly with anything outside of simple examples, none of them appear to consider how things fit together in the real world, you almost never see any of them used for anything more complicated than a keyboard layout or an LED matrix, they all have reinvented the wheel instead of using industry standard formats, and they all talk about the "difficulty of using traditional tools" as though placing each XY point in space in your head is easier than dragging things around the screen like in MS Paint. You also never see any serious hardware people use them. Every one wants to do it all from keyboard to finished product instead of being satisfied as a intermediate tool that does one thing well.

But, they all have very polished documentation, they come with examples, they have nice looking websites, and it's obvious someone put a decent amount of thought into making them. It's not like they are useless either. Making a big grid of things? It's nice to be able to write an algorithm to do that instead of entering them by hand.

I brought this up in that post about the LLM to CAD thing the other day. It's like people keep saying "hardware is hard" but then keep trying to solve it like they would work on software problems.

At a high level I think a lot of it is simply hubris from software engineers who see the basics of electrical engineering or 3D CAD and think that the basics are all there is to the field. It's the same as when people see a hello world or fizzbuzz program and think that's representative of software engineering before proposing no-code solutions.

Anecdotally as someone who studied mechatronics: Software engineers are far worse than any other engineering field in assuming that everything is trivial compared to SE.

When I'm using Fusion 360, I can't stop thinking that this whole experience would be much better with code. It has awesome underlying engine, but GUI UX is just terrible. I'd prefer to describe objects in code, observing code output in real-time on adjacent panel, using proper text editor to apply changes.

I've used OpenSCAD, it's not the thing I want, it doesn't have constraint solving, the key is using constraint solving with feedback to highlight warnings, etc.

Now maybe I'm not talking about complete replacement of GUI with code, but rather an alternative view, where you can either use GUI to model objects, or switch to code where everything is synchronized.

They're aiming to recapitulate the success of HDL design in the IC world. The jitx folks are pretty clear about that. There are a lot of problems with that that could be a medium-sized think piece, but some things folks are doing in the space are neat. PCB-level EDA is overdue for better design checks, for example.

> PCB-level EDA is overdue for better design checks, for example.

The software itself is perfectly capable - the problem is in the source data. The industry-standard data format is "datasheet PDF written by intern".

If you want better design checks you need someone to manually read and interpret a whole bunch of nonstandard and confusing datasheets, and enter it into your EDA software. And no, LLMs won't save you here: the tiniest detail is critical, and due to the habit of using one datasheet for a whole family of chips they are often self-contradictory to a casual reader.

Alternatively, get hundreds of competing manufacturers to agree on a single data exchange format, and get them to rewrite their documentation for a few decades worth of parts into that format - for free, with zero additional sales.

I can only talk about my own experience trying to learn FreeCAD for a project[1] I eventually used Build123d for.

For me FreeCAD was highly unintuitive. Everything is a chain of operations/modifications on solids(good!) but for some reason it won't let you modify anything but the last element in the chain?

I was working on a trackball device so part of the parameters are the size of the trackball you'd use.. This affects pretty much all the parts in the chain but you have to decide all the way in the beginning on what size you need. In code-based systems this is simply a variable you define in the beginning and can modify at any point. Let's say I want to use M2 screws instead of M3 ones or use a larger bearing: I can just change a variable at the start of the script.

Being an absolute beginner I also had to reorganize stuff a couple of times. With python/build123d that's a matter of shuffling around code in your editor. I don't even know how you would do that in FreeCAD without deleting and redoing large swathes of your design.

Then there's my general unease dealing with this opaque representation of your model where any previous step you may have took puts your project into some state that can't really be undone or at least not intuitively found. When working with code and something breaks you can usually recover from a broken state by stripping out whatever you were working on. At worst you can just go back to your last revision in Git. With GUI-based tools you have to pray that Undo/Redo gets you to a state you wanted without losing too much.

Maybe the proprietary tools work better here but they don't run on Linux and I also don't use them for ethical reasons.

Admittedly the whole experience with build123d is anything but perfect. I _would_ like to just pick stuff with the mouse where possible and have a nice real-time display of changes I make. Ideally I'd like to see some sort of editing graph where you can see intermediate steps and pick visually parts to operate on for the next step - all underpinned by a concise textual representation that can be versioned.

Maybe this is me showing SE hubris but it's how I was able to get a reasonably complex personal project done. Maybe programming somehow broke my brain, IDK.

[1] https://github.com/ginkgo/trackball/

The only thing FreeCAD has going for it is that it's free, everything else about it is far behind the serious commercial tools.

> Ideally I'd like to see some sort of editing graph where you can see intermediate steps and pick visually parts to operate on for the next step - all underpinned by a concise textual representation that can be versioned.

This is exactly how most[1] commercial 3D CAD packages have worked for at least the last 30 years, they've done it longer than Git or SVN have existed. Specifically everything is represented as a list of operations (sketches, extrusions, chamfers, etc.) and you can freely go back and edit any step, or you can click on any part of a model and see exactly what step was used to generate it.

Some CAD packages will let you see a textual representation, but it's only really useful for scripting when they do. The versioning tools that are built in to any CAD package are far better than trying to work with text.

[1]: Excluding the more obscure CAD packages like Creo that do things differently to fit in to a specific niche.

As an example of this:

Here's a hinge mechanism: https://files.catbox.moe/06g9cg.png

Here's the very first sketch in the timeline, I've just clicked on this to edit it, there was no undoing required: https://files.catbox.moe/xzr3un.png

Here it is overlaid on the model, which just requires a single mouse click to toggle: https://files.catbox.moe/339fvg.png

Here it is after I changed a bunch of numbers: https://files.catbox.moe/pvykrx.png

Here's what it looks like when I press the button to show the final model again: https://files.catbox.moe/6bjc0c.png

Just like that the entire model has changed based on the initial sketch. I didn't have to go edit any other features here.

As a bonus here's the assembly being moved by dragging the mouse after those changes, showing that this might not be the most well-designed hinge after those changes: https://files.catbox.moe/eztkja.mp4

Also here's the timeline I mentioned, you can see how I've clicked on a feature and it shows me exactly what it did, this also works when clicking on part of the model: https://files.catbox.moe/f0bb2k.png

Well, like I said: From open tools I had available b123d was the one that relatively quickly (within a weekend from picking up the tool) allowed me to mock up something to the point where I became confident enough to keep going.

I tried to do that with FreeCAD without too much success. I assume someone proficient with it could probably crank out the whole thing within an afternoon, but not me.

I'm sure professional tools are many times more productive, but you need to spend thousands of dollars and presumably months if not years of training to become proficient in them.

And admittedly that's more of a weird hangup of mine but to me it also sort-of misses the point to use a proprietary tool for building an open source project. No one without the tool could open the source files and make modifications.

> For me FreeCAD was highly unintuitive. Everything is a chain of operations/modifications on solids(good!) but for some reason it won't let you modify anything but the last element in the chain?

This has been a longstanding issue in FreeCAD. A big issue is that it is really difficult algorithm-wise to deal with changing geography: a tiny change might result in two objects which look the same, but have a completely different internal representation. If the next operation is attached to "face #23", it's going to freak out. This is called the "topological naming problem"[0], and it is pretty much impossible to solve completely.

FreeCAD itself can support the kind of parametric modeling you want, but because it's so fragile the UX is pretty horrible. To do it properly you essentially have to specifically design your entire model around being parametric from the start.

Luckily FreeCAD made some massive improvements in 1.0, and issues due to topological naming are now far less likely to occur. Hopefully it'll eventually turn from "guaranteed to ruin your day every time you try altering something" to "might need some manual adjustment in weird edge cases" - and that would also make it far more sensible to invest in UX for making mid-change modifications, or for modeling using variables.

[0]: https://wiki.freecad.org/Topological_naming_problem

XY coordinates are more or less temporary. We are working on llm-compatible layout definitions which operate more with constraints or loose auto placement specifications than XY directly eg https://docs.tscircuit.com/footprints/constraint

I think the most recent surge is due to LLMs, the only way to (easily) apply them is to have some form of code like textual representation of your problem domain so "circuits as code" is the obvious way to wedge them into electronic engineering.

Kicad also makes it easier to make such startups as it has an open file format with several different free viewer tools and lots of content (schematics/footprints). If that ecosystem didn't exist I don't think you would see as many of these startups around, but with that you can launch one of these tools within a initial VC funding