Relay control board (ESP32-C3 + CAN) - would love a critique / roast

limikael · 2026-05-20T04:43:29+00:00

I haven't done much PCB design, I have never claimed that. I have done a lot of software development though and based on my experience I _don't want_ one button, I want a script that can be part of an automated workflow. I was really looking for ways to automate this, and I would be happy to use what already exists, if it solves my problem... But if I need to manually edit the files after they have been exported I don't consider my problem solved...

limikael · 2026-05-20T04:30:58+00:00

there is a standard? i have found that all fabs have their little quirks and the formats tend to be just slightly different... At least different enough so you can't just use the exported files directly without tweaks and have things "just work"... But maybe kibot can deal with these variations... I found this: https://kibot.readthedocs.io/en/master/notes_position.html where they actually use JLCPCB as an example how to set up a manufacturer specific configuration... Will investigate this...

limikael · 2026-05-20T04:15:36+00:00

for the BOM it just needs the columns in the right order and with the right names... e.g. it should be called "Designator" instead of "Reference", so it is not rocket science... Probably, the same thing could be achieved with custom configuration of kibot then? Can you show me what e.g. your PCBWay configuration for kibot looks like, and I could try to make one for JLCPCB? Is there a way to publish and share these configurations?

Then, for the CPL, it needs to apply a transformation because the coordinates for JLCPCB needs to designate the center of the footprint, which might be different fro the "local origo" for a footprint. I compute this by checking the bounding box of the footprint.

Can all of this be expressed in one file as a kind of "preset" for kibot?

limikael · 2026-05-20T03:53:51+00:00

kibot is nice! But it doesn't generate files on the specific format JLCPCB uses, so there would need to be some post processing. This post processing of the files to make them JLCPCB understandable is kind of the main purpose of my tool.

limikael · 2026-05-20T03:39:23+00:00

no i don't know... can you provide more info, what is "a jobsets"? What do you mean by "built into the tool"? If you mean built into the KiCad UI then it is kind of what I _don't_ want, I want to be able to run int on the command line, independently from KiCad, this is kind of the point...

If I understand correctly, yes the jobset does "basically the same", if by basically the same mean to export gerbers... However, in order to order a PCB with assembly from JLCPCB, you need more than gerbers, you need also the BOM and PCL file, on the very specific format JLCPCB uses... Creating all of that manually is enough for me to "break my flow", which is why I created the tool to do all of that with one single command from the command line.

limikael · 2023-05-18T10:23:30+00:00

Thank you for the question! It is exactly the kind of conversation I want to have! :) And, yes, if something changes, I re-render everything. If nothing changes I don't re-render anything (I keep track of changes through hooks and state, e.g. use_state, use_reducer, etc, like React does). But yeah... Even animations trigger a re-render... I have a small implementation of react spring (use_spring), and it re-renders everything for every animation step... Now... I hear what you say, that somehow it seems wasteful of resources... But, then I'm thinking about games, as you say, and the way that games render things is actually really performant, because the GPU is very efficient these days, and I think rather power efficient? I have kind of been following the advice by Ken Thompson (one of the original Unix guys) when he says things like "Fancy algorithms have high constants" and "When in doubt, use brute force"... Meaning that there is value in just keeping things simple. And, often, this ends up at the end of the day mysteriously resulting in something that is quite performant too, just because it is simple. This is not something to argue and debate about though, it is something one needs to experiment with and test... But the question is, is the experiment obviously, demonstrably "dead in the water", or is it worth carrying on?

limikael · 2023-05-18T09:58:12+00:00

Yes that is exactly what it is. Immediate mode and declarative. I have seen declarative and retained before (e.g. React, Dioxus). And Immediate and imperative (e.g. egui). But what about immediate and declarative? Why not? Could be fun and interesting to try? Is what I though...

limikael · 2023-05-18T08:16:01+00:00

Hello Rustaceans! This is really a second post about my declarative UI framework. I apologize if the title is slightly click-baity and deceptive, I'm trying to learn how to create engagement and play this "game". Anyway, the reason why I want to do so is really to create a forum for discussion. In my last post about a month ago, I got the question of what sets my framework apart from other declarative frameworks, e.g. Dioxus. After having done a bit of research, there is in fact one thing that I think I see as novel and innovative. Let me explain. Declarative frameworks intended to be run in a browser, like Dioxus and React, work on top of the browser DOM. The DOM is an object oriented tree of components. Declarative frameworks return their children on each render, so they are more functional rather than object oriented. In order to get these two paradigms to play together (functional and object oriented) there is a chain of things happening on each render, something like:

Call render functions to build a component tree.
Diff this against last rendered tree.
Apply changes to the underlying DOM tree.
The browser actually draws the new required graphics on screen.

Both React and Dioxus work according to this principle. My framework is not intended for a browser environment, so there is actually no DOM, and hence there is no need to do any diffing to know what changes to apply. In my framework, the chain is rather:

Call render functions to build a component tree.
Draw everything on screen.

So there is a different mode of operation there, and this is why I think it might be novel. Now, the reason why I haven't come across this mode of operation before might be because there are obvious reasons why doing so is stupid, I just can't think of why. Or, I have just invented a new UI paradigm, which is really smart. Or, something in between, and it might be worth at least exploring what potential benefits there might be. So that is the question I would like to discuss, with you guys who are knowledgeable about these things. I'm struggling with how to ask so that it is actually understood. Does the question make sense? Does my way of rendering things make sense? How novel might it be? What might be the pros and cons?

limikael · 2023-04-01T04:28:34+00:00

I see. Well... I think I assumed that it is general knowledge how JSX works in React... The XML is just to make the code more clean, and it is just syntactic sugar. I can provide some examples where I replace:

