Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Discussion: Rules For Drawing Readable Schematics

Status
Not open for further replies.

atferrari

Well-Known Member
Most Helpful Member
This thread has been split off from the original sticky found at: https://www.electro-tech-online.com/threads/rules-for-drawing-readable-schematics.144863/

I run across the Olin's rules long time ago. Good that you brought them here.

I still insist in showing each chip with its pin out diagram as in real life.

It helps a lot when testing / debugging. The other way, when looking where to probe, I have to first find the point, know what pin number it is and then look into the actual pinout on the IC. Much too bureaucratic for me, a simple hobbyist and light years from an EE.
 
Last edited by a moderator:
I run across the Olin's rules long time ago. Good that you brought them here.

I still insist in showing each chip with its pin out diagram as in real life.

It helps a lot when testing / debugging. The other way, when looking where to probe, I have to first find the point, know what pin number it is and then look into the actual pinout on the IC. Much too bureaucratic for me, a simple hobbyist and light years from an EE.

Normally I would agree with you atferrari, except that if you depict a chip with its actual pinout diagram, it often leads to sloppy wiring (lots of wires crossing over each other) and ruins the Top=+, Bottom=-, Left=Input, Right=Output flow that most schematics follow. For debugging the wiring diagram may be more helpful than an actual schematic, but for looking at a schematic to try to follow the process flow, it becomes far more convoluted than it needs to be.
 
It helps a lot when testing / debugging.
I some times make different schematics depending on who will be viewing them.
You example of using the IC pinout in the schematic is good for repair.

I often make a schematic for layout that is how I want the parts placed.

For the theory as how the product works, that schematic shows flow. Like input to output.

I use different colors and line thickness to help people understand. For a PCB layout I might have a line very thick, labeled 3A/100V, because that is how the PCB needs to be. On the schematic if I put a bypass cap on a IC-pin that is how I need it on the layout.

Many times I have labeled like 12Vdc, 100khz sign wave, -7DC&3Vp-p 60hz, or I often attach a waveform.

Many CAD programs allow "layers". So I have a layer just for repair, one for purchasing, one for theory of operation, etc. Then when printing I can choose which layers print/don't print. I have gone to repair and got their notes and entered them into the schematic, on their own layer. "If Q3=hot replace D7"
 
Yes, showing flow. Did not think of it.
It makes sense.
 
Some people post a schematic with faint lines on a grey or colored background.
Some people post Cadence schematics that are negatives (white or colored lines on a black background)
Some people post schematics that are covered with Chicken Pox dots or graph lines.
Some people post schematics with tiny parts far apart from each other.
Don't do it!
 
Some people post schematics with tiny parts far apart from each other.
How about tiny parts on top of each other?
white or colored lines on a black background
Lets burn up $5.00 of ink / page printing. It will take minutes for the page to dry.
Some people post a schematic with faint lines on a grey or colored background.
How about gray on gray. (use high contrast please)
covered with Chicken Pox dots or graph lines
What about gray chicken pox on gray paper with gray lines. No one can see the mistakes.
Yellow on yellow? :(
 
Whilst I agree in the most part with this thread!! A lot of members can't afford the luxury of schematic software... As far as I'm concerned, a schematic should just be " legible "... If you can't read a schematic offered then request the OP draw a better schematic... If the OP doesn't, then don't help.

This thread has become trashed... The points you are all making have become derogatory..

I really don't think well will EVER get professional schematics, so as best as they can muster will have to do...

I will discuss this thread with moderation and see what we can salvage..

Locked for now....
 
I believe we can unlock this. I saw nothing rude or derogatory. I'm actually enjoying you guys' responses very much :D

Matt
 
Ian Rogers said:
A lot of members can't afford the luxury of schematic software

From what I have seen it is newbies with schematic software and simulator who seem to draw the worst convoluted schematics.

JimB
 
Olin has a certain way with people, and the absolute certainty that his way is the only way, but he makes valid points.

One that he failed to make...lines must never cross a component symbol. That makes a schematic impossible to follow!

Regarding schematic capture software, open source TinyCad is pretty decent.
 
Another point that I don't think he made, in schematics wires should ALWAYS go either left, right, up, or down. When people draw schematics with wires going off at angles it makes it very sloppy and difficult to follow. The only exception I can think of is in a bridge rectifier schematic, but even then I would prefer that it be redrawn to be either vertical or horizontal.
 
Hi
As a relative newbie and a total novice I'd like to add my two pennyworth .. .. in point form to achieve brevity :)

1. There are so many different bits of software relating to schematics/simulation and the like .. it is difficult to assess and decide which one to use because they all do something but none of them do everything and from a limited experience point of view it's almost impossible to make an informed choice. If you then ask in the forum, understandably, there are 47 differing opinions of which is best and you end up none the wiser.

2. The document was introduced to the forum yesterday by a much respected member, especially by me, to the extent that I immediately cut & pasted the document into my ring binder entitled 'Essential Information to Learn' .. ... but then the forum, including the guy who posted it have systematically anihilated the content as being flawed, in various degrees - just what is an novice suppose to think ?

I do think sometimes we are guilty of polishing the brass so much that the glare gets in the way :)

Respectfully

S
 
Last edited:
My opinion:
1) Olin's Rules and Guidelines are guidelines. There are exceptions.
2) The rule about crossing is never a connection should be one such exception. From TI Engineer's Handbbok:

upload_2015-6-11_14-47-28.png
upload_2015-6-11_14-48-0.png


