Solved: No schematic or pcb rats nest lines for adapter part

parts help
1

I am having trouble getting what I thought was a simple part to work correctly. What I want is a header / adapter that fits into a breadboard (standard DIP layout), and allows a 2xN header to be plugged in to it. The initial use is to allow an NRF24L01 radio module to be easily added to the breadboard view of a Fritzing sketch. I built the physical adapter from a pair of long leg 10 pin headers. Same thing that would be used to create an Arduino shield. Now I am trying to create a Fritzing part to match. It is supposed to be a series of female connections, like a breadboard uses, adjacent (0.1 inch) to male pins. Like a breadboard, no schematic view should be needed. For the initial part, I was not going to create a pcb view either, though that will turn into a simple 2 row set of pads to match the header layout.

The current breadboard view looks good, and even seems to work. Placing the adapter part on a breadboard, then adding another part to one of the female connections snaps into place nicely. Click/holding on one of the breadboard pins in that row highlights the end connection for the added parts, so it LOOKS like it is connected. Putting a jumper wire across the pair of female connectors highlights the opposite row when one side is click/held.

However, adding another part to the breadboard row does NOT create a rats nest line on the schematic or pcb view. For more fun, move the part away from the adapter in the breadboard view, create a connection on the schematic view, then move the part back to the adapter on the breadboard view. That gets rid of the rats nest line on the breadboard view.

2-pin-header.fzpz (2.5 KB)

header-test.fzz (33.2 KB)

What am I missing here?

2

Is what you are trying to do here similar to this (from the description, I think so but I’m not sure)?

If so your connections in the fpz file are incorrect in that they are male and you will need two connectors (one male presumably on the adapter) and one female to plug it in to as in the test sketch in this thread (you should also have schematic so that the connection will show up there). At present you part is a standard 2 pin connector without schematic which is likely why the rats nests don’t work. There are also a number of limitations related to this (layers being one, alignment being another) but it does seem to work.

Peter

3

The jack in that looks like it has the functionality I am trying for. I’ll see if I can massage it into the form I want. After that, see if I can get rid of the schematic view. Because of the switch in the jack, yours actually needs a minimal schematic view, though it could be simplified to a SPST switch.

In mine, it is all just wire (bus) connections, so (like breadboard) it does not really need a schematic view. At least not IF the bus connections feed through to create the needed rats nest wires when something is connected. Which is where the problem started. Functionally, I could create a schematic view, but it would not actually mean anything. Forcing schematic wires to route through a block is not nice. Since this needs bus connections, could not even use subparts to break up the block.

I’ll post (in a bit) another version with an icon that will better show the mechanical layout intended. Gone exploring.

4

Assuming your intent is to have a daughter board mount on a CPU board, I’m not sure you wouldn’t be better to just make a breadboard part with the daughter board in place and not bother with trying to make it connect. I’d then have two blocks in schematic (one for the daughter board one for the cpu board) with preconnected wires between the two blocks. The plugable in version is a lot of work for not much gain (being able to plug in a wall wart in bb as in real life struck me as possibly useful though).

Peter

5

It is not for a daughter board to cpu. Is is an adapter to connect a radio board (module) that has a 2x6 male header on to a breadboard. On a PCB, that is just a 2x6 set of 0.1 inch spacing THT pads. It needs more than direct connection to the Arduino board, because it needs 3.3 volts, and the Arduino does not supply enough current. But to hook it (by it self) to a breadboard needs 12 wires. 2 cables (0.1in space headers each end) of 6 wires each works, but that is messy both physical and in the Fritzing breadboard view. I took 2 male/female headers, bent the legs out sideways then back down again. Those then sit nicely on the inner columns, across the centre divider of the breadboard, allowing the 2x6 male header to plug in. Nice and neat physically for (software) development and testing.

Creating a custom breadboard with 2 extra pins where the centre divide usually goes would work. There is no specific size of breadboard though, and no fixed position for it to go. This is aimed at people learning Arduino to external hardware interfacing. See the ARDX (Arduino Experimenters) Kit information for context. I am adding some extensions to the existing projects / experiments, and want to keep it flexible for people to play with.

Another thing that would work, is creating the part for the radio module with the adapter ‘built-in’. That would then need doing separately for every else that had a 2xX maie header. I’m a programmer, and believe in DRY (Don’t Repeat Yourself). A separate adapter is so much cleaner and more flexible.

Here is a version of the in progress part, with a 3D ish icon to show the piece layout.

