On Thursday 04 November 2004 10:03 am, Stephen Meier wrote: > Magnus, > > I am trying to understand your idea of schematic capture workflow. > > 1) Select the symbolic device for example an And Gate or an op amp > 2) Determine the requirements for that element (speed, logic voltage > level, etc) > 3) find the set of devices that could fullfill the element requirements > (different devices or the same "second source" devices that could > fulfill the requirements > 3) Pick the phyisical devices and organize the elements into these devices > 4) Pick the packages for the devices (This is the first moment we > actually have pins) > > Comments?
The schematic is a symbolic representation of an idea. It should not be a manufacturing related document. There are two fundamental classes of users of gEDA/PCB. One group that does prototypes and quick "one-off" jobs. Putting all information in the schematic makes sense at that level. When your done you put all of the information in a file folder or CD and the job is done. Now lets go down the road of the other class, large scale design firms or contract manufacture. For many years I worked in a large contract manufacturing firm in North-West Pennsylvania. I'm sure we experimented with every conceivable way of doing it wrong over the many years of the company. The last thing you want to do is put procurement and manufacturing related items in the schematic, or schematic attributes. The schematic is near the start of a design process. You don't want procurement issues at the end of the manufacturing process peculating back up the process line requiring you to make document changes, and the time consuming approval process for those document changes. If all of your footprint, vendor part number etc. are in the schematic that document gets continually updated, even tho the symbolic representation of the idea has never changed. The right way to do it is put a non-significant number into the schematic, that number indexes into a data base, or a good Material Requirement and Procurement system. [A non-significant number in this cases means there is no categories or other information implied by the number. It is just a number. The next new part is number + 1. Use a very large number, we had 75,000+ different parts in our warehouse. Resist the urge to categorized things!] The database or MRP system is the hub that all other process link to. It contains the footprint, vendor number, approvals required, approvals on file (think FDA, NFPA, ATEX, MECS, EU etc), as well as cross index to alternate parts, and flags that say you can not use alternate parts (FDA etc). It is important to prevent recursive spider-webbing of the numbering system. From your document control system you can get any revision of anything you ever shipped, and can always reproduce the documents such as your Bill-of-Material. If you want to use a industry standard identifier then take a look at http://www.rosettanet.org/ . > >The actual problem is that too much is tied to "symbol". It doesn't scale > > well into the modern world. Consider what happens when the manufacturing department buys new equipment and want the foot prints changed to get a better yield, while the schematic is on file with the FDA. Any change dealing with the FDA cost big bucks, and a lot of time. > >>[Fundamental] The visible name of the package should be implemented as an > >>attribute, that is [7400, 74S00, 74LS00, ...]. Yes. The power pins should also be visible on all parts. Think field service while your hunched over in a four foot high dark wet coal mine shaft debugging equipment, because the fiber optic cable looked to much like wire-rope to the coal miners (they where both gray). > >You need to indicate Speedgrade, Temperature-range, Package for most > > things. There is a number of specialized things like Pb-free, > > avionics/space approval etc. etc. > >Depending on how large design one is making, the work-flow becomes quite > >different. For a larger design, choosing all the details at a singular > > moment in time becomes hard, and recycling that process becomes more and > > more expensive the larger design there is. Such designs are never static either because manufactures continually "improve" things. > >But then, I've been down this road before with no succsess. I've been > > stating this many times here. I can't see a chance of gEDA being used as > > a tool in my company ever as a result, since it will not match our most > > basic needs. I am sure many will enjoy it for other projects thought, but > > if you want to aim for prime-time you need to address the issues we are > > facing. I agree with the sentiment, but gEDA is not meant to be a MRP system. Nothing prevents you from doing what I said above with the database/non-significant number. For those that want to find out more about MRP/ERP issues take a look at these: "Supply Chain Math" at http://www.unusualresearch.com/ : "Manufacturing organizations must always deal with determining how to balance on-hand part inventories and suppliers' response times. Article 6 describes a project called supply chain, which focused on characterizing the various stochastic events influencing a manufacturing organization's shipment and inventory performance. A collection of statistical modeling assumptions, equations, and equation derivations are described that focus on minimizing on-hand inventory and optimizing supplier response time." GNU Enterprise (GNUe) is a meta-project which is part of the overall GNU Project. GNUe's goal is to develop enterprise-class data-aware applications as Free software. GNUe is itself comprised of several subprojects. http://www.gnuenterprise.org/ Compiere ERP + CRM Business Solution Smart ERP+CRM solution for Small-Medium Enterprises in the global marketplace covering all areas from customer management, supply chain and accounting. For $2-200M revenue companies looking for "brick and click" first tier functionality. http://sourceforge.net/projects/compiere/ -- � � � http://www.softwaresafety.net/ �http://www.unusualresearch.com/ http://www.bpaddock.com/
