Learnware

This was probably the most technically dense update so far, as I restructured the Learn mode to be modular and implemented a much more powerful calculation engine.
The Learn mode is no longer a single sequence of lessons but now has thematic modules (Ohm’s Law, Series vs. Parallel, and Multimeter in Practice (which is still to come)). Now, when entering Learn mode, you choose the module (1, 2, 3), and Esc always returns to the selection instead of exiting the entire mode.
Until now, the simulator could only perceive a single closed series circuit; it couldn’t build real branches. So, I implemented a new serial/parallel reduction-based engine that can correctly calculate any combination of series and parallel resistors mounted on the screen, including switches and buttons as part of the network. This engine coexists with the old one, and when the circuit has an LED or Motor, it continues to use the series chain logic, but when it’s just a resistive network, it uses the new engine. But there is still a limitation, since “bridge” circuits (which would require Kirchhoff’s Laws) are not supported for now; the program warns when it detects this situation instead of giving an incorrect result.
For now, the series and parallel module has 3 lessons: calculating total resistance in series, in parallel, and physically assembling two resistors in parallel to achieve a target current.
I also fixed a layout problem where longer statements went off the panel; for this, I implemented automatic line breaks that adjust the panel height depending on the text.

As I mentioned in the last devlog, I’m making changes to the learning method. In the last hour, I added things that were really missing from the simulator. I created a new type of lesson, “assemble_circuit,” where instead of typing a number, the user assembles the circuit on the screen and presses Enter for the program to automatically check if the assembled circuit meets the request (e.g., “achieves a current of ~15mA”). The verification uses the existing calculation engine, comparing the present components and the resulting current with what the lesson asks for, with a tolerance margin. While testing this, I noticed that there was still no way to adjust the component values ​​after they were placed (the resistance always stayed at 1000Ω, the battery always at 9V), which made Lesson 5 impossible to complete as planned. Even though I wanted to include this function from the beginning of this project, I hadn’t yet taken the time to do it. So I finally added value editing with the mouse wheel; now hovering the mouse over a resistor or battery and rotating the wheel adjusts the value in real time. The current value now appears below the component name (e.g., “Resistance (470Ω)”) (I wish I could add a screen recording to show this working, but it seems that only screenshots are allowed).
This ended up being a much bigger improvement than just “fixing” Lesson 5, since the simulator became much more realistic and experimentable, as before all components had fixed default values.

I forgot to mention on the last devlog, but answers now have a 5% tolerance if your calculator gives a wierd number for some reason

In this devlog and the next, I will mainly work on the learning mode, because the idea of ​​this simulator is precisely to teach people.
Instead of a single fixed lesson, there is now a list of 4 Ohm’s Law lessons, with increasing difficulty.
When you get a lesson right, pressing Enter again automatically advances to the next one. When you complete all of them, “All lessons completed!” appears and you exit Learning mode automatically.
During the tests I did, I noticed that Lesson 4 asked to calculate the resistance (given the desired voltage and current), but the code only knew how to check current responses, that is, the lesson was structurally inconsistent with the question it asked. So I corrected the Lesson class to support two types of questions (“current” and “resistance”), each with its correct formula, tolerance, and unit. The answer box now shows “mA” or “Ω” depending on what the lesson asks for.

In this devlog I only added things that I felt were missing. I implemented exporting the complete circuit to JSON for each component (type, position, color, inversion state) and specific properties (battery voltage, resistance value, switch state, multimeter mode), plus the wires and probes, all referenced by indexes so that everything can be reconstructed later quickly and without errors. I also implemented reverse loading; it reads the JSON, recreates all the components and ends first, then connects the wires between them in the correct order.
Shortcuts I defined: S to save, L to load.
I had left the saving and loading only sending an output to the terminal with print(), but I preferred to replace that with a visual notification on the screen itself. It’s basically a small box with a message that appears at the top saying “circuit saved” and “Circuit loaded” (in the printouts these messages still appear all in Portuguese because it’s my native language, but later in the project I intend to add support for other languages). This message disappears automatically after 2 seconds, so the user always knows that something has happened without having to look at the terminal.
With this update, I think the simulator is getting a really well-made graphical interface. Now I’ll probably work on adding the “Learn” mode, which currently only exists in the “initial” phase, which is through the terminal.