2-by-x-header2breadboard.fzpz (2.9 KB)

I’m also exploring Fritzing part creation, and this looked like it should be simple, but use a few features I had not tried yet. The part files have all been created using an xml aware text editor, not the Parts Editor and/or Inkscape/Illustrator.

6

Both the plug and jack parts in your example Fritzing sketch have a typo in the connector terminal ids.

For the jack, the part fzp file says

layer=“breadboard” svgId=“connector3pin” terminalId=“connector3terminal”

but the breadboard svg says

id=“connecotr3terminal”

For the plug, the part fxp file says

layer=“schematic” terminalId=“connector1terminal”

but the schematic svg says

id=“connecotr1terminal”

“ot” should be “to” in both svg file cases.

7

Ah, that makes things a bit clearer. Unfortunatly I don’t know of a way to make cables (there may be one, that I don’t know of though) so you are stuck with creating single wires for the cables. However I don’t think you need female connectors to do this. A standard 2xX female header (other than that the female header creation code appears to be broken at present) should do this.Iif you add a second set of pins to represent the ends of the connections at the .3 inch spacing with the pins bussed together that should do what you want. The wire from the module connects to the pin of the dual row connector and the pin on the breadboard (which is bussed to the same pin on the connector) connects to the arduino. Female pins are only needed when you want something like the breadboard which doesn’t do anything (routing wise) except connect wires together. In your case I think you want to connect wires from the radio module to the 2 row connector, and then connect wires from the breadboard to the arduino (and male connectors will do that). However I think you will need at least the pins in schematic to make the routing work, but if you don’t want them to actually show in schematic you should be able to define the pins as fill= none and just not put in the visible connections and everybody should be happy (Fritzing will have invisible pins to route, but they won’t actually show on schematic). In the plug case I wanted to make the physical connection clear to new users, and in this case you probably don’t. When you finish the entire part as the last step you need to import it to Fritzing (which will quite happily work) then edit it with parts editor and export it as a new part to get it registered with the database with a sequence number (that parts editor will create). If you don’t do this the part will load correctly but usually screw up when you try and save the sketch then reload it in to Fritzing as your new part isn’t registered in the parts database. Unfortunatly Fritzing is more tolerant on input parsing than on export/ saving parsing and there are several of these gotchas waiting to trip you up on reload (it also doesn’t like the px dimension on font-size and will set the font size to 0 when the part is edited for instance).

Peter

8

What I want is a very small breadboard with pins at the edge that will allow it to sit on top of, and connect to, a regular breadboard. If I create the radio module part correctly, no wires will be needed to add it to the breadboard view. Just like a standard DIP package sits across the centre of a standard breadboard, this would sit on the new breadboard. And make connections to the underlying breadboard, which would then have the usual wires to the the Arduino. And in this case a 3.3volt regulator. The schematic view would (should) have the radio module with (rats nest) connections to the Arduino and voltage regulator. The breadboard wires and both breadboard parts, are just wires, and do not need a schematic representation. At least that is the goal.

Another way to look as this, is as a ‘carrier’. A base DIP footprint that connects to a 2 row header.

I’m going to try again starting from a standard breadboard part, and also from a Header 1 part. Once I get a single connection to feed through properly, I can expand it to as many pins and connections as needed.

Maybe I can get a female breadboard pin to connect to another female breadboard pin. The initial failing attempt was putting a male pin at the end of the bus, to connect to the main breadboard.

9

Yep, sloppy (and part of the reason that I’m working on a python script to check for things like that). In this case it doesn’t break though as without the correct terminal id Fritzing defaults to using the pin as the as the connection point so the part still works. If both were misspelled the part would have failed to work.

Peter

10

I have a working version, based on a major cut down from TinyBreadboard. Now to see if I can finish the cleanup without breaking it, and see what the difference ends up from the starting broken version. For starters, this still has family Breadboard, which Fritzing treats special. I tried that before too, so there is something more.

11

Breadboard has a variety of special features, one of which is it is on the lowest level with everything else above it. I did what started out as a part but ended up being a fzz (due to performance issues and Fritzing bugs) with subparts for an education board for someone that contains an internal breadboard. I doubt that you want or need breadboard for this, but may not be understanding what you are trying to do entirely. The moduleid field in the fpz is important (along with a variety of things in the tags) to get it working correctly. @steelgoose is the expert on this level of Fritzing (he is where I have learned most of what I know).

Peter

12

