How do I name the files of my new part?

It is possible this may partly work. Here I modified a test copy of my 74x125 part (which has schematic subparts as does OPs new part, based on this one) with the family changed back to Generic IC from quad buffer and the pcb layer set to layers image=“pcb/dip_14_300mil_pcb.svg” as expected it loads correctly initially and trying to change the pins from 14 to 16 in Inspector gets this error message:

and leaves the package at 14 pins. So far so good. But now I changed edit pin labels false to edit pin labels true and the expected problem shows up (and an unexpected one too!):

I expected to get the box with 14pins and labels, but instead get a 8pin box with labels. I expected this to break the subparts but I can move the subparts in the original chip around still as well as the new 8 pin part in schematic but I expect the sketch is now screwed up as it has a new unknown entity in it in the form of the 8pin part in schematic. Indeed it has screwed up breadboard (which used to be a 14 pin DIP):

by replacing it with an 8 pin DIP which is tied to the new schematic part:

at the same time the subpart part still exists somewhere with the old settings:

I think this won’t be a problem when I set the family back to quad buffer:

property name=“family”>quad buffer

leave the pcb layerId

layers image=“pcb/dip_14_300mil_pcb.svg”

and copy my original pcb file in to core parts dip_14_300mil_pcb.svg so it exists there (this shouldn’t bother the parts factory because it doesn’t generate its pcb files in the parts repository but in a temp directory.)

then rebuild the part and try it. Indeed all seems fine, editable labels is false (and not setable because it isn’t a generic IC)

and pcb is a 14 dip without there being a pcb svg in the .fzpz file (but a new one in core parts!)

Peter

I lost track in that. What happened if you did NOT use family of Generic IC, and did not have an actual pcb svg file in either the core pcb folder or the fzpz? Just specifying pcb/dip_14_300mil_pcb.svg in the fzp with no real files matching?

I didn’t actually try that til just now, but that too seems to work although I don’t know how (perhaps the swapping mechanism finding a match in parts factory somehow?) Here there is no pcb svg in the fzpz file and no dip_14_300mil_pcb.svg in core parts, yet it finds an appropriate footprint.

so if that is what he ended up with it will likely work fine although I don’t know why.

edit: here is the part so you can try it as well:

74x125_test.fzpz (8.5 KB)

edit2: Yes parts factory appears to be generating one even though it isn’t a Generic IC:

I’ll be damned …

Peter

That is one of the “magic” file names that Fritzing recognizes. So this was not actually a good test of leaving a file out of the fzpz, to pick up the one already in core.

I asked about a list of those magic names a while ago, but never got a response. Have to dig through the code. Another item that FritzingCheckPart will not currently handle. You need a way to get factory to generate the file for you when testing. Or at least recognize it as a magic name, and not complain that it does not exist.

I’ve noticed that the “pcb/dip_14_300mil_pcb.svg” places a 14pin IC socket vertically, while the “pcb/dip_16_300mil_pcb.svg” places the 16pin socket sideways. It seems odd that there is this inconsistency in the factory svg parts library.

I would prefer my pcb sockets vertical, so I’m not sure whether to include the pcb.svg file in the fzpz. I know I can rotate it after inserting, but then I have to rotate the label back and it’s a hassle. I have lots of IC’s to insert and it’s just an unnecessary waste of time.

Another question: How do I control the placement of the label in pcb view? It places the “U” label off to the side, but I would prefer it central. I can’t see anything in the fzp, is it hardwired in?

It actually depends on what view you drag the part in to (there is a bug report about this open on github)

I think the rpc calls that create the other views are missing a parameter because it is consistent in the view that you drag in to but not (usually) the other two views.

Dragging them in to PCB should always align them right but then schematic and breadboard will be off in random order until the bug is fixed (and there isn’t currently a milestone for a fix!)

As far as I know it is hardwired although there may be an undocumented fzp attribute I don’t know of. It may be worth making an enhancement request (that used to be fairly futile, because development had died, but development has restarted and though bug fixing has priority some enhancements especially if they are easy, are being done)

Peter

I was talking about the pcb view only, using the

layers image=“pcb/dip_16_300mil_pcb.svg”

part in the fzp. If you try the above in the fzp it always comes out horizontal. Change the pins to 14 and it always comes out vertically.

Yes apparently so. This is why I had to pay to download the latest version of Fritzing. I hope they do continue developing it.

Odd! For me both work correctly on both 0.9.6 and 0.9.7 under Win10. Here I modified my 74x125 test part and changed the dip_14 (which always comes out vertical) to dip_16 and it also always (at least in 10 tries) comes out vertical.

which is what I would expect because parts factory isn’t likely to change orientation on size (not impossible, just unlikely :slight_smile: .)