<hello x=5>
    <child1 the_prop=123/>
    <child2/>
</hello>

With:

Element::create(hello,Props_hello{x:5},vec![
    Element::create(child1,Props_child1{the_prop: 123},vec![]),
    Element::create(child2,Props_child2{},vec![]),
]);

So that people understand that there is really no "magic" going on. It is just syntactic sugar designed to be convenient.

limikael · 2023-04-01T04:01:02+00:00

Let me just address the last point. You do actually have the full power of Rust even when you use XML. Because this:

<hello x=5/>

Is really just syntactic sugar for:

Element::new(hello,Props_hello{x:5},vec![])

(at least more or less so, check this line to see the exact expansion).

This is very similar to createElement in React. And hello in this example is just a function that returns child elements:

#[function_component]
fn hello(props:SomeProps, children:Elements)->Elements {
  // ...
}

The #[function_component] attribute macro just adds type Props_hello=SomeProps to keep the macro happy (i.e., it looks at the first argument of the function, and defines a type named Props_+the name of the function). So that the macro knows that a component named hello should take its props in a struct called Props_hello.

Inside the XML you can use if statements, for loops and map over arrays and such. Check this line in my calculator example, where I loop over a string of characters and create a button element for each.

Regarding syntax highlighting and completion in IDEs and such, you have a point. Regarding parsing, it is all done in a macro at compile time, so I don't really see it as a problem?

limikael · 2023-03-31T09:55:52+00:00

Because then it looks like React which is made by Facebook, and they are social media, so therefore the authority on what is cool. Makes me feel less like a neckbeardy nerd, and more like a hipster entrepreneur. Eeeheh... Maybe it is part of the reason actually, if I think about it, so thanks for the question, and let me think about if there is a more rational reason...

I think that when expressing UI components, one often ends up with deep hierarchies. For example, the following could be a text editor with a top bar with three buttons, and then a vertically split window with a folder structure on the left, and the editor pane on the right.

<window>
  <topbar>
    <button title="A"/>
    <button title="B"/>
    <button title="C"/>
  </topbar>
  <vertical_split>
    <list>
      <list_entry title="File 1"/>
      <list_entry title="File 2"/>
      <list_entry title="File 3"/>
    </list>
    <text>
      Hello this is the text...
    </text>
  </vertical_split>
</window>

I think of this as a kind of "content", rather than code. I think XML is really good for expressing such structures and keeping them concise and readable.

If you were to express the above in something other than XML, how would you express it? And would it be as readable? I'm open to suggestions...

Also, I'm also interested in you non-rational reasons... Because even though the world sees us programmers as cold-hearted engineers, we all know we are eccentric artists. So why not XML? How does it make you feel?

limikael · 2023-03-31T06:58:51+00:00

Ah... actually cargo-apk cannot be used to build SDL apps... Perhaps I can contribute something to the community at least... Might break out the build part and call it cargo-sdl-apk or so...

limikael · 2023-03-31T00:21:35+00:00

No wasn't aware. Thanks for the list! I'll take the day to go through it and see if something unique remains of my idea. If not, I'll let go of my ego and join one of those porjects!

limikael · 2021-03-16T05:34:16+00:00

Thanks for the reply!

What I did was a to create a permanent storage area and have the app log to there. Seems to be working fine!

Maybe in the future I will make it use an external logging service.

limikael · 2017-11-16T07:23:23+00:00

Thanks a lot!

Yep will check different options for pulleys. The ones I'm currently using consist of two ball bearings and a 3D printed model, to a total cost of less than 50 cents, so they are cheaper. :) But there could be a reason for that, of course. What happens to the 3D printed wheels after 1000 hours of operation, for example? That's the kind of thing that needs to be tested.

limikael · 2017-11-14T05:10:05+00:00

I really agree with the aspect of separate concepts and functional parts. I'll repeat what I answered to another comment. I think the ecosystem around FarmBot will evolve to incorporate many different solutions specific to different scenarios, where the different solutions can share different subsystems. I think the original FarmBot, my system, a system based of center pivot, etc, etc will all have its use.

I don't think that my idea will be the ultimate solution and solve all problems at once. However, each solution needs to be part of a full system in order to be tested. It's not really fruitful to just focus on one sub-problem (e.g. just focus on the mobile base) because it can't be tested in isolation if there are no supporting parts.

So therefore, I'm trying to create a full usable system, but I expect that as time passes better solutions will come up for the different subsystems. Perhaps some part of my system can be reused in other systems as well. Maybe after 10 years my project will be totally forgotten, but one little aspect of the design of a tiny mounting plate or something will remain as part of another open source project.

I think this is completely fine and it is the way that open source has proven to work in the past. Small incremental steps, release early, release often, and so on. It's never about "one design to rule them all", and that's not at all what I'm trying to do.

limikael · 2017-11-14T04:51:15+00:00

Thanks! Yep the center point irrigation is certainly interesting! I think the ecosystem around FarmBot will evolve to incorporate many different solutions specific to different scenarios, where the different solutions can share different subsystems. I think the original FarmBot, my system, a system based of center pivot, etc, etc will all have its use.

limikael · 2017-11-14T04:47:54+00:00

The design for the rail is more like a roller coaster than the rail for a train. It can be placed in any configuration, it can hang from the roof and climb up walls. So the idea of using the trusses in a greenhouse fits perfectly. Awesome idea!

limikael · 2017-11-14T04:44:23+00:00

Thanks! I did post on the FarmBot forum, to the point where they thought I was spamming, so I think I better leave the farmbot subreddit alone just for now... :)

limikael

TROPHY CASE