Standard properties

Hello,

I working on some parts and I wonder if there are some naming standard for properties like variant, package, family, … (I guess not)

When I work on the schematic diagram, I do not really care about parts physical characteristics (THT, SMT, …), which is something I will address when I’ll design the PCB.

My issue is parts does not seem to have standard keywords and implies to change the part to have another packaging.

Ex:
I need 5 switches in the schematic. I don’t care if they are THT, SMD, slider, latch, rotary…
When I go on the PCB, I would like to choose THT or SMD. But if the part (family) I chose in the schematic does not have this package, I need to change the part, then review the schematic, …

I think we could specify a list of keyword values for some properties:

  • family: resistor, switch, led, … + free text
  • package: THT, SMD, … + free text
    And probably others like variant, voltage, current, …

To help enforcing these rules, we could code them in the check-part tool and maybe also in an xsd describing the fzp files. No need to raise errors but warning and sufficient.
ex:
WARN: family property “whatever” is not part of the list “switch, resistor, led, …” Skip this message if your part does not belong to one of these families. You might report to fritzing team this new family.

What do you think about that ?

You guess correctly :slight_smile: there are currently no standards. To some extent (I expect mostly based on available time) at least family name is reviewed in parts QA (although of late there have been almost no new parts) to make sure they are unique and acceptable (for some undocumented value of acceptable!) There is some code to insure uniqueness as well, which is partly why the name field in connectors should be unique, it can get down to that to differentiate two parts, and possibly as well obsoleting can use name so may need to be unique (as specified in the parts file format document.)

I think we need to have a discussion and make a proposal for some more standards. The problem is there isn’t a lot of interest in doing that so so far. See this (almost totally inactive) forum post for an example of the problem:

That is likely the place to take these suggestions, but as noted there hasn’t been a lot of interest shown and unless we can find some people willing and able to make suggestions and do the work it likely (like development for so many years) isn’t going to go anywhere. I’d be happy to see that change but I’m not holding my breath :slight_smile: In the past (5 or more years ago when the forums were more active) there was a faction that opposed standardization as restricting, I don’t think there is anyone much with a strong opinion posting any more though. Unfortunately that also means there isn’t anyone with enough interest to do the work either (or as many as there used to be willing and able to make parts which is also a problem given how difficult part making is) , and this is going to take work. Working out what the new standards should be requires people with experience at part making and familiar with the code (both in short supply!) with time and interest in doing the work.

Peter

Hello Peter,

thanks for the feed back. I come from another technical field (pure software) going from standard defined by recognized and experienced people, to fully “no rules” approach … After discouraging the standard group, they all disappeared and now we’re in a kind of “happy” middle where we need to dodge bullets.

I don’t think we need to change the software to structure the parts. We can maybe enrich the QA process and your check part tool. My idea is to define a set of property names, a list of values for them and a tool to check. This does not break the model/software. If part maker wish to comply they can, but I’m sure there will be an added value for the ones willing to write ResistorModuleID instead of Resistance (for example).

Give me a bit of time, I’ll post a proposition, and I’ll be happy you (and others) to challenge it.

I understood that but that’s a “business model issue” (*). As we live surrounded by electronics, automation, … I guess electronic is not dead and Fritzing is a great tool. Sure we won’t design a jet fighter control board with a team of tenth designers but I’m sure smart people can make very valuable projects or prototypes. (The learning curve is nearly 0, and it produces the files for the Gerber files ready for the manufacturing.)

Stephane

In some cases such as family, we do need to change the code. At present if two members of a family have different numbers of pins, if you swap parts Fritzing breaks if the part is in a sketch as the part with less pins produces red rectangles for the missing pins as connectors are missing. So we need to figure a way to deal with that (I usually use a very specific family name which only has one member, but that doesn’t allow selecting a part from a broad family which is what you appear to want to do.) I think we need to figure out some standards that deal with to prevent that or provide a reason to fix the code if that can be done reasonably. The problem as I noted it to get the discussion by people with enough experience with the code to know where the issues are. There used to be enough people here in the forum that could do that, but development had died (and has since been restarted after 4 or 5 years of no development) but now most of the experienced folks no longer, post leaving us with the lack of experience or interest with doing the work. Documentation is always the most boring part of a project and thus the hardest to interest anyone in doing. Obsoleting is another one, there are a number of bugs there and currently little documentation. I’m currently working on doing some documentation (because someone wants a part update that requires obsoleting, but that runs in to bugs) and bug reporting. In some ways making more documentation and standards should be easier now as there appear to be less people that don’t want any standards any more :slight_smile: but we still need to find people capable of and willing to do the work. I am as bad as anyone else, I have been poking at an upgrade to FritzingCheckPart.py for around 5 years now, but it isn’t used all that much and I find it hard to get motivated (and even harder to learn to write good python, I’ve never been a real developer :slight_smile: ) I’m working on a python version of the parts factory (to prototype getting it out of the code to be more accessible) and am learning a bit more about proper python doing that but it is going slowly. The advantage is it is much less complex than FritzingCheckPart.py.

Peter

1 Like