_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI I designed my LED matrix PCB with code
alnwlsn wrote 19 hours 52 min ago:
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.
ginko wrote 12 hours 34 min ago:
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.
URI [1]: https://github.com/ginkgo/trackball/
crote wrote 3 hours 46 min ago:
> 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]:
URI [1]: https://wiki.freecad.org/Topological_naming_problem
LiamPowell wrote 9 hours 12 min ago:
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.
ginko wrote 7 hours 39 min ago:
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.
LiamPowell wrote 7 hours 57 min ago:
As an example of this:
Here's a hinge mechanism: [1] Here's the very first sketch in the
timeline, I've just clicked on this to edit it, there was no
undoing required: [2] Here it is overlaid on the model, which
just requires a single mouse click to toggle: [3] Here it is
after I changed a bunch of numbers: [4] Here's what it looks like
when I press the button to show the final model again: [5] 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: [6] 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:
URI [1]: https://files.catbox.moe/06g9cg.png
URI [2]: https://files.catbox.moe/xzr3un.png
URI [3]: https://files.catbox.moe/339fvg.png
URI [4]: https://files.catbox.moe/pvykrx.png
URI [5]: https://files.catbox.moe/6bjc0c.png
URI [6]: https://files.catbox.moe/eztkja.mp4
URI [7]: https://files.catbox.moe/f0bb2k.png
snops wrote 12 hours 52 min ago:
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
LiamPowell wrote 14 hours 51 min ago:
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.
vbezhenar wrote 16 hours 4 min ago:
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.
buescher wrote 18 hours 58 min ago:
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.
crote wrote 3 hours 36 min ago:
> 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.
seveibar wrote 19 hours 32 min ago:
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
URI [1]: https://docs.tscircuit.com/footprints/constraint
mystified5016 wrote 21 hours 8 min ago:
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')
krasin wrote 15 hours 34 min ago:
> Slightly tangential, but what's the state of the art in auto
routing and placement these days?
I always recommend quilter.ai: [1] - 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.
URI [1]: https://www.quilter.ai/
alnwlsn wrote 18 hours 44 min ago:
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.
zjorzzzey wrote 21 hours 24 min ago:
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: [1] (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!
URI [1]: https://ledsrace.at/zandvoort
joshvm wrote 19 hours 26 min ago:
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.
Neywiny wrote 21 hours 29 min ago:
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.
Neywiny wrote 25 min ago:
Looking back on this, lots of typos. I must've been really tired. I
hope the point still came across.
synapsomorphy wrote 21 hours 32 min ago:
Atopile is another thing in the circuits-as-code space: [1] 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.
URI [1]: https://github.com/atopile/atopile
kev009 wrote 15 hours 51 min ago:
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.
bb88 wrote 18 hours 13 min ago:
> 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.
crote wrote 3 hours 22 min ago:
> 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.
bogantech wrote 15 hours 6 min ago:
> 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
cactacea wrote 18 hours 4 min ago:
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.
0_____0 wrote 14 hours 56 min ago:
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.
tuetuopay wrote 11 hours 12 min ago:
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.
0_____0 wrote 5 hours 51 min ago:
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?
mystified5016 wrote 20 hours 57 min ago:
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?
imrishabh18 wrote 12 hours 14 min ago:
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!
URI [1]: https://docs.tscircuit.com/intro/quickstart-cli
saidinesh5 wrote 15 hours 17 min ago:
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.
0xFF0123 wrote 21 hours 34 min ago:
See also
URI [1]: https://github.com/atopile/atopile
sgnelson wrote 21 hours 38 min ago:
SVG PCB is a similiar concept. The nice thing is that it allows both
code and gui manipulation of the design.
URI [1]: https://leomcelroy.com/svg-pcb-website/#/home
apexedison wrote 16 hours 9 min ago:
Thanks for the shout-out.
boznz wrote 22 hours 11 min ago:
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:
URI [1]: https://rodyne.com/?attachment_id=1753
crote wrote 22 hours 25 min ago:
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]:
URI [1]: https://docs.ergogen.xyz/
seveibar wrote 22 hours 3 min ago:
(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)
whartung wrote 22 hours 30 min ago:
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.
convolvatron wrote 22 hours 33 min ago:
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.
crote wrote 22 hours 16 min ago:
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
URI [1]: https://wiki.freecad.org/images/thumb/7/71/FC_ConstrainedSke...
seveibar wrote 22 hours 14 min ago:
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
URI [1]: https://docs.tscircuit.com/footprints/constraint
mschuster91 wrote 22 hours 3 min ago:
What I'm missing is something like , just for generic connectors
- say, .
Also, for resistors, is there a chance for PTCs and NTCs? And
would benefit IMHO from a variant="[zener, schottky, photo]" plus
associated parameters for them.
seveibar wrote 21 hours 56 min ago:
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 (very
general purpose), but 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: [1] 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.
URI [1]: https://github.com/tscircuit/props/issues/211
mschuster91 wrote 21 hours 51 min ago:
> 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!
bogantech wrote 23 hours 0 min ago:
Horrendous routing
tuetuopay wrote 22 hours 46 min ago:
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.
mschuster91 wrote 23 hours 8 min ago:
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.
DIR <- back to front page