I found and read that thread when I was trying to create a part with both a bus and subparts. When I ran into the bug that does not allow both in the same part.

I don’t really want a breadboard, but i’ll use it if that is all that works. A carrier or adapter family would be better. Right now, a 2 pin breadboard is working. Continuing careful cleanup and testing. When ready, I’ll try changing the family, and see what happens. I have not found references to the special features and tags associated with breadboards. I’ve been working from comparisons of part files. I had not notice that there was something special about the module id. I might not actually have a proper breadboard part any more, since I changed that right to start, to a simple guid value.

13

As far as I know the source is the only documentation for this (and of course steelgoose who I believe has found most of it by experimentation). In general documentation is fairly lacking, but for me at least if the choice is documentation or finishing the code and/or cleaning up bugs I’ll take the latter. We can find and document stuff being able to extend and / or fix bugs I’m less sure of …

Peter

14

This could get into a religious war with others, but here is my opinion. With nearly 40 years doing programming for context.

RANT ON

For an application / product that has an api (like custom part creation), the documentation is actually part of the product. Missing the information about the rules to follow to use the product is a bug itself. Broken code means an usable app. So does lack of information about the requirements to follow when using it. Some bugs have more or less usable work arounds. Reading the code is a work around for no documentation. It is not a fix or proper alternative. Work arounds do not make either type of bug go away.

A work around that essentially says read the code is of limited usefulness. Even those with the right background are going to need to spend a significant amount of time to be able to use it. About as useful of work around as one that requires specialized knowledge of the internals of the operating system.

There should be some level of documentation before the code is even written. Call is specifications if you like, but what the program is to do better be known before writing the code. When the code is evolving, with no clear pre-defined direction, documentation is even more important. That situation involves a lot of try something, see if it works, back up and try something else. Those paths tried and rejected need to be recorded, to prevent even more wasted time when someone else tries the same failing path.

Code is never truly finished. Given the choice of 100 features that I can not use because there is no information on how to use them, and 50 features that have the documentation to use them, I’ll take the 50 plus documentation. If the documentation was being written right along with the code, treated as part of the package being produced, that would probably be more like 80 features. The documentation makes the code easier to write, easier to test.

Extracting usage information by reading the code takes 10 times as long as creating it as the code is written. Doing it afterwards means first learning what the code does, then creating the documentation from that knowledge. Forcing everyone to read the code to get the documentation means that every single person that wants to use those features needs spend that amount of time, for the features they are going to use. Versus the one tenth time needed by the one person writing the code, or better, writing the specifications before the code was written.

That does not mean the programmer needs to produce full detailed, ready to read documentation. It is quite valid to produce very rough content, that is then passed to someone else to clean up and make pretty. With the rough verbiage, it only needs a general knowledge of the application goals, and decent writing skills, to to turn out good documentation for everyone else.

RANT OFF

15

All true, but as I understand it (and I’m a late comer, so my experience is limited), Fritzing started out as a funded university research project so there may actually be more documentation than has been released. When the funding ran out it got converted in to an open source project I think (based mostly on the paid parts creation service that is available) hoped to be funded by parts creation for some of the commercial vendors (thus the lack of parts creation documentation) as well parts editor isn’t yet completed so its possible they were waiting for that to complete before documenting and then funding ran out. There appears (at least to me) to be a good and far reaching plan of how development should have proceeded, but funding died and my sense is that not as much funding as hoped for is coming in from open source and time on the developers part is now lacking (likely because of having to fight for funding for new research projects at the day job). If we want to see Fritizing continue, its up to us to help out documenting what we can and possibly trying to fix bugs in the source (although I’m finding just parts creation to be a challenge :slight_smile: ). The part that is here is pretty amazing even in its incomplete and somewhat buggy state. With enough effort you can usually work around the bugs to get it to do something useful to you (at least I can) and the source is available to make it better if you can, both good things as far as I’m concerned.

Peter

16

Solved

When I got the new version far enough along, I did some diffs with the original failing version. I noticed an error in the part.fzp file. I knew I did not want real schematic and pcb views, but somehow I had duplicated the icon svg references for those layers, instead of the breadboard svg. Swapping that got the failing version to work.

2-by-x-header2breadboard.fzpz (2.9 KB)

Now I can expand it to the full headers / carrier I want.

In the process of testing though, I confirmed that this only works when the part family is set to Breadboard. Anything else wants to put a representation for the part on the schematic and pcb views. Instead of just the (rats nest) wires.