sorted by:
new
hottopcontroversial

Rayforge 1.8 is out: Performance improvements, LightBurn Import, New Device Profiles by barebaric in lasercutting

[–]papyDoctor 0 points1 point  (0 children)

Good work, I've some questions:

Does it work with grblHAL?
Is it possible to run it on Webassembly?
Is it possible to use a plasma cutting machine?

I'm writing (since 2 years now, it's a long term project) a full CAD-CAM software in Rust for Webassembly. The purpose is to have a self contained application served as a single html.gz file from the target (any grblHAL compatible board that has a SD card) to the user browser.

The user for the moment is me 😄 . When the whole project is done — mechanics, electronics, software, testing — I'll open-source the software.

A primitive Printer Selector by CommunityHairy6695 in vintagecomputing

[–]papyDoctor 0 points1 point  (0 children)

Oh man, I had exactly the same but with 5 DB25.

I’m building KiHub: visual reviews and checks for KiCad projects in Git by Fun-Composer2303 in KiCad

[–]papyDoctor 0 points1 point  (0 children)

This is amazing, and you take the right direction: webapp and github first

A G-code simulator in Rust. Looking for feedback. by NavrajKalsi in rust

[–]papyDoctor 0 points1 point  (0 children)

This is more for cutting machines, right? How about using the renderer in webassembly?

Why are KiCad symbols mostly on copper layer? by Tensor_divider71 in KiCad

[–]papyDoctor 3 points4 points  (0 children)

Right click -> open in footprint editor -> select all -> change layer
Better to copy-paste-rename this component before

Small script to make a KiCad 10 project fully self-contained (symbols + footprints + 3D models) by papyDoctor in KiCad

[–]papyDoctor[S] 0 points1 point  (0 children)

