Connector128 missing from custom part

[arstneio]

Hello, I’ve been working on a custom part and Fritzing appears to skip over connector128 and I’m not able to select that pin in breadboard view. My part has 745 pins, so I created connector746 in Inkscape and assigned it to that problematic pin. Fritzing now seems to recognize the pin, but this seems like a weird fix. I’d prefer to figure out what went wrong and get it to recognize connector128 instead. When importing the SVGs I edited a generic IC with the max number of pins (128) and then increased the number of connectors. I don’t suppose it’s a coincidence that connector128 is the one that happened to fail? Screenshots attached to illustrate the problem.

Would appreciate any insight on the problem.

[vanepp]

Looks to be a quirk in parts editor. It does that sometimes (skips pins) for reasons unknown (I have seen it before in parts made by parts editor.) I have tools to renumber svgs and fzp files so if you upload the part as a .fzpz file (upload is 7th icon from the left in the reply menu) I can fix the numbering for you and you can see what parts editor does with it (I normally edit the files directly and don’t use parts editor.) My normal work flow is described in this tutorial, and thus may help you if you want to go directly for the files as well.

Part creation howto part 1 breadboard and pcb

Someone in this forum post requested help to fix up a part. So while doing that I decided to record what I needed to do in order to fix the part to provide a tutorial to create new / fix broken parts. If you start from the Tarjeta S4A EDU.fzpz file posted in the above thread, you should be able to recreate my improved part posted in the same thread. I started by loading the original part in to Fritzing, that indicates breadboard is (at first look anyway) pretty good, but schematic and pcb are…

Peter

[arstneio]

I appreciate the help! I’ve been using Old_Grey’s YouTube guide, but I appear to have made some mistakes, especially on the schematic view where some pins aren’t selectable, some anchor to the middle of the pin instead of the tip even though I used the “connector#terminal” trick in Inkscape, and the schematic itself has a blue outline around it for some reason when hovering over anything except the pins. Was going to post about the schematic issue after figuring out the connector128 problem, but since I’m sharing the part I thought it was worth mentioning here. Didn’t attempt the PCB, have no need for it in my project.

mega shield3.fzpz (406.1 KB)

[vanepp]

From my first look (which was to run your part through FritzingCheckPart.py to see what it complains about), it looks like parts editor is doing to you what it usually does to me and not setting the schematic terminalIds. The blue rectangle in schematic is likely missing pin definitions (since they are showing up in the error list.) There are hundreds of this error which says parts editor hasn’t set the terminalId

Warning 14: File
‘part.mega_shield_74bc8207457ecfa9134090d563ab9e68_2.fzp.bak’
At line 11210

terminalId missing in schematicView (likely an error)

Warning 14: File
‘part.mega_shield_74bc8207457ecfa9134090d563ab9e68_2.fzp.bak’
At line 11225

terminalId missing in schematicView (likely an error)

then this one which is the missing pin (which I will fix up)

Warning 35: File
‘part.mega_shield_74bc8207457ecfa9134090d563ab9e68_2.fzp.bak’

Connector128 doesn’t exist when it must to stay in sequence

you have an undefined pin in the bus definitions (since the buses are hidden in parts editor you may not even know that they are there!)

Error 53: File
‘part.mega_shield_74bc8207457ecfa9134090d563ab9e68_2.fzp.bak’
At line 11650

Bus nodeMember connector746 does’t exist

Error 69: File
‘svg.breadboard.mega_shield_e8b42e4b1ad36b3fc77908efbc4b76b3_6_breadboard.svg.bak’
At line 25

Found a drawing element before a layerId (or no layerId)

breadboard is missing a layerId, which will cause the part to not export as an image (svg, jpg, png etc.)

Error 18: File
‘part.mega_shield_74bc8207457ecfa9134090d563ab9e68_2.fzp.bak’

Connector connector0terminal is in the fzp file but not the svg file. (typo?)

svg svg.breadboard.mega_shield_e8b42e4b1ad36b3fc77908efbc4b76b3_6_breadboard.svg.bak

and sometimes the parts editor added the terminalId to the .fzp file but not to the schematic svg which will cause the wire to connect to the center of the pin.

Error 18: File
‘part.mega_shield_74bc8207457ecfa9134090d563ab9e68_2.fzp.bak’

Connector connector164pin is in the fzp file but not the svg file. (typo?)