There is no ambiguity in either circuit. Why stick to some pedantic "rule" in those and similar circumstances?

2) Regarding having pins on symbols not in the same sequence as on the package, there are times when that is an advantage (e.g., logic devices) and other times when it is not. I also happen to like leaving coupling capacitors and power pins separate from the symbol in some cases, particularly for logic devices (which is a violation of the "rules").

There is an advantage that has not been mentioned for having the pins in the same or roughly same locations as on the package. It makes routing and parts placement easier. One exception is power and ground pins.

Additionally with microcontrollers, you cannot predict with certainty how the signal pins will be used. Why not put them in the same order as on the package rather than having to have a large number of symbol variants?

John
 
Regarding having pins on symbols not in the same sequence as on the package, there are times when that is an advantage (e.g., logic devices) and other times when it is not.
I agree. However, if the sequence differs then it is helpful (particularly to newbies) to include the package pin numbers on the schematic to remove any possible ambiguity.
 
Hi
As a relative newbie and a total novice I'd like to add my two pennyworth .. .. in point form to achieve brevity :)

1. There are so many different bits of software relating to schematics/simulation and the like .. it is difficult to assess and decide which one to use because they all do something but none of them do everything and from a limited experience point of view it's almost impossible to make an informed choice. If you then ask in the forum, understandably, there are 47 differing opinions of which is best and you end up none the wiser.

2. The document was introduced to the forum yesterday by a much respected member, especially by me, to the extent that I immediately cut & pasted the document into my ring binder entitled 'Essential Information to Learn' .. ... but then the forum, including the guy who posted it have systematically anihilated the content as being flawed, in various degrees - just what is an novice suppose to think ?

I do think sometimes we are guilty of polishing the brass so much that the glare gets in the way :)

Respectfully

S

Many of the ideas that have been posted in this thread are merely additions to the guidelines, and are not really pointing out flaws. Some people may disagree with the guidelines, but they are simply opinions, as are the guidelines themselves. What would be ideal is if there was some standard that included a complete list (however difficult that would be) of all rules that any designer should follow to keep schematic drawing styles consistent worldwide. Any additions can be made after careful discussion among some kind of experts (how they would be elected I don't have a clue) and a new Rev of the document would be released. Such a document could be called "right", and anything that goes against it would be "wrong". I'm thinking of an IPC ("Institute for Printed Circuits", or "Institute for Interconnecting and Packaging Electronic Circuits") standard for schematics, rather than for PCBs. However, you are always going to have people who are stuck in their own ways, who prefer it one way over another. Perhaps they have a specific reason based on experience, or maybe it's just how they were taught, and nothing is going to change that (especially if they have 20+ years of experience under their belt).

The electronics engineering stack exchange allows members to edit posts and the changes will appear if the original poster accepts them. I am considering adding a few rules to the post for Olin's consideration. If anyone is interested in helping, feel free to post a response to this thread with your proposed rules, perhaps set apart by a bullet point (so that I know it is intended as an addition to the guidelines rather than just another post).

Regards,
Matt
 
DerStrom8
Is what you posted and your plan to extend it a collection of opinions, guidelines, or rules? Please chose one and stick with it.

As for a process to develop another list (if one is really needed), I am reminded of the adage that those who can do, those who can't teach, and those who can't teach write about it. TI is a doer in my view, that is one reason I picked examples from it. What value will a bunch of mostly anonymous individuals add to the excellent examples already available from various accomplished manufacturers?

John
 
DerStrom8
Is what you posted and your plan to extend it a collection of opinions, guidelines, or rules? Please chose one and stick with it.

The opinions have been compiled into a list of guidelines which in most cases I would like to see treated as rules. Ideally the opinions, guidelines, and rules are one and the same. I would like to add to Olin's list of guidelines with more good-schematic-drawing practices.

As for a process to develop another list (if one is really needed), I am reminded of the adage that those who can do, those who can't teach, and those who can't teach write about it. TI is a doer in my view, that is one reason I picked examples from it. What value will a bunch of mostly anonymous individuals add to the excellent examples already available from various accomplished manufacturers?

John

The idea is to compile these "excellent examples already available from various accomplished manufacturers" into a single list that anybody can use for reference to improve their schematic drawing skills. And I have never agreed with the saying you mention. Sure, sometimes it's true, but it's a horrid stereotype that is more often wrong than right (in my experience).
 
I am reminded of the adage that those who can do, those who can't teach, and those who can't teach write about it.

I'm a novice electronics engineer hewn out of a retired senior teacher .. .. .. I'd chose your words carefully here, if I were you !! :D :D

S
 
Hi

Firstly, I'm sorry, I couldn't resist the humour .. ..

But seriously, and again as a novice, I would have thought that the most important element to any schematic is legibility and anything that aids or adds to that is very important. The document Matt posted is great in that it highlights many if not all of the common pitfalls of schematic drawing that people like me would fall into. However, at the same time, the issues of orange dots on the page, formatting in negative image and other similar problems are not related to the schematic but the software in use at the time.

As a novice, I struggle to express myself properly using the correct terminology, symbols, calculations and components and as a result, I would be loathed to publish a schematic of mine in open forum because whilst I'm happy to take the criticism of my circuit because the generosity of the endless guidance that follows never ceases to amaze me, I'm less enamored with the sometimes overiding discussion of my means of expression which doesn't help at all.

JP- I'm only kidding; Matt - I welcome your efforts, TY

I'll watch this space with interest

Bestest..

S
 
Status
Not open for further replies.

New Articles From Microcontroller Tips

Back
Top