Peter

That may not be so easy :slight_smile: , as I recall they are generally made with a sprintf from a parameter list which makes finding all the possible values exciting.

Or generate a complete set of svgs for all possible sizes and pitches (which will be a pain to maintain.) Yet another item for the todo list for checkpart … I’ll have to find a different svg (that isn’t a special file name) to see if it will search core for a missing svg.

edit: it still works. I replaced the dip_16_300 in the test part with layers image="pcb/74HC139N_2.svg which is a 16pin dip svg in core parts and it still finds the footprint fine.

Peter

Yes, very odd! The placement is perfect for me except for the orientation.

I’m on 0.9.6 as I found 0.9.7 had a massive bug that prevented me from changing the number of pins on the generic IC. I’m running it on my laptop on Windows 7. My desktop is down at the moment.

I will post the part with the factory part and see how it goes. I’ve just been reading the standards that @microMerlin mentioned above.
https://fritzing.org/fritzings-graphic-standards/#download

I’m now in the process of modifying my part to better match the standards. I might be a while!

As @vanepp said, the default position is built into the code someplace, and there is nothing currently that can be done in either a specific part, or in user configuration to change that. The label can be moved after the part has been placed. I have never worried about it, since I seldom have a specific location that I always want the label to show up. Though for some parts (resistors), central is the normal choice for PCB view. My process when adding a part is to immediately set a few things like that.

A note though, when using multiple copies of a part. If you cleanup things after placing the first part, duplicates of that part will keep the relative position and orientation.

That is more consistent than my experience. What memory says, is that placement (in the initial view) is consistent for a session. For a specific part, whatever orientation the first placement gets will be the same for all future placements. However, shutdown Fritzing, and restart, and the next placement of the part might have a different orientation. I have never formally checked and recorded cases and steps to get there. That is just my casual observation. My process is to (automatically) rotate the part, rotate and possition the label when I place the first instance, then use duplicate from there on to keep consistency.

I have a script that generates permutation based on lists of possible values. It should not be difficult, if I can find that sprintf, and deduce the source/possible values for the parameters

You are correct, if I drag the part into the pcb view first, then the orientation is vertical. If I drag it in to Schematic or Breadboard view, then it’s placed in pcb view horizontally. I don’t get the same with 14 pin devices through, they always seem to get placed vertically.

edit: Yes, I do get this with 14pin ICs too. I guess it’s just the behaviour of the software. I just wasn’t aware of it before.

This version number sounds like a great idea, but it’s not shown this way in the naming standards.

Do the standards need updating!? I think I’ll keep it in my parts as it makes sense, as I’m sure there will be corrections to my new part!

A version number may be a good idea. I believe that the “expectation” is that (for svg files) only corrections will be needed, that will not change the version number, or it will be a “variant”, which will have different keywords and values to make up the name. The fzp file includes a version number field, and the module_id is what Fritzing actually uses internally to tell things apart. Anything else is supposed to be handle by the “obsoleting” process.

In that note: “expectation”, “supposed”. The real world may not cooperate.

Hello,
I’ve just made a new part using my previous part as a template. But I’m getting an error to the effect of “prefix0000 already exists…”

I found the reference in line 2 of the fzp, but I’ve never took much notice of this line before. I swapped it for the part number instead and it loads without error now. Is this the correct way to do it? What is the standard way to name the “module ID” and “referenceFile” on line 2?

Yes. The moduleId needs to be unique (which is why parts editor creates the long name, which is partly time based I believe.) The reference file is only used by parts editor and then I believe only for information so you can ignore that. As well as the moduleId the family and/or variant fields in the fzp file need to be unique to the part. Parts in the same family can be swapped, so the pins need to be the same (although that isn’t currently always true in core parts I don’t think.) I usually use the name of the part as the moduleId and append a “_1” such as “4050_1” for the moduleId. The _1 is a version number, so if you need to make a correction, it can change to _2 (along with all the svg file names) and the original part can be moved to the obsolete directory to be available for old sketches (Fritzing will tell you there is a new version of the part and ask you if you want to upgrade to the new part in that case.)

Peter

Thanks Peter. Do you think it’s worth including the package info, in case there are two parts with the same number but in different packages (DIP16, 300mil, SMD, etc)?

Yes the package should be there. The various different packages each need their own part files, but that is a case where family will be the same and the variant (or a package property) will select between the available packages, as a swap will work there as the pins are identical (usually anyway there are exceptions!)

Peter

In that case, I think I’ll use the file name used in the fzpz files, then everything matches. The files were named using the File Naming Conventions, but with the version number added on the end.

Thanks for this kind information.