Test driving DesignSpark PCB

In the summer of 2010 RS Components launched DesignSpark, an online community for electronics engineers. It is a similar community as Element14 from Farnell that was launched a year before. Like Element14, DesignSpark also offers a free circuit drawing and PCB design tool. Unlike the tool from Farnell that has some limitations - notably board size - the tool from RS is totally unlimited (meaning that there are no artificial limitations). Eagle Freemium, the tool from Farnell, in its free but limited version is allready used by many hobbyists, so would it be interesting for those users to switch to DesignSpark PCB?

Since I have been using (the professional version of) Eagle for a while now, I decided to try out DesignSpark PCB. I installed the latest version, which is 1.0.3. I had no PCB to design so I followed the tutorial that is included with the software. The tutorial is clearly written and pretty straightforward. A circuit diagram is quickly drawn thanks to the many libraries included, but the tutorial only uses some standard parts. If you follow the tutorial closely you will end up with a routed PCB in 45 minutes or so.

I noticed three problems in the tutorial text. The first one is a wrong connector specification. The text mentions a 5WP model, but you need a D9F. The second problem is more serious as I could not find the solution without the help from RS. The tutorial wants you to place a label on a net using the Display Net Name option that is supposed to be available from the right-click context menu, but I did not have this option. Looking through all the menus I could not find it either. The trick is that you have to select the _pin_ of the output symbol, not the symbol itself. The pin is the little cross that disappears as soon as you connect a wire to it. To select it you have to click on the extremity of the symbol. Actually it is much easier to right-click the wire to display the net name.
The third problem was the missing Spoke 10 option for the copper pour. This is a technology file issue, I probably did not load the right one.

I also tried importing an existing Eagle project. DesignSpark PCB includes a few Eagle macros that seem to work rather well, but not 100 %. In the schematic some junction symbols (the dots) were lost. Maybe these were the manually placed junctions in the Eagle file? Texts did not keep their sizes and the outlines of the page frames (or borders as the tutorial calls them) were gone. I also ended up with some labeled wires that were red, but not all.

On the imported PCB the texts not only had the wrong size, but they were rotated incorrectly too. A real problem was the fact that the Eagle project used a copper pour for connecting all the ground connections and these were not recognized by DesignSpark PCB even though the signal pads & vias had the right net names and were in the pour. Autorouting the PCB with or without grid did not solve the problem, and I am stuck at this point.

My quick test drive of DesignSpark PCB showed me that it is a very usable tool of at least the same quality as Eagle, but without the limitations of the Freemium version. I have used quite a lot of different PCB CAD packages and I found DesignSpark PCB easy enough to learn, but this may be different for other people. Switching to DesignSpark PCB may be interesting if you are not afraid of gerber files, because the PCB pooling guys, except for PCB Pool, do not (yet?) support uploading of complete DesignSpark PCB projects as they do for Eagle.

DesignSpark PCB seems a bit more production oriented than Eagle and you have easier control over the BOM. I also found the generation of the fab files easier. The technology files will probably confuse Eagle users (line widths f.i. have to be specified in the technology file first) and data entry is more work as is checking the PCB with all the different reports.

The most important difference between the two tools is definitely the design flow. DesignSpark PCB uses the classic capture-netlist-pcb flow

repeat until finished
{
draw/modify schematic;
generate netlist;
draw/modify PCB;
}

whereas Eagle has this automated. If you delete a part in an Eagle schematic, it is also deleted from the PCB. In DesignSpark PCB you have to initiate the update manually. Both ways of doing have their pros and cons and as long as you are used to it you will stay out of trouble, but if you aren’t, you will be in for some (unpleasant) surprises.

Another difference is in the separation of components and circuits. In Eagle, once you’ve defined a part you can only modify it in the library editor. DesignSpark PCB lets you edit a part up to some extent during capture. You can move pin names and numbers and add fields to parts that would be text comments in Eagle.

Let me finish this article with some remarks about DesignSpark PCB particularities:

