[squeak-dev] Greetings & development of Electrical Engineering Design application

lists.squeakfoundation.org at ben.coman.com.au lists.squeakfoundation.org at ben.coman.com.au
Thu Feb 24 17:07:35 UTC 2011


greetings all,

To introduce myself, I first experienced Smalltalk around 1990 as part 
of my undergrad in IT Engineering.  It made a great impression on me but 
unfortunately I never got a chance to use it professionally, and hadn't 
touched it since.  I then worked fifteen years in IT doing 
desktop/server/network support of windows/unix/linux systems.  My career 
got a bit stale so the past five years I have been doing external 
postgrad study at the University of Southern Queensland for a MEngTech 
Power Systems.  The past four years I've been working for a small 
Electrical Engineering & Contracting firm doing industrial control and 
power systems.

My Final Project & Dissertation is now upon me and I've decided to 
develop an engineering design tool.  The discovery of Squeak a few weeks 
ago and then working through Squeak by Example and the Laser Tutorial 
was a major influence in choosing to undertake this project.  Part of it 
is a schematic and connection drawing package where changes are live 
linked between associated drawings. For example, when wire numbers are 
changed on the schematic that will be reflected on the connection diagram. 

So now I need to evaluate and choose a framework.  So far the options I 
see are:

1. Pure Morphic - might has the advantage of being well supported with 
examples.   I can already imagine how things might be implemented - 
including maintaining vertical-or-horizontal-only orientations while 
moving wires around. It is more likely that unintended behavior can be 
understood and prevented.  The model coupling is also well demonstrated 
in examples.

2. Ned Konz's Connectors  - I have been playing with Ned Konz's 
Connectors framework this week and am quite excited by its potential.  
However I wonder how well it integrates with an underlying model to 
maintain consistency across multiple views.

3. GraphViz - seems to be less interactive than Connectors providing 
mainly graph auto-generation - though I haven't tried it yet.

4. Mondrian - seems to be less interactive than Connectors providing 
mainly graph auto-generation - though I haven't tried it yet.

5. Cobalt, for later addition of 3D equipment layouts and cable 
routing.   I could only spend a few hours with it.

In general, the more developed frameworks should provide more 
sophisticated features "for free", but the trade offs are time-to-learn, 
framework maturity, susceptibility to framework bugs, potential 
complexity to trouble-shoot framework internals.  Also there may end up 
a mismatch between requirements and framework possibilities, and being 
able to extend them.  There also doesn't seem to be a great deal of 
consolidated documentation for each framework.  So trying to understand 
the high level design and usage philosophy by wading through low-level 
code is awkward.

I am interested in your opinion on the choice of suitable frameworks? 
Did I miss any?

The basic model will be composed of:
a. Drawings - A3 size with standard client borders. A large electrical 
project may have thousands of drawings.
b. Components - with terminals to which wires connect.  These will be 
developed custom by the user.  Components have Subparts that scatter 
around a drawing.  For example a relay has an input-coil and an 
output-contact that appear in different parts of the circuit. .  
Component Subparts Components will have various graphical 
representations depending on which type of drawing they are on.
c. Wires - which inter-connect component terminals.  All 
short-circuit-connected wires should have the same wire number. 
d. Cables - contain multiple wires to connect between drawings and 
physical locations.
e. Voltages and currents on components and in wires.

Design rule checking (such as preventing mixed voltages) will be done 
against the model.  The schematic will be simulated to observe the 
effect of push buttons and relay logic. 

cheers, Ben



More information about the Squeak-dev mailing list