Ok, we need to be able to create circuits in the web interface. The basic idea will be how to use a HTML5 canvas to draw the schematic and use mouse events to manipulate the schematic. The first order of business is to have a Component class. This will know where the component is located at, generically know how to draw stuff and also know how to do movement, selection etc. We’ll start with a simple interface. Before we do that we need a class to contain everything about the schematic. We’ll do this with SchematicCapture. This will know about the list of components and it will also know things about how the view is defined.
I’ll warn you ahead of time, my HTML5 experience and prowess is not very strong. I am much more comfortable and accomplished in C++, and I’m sure I’m doing some horrible things that are horribly inefficient and brain damaged. This whole project is really just an educational experiment to see how good a UI made entirely in JavaScript is and how I can create one.
I’ll remark that I did discover a similar project to this one that is part of the MIT open courseware circuit course tool. Undoubtedly they did a better job than I did, but I’m trying to do this on-my-own in true not-invented-here fashion. I am also trying to document how I solve the problem step by step, mistakes and all.
Basic drawing
We’re going to use the notion of a windowing transform. Basically we have device coordinates which are the pixel locations, but we want a virtual canvas so we’re going to have “world” coordinates. The way we transform back and forth is quite simple. First, we have the notion of a xmin, xmax, ymin, ymax window we would like to view and we know our device is from canvas.width by canvas.height. To convert from device to world we make two functions to convert from world to device coordinates as
var xToDevice=function(x){return (x-xmin)/(xmax-xmin)*width};
var yToDevice=function(y){return (y-ymin)/(ymax-ymin)*height};
The first thing we need is a grid. We will make a grid line every dx. To draw the x grid we have the following code. First, we draw the background in yellow and then we draw the x lines in blue. We use floor to figure out where to start drawing the line to define xstart and then we continue until we go past xmax. Even though clipping would allow us to draw beyond, it would inefficient (and infinitely so) to draw everyline everywhere.
SchematicCapture.draw = function(){
...
// draw grid lines
context.fillStyle = "rgba(255, 255, 180, 255)";
context.fillRect(0, 0, width, height);
var dx=1;
context.strokeStyle = "rgba(100, 100, 255, .5)";
var xstart = Math.floor(xmin / dx);
for(var x=xstart;x<xmax;x+=dx){
context.moveTo(xToDevice(x),yToDevice(ymin));
context.lineTo(xToDevice(x),yToDevice(ymax));
}
...
Now we get something that looks like this… I know super exciting…
Once we have that abstraction we can delegate drawing to each component in our list as:
// draw symbols
SchematicCapture.draw = function(){
...
for(var v in this.symbols){
this.symbols[v].draw(xToDevice,yToDevice,context);
}
...
}
This is exciting, now we are ready to define a generic component. The main idea is we will have a list of points that the component knows to draw and a generic point that loops through and draws the points. The basic component will store a location and a rotation (0,1,2,3) for no rotation, 90 degrees, 180 degrees and 270 degrees. To do this we need three basic functions on our component: the constructor, the objectToWorld to transform points from object space to world space, and the draw which will draw the component. Here are the basic three functions for the component
// Construct a component at a given position and rotation
Component = function(x,y,rotation){
this.x = x; // xlocation of origin in world space
this.y = y; // ylocation of origin in world space
this.rotation = rotation; // 0 to 2
// compute the bounding box
this.box = [1e7,-1e7,1e7,-1e7];
for(var ptK in this.points){
var pt = this.points[ptK];
if(!pt) continue;
var pt = this.objectToWorld(pt[0],pt[1]);
this.box[0]=Math.min(this.box[0],pt[0]);
this.box[1]=Math.max(this.box[1],pt[0]);
this.box[2]=Math.min(this.box[2],pt[1]);
this.box[3]=Math.max(this.box[3],pt[1]);
}
}
// Transform from object space to world space a point x,y
Component.prototype.objectToWorld=function(x,y){
if(this.rotation==0) return [x+this.x,y+this.y];
else if(this.rotation==1) return [this.x+y,this.y-x];
else if(this.rotation==2) return [this.x-x,this.y-y];
else if(this.rotation==3) return [this.x-y,this.y+x];
}
// Draw a component at a given location
Component.prototype.draw=function(xToDevice,yToDevice,context){
context.beginPath();
//var points=[[0,-1],[0,0],[2,0],[2.5,-1],[3.5,1],[4.5,-1],[5.5,1],[6.5,-1],[7.5,1],[8,0],[10,0]]
var first=true; // first point has to be a moveTo
for(var dummy in this.points){
var ptOrig=this.points[dummy];
// check if we are at a null point and reset the draw count
if(ptOrig == null){first = true;continue;}
// transform the point into world device coordinates
var pt=this.objectToWorld(ptOrig[0],ptOrig[1]);
if(first){
context.moveTo(xToDevice(pt[0]),yToDevice(pt[1]));
first=false;
}else{
context.lineTo(xToDevice(pt[0]),yToDevice(pt[1]));
}
}
context.stroke();
// draw a label for the value of the component
var pt=this.objectToWorld(3.5,-3.5);
context.font = "10pt sans-serif"
context.fillStyle = "#000000";
context.fillText(this.value,xToDevice(pt[0]),yToDevice(pt[1]));
}
Now, we just need to define subclasses to define our component types. For example, here is our resistor component definition
ResistorSymbol = function(x,y,rotation){
this.points=[[0,-1],[0,0],[2,0],[2.5,-1],[3.5,1],[4.5,-1],[5.5,1],[6.5,-1],[7.5,1],[8,0],[10,0]]
Component.call(this,x,y,rotation)
this.value = "1k"
}
ResistorSymbol.prototype = new Component()
We can create definitions for capacitors, voltage sources and everything else we need similarly. If we hard code a few component constructors in our SchematicCapture class instantiation, we get something that looks like this:
Not bad!
Basic selection and interaction
Schematic capture is really not very good for anything unless we can move things around and add components. Let’s attack the problem of moving things around. Basically the idea is that we’ll register mouseDown, mouseUp and mouseMove handlers, and in the mouseDown we’ll find if we have selected anything to control how the other handlers work. We’ll use the bounding boxes that we have created as a simple way of knowing whether the given world-space coordinates are inside a component. We’ll just use linear search for now, but one could imagine making a bounding box hierarchy or something smarter to get down to some sub-linear (maybe logarithmic) time.
Highlighting
First thing I implemented was highlighting. This will make sure I have the coordinates transforming properly and the bounding boxes
bounding properly. I needed to do some refactoring, but the main thrust consists of delegating mouseMove to the schematic (which involved storing a pointer to the schematic type from the canvas type). The mouseMove implementation also needs to be augmented to check if we are inside something and if we are make it redraw in a nice color. Here’s mouseMove.
SchematicCapture.prototype.mouseMove = function(event){
...
var oldHighlight = this.highlight;
this.highlight=null;
for(var v in this.symbols){
var symbol=this.symbols[v];
if(symbol.inside(newX,newY)){
this.highlight=symbol;
}
}
if(this.highlight != oldHighlight) this.draw(); // only draw if we changed highlight
}
Here we have used the inside function on the component to check if a given world coordinate is inside a given world bounding box. Its implementation is this:
Component.prototype.inside=function(xWorld,yWorld){
return xWorld > this.box[0] && xWorld < this.box[1] && yWorld > this.box[2] && yWorld < this.box[3];
}
In addition to actually affect how drawing happens, we made SchematicCapture.draw() send the highlight flag into the Component.draw. I’ll spare you the annoying details.
Basic movement
Now that we have highlighting working we need to attack the more difficult task of movement. I’m going to just assume we need one selection for now to move. I’d like to have multi-select with shfit and marquee (a.k.a. bounding box) select working but all that jazz is complicated and I want to start simple.
Implementing these mouse interaction routines I’ve done about a billion times now, starting with OpenGL in my intro graphics class using fltk. In javascript it works pretty much the same as fltk, win32, gtk, Qt, and every other graphics library I have ever used. The best way to do these things is to remember the coordinate of the event that you last handled in the schematic class. Then when you get a new mousemove or whatever event you can look at the difference and add that as an offset to the component position you are currently selecting. In pseudocode
mouseDown(){
this.x,this.y=event.x,event.y
this.dragging=highlightedObject;
}
mouseMove(){
offx,offy=event.x-this.x,event.y-this.y
if(this.dragging){
this.x,this.y=event.x,event.y
highlightedObject.addOffset(offx,offy)
}
}
mouseUp(){
this.dragging=false;
}
Ok, it turned out to be a little bit more complicated than that. For one thing, I actually store the event x and event y in world space so I don’t need to double transform. Another major thing I wanted for the schematic capture was to clamp to a grid. To do this we might have fractional mouse movements with respect to the snapping grid. To avoid trouble with this and ensure simplicity, during interaction I keep an extra position for each moved component. This is done by the addOffset() function. It basically stores the x,y in this.fracX and this.fracY on the object, but it also rounds to create the this.x and this.y. This makes the rounding hysteresis work properly. In mouseUp I call a routine to drop the fraction in fracX , fracY and synchronize it to be the same as x,y. addOffset() is nice to break into its own function because I can do the handling of fractional positioning while at the same time being sure to update the world bounding box.
Adding wires
Adding wires is an important thing in that we need to be able to connect different components. Connections seem like they are going to be harder. Lets start out less ambitious and just represent line segments. I think that if we can have line segments just be a component like we already had, that will work nicely. Unlike other components, rotation probably doesn’t make sense, but lets just leave that in and ignore that for now. The basic method of representing a wire will be to use the position of the first end point of the wire and then store an offset to the second wire. So we’ll have two points in our base class draw [[0,0],[dx,dy]] where dx,dy = x2-x1,y2-y1.
One challenge is that we need to implement an inside function that will allow us to query whether we are close to the line segment. That turns out to be a simple linear algebra problem which is described in this diagram. Basically we make two vectors between the first point of the wire and the query point of the moues cursor and the second point in wire and compute cross product and dot product. That gives us values that can be used to measure perpendicular and parallel distance. You could also think about it as rotating the coordinates of the cursor position and translating them into a reference frame where the wire AB is along the x-axis. That begs the question why not just represent the wire with that as the object space, and that might make the inside test easier, but it really is just pushing the problem around and it would force us to support non-axis aligned rotations for components. So we’ll just do this in the inside call
The code corresponding to the wire component is:
WireSymbol = function(x,y,x1,y1){
this.points=[[0,0],[x1-x,y1-y]];
Component.call(this,x,y,0)
}
WireSymbol.prototype = new Component()
WireSymbol.prototype.inside=function(xWorld,yWorld){
// v1 is vector from first point of wire to the cursor position
// v2 is the vector from the first point to the second wire normalized
// dotProduct(v1,v2) = cos(theta) |v1| |v2| = cos(theta) |v1| must be in the interval [-threshold,v1+threhsold]
// crossProduct(v1,v2) = sin(theta) |v1| |v2| = sin(theta) |v1| must be within [-threhsold,|v1|+threshold]
var wireInsideThreshold = 0.5
var len=Math.sqrt(this.points[1][0]*this.points[1][0]+this.points[1][1]*this.points[1][1]);
var invLen=1./len;
var v1=[xWorld-this.x,yWorld-this.y];
var v2=[this.points[1][0]*invLen,this.points[1][1]*invLen];
var parallelDistance=Math.abs(v1[0]*v2[1]-v1[1]*v2[0]); // length of perpendicular segment i.e. distance from light containing segment
var perpendicularDistance=(v1[0]*v2[0]+v1[1]*v2[1]); // projected point parameter
return Math.abs(parallelDistance) < wireInsideThreshold && perpendicularDistance > -wireInsideThreshold && perpendicularDistance < len+wireInsideThreshold
}
Remaining things to do
I think that is enough for today. Let’s reflect and see where we are. We got a couple of things done.
- Basic drawing of gridlines and canvas
- Basic component infrastructure with wires, voltage sources, resistors, and capacitors visualized
We still have a ton to do that we should leave for a future post
- Interface to add components. Hopefully something like the “tab” convention in node-based graphics tools like Nuke and Houdini. Unobtrusive and fast!
- Interface to add wires
- Manage connections between components (need to track pins, wires overlapping pins and other wires)
- Deletion of components
- Selection/manipulation of multiple components
- Zooming and scrolling of virtual schematic
- The actual simulator!
There are several could be betters (CBBs) that we still have brewing:
- The code is a mess. Better compartmentalization, naming, commenting would be good
- We make too many temporaries (arrays). It’s hard to avoid without having functions for each component. I.e. look at transform(), we return an array.
- We could probably increase abstraction and elegance by having a vector class. In C++ this is really cheap and is the way to go. In JavaScript this blows up the number of temporaries to high hell. In general I find JavaScript makes having abstract and elegant code that is performant much harder than C++. The sub-typing feels expensive compared to C++’s facilities like structs, templatization, inlining, and all that static goodness.
To see what we have go to the page or check it out embedded here (live)
. Note I have used Ohm’s law for R1 and R2 separately and each component incident on B contributed to the KCL for B.
. Notice how this equation’s second term is the negative of the first term of the KCL at B. That is because these circuit elements contribute symmetrically to the linear system and so we will get a symmetric matrix if we do things right. This is a great property to have because there are special matrix solvers that are much more efficient but only apply to positive definite and symmetric matrices (i.e. conjugate gradient).
.
. If we write these all as a system we get