svg svg.schematic.mega_shield_e8b42e4b1ad36b3fc77908efbc4b76b3_6_schematic.svg.bak

Error 18: File
‘part.mega_shield_74bc8207457ecfa9134090d563ab9e68_2.fzp.bak’

Connector connector129pin is in the fzp file but not the svg file. (typo?)

This is likely the cause of the blue rectangle (although why it is blue rather than the usual red I’m not sure!) This pin is missing in the svg file but is in the fzp file. I’ll have a detailed look at the files and fix it up and post a corrected version in a bit.

Peter

[arstneio]

Thanks Peter, you’re a legend. Would’ve taken me ages to figure this out on my own.

[vanepp]

This is a complex board, I’m about 3/4 through rearranging breadboard. I think some of your problems are probably the prototyping area. They are likely providing the undefined in schematic pin numbers and there isn’t an easy solution.

Peter

[arstneio]

No worries, I understand. What would I need to do to sort out the schematic so it’s in a usable state? This is my first custom part of this scale, so few things about the process have been easy so far

[vanepp]

I’m going to use Randy’s schematic generator to make one. Thats why I’m rearranging breadboard to mesh with what the extension is going to want in schematic. That is usually the hardest part thinking in breadboard how it is going to reflect in to schematic. Randy’s extension is available here:

Fritzing-Schematic an Inkscape extension - released

Hi all! I have been working on an extension for Inkscape to create rectangular schematic symbol .svg files for use in Fritzing. I think I created a useful tool to speed up creation of schematic symbols, and now I want to share it with the community. It’s available on github: https://github.com/revolt-randy/Fritzing-Schematic-an-Inkscape-Extension. To install: In Inkscape, the edit menu → user preferences → system will have an option for ‘User extensions’ - allowing you to open the folder to…

It is pretty much all I use to make schematics these days because it turns out schematics that meet the graphics standards.

Peter

[arstneio]

This seems like a really useful tool. My attempt to do it manually by keeping track of which pins on the breadboard correspond to which connectorIds seems much less efficient and much more error prone in comparison.

[vanepp]

OK finally done. This has been a really worthwhile project (if time consuming ), while testing the final board I have managed (I think, more examination is required!) to reproduce a bug that causes routing database corruption that I have been chasing for the last 5 years. First time I have managed it and it tells me what to do to cause it maybe. In any case on to your board. Starting with the breadboard svg, here is the cause of the missing layerId message from FritzingCheckPart.py

there needs to be a group (typically called breadboard, but perhaps breadboardbreadboard if you cloned a Mega part) that contains all the drawing elements like this

An Edit->select all indicates there is something not easily select able outside the board boundary

It appears to be an unused not rendered rectangle that I will remove.

Then starting from the bottom left move the connectors to the bottom of the svg (to facilitate renumbering) like this.Note this is going to be somewhat strange bacause I am looking ahead to what I want to do in schematic so the order is not all that intuitive but I will explain.

Here I started with the first terminal block and changed its id to connector0pin+ (which is not normally used and tells my python scripts that this is where to start renumbering!) Usually I would proceed in squence up the terminal block, in this case I am going to alternate with all the pins that will bus together. In this case that is the pairing. The reason for this is we are going to overlay the pins on top of each other in schematic and ordering the pins this way makes that easier to do. So instead of the REF terminal block, my next pin is on the header connector like this:

the two pins connected by the green line need to be bussed together as they connect internally to the board. Now proceed in sequence up the terminal strip (alternating with the header)

here there is a change because there is a third pin (a pad) added to the group for the next bunch of pins so we need to add another pin to the group. I have now completely reorganized the connectors (hopefully correctly)

Here I finished with a Edit->select all, Edit–>resize page to selection (to reset the viewbox to start at 0 0) then Object->group and renamed the group breadboard to make the layerId (all drawing elements need to be inside the breadboard group!)

The connectors now start at connector0, and are in random order (some are not specified as connectors even in the prototyping area!) the prototyping area starts afte the last active connector. Now I need to renumber this with a script.

Now the pins start at 0 and go up in sequence

the proto area as noted starts after the last active pin as we likely need to do something to all of them and not having them mixed in makes that easier.

Now on to making schematic from this. Start from a empty svg (because the extension only adds things, it doesn’t delete!)

and set the parameters to do that you need to figure out how many pins on each side of the square in this case that will be 0 left (as there are no left side connectors)

