big electronics update

just wanted to let you guys know that i gave the electronics section a makeover tonight. got things nice and sparkly clean. heres a list of changes that i've made:

1. moved production boards to folder with other boards.
2. released and deleted previous versions of old powercomms/universal boards.
3. renamed all board folders to something consistent, and lowercase
4. removed any .pho (gerber) .ps (postscript) and .drl (drill) files from the repository. they are generated files, and are included with each release. this is so that developers must remember to re-generate them when they make a new release (instead of accidentally using the old ones in the repo.)
5. updated package script. it now takes a directory argument (of the board to release) and an optional release name argument. it now makes PDFs of all the boards!! its not gerber -> pdf, so the developer has to do a ps plot, but thats rather easy when you're doing a gerber one anyway. i'll get the gerber ones up soon i hope. also, the source files are included in the release now. the packaging system should be pretty solid for electronics now.
6. fixed and released the powercomms v1.2.1 board. more in a separate post.
7. fixed the optoendstop board to show the reprap silkscreen stuff.
8. fixed the stepper tester to have nice silkscreen stuff.

whew! that was a pretty hefty chunk of work. i've been meaning to really clean up that folder for a long time though.

Good work! 18 svn commits in under 3 hours... you were *really* working!

(I'm looking at doing a similar (but smaller) cleanup in the Reprap/lib directory myself. We don't need Java3D or Java Comm stuff in there any more.)

One thought: For packaging purposes, wouldn't it be more consistent with the other subsystems to release a single .zip containing files for a full set of *all* the boards, rather than four separate packages, one per board?

In other words, are we looking for one host package, one firmware package, one electronics package and one mechanics package (plus the external things like Kicad and AoI and so forth, which we didn't develop ourselves)? It's not a big deal to me, but in terms of explaining to newcomers what they should download, it might be simpler to have the boards all together in one .zip file?

Jonathan

thanks =)

at first i thought it makes sense to do a big release of all the boards, and it probably does when we get to some sort of milestone. however, they are all basically independant, with various versions of each. also, since you have to use kicad to plot the gerbers and ps files, and they are not store in svn anymore, it would be a huge PITA to try and release everything when you make a change to just one board.

the only two boards that will really be changing with any frequency are the powercomms and the universal. hopefully after we integrate the programmer into the powercomms, then it will be rather static for a while.

> since you have to use kicad to plot the gerbers and ps files,
> and they are not store in svn anymore, it would be a huge
> PITA to try and release everything when you make a change
> to just one board

Wasn't someone working on adding a command line option to Kicad to solve that -- so it can produce the Gerber files as needed from a Makefile? Did that idea ever get anywhere? It sounds like we need that to get a sane automated build process for these files. The current process includes "please remember to..." and so you can just *know* that at some stage, someone will forget!

Meantime, maybe the packaging script could at least check for the existence of those files and exit with an error message if they are missing, so you simply don't get a .zip if you forgot to generate them?

Jonathan

yeah, it was a "man... it would be nice..." type of thing. it would be pretty simple to add a check to see if the gerber files exist. then, once i get the gerber2pdf link working, all you have to remember to do is plot the gerbers. the pdfs would then be automatically generated from those.

then, when kicad eventually gets the commandline option, then we can completely automate the process. however, doing kicad -> gerber is pretty easy (and it usually remembers your plot options. i think i wrote a wiki page on how to set them anyway)