Problems creating decent standard compliant schematic

vanepp · August 25, 2023, 5:30pm

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:

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

github.com/fritzing/fritzing-parts

Parts policy discussion

opened 08:01PM - 24 Mar 23 UTC

vanepp

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 ``` <breadboardView> <layers image="breadboard/fc-51_breadboard.svg"> <layer layerId="breadboard"/> </layers> </breadboardView> ``` 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 ``` <module moduleId="Breadboard-test-ModuleID" fritzingVersion="0.12.34"> ``` where the trailing ModuleID in the moduleId field suppresses rotation by 45degrees in a breadboard ``` <property name="family">Breadboard</property> <property name="size">full+ test</property> ``` 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!) ``` <breadboardView> <layers image="breadboard/breadboard2.svg"> <layer layerId="breadboardbreadboard"/> </layers> </breadboardView> ``` 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