left 0
bottom 77 31 terms 24 headers 8 pads 2 gnds 6 * 2 ios so 90 pins so width needs to be 9.1in
(0.1 above the number of connectors)
right 66 22 for the terms + 2 * 22 for the headers and pads.
and thus height is 11.1in to allow 110 connectors
top 93 30 pads 6 top of header 31 terms and 26 for the headers
and thus 9.4in wide. So lets set all of that.

Note that it is best to have only the schematic svg open in Inkscape when running the extension, a bug in either Inkscape or the extension (I suspect Inkscape!) causes it to sometimes write the schematic in wrong svg window if more than one is open. It is possible to copy it to the right one then delete it but only one svg is easier. So set those parameters in to the extension. Because I usually miscount I used 10 by 10 (we need to adjust the borders later anyway!) Set the board name in the title slot.

then set the number of connectors and the other parameters (such as terminalIds!) then click apply to start the extension.

It works for a bit then puts up this screen for pin names

Here we need to enter every name twice to get the two bussed together pins (later we will need to do 3!) at A8 we need to do three labels each because there is an extra pin in the group. Once all the labels are entered we get an svg that looks like this

Now we need to do some editing to come up with the final (and smaller!) schematic. What we are going to do is to overlay the extra pins to reduce the size of schematic while leaving the correct pin definitions present. To do that we need to remove all pin numbers (because each pin will have multiple pin numbers and there isn’t enough space) and all the duplicate pin labels like this

everything circled in red needs to be deleted like this

Now we need to move both the pin and terminalId

now both connector0 and connector1 are in the same place in the svg. Once they are all done we will move the combined pins so there is only 0.1in between them (thus reducing the size of schematic!)

In the end the final schematic looks like this

note none of the several hundred proto area connectors in breadboard are reflected in schematic and we will need to do something about that in the fzp file to avoid problems. Schematic is now complete so on to the .fzp file. Replace the current connectors with a set generated by FritzingCreateFzpConnectors.py

GitHub - vanepp/FritzingCreateFzpConnectors: Create Fritzing fzp file...

via

FritzingCreateFzpConnectors.py -n t 236

to create the 235 active connections. Substitute that for the current terminals and set the description field for all connectors. When that is finished generate the connections for the proto pins (only in breadboard) via

FritzingCreateFzpConnectors.py -n -P t 518 236

which generates 518 proto connectors starting at connector236. Append that to the end of the connectors and use a global replace to change the description to “proto pin”
then delete the entire buses section and replace it with a new hand edited (unfortunately!) bus definition set.
Add a url for where to get a board and the .fzp is done. Now run it through FritingCheckPart.py and correct any errors

Error 54: File
‘part.mega_shield_1.fzp.bak’
At line 7080

Bus nodeMember connector164 already in bus D19

only a node member error so correct that. Now checkpart runs clean

$ FritzingCheckPartw.py part.mega_shield_1.fzp

**** Starting to process file Startup, no file yet

**** Starting to process file part.mega_shield_1.fzp

**** Starting to process file svg.breadboard.mega_shield_1_breadboard.svg.bak

**** Starting to process file svg.schematic.mega_shield_1_schematic.svg.bak

**** Starting to process file svg.breadboard.mega_shield_1_breadboard.svg.bak

Warning 29: File
‘part.mega_shield_1.fzp.bak’

Processing view pcbView, File svg.breadboard.mega_shield_1_breadboard.svg.bak
has already been processed
but will be processed again as part of this fzp file in case of new warnings.

so build and test the part. Load it in to Fritzing and verify the buses are correct by clicking on each pin and make sure the correct pins light yellow like this (with ground selected)

do the same in schematic (most pins will only light up themselves as they are all overlaid, gnd and +5V are the exceptions!) As well I notice the background sometimes lights up blue. I don’t know why, it doesn’t appear to indicate an error and doesn’t always happen.

Then add headers to test every connection and make sure they are correct.In this case there are problems (probably with the order of overlaid pins in schematic)

