Why I'm Building Dashcaf

There's a specific moment I've watched happen dozens of times, first as a student and later as a teaching assistant for "Control" and "Optimization" at the University of Guilan: someone understands a concept right up until they have to actually simulate it, and then they lose it completely.

Not because the concept was too hard. Because the gap between "I understand what a transfer function is" and "I have MATLAB open, a license that might not be active on this machine, and a block diagram that isn't behaving the way the textbook implied it would" is enormous, and it has nothing to do with whether the underlying idea makes sense. Dashcaf exists to close that specific gap.

What it actually is

Dashcaf is a block-diagram simulator that runs entirely in the browser. You drag blocks onto a canvas — a step input, a transfer function, a gain, a scope — wire them together, and press run. It simulates the system live, using a validated RK4 solver, and shows you the result. No install, no license file, no waiting for a lab machine to free up. It currently covers fourteen engineering disciplines and 68 customizable blocks, and every project is shareable by link and exportable, so a result you build doesn't stay trapped on one computer.

That list of features is the easy part to explain. The reason I'm building it is less about the feature list and more about who gets stuck without it.

Who this is actually for

I've been on both sides of the access problem. I spent years running control systems for real industrial equipment — wood dryers, boilers — long before I had any formal training in control theory, because the machinery didn't care whether I had the right software license, it just needed to work. And I've spent years since then watching students who do have the formal training get stuck anyway, because the tooling between "I understand this" and "I can test this" is expensive, unreliable, or simply not there when they need it at 11pm before an assignment is due.

Dashcaf is for both of those people. It's for a student who needs to actually see a PID controller respond to a step input instead of just deriving its transfer function on paper. It's for an engineer who wants to prototype a system quickly without opening a heavyweight desktop tool and waiting for a license server to respond. It's for anyone who's ever had the right idea and the wrong tools at the same time — which, in my experience, describes most people most of the time.

A concrete example, not an abstraction

Take something as ordinary as tuning a PID controller — the kind of exercise that shows up in almost every control course. On paper, you derive gains and reason about stability margins. In practice, understanding why a particular gain makes a system oscillate, rather than just being told it will, means watching it actually oscillate. In Dashcaf, that's a step input, a PID block, a plant transfer function, and a scope, wired together in under a minute. Nudge a gain, rerun, watch the response change. That loop — change something, see the real consequence immediately — is where the understanding actually happens. It's the same loop I used, without naming it that, when I was adjusting a boiler's control parameters and watching the temperature trace respond over the following hours. Dashcaf just makes that loop take seconds instead of a production run.

Why I'm not treating it as a side project

I want to be direct about this: Dashcaf is my startup, not something I tinker with between research deadlines. I think the honest version of "I want to make engineering more accessible" has to mean actually building and maintaining something people can rely on for years, not shipping a demo and moving on. That means real infrastructure decisions — a validated solver instead of a quick approximation, exportable results instead of a walled garden, a growing block library instead of a fixed set that stops meeting people's needs the moment their coursework gets interesting.

It also means being honest about scope. Fourteen disciplines and 68 blocks is a real foundation, not a finished product. The plan is to keep growing it — more blocks, more disciplines, more of the workflow that makes it useful past a single homework assignment and into actual project work, research, and teaching.

The through-line

If you've read anything else I've written here, you'll recognize the pattern: I keep ending up in the gap between understanding something and being able to actually use it, and I keep trying to close that gap with something concrete. Ten years of industrial control systems taught me that theory only earns its keep once it's running on real hardware. Dashcaf is the same instinct, aimed at the moment right before that — the moment a student or an engineer needs to go from "I think I understand this" to "I just watched it work," without anything standing in the way.

That's the whole reason it exists, and it's why I'm building it to last.