Re: gEDA-user: Collaborative Development of Boards
John Griessen wrote: There's a way to do sublayouts if they have corresponding subschematics, you just can't have them placable from the footprint library. Is this already noted as a feature request in the trackers? See: http://www.gedasymbols.org/user/john_griessen/ pcb-hier-cells Generator Where can I find the ./pcb-hier-cells pcb-layout-2-replicate.conf referred to on your page? ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 21.01.2011 01:33, schrieb John Griessen: On 01/19/2011 06:23 PM, Markus Hitter wrote: One possible drawback for both ideas: you can't route tracks through the foreign area/sub-layout, even if there's enough room after assembling the zones. In chip layout, where you do have layout sub-cells definable by the tools, all you do for for the route through tracks is put them in the sub-cell as a floating unconnected trace that you do LVS on only at a higher level of completeness -- when it's with the surroundings. Floating tracks might trigger a DRC, but I think they are perfectly valid and I'd rewrite the DRC. I can't remember if DRC2 or anything else complains about floating tracks... John @John, it's interesting that you give an example for collaboration that's in chip design. Chip design is closer to my (professional) home turf than board design (just a hobbyist :-) ), but I always saw the limitation about what I can do in my basement (and limited myself somehow). The chip design floe I know reserves the lower level metal layers to sub-cells and the higher level metal layers to global wiring in reserved to connect the sub-cells (with some simplification). @all on a board level collaboration I see basically two different approaches: 1. time slicing 2. area slicing 1. time slicing One person owns the board for a given period of time, the workflow is: checkout -- work on the board -- chaeckin and the next person takes over. This is the approach to use if the contributors are in different time zones and it really requires godd communication. I think this is supported by geda out of the box as it boils down to a communication problem. 2. area slicing This is far more challenging than the work flow described above The design needs to be partioned into sub-cells, process them independently, and do the connections between thte sub-cells on reserved layers. There are some requirements that the gaf design flow can't fulfill (yet). Net: the question is how you define collaboration that defines your infrastructure sequential or concurrent updates to the desing library. - From my experience the time slicing approach is easier to handl and better supported by tools (cvs, svn...) - -- Mit freundlichen Gruessen Dietmar Schmunkamp -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk06OCoACgkQn22l+QvEah2qNACdF+rzHCg2/yeEgfwMs1jeEV4w wsoAnA8+SB1rilTObZvzmI13y7gFqGVV =giNs -END PGP SIGNATURE- ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
Am 20.01.2011 um 02:24 schrieb Stephan Boettcher: If everybody sticks to a sublayout, at least the VCS merges will not conflict. If the drawn copper conflicts, that's what needs to be cleaned up after the merge. For efficient collaboration there should be some aggrement about who draws where, but technically there should not be any limits how sublayouts overlap. That's back to square one. The purpose of collaboration with a VCS isn't to get something initially done - you could easily use copy paste for that - but to refine things over and over again. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On 01/19/2011 06:23 PM, Markus Hitter wrote: That said, I could use such sub-layouts right now, and they'd save quite a bit of work :-) There's a way to do sublayouts if they have corresponding subschematics, you just can't have them placable from the footprint library. See: http://www.gedasymbols.org/user/john_griessen/ pcb-hier-cells Generator John -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On 01/19/2011 06:23 PM, Markus Hitter wrote: One possible drawback for both ideas: you can't route tracks through the foreign area/sub-layout, even if there's enough room after assembling the zones. In chip layout, where you do have layout sub-cells definable by the tools, all you do for for the route through tracks is put them in the sub-cell as a floating unconnected trace that you do LVS on only at a higher level of completeness -- when it's with the surroundings. Floating tracks might trigger a DRC, but I think they are perfectly valid and I'd rewrite the DRC. I can't remember if DRC2 or anything else complains about floating tracks... John -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
Am 18.01.2011 um 01:56 schrieb John Griessen: I thought about this some more after sleeping last night, and what Markus is probably asking for is a position range sensitive diff or auto- merge. When people make changes in PCB that can be merged, it means they are working in different places, zones, quadrants... IOW if you could say easily *where* you were working was different and not overlapping another's work, an auto-merge would work -- if it only over-rode layout traces and footprints in the limited zone of the change made... That reminds me on an idea discussed here a few weeks ago: drop the current footprint logic and replace it with full fledged circuit layouts. You'd edit the sub-layout in it's own file and insert that into the total layout as a non-editable, but movable block. One possible drawback for both ideas: you can't route tracks through the foreign area/sub-layout, even if there's enough room after assembling the zones. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
Markus Hitter m...@jump-ing.de writes: Am 18.01.2011 um 01:56 schrieb John Griessen: I thought about this some more after sleeping last night, and what Markus is probably asking for is a position range sensitive diff or auto- merge. When people make changes in PCB that can be merged, it means they are working in different places, zones, quadrants... IOW if you could say easily *where* you were working was different and not overlapping another's work, an auto-merge would work -- if it only over-rode layout traces and footprints in the limited zone of the change made... That reminds me on an idea discussed here a few weeks ago: drop the current footprint logic and replace it with full fledged circuit layouts. You'd edit the sub-layout in it's own file and insert that into the total layout as a non-editable, but movable block. One possible drawback for both ideas: you can't route tracks through the foreign area/sub-layout, even if there's enough room after assembling the zones. Why do you need that limitation? Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user -- Stephan Böttcher FAX: +49-431-880-3968 Extraterrestrische PhysikTel: +49-431-880-2508 I.f.Exp.u.Angew.Physik mailto:boettc...@physik.uni-kiel.de Leibnizstr. 11, 24118 Kiel, Germany ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
Am 19.01.2011 um 22:27 schrieb Stephan Boettcher: Markus Hitter m...@jump-ing.de writes: Am 18.01.2011 um 01:56 schrieb John Griessen: I thought about this some more after sleeping last night, and what Markus is probably asking for is a position range sensitive diff or auto- merge. When people make changes in PCB that can be merged, it means they are working in different places, zones, quadrants... IOW if you could say easily *where* you were working was different and not overlapping another's work, an auto-merge would work -- if it only over-rode layout traces and footprints in the limited zone of the change made... That reminds me on an idea discussed here a few weeks ago: drop the current footprint logic and replace it with full fledged circuit layouts. You'd edit the sub-layout in it's own file and insert that into the total layout as a non-editable, but movable block. One possible drawback for both ideas: you can't route tracks through the foreign area/sub-layout, even if there's enough room after assembling the zones. Why do you need that limitation? Without that limitation, a zone is no longer a zone and conflicts can happen. Doesn't apply for tracks drawn to the main layout, of course. Also doesn't apply to sub-layouts of undefined size, but then the idea of sectoring a board for different contributors becomes a bit limited. That said, I could use such sub-layouts right now, and they'd save quite a bit of work :-) Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
Markus Hitter m...@jump-ing.de writes: Am 19.01.2011 um 22:27 schrieb Stephan Boettcher: Markus Hitter m...@jump-ing.de writes: Am 18.01.2011 um 01:56 schrieb John Griessen: I thought about this some more after sleeping last night, and what Markus is probably asking for is a position range sensitive diff or auto- merge. When people make changes in PCB that can be merged, it means they are working in different places, zones, quadrants... IOW if you could say easily *where* you were working was different and not overlapping another's work, an auto-merge would work -- if it only over-rode layout traces and footprints in the limited zone of the change made... That reminds me on an idea discussed here a few weeks ago: drop the current footprint logic and replace it with full fledged circuit layouts. You'd edit the sub-layout in it's own file and insert that into the total layout as a non-editable, but movable block. One possible drawback for both ideas: you can't route tracks through the foreign area/sub-layout, even if there's enough room after assembling the zones. Why do you need that limitation? Without that limitation, a zone is no longer a zone and conflicts can happen. Doesn't apply for tracks drawn to the main layout, of course. Also doesn't apply to sub-layouts of undefined size, but then the idea of sectoring a board for different contributors becomes a bit limited. Why? If everybody sticks to a sublayout, at least the VCS merges will not conflict. If the drawn copper conflicts, that's what needs to be cleaned up after the merge. For efficient collaboration there should be some aggrement about who draws where, but technically there should not be any limits how sublayouts overlap. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On Mon, 2011-01-17 at 18:56 -0600, John Griessen wrote: I thought about this some more after sleeping last night, and what Markus is probably asking for is a position range sensitive diff or auto-merge. When people make changes in PCB that can be merged, it means they are working in different places, zones, quadrants... IOW if you could say easily *where* you were working was different and not overlapping another's work, an auto-merge would work -- if it only over-rode layout traces and footprints in the limited zone of the change made... tag for this concept: zone-diff That is a good idea indeed. Could you file a feature request for it please? https://launchpad.net/pcb/+filebug I would have called it spatial-merge ;) John -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On Monday 17 January 2011 08:01:53 ge...@igor2.repo.hu wrote: On Mon, Jan 17, 2011 at 08:22:02AM +0100, Stephan Boettcher wrote: ge...@igor2.repo.hu writes: If you edit one object, that won't ever move other objects around by side effect. VCS systems I know depend on this feature. I think PCB already provides this feature, keeping order of objects, Not really. When you edit a line, it somehow gets thrown into an entirely different slot in the list. Like if there is a vector of allocated slots, some marked unused, and when something is changed, it is thrown into the first unused slot. Probably some feature of some glib(?) container class? It's not too bad for vcs diffs, but could be a little better. Not worth the trouble to fix this, I guess. Hmm, maybe I mix it with something then. I recall some efforts, maybe by Peter to get this fixed in PCB or in gschem. Or else my memory just fails. Due to the way the gschem editing model works, and particularly the undo system, stuff tends to get shifted to the end of the file when edited. This is something that I've made a few improvements to in the past, but fundamentally the problem hasn't gone away. This is actually an extremely difficult problem to solve. Saving a file could be considered as mapping a three-dimensional space (x position, y position, z-index) onto a one-dimensional space (file position). At the moment, the file position is mapped 1:1 to z-index, i.e. last-on-top. Other possibilities (assuming that an alternative way of indicating z- ordering can be found) include defining a Hilbert-Peano curve on the x-y schematic plane and mapping position along that curve to file position. There is no easy fix here. Peter -- Peter Brett pe...@peter-b.co.uk Remote Sensing Research Group Surrey Space Centre signature.asc Description: This is a digitally signed message part. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On Jan 17, 2011, at 5:41 PM, Peter TB Brett wrote: Due to the way the gschem editing model works, and particularly the undo system, stuff tends to get shifted to the end of the file when edited. This is something that I've made a few improvements to in the past, but fundamentally the problem hasn't gone away. This is actually an extremely difficult problem to solve. Saving a file could be considered as mapping a three-dimensional space (x position, y position, z-index) onto a one-dimensional space (file position). At the moment, the file position is mapped 1:1 to z-index, i.e. last-on-top. Other possibilities (assuming that an alternative way of indicating z- ordering can be found) include defining a Hilbert-Peano curve on the x-y schematic plane and mapping position along that curve to file position. There is no easy fix here. When it comes to gschem files, I believe there is a potentially useful compromise. The .sch file structure describes a tree. At each level in this tree the order of the branches does not matter. So, a canonical ordering of a .sch file just requires some sorting criterion. Sort the branches at each level to achieve canonical ordering. Small changes won't scramble the canonical representation much. Canonicalizing .sch files would be easy in our lambda-geda framework. Is there any interest? --- John Doty Noqsi Aerospace, Ltd. This message contains technical discussion involving difficult issues. No personal disrespect or malice is intended. If you perceive such, your perception is simply wrong. I'm a busy person, and in my business go along to get along causes mission failures and sometimes kills people, so I tend to be a bit blunt. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
John, Stephan, Rick, Tibor, many thanks for your insights. I'm convinced there _has_ to be some sort of leadership when different, but technological equal design solutions appear. Am 16.01.2011 um 22:37 schrieb Rick: To be honest, I was a little turned off when I tried to read your web page and the opening didn't even tell me what you are doing! It referred me to another web site entirely... and then another... The link I gave is only one of many pages of a fascinating bigger project, so you typically find this page from higher level ones. This bigger project is about building self-replicating machines, and the circuitry shall drive their stepper motors. There are at least a dozen competing circuitries, most of them at a commercial, read-only open source level. Am 17.01.2011 um 06:28 schrieb ge...@igor2.repo.hu: While PCB isn't that bad at keeping changes to the saved file small, there's always at least the also stored file creation date letting merges fail. Yes, I agree on this one. I think storing such modification date is just the wrong thing to do. I've filed a bug for this: https://bugs.launchpad.net/pcb/+bug/703914 As I'm not aware of a use case for this data, I suggest to get rid of it entirely. If somebody has a use case, please speak up there. The other problem is diff. Again, I don't think there is anessential difference between team work and VCS in software development and in using the same methods/tools on other fields; at least we have the same methods, but some tools are partially missing. As you mentioned one of the differences is the inspection of changes, but there's another one. Track positions are more like the programmer's object data, than like source code. So they can change often, and often without the intent to change functionality of the layout. One solution would be to not store track positions at all, but always generate them with an autorouter on the fly. As long as autorouters aren't as full-featured as compilers in the software world, this isn't an option, though. Future music :-) there's never a version where the changelog says Deleted 20 unused features. Patched 300 memory leaks. No new features added. Sure there are. Actually, they're my favourite ;-) However, your point is totally valid on the other hand: these little fixes, getting the silk layer look nicer for example, does not make any sense if you will move half of the elements in the near future, for example because you don't even have a decision on the connectors yet. The point isn't about refusing cleanup, it's more about doing such cleanups and all those small changes in seperate commits. Each change in it's own commit, so it can be reviewed or cherry-picked easily. I know, the temptation to do it all in one batch is big, as all the current shortcomings are right in front of your eyes. But you loose a lot later. Probably a matter of demonstration the advantages ;-) Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. (FH) Markus Hitter http://www.jump-ing.de/ ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On Mon, 2011-01-17 at 13:50 +0100, Markus Hitter wrote: As you mentioned one of the differences is the inspection of changes, but there's another one. Track positions are more like the programmer's object data, than like source code. So they can change often, and often without the intent to change functionality of the layout. What about extracting the _topology_ of the tracks (probably using / refactoring some code from the topological auto-router). It should not be too hard to produce a same / different output from comparing to topologies, without caring about he minutiae of every coordinate along the way. Producing a useful diff view would be harder of course. One solution would be to not store track positions at all, but always generate them with an autorouter on the fly. As long as autorouters aren't as full-featured as compilers in the software world, this isn't an option, though. Future music :-) This is an interesting idea. Auto-routing to match a particular topology would be feasible, even if a full auto-route from scratch would not be. The topological auto-router can do this. The hard part of auto-routing is generating an efficient topology to use. there's never a version where the changelog says Deleted 20 unused features. Patched 300 memory leaks. No new features added. Sure there are. Actually, they're my favourite ;-) For my money, it sounds like there should have been at least 21 commits there, if not 320. ;) Still - PCB designs are more like deployed web-software.. very linear in their development, and diverging branches don't make a lot of sense. PCBs are of course harder, as it becomes harder to partition and segregate areas of conflict so individual changes could be reverted. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On Mon, 2011-01-17 at 13:50 +0100, Markus Hitter wrote: As you mentioned one of the differences is the inspection of changes, but there's another one. Track positions are more like the programmer's object data, than like source code. So they can change often, and often without the intent to change functionality of the layout. What about extracting the _topology_ of the tracks (probably using / refactoring some code from the topological auto-router). It should not be too hard to produce a same / different output from comparing to topologies, without caring about he minutiae of every coordinate along the way. Producing a useful diff view would be harder of course. One solution would be to not store track positions at all, but always generate them with an autorouter on the fly. As long as autorouters aren't as full-featured as compilers in the software world, this isn't an option, though. Future music :-) This is an interesting idea. Auto-routing to match a particular topology would be feasible, even if a full auto-route from scratch would not be. The topological auto-router can do this. The hard part of auto-routing is generating an efficient topology to use. there's never a version where the changelog says Deleted 20 unused features. Patched 300 memory leaks. No new features added. Sure there are. Actually, they're my favourite ;-) For my money, it sounds like there should have been at least 21 commits there, if not 320. ;) Still - PCB designs are more like deployed web-software.. very linear in their development, and diverging branches don't make a lot of sense. PCBs are of course harder, as it becomes harder to partition and segregate areas of conflict so individual changes could be reverted. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
Sorry, I sent this twice. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On Mon, 2011-01-17 at 09:01 +0100, ge...@igor2.repo.hu wrote: On Mon, Jan 17, 2011 at 08:22:02AM +0100, Stephan Boettcher wrote: ge...@igor2.repo.hu writes: If you edit one object, that won't ever move other objects around by side effect. VCS systems I know depend on this feature. I think PCB already provides this feature, keeping order of objects, Not really. When you edit a line, it somehow gets thrown into an entirely different slot in the list. Like if there is a vector of allocated slots, some marked unused, and when something is changed, it is thrown into the first unused slot. Probably some feature of some glib(?) container class? It's not too bad for vcs diffs, but could be a little better. Not worth the trouble to fix this, I guess. Are you guys talking abut PCB or gschem? PCB does often re-use element memory from deleted objects, so could insert new objects mid way into a list. I'm not sure which (if any) edits cause PCB to create a new object though. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On 1/17/2011 7:50 AM, Markus Hitter wrote: John, Stephan, Rick, Tibor, many thanks for your insights. I'm convinced there _has_ to be some sort of leadership when different, but technological equal design solutions appear. Am 16.01.2011 um 22:37 schrieb Rick: To be honest, I was a little turned off when I tried to read your web page and the opening didn't even tell me what you are doing! It referred me to another web site entirely... and then another... The link I gave is only one of many pages of a fascinating bigger project, so you typically find this page from higher level ones. This bigger project is about building self-replicating machines, and the circuitry shall drive their stepper motors. There are at least a dozen competing circuitries, most of them at a commercial, read-only open source level. Yes, and I have seen the project before. But it took me a couple of reads to realize what this was. Also, I had the exact same problem when I first encountered this project. I think I had to dig for ten or fifteen minutes just to figure out what the project was about. I see this problem all the time when I go to opencores.org. It seems like every project assumes you understand the purpose and goals of their little project not to mention the status. I'm only trying to say that to get more people interested, it would make sense to have your pages provide a bit more basic info so that someone reading it for the first time doesn't have to turn it into a research project just to understand what it's about. Just my two cents worth... Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
Peter Clifton wrote: What about extracting the topology of the tracks (probably using / refactoring some code from the topological auto-router). Isn't this what gnetlist does? I'd say, the netlist contains all topology but no geometry. ---)kaimartin(--- -- Kai-Martin Knaak tel: +49-511-762-2895 Universität Hannover, Inst. für Quantenoptik fax: +49-511-762-2211 Welfengarten 1, 30167 Hannover http://www.iqo.uni-hannover.de GPG key:http://pgp.mit.edu:11371/pks/lookup?search=Knaak+kmkop=get ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On Mon, 2011-01-17 at 21:29 +0100, Kai-Martin Knaak wrote: Peter Clifton wrote: What about extracting the topology of the tracks (probably using / refactoring some code from the topological auto-router). Isn't this what gnetlist does? No - we are talking cross purposes I think. gnetlist produces a netlist from a schematic. With regards the PCB, I was thinking more of producing an output which described the _topology_ of the wiring. That is, describing relative to other wiring / obstacles, where various tracks are, but without getting into the minutiae of which XY coordinates each segment of track occupies. -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) Tel: +44 (0)1223 748328 - (Shared lab phone, ask for me) ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On 01/16/2011 11:28 PM, ge...@igor2.repo.hu wrote: Some of the most hardcore ones are even do modifications using text editor on regular basis, and it is often faster than ivoking PCB for a click-around session - you have the same diff tool, and the language is the same, so you jump the same 2 level of abstrsctions. So what's the big deal the two processes still differ so much seamingly? The middle one. Non-programming EEs usually won't do the middle step, which means they won't be able to do the 2nd abstraction either. Without diff, your VCS reduces to a shared file system with backups. Thanks Tibor, Great writing about teams. I thought about this some more after sleeping last night, and what Markus is probably asking for is a position range sensitive diff or auto-merge. When people make changes in PCB that can be merged, it means they are working in different places, zones, quadrants... IOW if you could say easily *where* you were working was different and not overlapping another's work, an auto-merge would work -- if it only over-rode layout traces and footprints in the limited zone of the change made... tag for this concept: zone-diff John -- Ecosensory Austin TX ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On 01/16/2011 03:11 PM, Markus Hitter wrote: Being more a mechanics and software guy, I'm astonished how things in the electronics world apparently work. Perhaps I'm exaggerating a bit. Teams I've worked on set responsibilities and have time goals. I've not had any free hardware collaboration happen yet. Not sure it will...so best to have your own goals lined out and try to enlist others to follow. If none of the volunteers will follow, let their branches and forks of the project be there, but don't accept all of them in your production branch, then execute that one for manufacturing and selling and let the dead branches lay there in a git repos unused except by some that would never agree to help get something out the door. Weed out collaborators that have no goal like yours. Leading is the same as with pay or no pay -- you must make an example by doing to get people to follow you. To get the best collaborators enlisted, argue the time it takes to do it all different ways is lost as a way to try and get them to use the same design components. Figure out what their goals are. Ask questions like, What does that do for you to use that connector?, then show how your choice does almost the same satisfaction for them, if not, how is theirs better? What could the time spent to switch get -- it's really lost time, so that is one lever to use. Arguments over resistors and caps are seldom, but I can see connectors. I've made connector choice early and important in my planning and allow time to get them at good prices from Taiwan. Flat flex cable and connector is my favorite for low costs. John ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
Markus Hitter m...@jump-ing.de writes: Being more a mechanics and software guy, I'm astonished how things in the electronics world apparently work. Perhaps I'm exaggerating a bit. Is it even possible to do something in collaboration? I'd appreciate any answer. In our lab we recently had very nice results partitioning the work across multiple boards. The mechanics engineer did a fine housing, a PhD-student made the front-end board with eagle, I made the main board with gEDA/PCB, and our electronics engineer does the power board, using eagle. There was FPGA and ARM7 firmware to do as well. Lot's of opportunities to devide work and to collaborate. You have to agree on the interfaces for sure. But collaborating on a single layout is pretty stupid. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On 1/16/2011 4:11 PM, Markus Hitter wrote: Hi all, having run an open source electronics project with the intention of collaborative development for a few months now, the experience is less than inspiring. So I'm looking for opinions on how to do better. http://reprap.org/wiki/Generation_7_Electronics http://github.com/Traumflug/Generation_7_Electronics Looking at what happened in these few months, I think the essence can be described in 3 topics: 1. Files aren't mergeable. While PCB isn't that bad at keeping changes to the saved file small, there's always at least the also stored file creation date letting merges fail. One can store a design's files in a Git repository, of course, but always only in a linear fashion. As soon as one collaborator works on something, all others have to wait until he's done. The versioning system would actually need a locking mechanism, like good ol' CVS had. 2. Agreements on design decisions are impossible For example connectors: Some use connectors with 4 mm spacing, others use 5.08 mm spacing, third people consider anything pluggable as stupid and use nothing but screw connectors. A project leader - y'know, open source tries to avoid such terms - can do a decision, of course, but single people will plainly refuse to manufacture or use anything without their favoured connector. Such design details are apparently hardcoded in electronics' people's brains. As a result, lots of incompatible designs exist, and there's nothing like a preprocessor, which could switch between different details on the fly. The same applies for FETs, diodes, jumpers, whatever. 3. No focus on the problem to solve If you look at the recent commits of this project you'll see enhancements always coming along with a plentitude of unrelated changes. Yes, make these pads a bit bigger, but also move a track here and change a text there. looks better. IMHO, doing such random changes is good for nothing but asking for trouble. Yet, none of the coworkers seems to see what I'm talking about. They do looks better all the time, making reviews a lot harder, and sometimes you even get regressions. Being more a mechanics and software guy, I'm astonished how things in the electronics world apparently work. Perhaps I'm exaggerating a bit. Is it even possible to do something in collaboration? I'd appreciate any answer. Cheers, Markus P.S.: Yes, I'm well aware of the Arduino project, and I see only single people results there. No collaboration. P.P.S.: The project's success isn't as bad as the above might imply. The design actually works. I feel your pain! Even working in a company, it gets frustrating for both designer and manager alike. Managers only want to focus on the short term goals because it is hard to meet the long term goals if you don't meet the short term goals. Designers want to optimize everything with the idea that with optimization comes efficiency resulting in meeting the goals better and possibly quicker. Of course, neither is 100% right, but at least company management can make decisions and end stalemates and thrashing. In a volunteer project it is hard to get people to focus on the appropriate goals. But this is in no small part because the goals are not agreed on and possibly also not communicated even when agreed on. My one suggestion is to get your participants to agree to written goals and then make them very visible so they are not forgotten. In reality, you have to work using the same methods as in a job. You just can't beat people with a stick to make them do it. The stick doesn't work well in a job environment and doesn't work at all in a volunteer group. But without goals and the rest of the organizational stuff, the work will proceed slowly, not always in the right direction and result in a lot of frustration. Sorry I can't be a bit more specific. To be honest, I was a little turned off when I tried to read your web page and the opening didn't even tell me what you are doing! It referred me to another web site entirely... and then another... Rick ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
Hello Markus, On Sun, Jan 16, 2011 at 10:11:31PM +0100, Markus Hitter wrote: Hi all, having run an open source electronics project with the intention of collaborative development for a few months now, the experience is less than inspiring. So I'm looking for opinions on how to do better. http://reprap.org/wiki/Generation_7_Electronics http://github.com/Traumflug/Generation_7_Electronics Looking at what happened in these few months, I think the essence can be described in 3 topics: Mech and programming bakground, I have the same, but I don't agree these things would work any better in programming. As others, I also think these problems are basically the same for free and for non-free jobs, as others on the list already expressed. Team work is hard to do right, and this is largely independent of the field you try to do it in engineering. 1. Files aren't mergeable. While PCB isn't that bad at keeping changes to the saved file small, there's always at least the also stored file creation date letting merges fail. One can store a design's files in a Git repository, of course, but always only in a linear fashion. As soon as one collaborator works on something, all others have to wait until he's done. The versioning system would actually need a locking mechanism, like good ol' CVS had. Yes, I agree on this one. I think storing such modification date is just the wrong thing to do. Since I started to use PCB, I always stored everything in svn and I often had minor problems with the date lines. Subversion, and any other decent version control system offers means to generate last mod date, author info, etc by the VCS in a way this meta-info will look like being part of the file content to the end user while it won't interfere with versioning, especially won't cause diffs. I suggest we make this part of the file format optional, default turned off. (Feature request #1) The other problem is diff. Again, I don't think there is anessential difference between team work and VCS in software development and in using the same methods/tools on other fields; at least we have the same methods, but some tools are partially missing. How does it work with software? A. the source code is an ordered list of objects (not in the OOP sense). If you edit one object, that won't ever move other objects around by side effect. VCS systems I know depend on this feature. I think PCB already provides this feature, keeping order of objects, but in my daytime job I often meet non-programming tasks where the editor doesn't and if you do a minimal change, fix a typo in a text or anything alike, things get reordered and you always get a full-file-diff. So whatever tool you use, you must make sure it does minimal change needed in the source file. B. diff. When you work on souce code, you make a diff to see what others changed, or what you are going to submit as your change. With programming, you have the same stages as with PCB. For programming: - real representation is when your program is running; this is the final form, as interpreted (not in the CS sense) by the machine, the goal of your efforts - the source code is something abstract you don't see working while editing; you look at your source code and interpret it, and imagine how it would work, but sure it won't translate 1:1, you use your brain a lot for that transformation while coding - diff is the second abstraction, a language describes changes between 2 such abstract source code. Experienced programmers have the skill to read an intrepret the change, reconstruct the source code in head, interpret those code and reconstruct the final behaviour. This requires jumping 2 levels of sbastraction in one step, transarently. Now for a PCB (assuming we are talking about the layout work only, as your mail suggested): - real representation is what the GUI shows, this is almost 1:1 what you will get in form of copper and plastic. - the source code is PCB file, this is what fed into the VCS system. Same abstraction as with program source code vs. running the program, and PCB users can even do the same trick interpreting the sources to different degree. Some of the most hardcore ones are even do modifications using text editor on regular basis, and it is often faster than ivoking PCB for a click-around session - you have the same diff tool, and the language is the same, so you jump the same 2 level of abstrsctions. So what's the big deal the two processes still differ so much seamingly? The middle one. Non-programming EEs usually won't do the middle step, which means they won't be able to do the 2nd abstraction either. Without diff, your VCS reduces to a shared file system with backups. In reality you probably won't ever get all your contributors to learn the file format and track changes on that level, so you'll need something else. Probably a graphical
Re: gEDA-user: Collaborative Development of Boards
ge...@igor2.repo.hu writes: If you edit one object, that won't ever move other objects around by side effect. VCS systems I know depend on this feature. I think PCB already provides this feature, keeping order of objects, Not really. When you edit a line, it somehow gets thrown into an entirely different slot in the list. Like if there is a vector of allocated slots, some marked unused, and when something is changed, it is thrown into the first unused slot. Probably some feature of some glib(?) container class? It's not too bad for vcs diffs, but could be a little better. Not worth the trouble to fix this, I guess. -- Stephan ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On Mon, Jan 17, 2011 at 08:22:02AM +0100, Stephan Boettcher wrote: ge...@igor2.repo.hu writes: If you edit one object, that won't ever move other objects around by side effect. VCS systems I know depend on this feature. I think PCB already provides this feature, keeping order of objects, Not really. When you edit a line, it somehow gets thrown into an entirely different slot in the list. Like if there is a vector of allocated slots, some marked unused, and when something is changed, it is thrown into the first unused slot. Probably some feature of some glib(?) container class? It's not too bad for vcs diffs, but could be a little better. Not worth the trouble to fix this, I guess. Hmm, maybe I mix it with something then. I recall some efforts, maybe by Peter to get this fixed in PCB or in gschem. Or else my memory just fails. Yes, I agree it is not too bad for the diffs in practice, at least when I edit a file alone on multiple computers I rarely see actual problems - except diffs caused by storing the date. ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
Re: gEDA-user: Collaborative Development of Boards
On Sun, Jan 16, 2011 at 11:28 PM, ge...@igor2.repo.hu wrote: Yes, I agree on this one. I think storing such modification date is just the wrong thing to do. ... I suggest we make this part of the file format optional, default turned off. (Feature request #1) +1 agree, kill with fire, would do business with again, etc. Regards, Mark markrages@gmail -- Mark Rages, Engineer Midwest Telecine LLC markra...@midwesttelecine.com ___ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