This devlog took longer than usual (I’ll try to make sure this doesn’t become the norm, even though the last one was already delayed), but at least it had a reason; this was the most technically demanding part of the project so far, especially because of the multimeter.

I made several corrections and refinements, such as the multimeter probes, which previously looked rather unsightly floating and disconnected from the multimeter, but now have a visual wire that always connects them to the instrument body, even when it’s moved across the screen. I also added the ability to invert/mirror components with polarity, LEDs, and batteries; by pressing F while the component is selected, the component flips. This is useful for assembling circuits in a more natural and organized way, without being stuck with a single orientation (and it was annoying me having to have one cable crossing over another). I thought I would do this quickly and easily, but after some attempts, I still had a subtle bug: the electrical logic continued to assume the same orientation, ignoring the visual inversion. That is, even if, after inverting, the + appeared as -, the code still assumed that the polarities were in their original place and therefore did not correspond (I hope that makes sense). So, I had to correct it so that the pins were physically fixed and the… The logic “asking” if the component is reversed, instead of trying to move the pins.

Now, the part that took the longest and also the last thing I did in the code, a multimeter with two modes. The multimeter was very “basic” and I wasn’t liking it very much, so I changed its appearance and decided to change its behavior as well. Now the multimeter has V mode (voltage, measured between two points without interfering with the circuit) and A mode (current, alternating with the M key). The A mode was the biggest challenge, since the two probes could now be part of the electrical circuit itself, that is, I cut a wire, connect each end to one side of the cut, and the multimeter measures the current that passes exactly there, just like a real ammeter. This forced me to rewrite the algorithm that traverses the circuit to know how to “pass through” the multimeter when it is in A mode, but ignore it (not interfere) when it is in V mode.
This involved a lot of experimentation and some positioning bugs along the way. (The probes were placed in the wrong spot, inheriting the position of the palette instead of the position where they were dropped), but now everything is working as you would expect from a real multimeter.

A lot has happened since the last devlog; this was the phase of making the simulator more complete and visually clear. (I apologize for adding so much time to a single devlog, but I kept having ideas and working on them, I didn’t even realize it had been 3 hours without any breakdown.)

In terms of interface and usability, it’s now possible to delete components and wires with the right mouse button (deletes the component + connected wires, or just an isolated wire).
The components are no longer generic rectangles: now they have real electrical symbols, a battery-style cell (with +/-), a zigzag resistor, an LED as a triangle + bar (also with +/-). (I used a bit of AI in this part of the element design to make sure it’s well done and with the correct symbols, since I sometimes get confused with the symbols.)

I also added new components (and I still intend to add more):
Switch, clickable, toggles between on (closed green line) and off (open, red); If switched off, the circuit shows “Open circuit”.
Capacitor, symbolized by two parallel lines, currently “transparent” to the calculation (still without simulation of charge/discharge over time).
Button, like a switch, but only stays on while the mouse holds it down.
Motor, symbolized by a circle with “M”, treated as a series voltage consumer (like an LED, but without requiring polarity or current limit). The motor was what gave me the most trouble because I tried to use it with the same logic as the LED, but to do so I had to rewrite the motor calculation in my code.

As I mentioned before, I rewrote the calculation engine to traverse the real circuit chain starting from the battery (instead of just grouping connected components), and this allowed the simulator to support multiple LEDs in series (summing the forward voltages of all of them), detect LEDs connected backwards (current entering through the cathode), with an explanatory warning, mix different types of “consumers” (LEDs and motors) in the same circuit (the problem that made me want to change this part of the code), and I fixed a bug where a circuit with only a motor (without an LED) showed no results.