as well we haven’t set a label field which we need to correct. Here there is a short between 3 of the pins (circled in red) that needs to be corrected. It appears to have been a breadboard error, deleting and rerunning the wires corrects the problem, and a check of the part files shows no errors (which is why I deleted and rerouted the wires.) I did correct the label field in the .fzp file though (set to A for assembly.) This appears to be an instance of db corruption so save a copy of the .fzz in broken-routing.fzz in this directory to look at later. Generate a new part to pick up and test the label field and start t a new test sketch. Done and tests clean. The test sketch (included with the part below) looks pretty messy, but tests that every connection goes to where it should.

the real test is schematic to make sure all of the2 or three connections on the overlaid pins go to the correct place as it is easy to make an error here.

The wires at an angle are to verify all the terminalIds are correct (since this is Randy’ extension they all are, but I may have missed moving a terminalId with a pin which this will show up here.) Since all appears well we can declare this done with the following part and its test sketch, and I can continue on poking at the routing bug and a couple of undo issues I found during this.

mega-shield3.fzpz (171.8 KB)

and the test sketch

mega-shield3-test-Sketch.fzz (244.9 KB)

If you have questions don’t hesitate to ask!

Peter

[arstneio]

Hey Peter, I greatly appreciate your diligence in not only fixing the breadboard and re-creating the schematic so that it meets Fritzing standards, but also documenting the process for my learning benefit.

I’m going to need to study your highly detailed part creation guide, which may resolve most of my confusion, but one thing that’s not immediately clear to me is why Fritzing doesn’t require any pins in the schematic drawing which correspond to the proto pins. I was under the assumption that every connector#pin in the breadboard svg needs to correspond to a connector#pin in the schematic svg (something I may have picked up from one of Old_Grey’s videos). Having examined a couple of schematics of similar parts (ie containing a large number of prototyping pins) in Fritzing (eg: Arduino Mega Proto Shield (v6)), the pattern seemed to be to stack all those proto pins on the bottom edge (similar to how you stacked the bussed pins). Your process doesn’t seem to have to make that compromise, which looks way nicer. I’m just trying to understand how you’ve circumvented that “requirement”?

I’ve never tried manually editing the .fzp file with a text editor. I’m guessing there’s a trivial way to change all the pins from male to female (similar to how you changed all the descriptions to “proto pins”?). Attempting to use the part editor’s “set all to ___” feature in the Connectors section with 700+ pins crashes Fritzing.

Lastly, why was it necessary to delete the entire buses section and replace it with a new hand edited! (sorry you had to go through that) bus definitions set?

Thanks again.

[vanepp]

@arstneio

Fritzing doesn’t require any pins in the schematic drawing which correspond to the proto pins. I was under the assumption that every connector#pin in the breadboard svg needs to correspond to a connector#pin in the schematic svg (something I may have picked up from one of Old_Grey’s videos).

Normally that is true (and should be your usual assumption) however proto pins (such as the breadboard) are special. They only appear in breadboard not schematic or pcb (there is special code that deals with breadboards the makes this happen.) In this case I generated a fzp line the looks like this (this is the last used pin 235) note it has a schematic view (but no pcb) definition

    <connector id="connector235" type="male" name="Pin 236">
      <description>SCL</description>
      <views>
        <breadboardView>
          <p svgId="connector235pin" layer="breadboard"/>
        </breadboardView>
        <schematicView>
          <p svgId="connector235pin" layer="schematic" terminalId="connector235terminal"/>
        </schematicView>
      </views>
    </connector>

this is pin 236 (the first proto pin)

<connector id="connector236" type="male" name="Pin 237">
  <description>proto pin</description>
  <views>
    <breadboardView>
      <p svgId="connector236pin" layer="breadboard"/>
    </breadboardView>
  </views>
</connector>

it has no schematic definition (nor pcb) and thus won’t appear in schematic. The fzp file controls whether a pin is needed in a view so it is possible (there are actually several ways, I could have used the inhibit key word on the schematic definition as well) to suppress a pin in a view but it isn’t normally done. So normally the advise that a pin must exist in all views is good (because if it is in the fzp file but not the svg that will cause a Fritzing error.) This is a case of if you know what you are doing it is safe to do it and it saves space in the files (which isn’t normally a great concern.)

@arstneio

I’ve never tried manually editing the .fzp file with a text editor. I’m guessing there’s a trivial way to change all the pins from male to female (similar to how you changed all the descriptions to “proto pins”?).

Yes, I usually use vi under cygwin (since I’m an old unix user) and a substitution across multiple lines is easy. Most text editors have a similar function.

@arstneio

