# Problems creating decent standard compliant schematic **URL:** \ **Category:** beginners\ **Created:** [August 25, 2023, 5:50am UTC](https://forum.fritzing.org/t/problems-creating-decent-standard-compliant-schematic/20314 "2023-08-25T05:50:34Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![skillbank](https://forum.fritzing.org/letter_avatar_proxy/v4/letter/s/8e8cbc/32.png) [@skillbank](https://forum.fritzing.org/u/skillbank)\ **Post date:** [August 25, 2023, 5:50am UTC](https://forum.fritzing.org/t/problems-creating-decent-standard-compliant-schematic/20314/1 "2023-08-25T05:50:34Z")
Having tried many other schematic design apps I tried to use Fritzing to do the same. I wasnt pleased with the results, even for a very simple circuit. ![358ff4328a6f4e626ec72e66bfb0e5b765e9deed](https://forum.fritzing.org/uploads/default/original/3X/3/5/358ff4328a6f4e626ec72e66bfb0e5b765e9deed.png) Sorry this will take a few replies as I can ony paste 1 image at a time. ---
**Author:** ![skillbank](https://forum.fritzing.org/letter_avatar_proxy/v4/letter/s/8e8cbc/32.png) [@skillbank](https://forum.fritzing.org/u/skillbank)\ **Post date:** [August 25, 2023, 5:56am UTC](https://forum.fritzing.org/t/problems-creating-decent-standard-compliant-schematic/20314/2 "2023-08-25T05:56:07Z")
Here is the schematic Fritzing produced ![d6fab81ca6d1a430ce7e70011a4b91bc1d4248a3](https://forum.fritzing.org/uploads/default/original/3X/d/6/d6fab81ca6d1a430ce7e70011a4b91bc1d4248a3.png) You can see the power rails are not where they should be nor are inputs left and outputs right. ---
**Author:** ![skillbank](https://forum.fritzing.org/letter_avatar_proxy/v4/letter/s/8e8cbc/32.png) [@skillbank](https://forum.fritzing.org/u/skillbank)\ **Post date:** [August 25, 2023, 5:56am UTC](https://forum.fritzing.org/t/problems-creating-decent-standard-compliant-schematic/20314/3 "2023-08-25T05:56:59Z")
I was able to improve the schematic - a bit ![c5c5953d16f65a782fc784350dd264522321f03b](https://forum.fritzing.org/uploads/default/original/3X/c/5/c5c5953d16f65a782fc784350dd264522321f03b.png) and it completely messed up the breadboard view ---
**Author:** ![skillbank](https://forum.fritzing.org/letter_avatar_proxy/v4/letter/s/8e8cbc/32.png) [@skillbank](https://forum.fritzing.org/u/skillbank)\ **Post date:** [August 25, 2023, 5:58am UTC](https://forum.fritzing.org/t/problems-creating-decent-standard-compliant-schematic/20314/4 "2023-08-25T05:58:47Z")
![ec7f356fe3fbf984d5213cd08a51e7af6801a7d3](https://forum.fritzing.org/uploads/default/original/3X/e/c/ec7f356fe3fbf984d5213cd08a51e7af6801a7d3.png) **Am I just doing it wrong? I find the interface very idiosyncratic as compared to other schematic apps.** ---
**Author:** ![vanepp](https://forum.fritzing.org/user_avatar/forum.fritzing.org/vanepp/32/4426_2.png) [@vanepp](https://forum.fritzing.org/u/vanepp)\ **Post date:** [August 25, 2023, 5:30pm UTC](https://forum.fritzing.org/t/problems-creating-decent-standard-compliant-schematic/20314/5 "2023-08-25T17:30:15Z")
First, what fritzing version are you using (current is 1.0.0)?) I ask because the pot in your images is old style, the current versions look like this in schematic: ![capture](https://forum.fritzing.org/uploads/default/original/3X/4/b/4b3e4ff8d47317c59b0138b9bb6d2e4f0dfb4b98.jpeg) This part was recently updated from the original layout which is as you show in your images. Then unlike most other EDA packages Fritzing reflects changes in any view (such as schematic) in to the other 2 views. Sometimes this causes problems if there is already a conflicting connection in another view. That is possibly what happened to your breadboard image. This is a relevant topic because there is a discussion going on on github here > > > This is a continuation (with a better topic name) from #367 . The intent is to m…odify and possibly write new standards for parts. We have the part file format document > > https://github.com/fritzing/fritzing-app/wiki/2.1-Part-file-format > > and the graphics standards > > https://fritzing.org/fritzings-graphic-standards > > both of which may need updates as part of this discussion, but which provide the basis for this discussion. > > @KjellMorgenstern @mMerlin @failiz where suggested in #367 as people who need to be involved, but I expect anyone else that is interested should also be welcome to join in. > > My broad outline is to get a parts policy in place that allows automated checking of parts and consistency of parts (at least those included in core parts) so schematic as one instance looks the same and interoperates well with other parts. The longer term goal is, once a policy is in place, to start a project to update the parts in core parts to meet the new standard. (that is likely to be a lot of work, but requires the policy to be in place to allow it!) That would also allow the automated checking of parts that are submitted to core parts to make sure they meet the standards. However it leaves the user able to create custom parts that don't meet the standards (either due to time constraints or lack of need of some views) for their personal use which has been one objection raised in past discussions on this topic. Another topic is the layout of the repository as discussed in #4018 . Documenting the format of the .fzpz file and its association / conversion to the repository format should be done. I am not aware of any documentation on the format of the .fzpz file existing (pointers to anything I have missed are welcome!) Documentation on each field in the fzp file would be useful. For instance the version field is often set to 4 where I think it should start at 1 for a new part and increase by one for each new version of the part. My update to the obsolete.py script available in #347 addresses that by setting the version field to 1 if there isn't one already or increasing the current version field by 1 if there is one.. Issue #365 to standardize the parts labels (which affects the label field in the fzp file) also enters in to this discussion as I think it is desirable to standardize the label field in parts. File name conventions for fzp and svg files are also an issue that needs to come up. I would prefer that the version number appear in the files so for the first version of the part the fzp and svg files end in \_1 such as part.fc-51\_1.fzp for the first version of a part. One question would be is there a need to add a guid field (a globally unique identifier) to the file name as parts editor currently does when editing parts? As noted I think we need to update the part file format document to specify all the fields in a fzp file along with their suggested initial value and what they relate to in other files. As an example > > \`\`\` > \ > \ > \ > \ > \ > \`\`\` > > The layerId field here needs to match the group id (in both case and spelling) in the svg file specified in the image file a couple of lines above it. Documenting the special case properties and what they do would be good. An example is all the special formats for a breadboard such as > > \`\`\` > \ > \`\`\` > > where the trailing ModuleID in the moduleId field suppresses rotation by 45degrees in a breadboard > > \`\`\` > \Breadboard\ > \full+ test\ > \`\`\` > > the family needs to be Breadboard with the size property selecting between the possibilities (and that the combination of family and size need to be unique!) > > \`\`\` > \ > \ > \ > \ > \ > \`\`\` > > and the breadboard layerId "breadboardbreaddboard" trips special code that allows the part to move down to the same level as the breadboards. This is used by the Arduinos for instance (which are otherwise not a breadboard) I think to allow shields to be mounted above them. That will probably do to start this discussion rolling I hope! the intent of which is to update the standards docs to specify part and schematic specifications with the view to then updating the core parts to match the new specs. That however will likely take a long time even when the discussion completes (if it completes) as it is going slowly. The requirement for a “standard” schematic has come up, but I am unaware (which may just be my ignorance!) of a standard. Apparently Kicad has a standard of some kind but pointers to examples and/or desires for formats preferably with documentation would be desirable. Most of the parts in your images are old (more than 10 years) and development in Fritzing stopped in 2016 (and started again a few years ago) which means not much got changed for quite a few years and the standards have always been relatively incomplete (and changing them has been in the past controversial!) There is now a head developer who has the ultimate say in what gets done (in the past the discussion was among users because there were no developers!) That said you breadboard problem is likely solvable by deleting all traces in breadboard (Routing-\>select all wires, then delete) which will reduce the wires to rats nest lines sourced from schematic. As part of that there is currently a bug where changes made in more than one view can cause routing database corruption which ruins the entire sketch (and the only solution is usually to start over.) So the advise is make all your changes in one view and then click on (and correct if needed) the rats nest lines in the other views. After 5+ years of trying to reproduce this bug I finally managed it (and the developers found an even easier way to reproduce it!) and some fixes may have made it in to 1.0.0 but more are still needed. Til that is done the advise still stands (although it isn’t necessarily only changes in more than one view that causes the problem!) Hope this helps some! Peter ---
**Author:** ![microMerlin](https://forum.fritzing.org/letter_avatar_proxy/v4/letter/m/76d3ee/32.png) [@microMerlin](https://forum.fritzing.org/u/microMerlin)\ **Post date:** [August 25, 2023, 7:20pm UTC](https://forum.fritzing.org/t/problems-creating-decent-standard-compliant-schematic/20314/6 "2023-08-25T19:20:05Z")
Ignoring the pot graphic version and potential future changes, I have never seen changes done on schematic view cause parts on breadboard view to move. Did you move them yourself to show the wiring problems that resulted from the cleanup of the schematic view? I “expect” that what happened, is that when cleaning up the schematic view, you connected to the opposite ends of the both the resistor and pot. Electrically that does not make any difference, but because Fritzing links wiring on all of the views together, it “added” those _new_ connections to breadboard view. That is where the dashed “rats nest” wires in breadboard view are coming from. Indications of that, are the green rats nest wire from the pot to 5V on the Arduino, the black rats nest from the “+” side of the pot to the “GND” side of the LED, and the pink rats nest from the “wrong” end of the resistor to D13. There is also a rats nest wire from the other end of the resistor to the lead for the LED. All of this because your cleanup in schematic view “changed” which end wires are connected to. Your schematic image does not show it, but I expect rats nest wires there doing the same kinds of things, because, if the breadboard parts were moved back onto the breadboard, the wires there would go the opposite directions. With Fritzing, the recommendation for best results is to do all of the wiring in a single view first, then route the rats nest wired created in other views, without creating new connections. Rotate and flip the components in that view to get the wires to route cleanly. If that is not enough, and you really need to change where the connection go (opposite ends of the pot), then go back to the original view, and change the wire connections there first. That will update the rats nest wires, and prevent the sort of issue you are seeing. In this case, rotating R2 in schematic 180 degrees and reverse the VCC and GND connections for the pot in breadboard view will probably get what you want. Instead of making any changes in breadboard view, in schematic, flip both R1 and R2 vertically. For additional cleanup in schematic, I would replace the ground wires with 3 ground symbols, and the 5V wire with a pair of voltage bus symbols. But that is just my preference. ---
**Author:** ![skillbank](https://forum.fritzing.org/letter_avatar_proxy/v4/letter/s/8e8cbc/32.png) [@skillbank](https://forum.fritzing.org/u/skillbank)\ **Post date:** [August 26, 2023, 5:58am UTC](https://forum.fritzing.org/t/problems-creating-decent-standard-compliant-schematic/20314/7 "2023-08-26T05:58:24Z")
Thanks for your replies @microMerlin and @vanepp I wasnt aware there was a new version of Fritzing, and when I looked at the download page I see no way to download it without paying - which I’m reluctant to do just to test it. Maybe someone should update this on Wikipedia: > Fritzing is an open-source initiative[3] to develop amateur or hobby CAD software for the design of electronics hardware, intended to allow designers and artists to build more permanent circuits from prototypes. It was developed at the University of Applied Sciences Potsdam.[4] Fritzing is free software under the GPL 3.0 or later license, uM I’d agree with your analysis, I’ve played around with it a bit and my best result was starting from the schematic, then moving the components and placing the wires. IMHO thats a bit AAF compared to what a beginner would do. ![image](https://forum.fritzing.org/uploads/default/original/3X/b/0/b0098ec3ea9bf01e75e85c7fce5f529fa3dee804.png) Using seperate ground and voltage bus symbols makes sense in relation to the buses on the breadboard, less so on the schematic. ---
**Author:** ![microMerlin](https://forum.fritzing.org/letter_avatar_proxy/v4/letter/m/76d3ee/32.png) [@microMerlin](https://forum.fritzing.org/u/microMerlin)\ **Post date:** [August 26, 2023, 2:16pm UTC](https://forum.fritzing.org/t/problems-creating-decent-standard-compliant-schematic/20314/8 "2023-08-26T14:16:46Z")
The reverse also works. Position and wire the breadboard, then do schematic. The condition there is to “use” the rats nest wires created in breadboard when working on the schematic. Re-orient the components on the schematic so that the routing will work, instead of creating a new wire to the opposite end of resistors and other components. Using power and ground buses in schematic makes it much cleaner, once it gets a bit more complex. For the simplest cases, there is not a lot of benefit. For me, it is just ‘convention’. EDIT: Fritzing is still open source software, if you have the time and skill to build it from source yourself. GPL is open “source” software. Executable apps are not included in that definition. Sometimes they are available for free as well, but it is not a requirement.