At this moment, the simulator already supports 7 different components (battery, resistor, LED, switch, button, capacitor, motor), all with their own symbols, pedagogical error detection, and a calculation engine that traverses the real circuit instead of always assuming the same fixed structure.

Now I want to add a multimeter, which will be different from the others because it’s not another link in the chain, but a measuring instrument that connects to a point of your choice.

I consider this to be the most important milestone so far because I’ve connected the visual interface to the electrical logic. Until now, I had the two parts separate, the “brain” (calculations and warnings) and the interface (drag/drop), but now they work together.

What changed:
Each visual component now has a real electrical object associated below it (a Battery, Resistor, or LED).
I implemented a simple grouping algorithm: it goes through all the wires and discovers which components are connected to each other (even indirectly).
Each connected group is passed to the existing logic (SeriesCircuit), which validates and calculates the circuit.
The result appears in a real-time panel in the corner of the screen: voltage, current, power, and status if everything is okay, or a red warning if there is insufficient resistance or excessive current.
In other words, I can now drag a battery, resistor, and LED onto the screen, connect them with wires by clicking on the pins, and immediately see if the circuit is correct, and if not, understand why and how to fix it.

Since the last devlog, I’ve started working on the graphical interface with pygame (I chose pygame instead of tkinter because it gives more control over drawing and mouse interaction).

What’s already done:

Base window working, with main loop and correct closing.
Components represented as draggable rectangles with the mouse (VisualComponent).
A fixed side palette with Battery, Resistor, and LED. When dragging from the palette to the main area, a copy is created, and the original is always available in the palette.
Each component now has connection pins (left and right), visible as small circles.
I implemented the wires: you click on one pin, then another, and draw a yellow line connecting the two components.

That is, I can already drag a battery, a resistor, and an LED onto the screen and visually connect them with wires. Now I just need to make this visual connection “mean” something, combine it with the electrical logic I already had (voltage/current/power calculation and the pedagogical warnings).

Since the last devlog, I’ve focused on thoroughly finalizing the electrical logic before moving on to the visual interface.

Since then, I’ve completed the circuit validation. Now, in addition to detecting when a resistor is missing, the program also detects when the chosen resistor is too low and the current would exceed the LED’s limit (always with an explanation and suggested value, never just “error”):
“Current above LED limit
With this resistor (100 Ω), the current would be 70.0 mA, but this LED
can only handle up to 20 mA.
💡 Use a resistor of at least 350 Ω.”

I also started the “Learn” mode, creating a Lesson class that generates a statement (e.g., “9V and 1kΩ, what is the current?”), accepts the user’s answer, checks it with a tolerance margin, and always explains the formula used:
“You have a 9V source and a 1kΩ resistor. What will the current be?
Your answer in mA: 9
✅ You got it right!
I = V / R = 9 / 1000 = 9.0 mA”

This project, Learnware, is intended to be an electrical circuit simulator in Python, designed to teach electronics interactively to those who want to work more with hardware, focusing on explaining the why of things, not just showing results.
The ultimate goal is to have an area where you drag and drop components (batteries, LEDs, resistors, buttons, capacitors, motors, Arduino/ESP32, etc.), connect them with wires, and the program calculates everything in real time. There will also be a “Learn” mode with lessons, and later, connection to real hardware (ESP32/Arduino).

So far I’ve created classes for the components (Battery, Resistor, LED) using dataclasses, a SeriesCircuit that connects battery + resistor + LED and calculates voltage, current and power, and the part I found most interesting is that, instead of just giving an “error” when the circuit is poorly assembled (e.g., LED connected without a resistor), the program explains the problem and suggests the correct resistor to use, such as:
⚠️ Excessive current
This LED does not have a resistor to limit the current.

In a real circuit, this can damage the LED.

💡 Try adding a 350 Ω resistor.

And when the circuit is correct, it shows:
Voltage: 9 V
Current: 7.0 mA
LED Power: 0.01 W
Status: 🟢 Functional circuit

(In the initial development phases, everything will be written in Portuguese from Portugal, but I plan to add support for more languages ​​in future updates)