Lastly, why was it necessary to delete the entire buses section and replace it with a new hand edited! (sorry you had to go through that) bus definitions set?

It wasn’t necessary, just easier. The new layout changed the number of pins in the buses from what was there. I figured it was going to be easier to just recreate the bus section from scratch rather than try and adjust what was there. The best answer (which I haven’t done yet) is to make a script that will generate a bus definition from a config file of some kind since most of it is boiler plate.

Peter

[arstneio]

I understand. Thank you for your help!

[vanepp]

You are most welcome, we need more people that can and will make parts and you look to be making good ones.

Peter

[arstneio]

Sorry to bother, but I’ve run into a little problem with the schematic.

I noticed some missing connections while working on the breadboard view in Fritzing. For example, A5 should actually have 4 bus connectors, but it only had 2. In an attempt to fix this, I made the following change in the .fzp file (just to connector753 at first to see if it would work), where connector753 is one of the proto pins which should be connected to A5:

<bus id="A5">
  <nodeMember connectorId="connector26"/>
  <nodeMember connectorId="connector27"/>
  <nodeMember connectorId="connector753"/>
</bus>

then I added the code:

<connector id="connector753" type="female" name="Pin 754">
  <description>proto pin</description>
  <views>
    <breadboardView>
      <p svgId="connector753pin" layer="breadboard"/>
    </breadboardView>
    <schematicView>
      <p svgId="connector753pin" layer="schematic" terminalId="connector753terminal"/>
    </schematicView>
  </views>
</connector>

and I went into inkscape and created connector753pin and connector753terminal:

However, now Fritzing is once again not recognizing pins in schematic view. And not just A5, but half the analog pins are having this issue where connections anchor to the middle of the schematic drawing instead of the pin.

Where have I gone wrong?

mega_test_A5.fzpz (191.9 KB)

[vanepp]

@arstneio

Sorry to bother, but I’ve run into a little problem with the schematic.

No bother, parts making bites without warning and is in general hard. When I first started I asked a ton of questions and am paying forward the assistance I got, so no problems .

FritzingCheckPart.py to the rescue!

$ FritzingCheckpartw.py part.mega_shield_1.fzp

**** Starting to process file Startup, no file yet

**** Starting to process file part.mega_shield_1.fzp

**** Starting to process file svg.breadboard.mega_shield_1_breadboard.svg.bak

**** Starting to process file svg.breadboard.mega_shield_1_breadboard.svg.bak

Warning 11: File
‘part.mega_shield_1.fzp.bak’
At line 55

Type female is not male (it usually should be)

Warning 29: File
‘part.mega_shield_1.fzp.bak’

Processing view pcbView, File svg.breadboard.mega_shield_1_breadboard.svg.bak
has already been processed
but will be processed again as part of this fzp file in case of new warnings.

Error 15: Can not rename

‘svg.schematic.mega_shield_1_schematic.svg’

to

‘svg.schematic.mega_shield_1_schematic.svg.bak’

‘svg.schematic.mega_shield_1_schematic.svg’

No such file or directory (2)

Error 20: File
‘svg.schematic.mega_shield_1_schematic.svg’

During processing svgs from fzp, svg file doesn’t exist

You have renamed the svg file but not updated the reference in the fzp file so it can’t find the schematic svg. I’m surprised it has a schematic view, it may have found the original svg I guess.

schematic is

svg.schematic.mega_shield_1_schematic_A5_plain.svg

in the file system but

schematic/mega_shield_1_schematic.svg

in the fzp file so it is looking for

schematic/mega_shield_1_schematic.svg rather than

svg.schematic.mega_shield_1_schematic_A5_plain.svg

which is the new svg.

The image line in the fzp file needs to get the updated file name to work.

<schematicView>
  <layers image="schematic/mega_shield_1_schematic.svg">
    <layer layerId="schematic"/>
  </layers>
</schematicView>

While I’m here, one of the other things FritzingCheckPart.py does is remove the px from font-sizes (which Inkscape adds back in for CSS compliance.) Fritzing will assign the font size with a trailing px either a value of 0 (very small fonts) or 255 (very large fonts and ignore the set value. You can do this with a text editor but I find FritzingCheckPart.py to be easier (and it checks for other problems like this one as well.) If you have the original svg still in your mine parts bin, Fritzing will have been using that for your new part which is likely why the problems because the pins likely don’t exactly match.

Peter