Following are the online documents of the parameters driving Adagio’s DC and AC electrical systems”
Energy budget – DC (PDF)
Energy budget – AC (PDF)
AC system requirements (PDF)
Ground design – Lightning, AC/DC, HF radio
12/24VDC battery parallels/disconnects
Following are the basic online documents of Adagio’s electrical design:
Runs: Geometry of each major cable routing (PDF)
Cables: Circuit/cable definitions (PDF)
Conds: All connections to every device (PDF)
Adagio’s electrical design has been developed using a relational database design tool that I developed using FileMaker ProÂ®. The philosophy is that documenting a moderately complex design using only schematics is time-inefficient and not that helpful for either installation or trouble shooting.
This system has worked very well for us so far. Our electrician loves it, and wants to borrow my Powerbook for use on the job while wiring (because you can so quickly find things, trace circuits, etc. in the dbms – as opposed to searching through a book of pages).
A brief overview – the dbms is comprised of 12 relations which I’ll call tables. For those using the dbms design for the first time, following are the core tables and concepts:
1. The Runs table defines the physical routings of all the cabling. This corresponds to CAD drawings of same. Many different connections can use same run, or series of runs. Note that the Conds script “Report Runs Summary” shows you every connection going through any ducting, along with the OD size of the cables.
* I use the naming convention nn.1, nn.2, …, nn.M for Runs IDs where there are various cables going through the same ducting “nn” but which have different run lengths. This is just to force them to group together in the report.
2. The BOM table defines all the components [about 100 pages, a bit too big to put on the website] – from consumers to panels to buss-bars. Therein are defined the electrical characteristics (V, A) and terminal sizes if relevant (like 10-32 screw). This is also the bill of material for purchasing everything except terminals and wire.
* Because each BOM entry defines a physical device/location, you will notice multiple entries with Qty=1 for the same thing (say an 8-gang panel, or a sump pump). Find all the Blue Sea parts, sort by mfg part#, then look at the VendorsDetail report – you’ll see how I’ve summarized these multiple references to the same part#. The VendorsSummary report just shows the total qty lines.
3. The Conds table defines all the connections in terms of an Input Device and Output Device – the devices being referred to by their BOM IDs. I.e., Input == From, Output == To device. I use the convention that the load is defined by the Output Device – which simplifies describing common situations like lights, fans, … supplied by a panel. The Conds table is just a wirelist as used in electronics biz – you can wire and trouble shoot the boat with only this document.
Note that there are some subleties in defining multi-core connections:
* simple cases are such as a duplex wire from a panel to a device. The panel pins will be something like “2,2N” where the device pins will be “P/N” for both pos/neg. The #cores will be 2, the cable type “Dup” for duplex. The computed length/weight/resistance of the wire to be purchased will be 1-way length defined in Conds.
* where you build a circuit with multi-core wire leading to various devices/pins, you describe each single-wire connection in a separate Conds entry. E.g., look at all the Conds entries for inDev = 2071, the mastbase terminal block. There you’ll find 4 separate entries for the 4 core cable running up mast to Tricolor/Strobe/Anchor light. Then look at buyLength in the data dictionary – you’ll see that in such cases the length is divided by the # of cores because of the 4 references to the same piece of cable.
4. The Cables table defines multiple Run and/or multiple consumer loading cases. The Cable (same as Circuit) ID, when referenced in a Conds entry, defines the AWG wire size – i.e., overrides the from-to AWG computed by the Conds table. You simply enter a list of Run IDs, then a list of consumer device IDs which you have decided represent the worst case operating load in shared conductor situations.
5. The allowable voltage drop, as %, is defined in Conds (and Cables if an entry subsumes a given connection). The ABYC wire size computation is the same in either case – the wire size is the larger of that required by “inside engine space ampacity” (conservative) or by the specified drop”.
6. You have to decide what type of wire, color code, and number of conductors to be used – all defined in the Conds entry.
7. Similarly, you have to decide what type of termination is used on both ends for each Conds entry. The default terminal type is RT = Ring Terminal. The allowable types are defined by the TerminalTypes table (bet you already figured that out <g>). I also use the type “SOL” for soldered terminations where we don’t use any kind of terminal.
8. Note that I use the convention that PT = Pin Terminal, which is how wires are terminated that are secured in a hole by a screw (a common AC connection). We actually use Ancor pin terminals, but some folks just tin the end.
9. Wire size priority scheme, from highest to lowest: Conds/BuyAWG field – where you enter what you want, the Cables/reqdAWG field described above, last the Conds/reqdAWG field.
10. Other key CAD drawings (these are layers with variations for voltage – i.e., 24VDC Panels, 230VAC panels). Every drawing shows physical locations as well as logical design, and tags the devices with their BOM IDs which appear in the Conds table, etc.
* buss terminations/distribution points
* ground system design for DC/AC/lightning LPS & Bonding/HF
* nav and deck lights
* pumpsSump, pumpsSea, pumpsFuel
* 12/24V Batteries/Charging
There are only about 15 key schematics, because most simple things are fully described by the Conds table.
11. A slightly complex issue is the generation of correct terminal part#s. The Conds script PopulateTerminals does this. It creates the Terminals table based upon the Conds entries in conjunction with the AncorTerminals table definitions. Ancor terminals which use diff wire sizes will have multiple entries, but same part number.
12. If you want to generate a list of all the terminals you need to buy, as we did so we can order everything from Ancor/US, you have to do a bit of work to find out what gizmos are on each device and tell the Conds table what to use if not a ring terminal. This includes the screw size if it is a ring terminal. Note that BOM can only define one screw size. When a device has different screwsizes for diff pins, you override this in the Conds table. A special case is Blue Sea panels, with have #10 screws for feeds, #8 for buss bars, #10 for breakers. I hard-coded this logic into the ScrewSize script.
The Terminals script “Report Summary” generates the purchase order for terminals.
13. The purchase order for wire is generated by the Conds Script “Report Wire Purchase Summary”.
14. Because Conds defines each wire or cable as from/to, how do you analyze a printed report to find everything connected to a specific device/pin? Run the Conds script “Report Explode” (and be sure to run “Explode Delete” after you have your report). Report Explode mirrors every Conds entry, reversing the from/to fields – creating a table with 2x the original number of entries. In this report you will find in the first column (inDevID) in sorted order every device in the dbms, so you can quickly trace out any circuit and be sure you didn’t miss something because you didn’t know whether it was an “in” or an “out”. Note that mirrored entries are identified by an “x” in the DeleteMe field in the report so you can tell which are “phantom” entries. These will not have their AWG size calculated because the load device is now in the “in” position – e.g., a 100A panel supplying a 3A motor.