Can anyone hear me?
Rocketmagnet
I came across this project a while ago, and I made several posts here,
but got no replies :(
I am very interested and might also be interested in helping if I
can. I have a lot of experience in both using CAD daily and writing
CAD applications.
I've posted some of my thoughts and comments already, it would be nice
to know if anyone heard them.
Many thanks
Hugo Elias
Graham Hemingway
Rocketmagnet
Thanks for the reply. Well, I guess much of what I wanted to say was
in the last 5 or so forum posts here. Especially the one titled User
Interface thoughts.
I have quite a lot of experience of CAD of various kinds, and so many
thoughts and ideas, some of which I am trying out in my Printed
Circuit Board CAD application
I'm working on: http://www.liquidpcb.org
I'm also working on a library to import STEP solid models, since there
doesn't seem to be any open source code available for this (except
Open Cascade which is
a nightmare). https://sourceforge.net/projects/solidfile/
I would love to help the project, though I don't have a lot of time.
Perhaps I cen just help my testing, and making suggestions about
things, especially the user
interface.
Many thanks
Hugo
ben lipkowitz
I recently came across your liquidPCB site and it embodies a lot of ideas
that I had come up with independently. I was going to have a go at making
a non-sucky PCB layout editor using Python and Cairo. I was also going to
start a STEP library independent of opencascade a couple years ago, but I
got overwhelmed by the piles of documents written in standards-ese
language. It might be easier and more useful to start with IGES first,
which has excellent and freely available documentation. How are you going
to get the ISO STEP standards documents? They cost about $15k for each AP,
or so I hear. BRL-CAD has offered access to them if you are willing to
make a converter to/from BRL-CAD format.
Right now I'm working with a loose group of people at
openmanufacturing.net on some free-libre automated dependency /
functionality analysis software[1], for answering questions like "how do I
build a spaceship with what I've got laying around?" and then printing
step by step instructions on how to do it. You might be interested in some
of our discussions. We are desperately in need of a minimal yet hackable
solid modeling CAD program for distributed collaboration.
ciao,
-fenn
[1] http://heybryan.org/mediawiki/index.php/SKDB
Graham Hemingway
Thanks for your interest in Wildcat. I am very aware that it is
nowhere even close to being a useable product but I am excited about
how many people are interested in open source solid modeling. I will
have to keep an eye on liquidpcb and openmanufacturing.
If there is anything I can do, please let me know. I spend my days
coding away trying to get Wildcat further along, but I always welcome
feedback and suggestions.
Cheers,
Graham
Rocketmagnet
> I am very aware that it is nowhere even close to being a useable product...
I know the feeling.
> If there is anything I can do, please let me know. I spend my days
> coding away trying to get Wildcat further along, but I always welcome
> feedback and suggestions.
What makes my life difficult (doing robotics) is that I have one
application
for mechanical CAD, one for CAM, one for the schematic and one for the
PCB. They're all different, have different interfaces and don't
always talk
to eachother nicely. To make it worse, two of them run on Windows and
two on Linux! Argh.
The other thing is, all the documents depend on eachother. I.E. If I
make
a change in one, then I have to, manually, propogate that change
through
the others. Sometimes I forget to do this, and end up having to re-
manufacture
something.
What I'd love is if they could all be in the same application. In
fact, it would
be even better if they were seamless. It would be great if I could
have all
my CAD documents for one project literally open in the same window.
(I tried to upload a mockup picture to my web site, but the FTP seems
to
be broken)
Imagine, in the instance of mechanical CAD, one window containing
a huge spread of tens or hundreds of solid model parts. All spread
out. So you
can zoom out and get an overall view of all the parts of a robot hand,
say, or zoom
in and edit one part. Inbetween those parts would be arrows showing
which docs depend on which others. When you edit one part, others
would
either automatically change, or become highlighted to let you know
they need
attention. Some of these might be asssemblies, so, when you edit one
part
you see it instantly change in the assembly.
Other documents might then be PCBs, which are also part of the
dependency tree.
Model of casing --> Model of PCB --> PCB layout <-- schematic
I don't know if I've made this very clear. Another way to think about
it is: To switch
from one document (e.g. solid model or pcb) to another in your
project, rather than
using ctrl-tab, you'd just scroll over there, or zoom out, then zoom
into the document
you want.
Basically, this is a kind of window manager, where each type of
document is
handled by a plugin or something. And somehow the documents can pass
information
about events or updates to eachother. So, if I click on a net in my
schematic, then the
relevant traces on the PCB could highlight.
People could then write more plugins. For example, someone might write
a stress
analysis plugin. So, you see a document with the results of a stress
analysis there
among your other docs. It would automatically update when you make a
change to
the part it's analysing. Other plugins would be importers and
exporters. For example
a STEP exporter. Again, when I make a change to a solid part, the STEP
exporter
automatically updates the STEP file on disk, to make sure it's never
out of date.
Again, this is all a mad lot of work, but I think it would make an
amazing platform for
open source engineering.
Any thoughts ?
Hugo
Rocketmagnet
section.
EDA_Workspace.png
Hugo
ben lipkowitz
> What makes my life difficult (doing robotics) is that I have one
> application for mechanical CAD, one for CAM, one for the schematic and
> one for the PCB. They're all different, have different interfaces and
> don't always talk to eachother nicely. To make it worse, two of them
> run on Windows and two on Linux! Argh.
Jef Raskin is rolling in his grave...
> The other thing is, all the documents depend on eachother. I.E. If I
> make a change in one, then I have to, manually, propogate that change
> through the others. Sometimes I forget to do this, and end up having to
> re- manufacture something.
This is a major bummer, but how do you go about specifying the
dependencies? There are some non-obvious side effects (to humans too!)
like, if I move this strut here, it will make a ground loop. Or, if I
change this capacitor to 1 Farad it throws off the weight balance. It
seems like you would have to write unit tests for your end product's
desired functionality, and then run it in some super duper multi-domain
simulator. Of course a simple interference fit check would solve 95% of
manufacturing problems.
> What I'd love is if they could all be in the same application. In fact,
> it would be even better if they were seamless. It would be great if I
> could have all my CAD documents for one project literally open in the
> same window.
>
> Imagine, in the instance of mechanical CAD, one window containing a huge
> spread of tens or hundreds of solid model parts. All spread out. So you
> can zoom out and get an overall view of all the parts of a robot hand,
> say, or zoom in and edit one part. Inbetween those parts would be
> arrows showing which docs depend on which others. When you edit one
> part, others would either automatically change, or become highlighted to
> let you know they need attention. Some of these might be asssemblies,
> so, when you edit one part you see it instantly change in the assembly.
This sounds terrible. Why would you try to convert your 3D geometry into a
2D layout? And do you really want different documents in the same window?
Why not one for the whole project? Or, the other extreme is something like
http://www.bruno.postle.net/neatstuff/draft/
(which is very much what you're after, after all)
> Other documents might then be PCBs, which are also part of the
> dependency tree.
>
> Model of casing --> Model of PCB --> PCB layout <-- schematic
>
> I don't know if I've made this very clear. Another way to think about
> it is: To switch from one document (e.g. solid model or pcb) to another
> in your project, rather than using ctrl-tab, you'd just scroll over
> there, or zoom out, then zoom into the document you want.
Just rotate around the cad model until you see the pcb, then click
on the pcb to edit it (and perhaps some nifty automatic view locking to go
into 2D pcb editing mode, but this shouldn't be required)
> Basically, this is a kind of window manager, where each type of document
> is handled by a plugin or something. And somehow the documents can pass
> information about events or updates to eachother. So, if I click on a
> net in my schematic, then the relevant traces on the PCB could
> highlight.
Event passing can be done between applications in most modern GUI
frameworks. Hilighting nets between schematic/layout is brain-dead
obvious, and I seriously wonder why it isn't a standard feature of EDA
packages.
> People could then write more plugins. For example, someone might write a
> stress analysis plugin. So, you see a document with the results of a
> stress analysis there among your other docs. It would automatically
> update when you make a change to the part it's analysing.
What I really want is an algorithm to automatically find the optimum
geometry for the constraints I've given it. But, having a real-time "play"
mode with various physics simulations would be very useful too. I saw on
your webpage some beginnings of this:
http://freespace.virgin.net/hugo.elias/models/m_cloth.htm
http://freespace.virgin.net/hugo.elias/models/m_ffire.htm
> Other plugins would be importers and exporters. For example a STEP
> exporter. Again, when I make a change to a solid part, the STEP exporter
> automatically updates the STEP file on disk, to make sure it's never out
> of date.
How does it not bog the system down? This can already be done with "file
alteration monitor" or similar.
> Again, this is all a mad lot of work, but I think it would make an
> amazing platform for open source engineering.
>
> Any thoughts ?
I jotted down some similar ideas here a couple years ago:
http://fennetic.net/cadwiki/
> Hugo
-fenn
Graham Hemingway
Rocketmagnet
> > The other thing is, all the documents depend on eachother. I.E. If I
> > make a change in one, then I have to, manually, propogate that change
> > through the others. Sometimes I forget to do this, and end up having to
> > re- manufacture something.
>
> This is a major bummer, but how do you go about specifying the
> dependencies?
export a netlist and import it into the pcb editor. If I change the
design of the casing, and therefore the required shape of the pcb, I
then have to create an engineering drawing of the pcb shape, export it
as a .dxf, run a script to convert that to a pcb with a silk-screen
outline of the shape. Delete the old outline from my layout, and
import the new layout in.
How would I like to specify them? Well, some of them should be pretty
obvious for the software. I should just be able to point the
schematic and layout at eachother, and let them work it out. I should
be able to tell the layout that I want a certain solid model to
represent the pcb outline etc.
LiquidPCB can nearly do this. You can give it a solid model in the
form of a polygonal mesh exported from a CAD package, and it'll work
out the outline and the position of any round holes, converting them
to vias. But there's no automatic updating there yet.
> There are some non-obvious side effects (to humans too!)
> like, if I move this strut here, it will make a ground loop. Or, if I
> change this capacitor to 1 Farad it throws off the weight balance. It
> seems like you would have to write unit tests for your end product's
> desired functionality, and then run it in some super duper multi-domain
> simulator. Of course a simple interference fit check would solve 95% of
> manufacturing problems.
of the ideas, like writing unit tests for things like centre of
gravity is actually a very good idea, but still not something you'd
have to do if you didn't want to. I guess it's a little bit like a
spread sheet, where you can define formulas and functions so that, if
you change one cell, loads of others can update. But in this case,
they might require the user to do the updating. Or they might
politely wait for permission to update if they would require a lot of
processor time.
Yeah, unit tests is actually a very *very* good idea. Graham, can we
have unit tests in Wildcat?
> This sounds terrible. Why would you try to convert your 3D geometry into a 2D layout?
excellent idea, and something that high end PCB editors already do.
Many people think of PCB design as a 2D affair, but it's actually very
3D when you're designing something like a robot or a mobile phone.
The shape of the PCB, and the form factor of the components are
intimately tied to the CAD. Really, you need a 2-way flow of solid
model data between your mCAD and your eCAD. You need to do
interference checking between the casing and the components.
For example, for one of our robot hands, there are 140 or so
individual plastic parts and 37 individual PCBs. All of which are
intimately dependent on eachother. Most mCAD already has the ability
to propogate information between solid models. In fact, it would be
almost impossible to do my job without this ability. However, I still
have to remember to open each part which needs changing (and it
doesn't tell me which), update them, save them, and do the same for
any parts which depend on them in turn. I also have to remember to
check that I didn't make a change which would affect one of the
components on a PCB somewhere. It's a massive dependency nightmare.
The only way to make this properly reliable is to automate as much as
possible. And therefore the mCAD and eCAD have to be able to share
solid models.
> And do you really want different documents in the same window?
It's not much different from having them on the same screen, and we
have no problem with that idea. For the 140 plastic parts and 37 pcbs
of our hands, it would be fantastic to just see them all laid out
infront of me on the screen. It really gives you a sense of the size
of the project. It also makes it trivial to find any part, because
it's in a sensible place, and I can just zoom right into it.
Another way to think about it is to think of them all inside their own
windows (they could have a box drawn around each one), but the whole
windowing system can zoom in and out massively. And there's no need
to 'open' a document most of the time. It's automatically opened if
you need to edit it.
Or, think about it like this. Each part is represented by an icon, and
all of the icons for the project are laid out on a huge sheet. Except
each icon looks just like the part. And when you zoom into it, the
part is automatically loaded from disk, and you're in edit mode
without even asking for it. Or maybe you'd have to unlock the part to
allow you to edit it.
> Event passing can be done between applications in most modern GUI
> frameworks. Hilighting nets between schematic/layout is brain-dead
> obvious, and I seriously wonder why it isn't a standard feature of EDA
> packages.
> What I really want is an algorithm to automatically find the optimum
> geometry for the constraints I've given it.
just function minimisation.
> > Other plugins would be importers and exporters. For example a STEP
> > exporter. Again, when I make a change to a solid part, the STEP exporter
> > automatically updates the STEP file on disk, to make sure it's never out
> > of date.
>
> How does it not bog the system down? This can already be done with "file
> alteration monitor" or similar.
just change visually to let you know that they needed seeing to. So
it wouldn't re-export a STEP every single time you edit a part, it
might just become highlighted to let you know it was out of date. Then
you click on it, and it exports. And there could also be a control to
say "update everything which depends on this part I just edited".
Lots of good ideas there.
> http://www.bruno.postle.net/neatstuff/draft/
and there.
Did you see those Graham?
Hugo
Rocketmagnet
> physical system and then at some later point hand it off to the software
> team. The programmers then have to make their code work based on the
> physical design and have very little input back to the mechs.
> What happens if the software can't achieve its goals because of constraints
> in the hardware? Why happens to the software if a change is made to the
> hardware? Currently, I don't know of any first-class CAD apps that have
> links into any of the dominant embedded software design packages,
> or visa-versa.
match. Some eCAD packages connect the pcb layout with the FPGA pin
designations to help search for an optimal design. I think connecting
software to the hardware would also be extremely helpful. Perhaps the
CAD systen can generate header files based on the schematic?
> Once we get Wildcat to where it can model solid parts and assemblies
> (admittedly a good ways into the future), my next step is to explore ways of
> automating and easing the flow of information between these two domains.
> PCB and numerous other areas are exactly the same. And there are no
> existing solutions from what I have seen.
perhaps we should start thinking about how they would integrate.
Sooner, rather than later. The sooner we think about it, the smoother
it will be.
Hugo