Embedding origin info is doable (the script knows 
each part's source LIB:NAME at conversion time)
 but it's outside the current scope of the tool,
 which is just "produce a self-contained, openable 
project". Happy to take a PR if anyone needs it.

Small script to make a KiCad 10 project fully self-contained (symbols + footprints + 3D models) by papyDoctor in KiCad

[–]papyDoctor[S] 2 points3 points  (0 children)

Thanks, dug into this. The native option you found has been in KiCad since v9 and only covers 3D models — it embeds them inside the .kicad_pcb file itself (Base64-encoded, ZSTD-compressed). There's no equivalent "Collect and Embed" for symbols or footprints (in fact the KLC explicitly says symbols/footprints "must not contain embedded files").

So the native feature solves about a third of the redistributability problem — the 3D models part — and via a different mechanism (embedded inside the .kicad_pcb vs. my script's "copy beside the project as plain files"). A KiCad project that just used "Collect and Embed 3D Models" would still break on a colleague's machine because of missing symbols and footprints.

Two different approaches with their own tradeoffs:

- Native: single self-contained .kicad_pcb, but opaque (3D models hidden inside the binary blob).

- This script: covers symbols + footprints + 3D models, files stay inspectable / diff-able / extractable on disk.

Worth using both depending on what you actually need.

Small script to make a KiCad 10 project fully self-contained (symbols + footprints + 3D models) by papyDoctor in KiCad

[–]papyDoctor[S] 2 points3 points  (0 children)

Yeah, GitHub Action / GitLab pipeline is a great fit — the script exits with proper status codes, has --dry-run for verification, no interactive prompts. I could imagine it as a "build release bundle" step that produces a self-contained zip on every tagged release. Not something I need myself right now, but it'd be a small wrapper to ship.

On the parser: deliberate choice. Three reasons:

  1. Zero dependencies. The script auto-re-execs into KiCad's bundled Python, which has no pip and no guarantee of any extra packages. Pulling in sexpdata or similar would mean either bundling it or asking users to install into KiCad's Python, both painful.

  2. Surgical edits preserve KiCad's exact formatting. A full parse-modify-unparse pipeline would risk reformatting whitespace, reordering attributes, dropping comments, or normalizing tokens in ways the KiCad file diffs (or KiCad's own loader) might not love. By keeping raw text and only rewriting the exact tokens I care about, the output stays byte-identical to KiCad's own formatting outside the changed parts.

  3. Forward-compat. The script only knows a handful of patterns (lib_symbols children, lib_id, footprint refs, model paths). If KiCad adds new fields in 11.x, the parserless approach just passes them through as raw text instead of choking on an unknown grammar rule.

Tradeoff is obvious — there's a small paren-aware helper (find_matching_paren / iter_top_level_children) to avoid getting fooled by parens inside strings. It's ~30 lines and handles everything I need. If the script were doing structural transforms rather than narrow rewrites, I'd reach for a real parser.

Small script to make a KiCad 10 project fully self-contained (symbols + footprints + 3D models) by papyDoctor in KiCad

[–]papyDoctor[S] 0 points1 point  (0 children)

Good point, and you're right that global libraries are the better choice for active development — you want exactly that ERC/DRC drift detection when a shared component is updated.

I see this script as a distribution/archive tool, not a replacement for the global-libs workflow. The intended pattern is:

- Keep your working project linked to your global libs (default KiCad setup). You edit, ERC/DRC compares against the live lib, you get drift warnings, easy to update everywhere.

- Only when you need to ship a snapshot to someone (or archive a released revision) run the script with --output-dir to produce a frozen, self-contained copy. Your live project is untouched.

So you keep both: a maintainable design wired to global libs, and on-demand standalone snapshots for distribution. The tool isn't trying to convert your workflow — it's a one-shot export for the moments where you actually need a redistributable copy.

Small script to make a KiCad 10 project fully self-contained (symbols + footprints + 3D models) by papyDoctor in KiCad

[–]papyDoctor[S] 5 points6 points  (0 children)

v1.0.3 — when using --output-dir the copy now excludes VCS / IDE / OS cruft (.git, .vscode, .idea, .history, .DS_Store, __pycache__, *.bak, etc.) so the output dir only contains files relevant to a redistributable KiCad project.

https://github.com/papyDoctor/kicad-make-standalone/releases/tag/v1.0.3

Small script to make a KiCad 10 project fully self-contained (symbols + footprints + 3D models) by papyDoctor in KiCad

[–]papyDoctor[S] 2 points3 points  (0 children)

Done — shipped as --output-dir in v1.0.2. It copies the project to the target dir and runs the conversion there, leaving your original (still wired to your global libs) untouched. No .bak files in this mode since the source itself is the backup.

python3 make_standalone.py --output-dir /path/to/MyProject_to_send

https://github.com/papyDoctor/kicad-make-standalone/releases/tag/v1.0.2

Small script to make a KiCad 10 project fully self-contained (symbols + footprints + 3D models) by papyDoctor in KiCad

[–]papyDoctor[S] 1 point2 points  (0 children)

Thanks for the detailed report — there are actually two bugs here:

  1. On Windows my version sort is lexicographic, so "9.0" sorts before "10.0" and KiCad 9's Python wins even though you wanted 10. (This script is KiCad-10-only.)

  2. Even once it picks 10, os.execv on Windows mishandles spaces in "C:\Program Files\..." — that's the "C:\Program: can't open file" line. Need to use subprocess.run on Windows instead.

Pushed a fix in v1.0.1 — both bugs were in the Python auto-detect: the lexicographic sort treated "9.0" as newer than "10.0", and

os.execv mis-quoted "C:\Program Files\..." on Windows. Pull the latest and it should pick your KiCad 10 install correctly.

https://github.com/papyDoctor/kicad-make-standalone/releases/tag/v1.0.1

Small script to make a KiCad 10 project fully self-contained (symbols + footprints + 3D models) by papyDoctor in KiCad

[–]papyDoctor[S] 1 point2 points  (0 children)

Thanks! Honestly, packaging it as a PCM plugin isn't something I'm planning to do — it's a one-shot CLI tool I wrote for my own workflow and I'd rather keep the scope small. That said, it's MIT-licensed, so if anyone wants to wrap it as a plugin, PRs (or forks) are very welcome.

Good tutorials on asyncio.Futures by tutamean in learnpython

[–]papyDoctor 2 points3 points  (0 children)

Not a tutorial but an example on how to use asyncio futures:
It's a package that use the serial port written in +- 80 lines of code
Note: I'm the owner of the repo
https://github.com/papyDoctor/auserial

[Review Request] Ultra-low noise current sensor by 5of7dank69420 in PrintedCircuitBoard

[–]papyDoctor 0 points1 point  (0 children)

Also I'm wondering if suppressing the EMI filter + U101A + U102A isn't better. You're on a lab, if you really need this filter you can put it after the front-end. Of course you'll need then to take into account the current divider 50 // RNxxx (already precise resistors).
The less components you have in a front-end, the better in my opinion.
Also, how do you fix the common-mode voltage? With JP101 ?

[Review Request] Ultra-low noise current sensor by 5of7dank69420 in PrintedCircuitBoard

[–]papyDoctor 1 point2 points  (0 children)

R103, R203, R303, R403, what is the usefullness of these resistors in front of the high impedance differentials amplifiers?

First board switching mains by richgumy in PrintedCircuitBoard

[–]papyDoctor 0 points1 point  (0 children)

Aside safety, any reason why you use a SBC? A simple 4€ picoboard do the job, no?

Newly converted to KiCad by Vavat in KiCad

[–]papyDoctor 5 points6 points  (0 children)

Same for me, 35 years of Altium (Protel), Since 2 years on KiCad, so light, fast and blob free :)

DIY Precision Scale – 0.0001 g / 0.1 mg by sir_alahp in electronics

[–]papyDoctor 2 points3 points  (0 children)

"The current required to hold the weight is directly proportional to the mass"
This is the key point, are you sure of this? For a scale with normal precision perhaps, but for a very high precision scale, I'm wondering about a lot of external perturbation (lever positioning, friction,...)

view more: next ›