[Ground-station] How are we set for layout tools?
John Ackermann N8UR
jra at febo.com
Tue Jul 28 07:59:21 PDT 2020
One suggestion: it might prove very useful over time, regardless of
tool(s) used, to maintain in a repo libraries of the symbols and
footprints used in all group projects.
John
----
On 7/28/20 10:53 AM, Keith Wheeler via Ground-Station wrote:
> Again, my sincere apologies to the group. This has been the second time
> in a few days I’ve uncharacteristically taken something very personally;
> I’m not sure if the combined stress of the current situation,
> unseasonable heat where I am, and some underlying health issues are
> causing me issues; I'm working on evaluating root-cause.
>
> It seems we have a strong support for Kicad and a number of users of
> this tool. In addition to layout tools, I think there are some other
> topics we should reach a consensus on for hardware design. I suggest the
> following:
>
> 1.
>
> For primary work we standardize on Kicad. If any work for a primary
> team project is done in another tool, it should be shifted to Kicad
> as soon as possible.
>
> 2.
>
> Ancillary projects (proof of concept, promotional, fundraiser items)
> may be done in any tool a volunteer has access to. It is preferred
> that Kicad support import of the original tool’s source files, and
> where possible a Kicad version should be published
>
> 3.
>
> If we don’t have this yet, we should create a hardware project
> template that includes expected output files: gerbers for all
> layers, including solder stencil, pick and place files, and bill of
> materials (csv format?). These files are to be updated per tagged
> release. This also opens the question of do we have a repo for
> source and another for tagged released outputs.
>
> 4.
>
> The visual nature of hardware source makes it fundamentally
> different from software source. Any text editor will work with a .c
> file; however even an open source text based schematic source file
> must be opened with the correct tool to view the schematic. Not all
> parties interested in the schematic and layout source files will
> desire access to the tool. We should publish these in a more common
> format (pdf?), perhaps at every tagged release. I think publishing
> widely readable schematic images may have a benefit over "just"
> publishing the source for a specialized tool. Legal experts could
> chime in here.
>
> As I stated Kicad has always seemed counter-intuitive to me and is a
> realm where I lack experience/skill. On topic 2, I’ve made a request on
> slack that the “trans-ionospheric) badge source files be imported into
> Kicad by someone with those skills, and Kicad versions be placed in the
> repo. This offers a non-critical test of this process.
>
> On topics 3 and 4: the trans-ionospheric repo has an “outputs” directory
> with gerber layers, tool DRC reports, and assembly, layer, and drill
> drawing pdfs. Alongside the schematic source are pdfs of the schematic
> sheets. Perhaps this could be the nucleus for a discussion on our
> standard hardware repo structure and content.
>
> Again my apologies for my outburst. I am strongly committed to ORI, open
> source, and the outstanding opportunities this group has to do
> beneficial work.
>
>
> On Tue, Jul 28, 2020 at 4:15 AM Николай <d256 at yandex.ru
> <mailto:d256 at yandex.ru>> wrote:
>
> DipTrace (www.diptrace.com <http://www.diptrace.com>) is good (has
> diff pair routing for example) and not expensive.
>
>
> 28.07.2020, 07:00, "Keith Wheeler via Ground-Station"
> <ground-station at lists.openresearch.institute>:
>
> My apologies to everyone; re-reading that it comes off much
> harsher than I intended.
>
> My points were simply:
>
> 1) I was merely answering Michelle's questions about what tools
> the team had access to, not trying to state we should use one
> tool over another
> 2) Some prefer and have great success with Kicad; that's
> fantastic, use the tools that work for you, that's what I do
> 3) As Bruce pointed out, Kicad continues to evolve and from what
> I've heard has the ability to import Altium documents now, on
> top of the many other importable formats
>
> Again, my apologies for coming off harsh, long hot day here in
> the PNW.
>
> -Keith
>
> On Mon, Jul 27, 2020 at 7:49 PM Keith Wheeler
> <keith.m.wheeler at gmail.com <mailto:keith.m.wheeler at gmail.com>>
> wrote:
>
> An amazing amount of discussion (and some latent feelings)
> brought up by me merely answering the "what layout tools do
> we have" question.
>
> Next time I'll be sure to make a disclaimer that my
> professional day to day use of a proprietary tool isn't
> meant to upset the open source gods. Circuit Studio natively
> uses my nearly two decades worth of Altium libraries and
> previous designs and costs $495 for a perpetual license,
> plus an annual fee if you want updates. I try Kicad every
> year or two but find it odd and counter-intuitive, and
> having the overall feel of software people saying "wouldn't
> it be cool to do open source hardware tools" rather than
> hardware people saying "here's what we need in open source
> tools". The switching costs of learning a new
> (counter-intuitive to me) tool along with importing many
> years of work are just too high for me. Obviously not for
> everyone nor necessarily for the work ahead of us.
>
> I'm not a retired pundit so I apologize for not having the
> time to play with a tool when I have to work for a living.
>
> I don't apologize for having volunteered my time and
> shameful tool skills to do layout for an ORI fundraiser as
> well as other work for "the community". It's what we do.
> Even without much in the way of appreciation.
>
> I will clarify the following:
>
> On source files: there is an opensource altium2kicad tool
> for the source files (schematic and pcb source) so any work
> done in this tool is not trapped in proprietary files. And
> apparently early this year an Altium importer was added to
> Kicad project. Additionally PCB "manufacturing" only
> requires gerbers RS274x/gcode output text files, not
> proprietary.
>
> All that said I really have no dog in this fight and will
> let you return to your philosophical debates, I've got
> boards to design.
>
> On Mon, Jul 27, 2020 at 7:47 PM Wally Ritchie via
> Ground-Station <ground-station at lists.openresearch.institute
> <mailto:ground-station at lists.openresearch.institute>> wrote:
>
> Yes snapeda is a great resource. I've been using it for
> the past 2 years. It often has a part I need - sometimes
> with the 3d model as well. Generally, it's a reliable
> shortcut. I too have sometimes has to tweak the part but
> it's usually far less effort than building from scratch.
> I don't recall any serious errors in their parts.
>
> I wouldn't bet against autodesk and eagle. Eagle is part
> of their cloud SAAS strategy and enhances their product.
> I don't think they care at all about the workflow of
> hobbyists - they care about the workflows of teams
> producing commercial products. They do not care one bit
> about loosing non-paying customers to KiCad. They care
> about loosing paying customers to Altium. Perhaps
> someday they'll drop free versions. But it doesn't hurt
> their sales and enhances the flow of paying subscribers
> while getting them some library parts for zero
> investment. So it's unlikely. Autodesk has for years
> provided free versions of tools! like inventor to
> educational and non-profits like FIRST to get students
> familiar with their products. They are a billion dollar
> company doing quite well. They may someday have to
> overhaul the Eagle code base. But that doesn't appear to
> be anything in the near future. Eagle remains far more
> open than any other commercial package with respect to
> adding and extracting data and supplementing it. In any
> case there is plenty of room for KiCad and Eagle in the
> short term.
>
>
> On Mon, Jul 27, 2020 at 9:49 PM John Ackermann
> <jra at febo.com <mailto:jra at febo.com>> wrote:
>
> That's a great synopsis, Wally.
>
> One unavoidable concern, and I don't have an answer
> for it, is the learning curve where different team
> members are used to different tools; that's much
> more likely in a volunteer project than a commercial
> enterprise, I think. Standardizing on a tool within
> everyone's reach helps with that, but I doubt that
> outweighs the other arguments you're making.
>
> But as a tiny side point I'll mention again, just
> for future reference, that snapeda.com
> <http://snapeda.com/> seems to have a very good
> engine for designing symbols and footprints
> according to some (unknown to me) standard
> specification, and a very large collection of
> pre-defined parts. I often make minor edits to
> their files (easy to do in KiCad), but so far
> everything I've used from them has worked -- as in
> physical footprint matches physical device, and
> wires go to the right places. (Now, keep in mind
> I'm dealing with far more pedestrian parts than the
> ones you're talking about...)
> On Jul 27, 2020, at 8:51 PM, Wally Ritchie via
> Ground-Station
> <ground-station at lists.openresearch.institute
> <mailto:ground-station at lists.openresearch.institute>> wrote:
>
> 1. Few if any tools are perfect, certainly not
> any PCB design tools, or as John Ackermann
> eloquently put it - all of them suck to varying
> degrees. All depends on whether your outlook is
> half-empty or half-full, what you are trying to
> accomplish, and what value you place on
> different things - especially, time and money.
>
> 2. Generally, we are not in the business or
> non-business of producing tools - except maybe
> those that are so specialized to our tasks that
> they make sense, either because of the nature of
> the task or the learning curves associated with
> the alternative. So we might write some ad-hoc
> open-source verification tools in python instead
> of an expensive simulink framework - then again
> the latter may make more sense - it all depends
> on what we are trying to do and the skill sets
> available to the project.
>
> 3. We are embarking on a level of Engineering
> development on a scale not undertaken before in
> the Amateur community, at least with regards to
> the technologies we are working with - $2000 FPA
> chips, $800 radio chips, 12 layer boards, SERDES
> lanes operating at 12GHz, multi-kilobuck dev
> boards. These many technologies are pretty far
> from traditional Amateur radio and hobby boards.
> The projects we are undertaking involve
> professional skill sets in many fields. Those
> working in these fields are accustomed to having
> tools able to do the job at hand. We are
> counting on many Amateur Radio Enthusiasts who
> are in fact professionals with relatively
> current skill sets, many with high hourly value
> in commercial or government settings. We are
> asking such hams and non-hams to contribute to
> our projects on a volunteer basis. We don't
> expect them to have to bring or buy their own
> software tool licenses, test equipment, $3000
> eval boards, or $2000 chips. We want their
> skills - not their stuff. For these projects to
> succeed we will find ways to supply the stuff -
> and the volunteers will supply the much higher
> value engineering labor. Whatever investments we
> make in tools will be those that are highly
> leveraged.
>
> 4. You wouldn't make your own hammer, or drill,
> or CNC machine - although you could with open
> source designs. It might be fun to do that - but
> it would be a diversion taking you away from the
> current mission. If you can get a carpenter to
> build something for free labor - you wouldn't
> ask him to make his own tools - just because he
> can. We won't build our own spectrum analyzers
> or oscilloscopes - although we could. We focus
> on our project and we will beg, borrow, steal,
> or buy if necessary the tools and test equipment
> to complete the jobs we are doing.
>
> 5. With regard to PC tools, the opinions that
> matter are those of the people who will be doing
> the critical work and what they need to perform
> their job. What tools are used for a simple
> pi-shield don't matter much. What tool is used
> to produce a 12 layer FPGA board with 5 DDR4's
> and a dozen transceiver lanes may matter much -
> especially to the person doing the work and the
> downstream fab, smt, and test processes. Over
> the past few decades or so the roles of pcb
> layout specialist and draftsman have all but
> disappeared. Mechanical engineers themselves are
> married to solidworks, or Catia, or whatever.
> EEs are married to Allegro, Altium, OrCad or
> some other multi kilobuck per seat tool - and in
> relatively rare cases some small companies may
> use Eagle Professional multi-seat versions -
> some still living in Version 7 and others having
> moved to Autocad Fusion. Mechanical and
> Electrical groups often need close collaboration
> which is the value that PCB/3dCAD integration
> brings to the table. Catia handled this well at
> the high end if you have megabucks. Fusion looks
> like it's workable for the low end. I've never
> known of any organization doing commercial or
> military work using KiCad. I suppose it's
> possible but it's usually a poor choice
> economically - like asking engineers to work at
> ping-pong tables sitting on folding chairs with
> CRT monitors. These are certainly cheap and
> plentiful. But productively comes from proper
> capitalization of workers - including
> programmers and engineers. Time is money.
> Volunteer time may have zero associated dollars
> but it has associated value that we do not wish
> to squander - especially when it comes to the
> most complex parts of our projects.
>
> 6. Our goals are to produce open source designs
> that anyone is free to adapt to their specific
> needs. Some parts may require specialized tools
> to use - we wish to minimize that, but non-free
> non-open source tools may sometimes be required
> to utilize the sources. We can limit IP and
> endeavor to avoid purchasing IP beyond that
> included with the standard tools. But I don't
> think we can afford not to use commercial tools
> when they are the best choice for completing a
> particular set of tasks. If we need Matlab to
> run a vendor's filter generation tools - so be
> it. If someone wants to take on converting this
> to Octave - please have at it. If you can modify
> it and prove it's valid we'll be happy to use
> it. Otherwise, we will just suck it up and use
> Matlab (beg'd, borrowed, stolen, or purchased).
>
> 7. Eagle has a long following - many have used
> it since Version 4 or early on Mac, Linux, and
> Windows. They captured a lot of users a decade
> ago with free versions for hobbyist use, free
> versions usable by board houses, and economic
> professional versions with auto-routing etc.
> It's a bit weird and quirky but generally
> extremely stable. I don't see any reasonable
> argument against using Eagle. Nor KiCad for
> those so inclined. But I am against mandating
> either the forced use of open tools or
> particular tools. As projects involving PC
> boards proceed - consensus will likely appear as
> to what is appropriate for the task at hand.
>
> 8. While we are on the subject, PCB layout has
> some esoteric black art skills - especially for
> RF - but a very major part of the work
> load involves preparing footprints, symbols, and
> 3d models for parts. While there are lots of
> parts in standard libraries there is a rule that
> says that many of the ones you want won't be
> there (unless you made them before). There is a
> lot of effort required to make parts correctly
> and to verify them. But this does not involve
> special skills - just a normal skill with the
> tool and the usual conventions (like what goes
> in what layers and what does not. There are
> tools that will generate parts from generic
> descriptions to the formats of popular cad tools
> - e.g. Ultra-librarian and Library Loader - but
> they are often less than ideal - particularly
> with complicated parts that should have multiple
> symbols in functional groupings, not one big
> block with 900 pins. Element14 also added a lot
> of parts (thank you) to Eagle, but often with
> poor symbols. And a lot of stuff you'll download
> from the Internet is poor or outright wrong. If
> a part cannot be found, then considerable time
> will need to be devoted to building and
> verifying the part before the PCB layout can
> continue. Even if a part is found - is it
> correct? What design rules are implied? Frankly,
> this is the vast majority of all PCB design
> activities. So this is an area where many hands
> could potentially help by contributing. There
> will be ongoing needs to build parts, verify
> parts, and manage libraries of proven good
> parts. Have a look at the oresat project's Eagle
> libraries
> https://github.com/oresat/oresat-eagle-libraries. They
> seem to have a workable approach for their needs.
>
> 9. PCB design software is more than schematic
> capture and layout. It also involve simulation
> (e.g. Spice) and design rule verification. Over
> the last decade, integration with 3D mechanical
> tools has also become common. Those in the tool
> business must continue to provide value to
> their customers. Autodesk bought Eagle to add to
> their other offerings. Their Fusion product is
> now pretty usable and economical at the low end
> and integrates with their 3D. They continue to
> offer free eagle versions but their main
> offering is now their $60/month Fusion product.
> Several in this group use these tools
> professionally and they are good value for
> money. The Autodesk model is pretty workable as
> the tools are licensed per named individual but
> they can be purchased month to month (or
> longer). So they are a good match to specific
> board projects. Part work can always be done
> with the free versions or the very stable
> version 7. When we are designing and building
> complex boards with $2000 parts a few months of
> Fusion for a couple of people is in the noise.
> They are a wise use of funding - especially when
> they leverage what would otherwise be tens of
> thousands of dollars of engineering labor.
>
> 10. So I think that the original question that
> started this thread should probably be rephrased
> as:
>
> A. Who has available time and willingness in the
> coming months (and reasonable skill) for
> building parts in X, or Y, or X and Z including
> Footprints, Symbols (not just big squares), and
> 3D models and/or verifying same keeping in mind
> that it's usually best for building and
> verifying to be done by different persons. What
> tools would be needed to take advantage of those
> skills.
>
> 11. As to the complex boards, I think that is
> going to be case by case as design/layout/design
> rules etc are pretty much engineered together
> and difficult to partition within a single
> board. Generally, the board designer(s) will be
> using the tools. I'm sure expert advice on best
> practices for any tool will always be encouraged
> and well received.
>
> 12. As a final note, Eagle/Fusion 360 in the
> latest versions have a feature called "Design
> Blocks" which allow grouping of components and
> traces to be made and treated as one (other
> tools also have this but it has been notably
> awkward to do this with Eagle in the past). This
> adds another layer of library-like work. It's
> especially useful for things like switching
> power supplies and audio circuits where
> grounding and routing issues are critical. It's
> valuable to have drop in blocks for such things
> that have been proven all the way to hardware
> verification (including EMC). Generally using
> these and the 3D fetures requires Fusion as well
> a Fusion user in the Organization that hosts the
> resources. So there might need to be at least
> one more or less permanent fusion subscription
> by the organization in addition to whatever
> month to month subscriptions are required by
> those that are not already fusion subscribers.
>
> As usual - this is only my $0.02 - your mileage
> may vary - use at your own risk.
>
> WU1Y
>
>
>
>
>
>
>
> On Mon, Jul 27, 2020 at 3:51 PM Bruce Perens via
> Ground-Station
> <ground-station at lists.openresearch.institute
> <mailto:ground-station at lists.openresearch.institute>>
> wrote:
>
>
>
> On Mon, Jul 27, 2020 at 9:32 AM Robert
> McGwier via Ground-Station
> <ground-station at lists.openresearch.institute
> <mailto:ground-station at lists.openresearch.institute>>
> wrote:
>
> I wish to say that the issue of which
> tool to be used should not be dependent
> on cost or personal ability to pay.
> Don't ask me more than that, but you are
> entitled to guess all you want.
>
>
> This is just fine if you are making a
> decision on behalf of your university,
> Federated Wireless, or Hawkeye 360.
>
> We are Amateurs.
>
> It is a given that we would be using these
> tools in a personal capacity to build
> experience and achieve our own projects. And
> then using them in a broader role. Thus, a
> tool which is in our reach financially is
> indeed important.
>
> We also wish to teach with our tools.
> /Formal/ education is not a mission of ORI
> because of the need to be licensed and
> accredited, and the fact that this would
> have delayed our initial 501(c)3 acceptance.
> But we still wish to teach through example,
> through the opportunity to participate, and
> all of the things we create.
>
> When we first got money, we used it to
> license proprietary software. This is
> ironic. It's certainly less than optimal,
> and we should be using Open Source if at all
> possible. Decisions to license proprietary
> products should never be made lightly.
>
> Thanks
>
> Bruce
>
>
>
> --
> С уважением, Николай.
>
More information about the Ground-Station
mailing list