Schematic capture
- Setting the component value of parts that do not have the value field is tedious, but can be done without editing the part in the library editor.
- Setting the component value is a bit tedious too as it involves at least two double clicks and two OKs.
- When two nets are merged, you cannot choose the name of the merged net.
- Block dragging is a bit strange and will move wire segments that you probably did not want to move.
- I had grid problems. Wires and parts placed on the grid somehow were moved off the grid, probably after a block move even though I never changed the grid or switched it off.

PCB
- The autorouter is not very powerful. It works with the tutorial, but I could not get a simple circuit to route except for a few wires. It turns out that you have to set the intertrack and track-pad spacings properly in the Design Technology window depending on the component lead pitch to get it going. You may also want to reduce the via size. I finally managed to get a very simple design to complete, but I was not impressed with the result. Then again, I always route manually so I don’t really care about the autorouter.
- You can generate reports for lots of things. These are displayed in Notepad and before you know it you have lots of Notepad windows open. If you rerun a report it will get a new window instead of overwriting the old one.
- Don’t forget to activate the Show nearest node on net if you route manually, otherwise you have absolutely no idea where you are going.
- I liked the single doc PDF that you can produce and that will hold all the plots. You should include the board outline in at least one plot, otherwise the paper size will wrong.
- I also like the plot preview option and the simple checkbox to cover vias with solder resist.
- Nice also is the auto place function to put parts on the board, allthough the result may not be exactly like how you would do things.

Projects
- You cannot rename a sheet? The only way I managed to do this was to save the project in a new location.

Eagle switches to XML

Last week a rumor started spreading about Eagle, the popular schematic capture and PCB drawing package used by thousands of electronics enthusiasts, switching to a text-based file format. We at Elektor asked CadSoft, the editor of Eagle, about this rumour and got it confirmed. Somewhere in the hopefully near future Eagle will start using an XML-based file format for storing its drawings. The reason for this change is, according to CadSoft, that the binary format has reached its limits.

I find this reason a bit strange. Why would a text format be more flexible than a binary format? I mean, text is just limited binary, right?

Of course a text-based format is human readable, which is an advantage when trying to debug a broken file. But will this help in real life with a multi-megabyte sized file? (BTW, I have never yet had to debug a PCB file.)
A text-based format will be cross-platform as it avoids byte ordering issues, a good thing. Using XML is probably a good idea too, because it is a well known format and many tools & libraries for fiddling with XML files are readily available.
For the user a text-based format is interesting as it may help speed up certain repetitive tasks like net labeling or copying blocks. Users will start writing utilities for manipulating Eagle files.

Will they? Probably. They always do.

But Eagle already offers a powerful scripting language that lets you do lots of things without learning the file format first, so why bother? By writing a script you can already export everything yourself to a human readable format. And that is exactly what RS did for DesignSpark, the competitor of Eagle Freemium by Farnell (who bought CadSoft some time ago). RS offers scripts that allow you to export Eagle files as ASCII data. This is what it looks like:

EAGLE_INTERMEDIATE_ASCII "my_board.brd"

(asciiHeader
(fileUnits IN)
)
(library Library_1
(padStyleDef "Oval1"
(holeDiam 0.0314961)
(padShape (layerNumRef 1) (padShapeType Oval) (shapeWidth 0.0514961) (shapeHeight 0.102992))
)
(padStyleDef "Round1"
(holeDiam 0.125984)
(padShape (layerNumRef 1) (padShapeType Ellipse) (shapeWidth 0.133984) (shapeHeight 0.133984))
)
(padStyleDef "Rectangle1"
(holeDiam 0)
(padShape (layerNumRef 1) (padShapeType Rect) (shapeWidth 0.07) (shapeHeight 0.1))
(padShape (layerNumRef 16) (padShapeType Ellipse) (shapeWidth 0) (shapeHeight 0))
)
…

That is not so different from XML, is it?

The only reason I can think of why Farnell/CadSoft wants to switch to XML is that they hope that the heavyweights like Cadence or Pads will start writing Eagle import filters for their products. These products already know XML, it would be easy enough to add Eagle support. And that would be a good sales argument for Eagle. Start simple and low-budget with Eagle and when you’re ready to move on to something more serious you won’t lose your work.

It is all about compatibility.