[Discuss] Advanced part parameters

[Drachenkaetzchen]

Right now, we "only" have parameters which are bound to numeric values. However, we want to have parameters like "strings" and "colors".

This is a bit of effort, because it doesn't look as if ExtJS supports multiple editors per column or different column types. Need to investigate how this is possible. For now, I recommend that we use the comment field to add such information to parts and move the issue to V2.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[scrupeus]

What about parameters linked to categories? Using the following categories as an example...

• Electronics
  • Resistor
    • Surface mount
    • Thru-board
  • Capacitor
    • ...
  • IC
    • Amplifier
      • Op amp
      • In amp
• Mechanical
  • Fastener
    • Bolt
    • ...

Category 'resistor' would have parameters such as resistance, tolerance, package, etc. Category 'IC' would have package, etc. But child categories would inherit their parent's parameters and be able to add their own. So category 'Amplifier' would add common amplifier parameters such as number of channels, voltage range, etc. And selecting a part from 'Amplifier' (or one of its descendants) would give all the parameters from 'IC' plus 'Amplifier'.

This would simplify parametric searching/filtering - select a category and only parameters relevant to that category and its ancestors would be shown in the filter/search panel.

It also forces consistency between parts in the same category - arbitrary setting of parameters leads to parameters not being entered and problems filtering/searching, while presenting a list of pre-defined parameters guides the entry of required data.

Frontend implementation would be easy (just add a parameter entry panel to the category editor) but the backend would require some thought. I wouldn't expect it to be too difficult though? Once that's done, adding parametric filtering/searching is not difficult.

[elsni]

I thought about a similar situation some time ago, and I had an idea. Sure, this would require a major redesign of the database and BL. So, what about dynamic association of parameters, values etc.? I mean like adding a "feature" to a part, like adding a tag. Feature could be i.e. Value, Parameter etc. if you think further, everything what is stored in static DB colums can be a feature: storage location, name, description. Some features like name or value and storage location are required, others are optional. To make this usable (thinking of input forms), predefined feature sets should be configurable by category and the part input form is dynamically created using the associated features.

[Drachenkaetzchen]

It's not a good practice to create a fully dynamic database. Not only it would bring performance down to it's knees, it would be a nightmare for users to configure and horrible to write.

(I've been to the "make a fully dynamic system" point 10 years ago and I can assure you: It will create more problems that it will solve).

[xadonxander]

What about making the column text and sorting it out in the backend?

[Drachenkaetzchen]

A text field would make it impossible to let the database do search+sorting work; e.g. if you seek for a part which is 100Ohms +- 5%, we can't search for all parts which have between 95 and 105 Ohms.

[xadonxander]

There would need to be 2 searches 1 for the newly added text parameter table and 1 for the part parameter table. Use php to decide if you are searching for a number or text and run the appropriate search. This would require a new table to store the text parameter.

[Calrion]

Before I get started, I do want to say that the way PartKeepr handles numeric parameter values is fantastic!

I agree with @scrupeus: linking a set of parameters to a category would be ideal, especially if you could also specify that certain parameters were required for parts in that category (e.g. if you're adding a part to the "fixed resistors" category, you must specify resistance, tolerance, and material). A list of name, unit, and a 'required' checkbox on categories would be sufficient; I agree that these definitions should cascade to child categories.

I would like to see string values accepted, but the bigger use case for me is enumerations; this way, integrity can be more easily maintained while still permitting necessary values—the empirical case for me is capacitor dielectric material. I'd also like to see boolean parameters (represented by a checkbox in the UI and ideal to indicate, say RoHS compliance) and maximum and minimum value restrictions on numeric parameters. Provided the definitions cascade as I mentioned above, I think the best place to define these would be on the category; otherwise, they're probably best defined with units (which would need to be renamed).

[DarkDust]

I don't know about the DB scheme, here's just an idea I had: how about using ranges for numbers, maybe with a parser/formatter on the frontend. This way you could cover 1MOhm +- 5% (OHM_low = 950000, OHM_high = 1050000), 4-12MHz (Microcontroller frequency range), temperature ranges, measurement tolerances, etc. For exact values, low=high.

[Drachenkaetzchen]

Advanced part parameters are now implemented, however, quite some features from this issue aren't there yet, thus I'll not close this issue yet.

[HendriXML]

.