Author Topic: Altium Designer cover page and formatting guidelines  (Read 3534 times)

0 Members and 1 Guest are viewing this topic.

Offline Pack34Topic starter

  • Frequent Contributor
  • **
  • Posts: 753
Altium Designer cover page and formatting guidelines
« on: March 07, 2017, 10:01:43 pm »
Does anyone have any good examples for this?

I'm about to start a standard at work and would like to start off on the best foot possible without having to go back and redoing old work because something was missed.
 

Offline Gribo

  • Frequent Contributor
  • **
  • Posts: 629
  • Country: ca
Re: Altium Designer cover page and formatting guidelines
« Reply #1 on: March 07, 2017, 10:39:56 pm »
Check out Fedevel's sample projects and Youtube tutorials. He has one dealing with this subject.
I am available for freelance work.
 

Offline julianhigginson

  • Frequent Contributor
  • **
  • Posts: 783
  • Country: au
Re: Altium Designer cover page and formatting guidelines
« Reply #2 on: March 08, 2017, 01:33:21 am »
Are you talking about schematic templates and a schematic cover page?

Schematic templates are pretty easy..

1) make up a title block with everything you want. I'm not a fan of default Altium block because it's a bit simple. But I'm also not a fan of the ANSI title block, it's got too much stuff that isn't relevant to electronics and modern file based designs... I say use the default and ANSI presets as a guide, and draw your own. just using the bits of info your company needs... this will come back to your workflow. do you have a separate schematic designer, checker, and approver? then you need at least to show designed by, checked by, approved by. and maybe also drawn by if you have a separate drafter to designer... do you want to support production release and non production release file versions? in that case you need to show this however it's defined. Do you have a design cycle status to display ("new", "release candidate", "release", "under change", "deprecated") do you have document numbers? (the number of times I've seen schematic sheets with a document number field that is there but unused... or has a name in it... you don't have to have document numbers if you don't want to! but if you are having them then you also need a document numbering system and people have to use it!!!) Do you have multiple customers? if so, project's customer is important.

2) try to use standard document parameters as found in document options, then use text in the template to display parameter values.. Add parameters when you have to, and use similar descriptive naming convention! This way when you eventually update the template, because requirements for your template will ALWAYS evolve as your process matures and needs change, you can just re-apply the updated template to old schematic sheets in the future as you go, and nothing will get blown away. Conversely, if say, your business address changes one day... well - next time you're working on an old file, just open the parameter manager, grab the relevant parameters for each sheet in the project and bulk replace them. Much faster than directly hacking multiple text objects on every single sheet!

3) once you have done your first sheet template and are 100% happy with it, you just go through and re-size the page in properties, saving each time (and moving the title block into new bottom right corner)  to make all the others.

4) One thing with the template  or any other kind of schematic file - make sure any images (like say company logos) are embedded INTO THE DOCUMENT or they disappear when the files are moved! (or they automatically change when the files are edited and that's totally NOT COOL for a controlled design..) There's a checkbox for embedding an image when you place it... I've seen this issue multiple times even with big design contractors around here... and to show how dangerous this is - if you open fedevel academy's imx6rex project, they have this exact issue with their project cover sheet - the top and bottom board photos that it's mean to show are directory linked and of course those files aren't part of the project..

5) chuck in a "this file is confidential to blah blah blah - Not to be copied, backed up or distributed without permission in writing" if you want. Hell, put in a destruction clause if you feel like it. Your pointy haired manager will love this and it'll make them think you know all about IP protection... (nobody else will care) Also put in a clause that any physical print of the file is automatically uncontrolled, and therefore unable to be used for any official purpose. This will make you look like a hardcore process demon, and your pointy haired boss will love that too. Also it could actually be useful as it will cover you and your team when some giant goose in production or testing or operations starts using a pile of paper for their work, gets confused about the latest version of different sheets, and makes a huge mess, then they try to pin it on engineering.




As for a cover page and block diagram as presented by fedevel academy... I'm not sure... most of the work he does here is necessary because he doesn't do hierarchical schematics, so you need those pages to tell you where everything is.

If you do a hierarchical design then you will have the structure drawn up already so don't need a block diagram..

As for the cover sheet - first up is the page index, here I guess it comes back to - how big are your schematic designs going to be? if they're just a 5 or 6 pages, then do you need another page to show a page index? all you might want for the cover sheet is the project info, release status, date, and what variant(if any?) is in play. But in that case, maybe you should just have all that in the title block on every sheet? Otherwise what happens with uncontrolled prints when someone messes up a collection of pages from physical prints of different versions of the project? (yes this should never happen, but it always does somehow)

A revision history sheet in the schematic is a good idea if you have nowhere else to track changes. but ideally you would have this capability somewhere better. Depends on how the output documents will be used, really.

Any more complex descriptions of what the design does or requires is, IMO, better off in an appropriate accompanying document (requirement spec, design spec, test spec, experiment, technical construction file, etc)
« Last Edit: March 08, 2017, 01:37:27 am by julianhigginson »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf