Using InvenTree to store KiCad Data #4133
Replies: 16 comments 71 replies
-
|
What about adding this as a plugin functionality instead of directly integrating this into inventree core? |
Beta Was this translation helpful? Give feedback.
-
|
I think there are enough users to put this into core. The possibilities around change management, impact analysis etc. seems to be bright. Maybe we should create an epic for this? @SchrodingersGat |
Beta Was this translation helpful? Give feedback.
-
|
Ok, it seems very straightforward to get running. The problem is more how you implement permissions, users, ... - maybe we start with only one supported DB and then expand? I think we might need to write a backend to handle user management. |
Beta Was this translation helpful? Give feedback.
-
|
F-A-N-T-A-S-T-I-C!! All KiCad team users have been waiting for it impatiently (eg. me first!) and it is finally coming! Also worth noting the new |
Beta Was this translation helpful? Give feedback.
-
|
@eeintech on the last survey that asked 60% of 40 participants were interested in a KiCad integration. I would not but to much weight on that number though, the turnout is too low to be reliable. |
Beta Was this translation helpful? Give feedback.
-
What about trying to support other OSS CAD software like FreeCAD? (Although I'm not sure if there is currently a possibility of integration with freecad) |
Beta Was this translation helpful? Give feedback.
-
|
In my experience, FreeCAD is not a serious replacement for professional MCAD like Siemens NX, Solidworks, CATIA or Inventor. You could probably replace AutoCAD or Fusion 360 with it. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, I'm using Inventree, have around 500 electronic parts in it and would love to use it with KiCAD. Also, I have been using Altium for 6 years now. Before that, I was using Eagle. Also, I'm one of maintainers of contents of an ordering system in my company. It would be great if there were these things in Inventree to make it much more usable for electrical engineers:
|
Beta Was this translation helpful? Give feedback.
-
|
@MR-DOS This feels like a lot of different requests. If you want something implemented it would probably be more successful to file feature requests as we can better keep track of them that way. A few of your suggestions are already filed if I understand the short descriptions right. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, not currently a user of InvenTree but would instantly start if KiCad integration was added! :) I am an EE looking for an inventory management system for our local MakerSpace. Based on InvenTree's electronics & sales focus I suspect it would not be ideal for a 'space that includes sewing, woodworking, metalworking, and other non-technical crafts. If external barcode support was an option, it could be easier to get people on board for the sales angle, but I don't see that anywhere. |
Beta Was this translation helpful? Give feedback.
-
|
We have nothing directly to do with electronics either, but InvenTree works well! For us, the sales aspect is important. However, I recently realised that the Sales Order is quite useful in order to create an overview of all the parts required for an internal project - I created a sales order to us as a customer, and added all the parts required (which you would not have in a PO, for example, since these are per supplier). This aspect might be interesting to you in your MakerSpace as well! |
Beta Was this translation helpful? Give feedback.
-
|
@kriskeillor external barcodes are supported already by InvenTree - https://docs.inventree.org/en/latest/barcodes/custom/ :) |
Beta Was this translation helpful? Give feedback.
-
|
I've just started to evaluate InvenTree & now have around 600 parts imported from PartKeepr. I'm favourably impressed so far - creating parts using the sister project, KinTree, complete with parameters is particularly useful. |
Beta Was this translation helpful? Give feedback.
-
|
@matmair I don't think he meant to connect directly as the format of the KiCad DB is different than InvenTree DB so it's not plug-n-play. It would take a bit of work to add a middle-layer which should operate the following steps (triggered by user opening remote symbol library in KiCad):
You could also imagine an InvenTree plugin regularly syncing data to the KiCad DB so it is always up-to-date. I don't know which is the best strategy, what do you think? Any better option in mind? |
Beta Was this translation helpful? Give feedback.
-
|
It is spelt out as |
Beta Was this translation helpful? Give feedback.
-
|
Looking into it as we chat, I don't see how it would work with the current InvenTree database without creating a mess, the The middle layer/database is needed to run the full chain: And supervising the sync between "KiCad" and InvenTree databases, eg. user changes value in kicad database and vice-versa. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe something changed since the testing releases for 7.0 but it populated my test-parts after I just added the parts table via the new database connection file. |
Beta Was this translation helpful? Give feedback.
-
|
@matmair Are you referring to the |
Beta Was this translation helpful? Give feedback.
-
|
As a read-only user - is the risk of bad things happening really very high? You could mirror the database and operate on a copy. I used something similar in PartKeepr _ accessing the mySQL database directly as a read-only user and had no problems.
… On 24 Feb 2023, at 16:52, Matthias Mair ***@***.***> wrote:
@Gasman2014 <https://github.com/Gasman2014> directly connecting to the database has serious security and operations implications, I strongly recommend against it.
—
Reply to this email directly, view it on GitHub <#4133 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACADFOIBDGE4RGNHIK4M23LWZDRLVANCNFSM6AAAAAATOCJ6NM>.
You are receiving this because you were mentioned.
|
Beta Was this translation helpful? Give feedback.
-
|
That would also be my expectation. The kicad database functionality is simply a mechanism to link to an existing database via an ODBC connection. The fields accessible within kicad are exposed via a .json file which defines the connection and the field mapping. This is strictly one way read only. The addition of a symbol and footprint field (these are paths to existing files and not footprint or symbol descriptors themselves) would serve to complete the structures necessary to place a complete component.
Now, at present, it is helpful to subdivide the data into tables by class of part so that you don’t just have a ragbag of hundreds of resistors, capacitors and other components lumped together but that is a different issue.
… On 24 Feb 2023, at 21:33, Matthias Mair ***@***.***> wrote:
Maybe something changed since the testing releases for 7.0 but it populated my test-parts after I just added the parts table via the new database connection file.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.
|
Beta Was this translation helpful? Give feedback.
-
|
See my comments above: As I said library to database table is one-to-one matching. |
Beta Was this translation helpful? Give feedback.
-
|
Can’t you use an SQL ‘View’ to bring the necessary data together in a single entity? I’m not any sort of SQL expert but I thought Views could accomplish something like this https://www.sqlshack.com/sql-view-a-complete-introduction-and-walk-through/ |
Beta Was this translation helpful? Give feedback.
-
|
Proof of concept.
Hacky example with a ‘View’ into a minimal ‘capacitor’ selection - Capacitors_MLCC.
You can define a .kicad_dbl to use this table to present this data within the KiCad schematic.
The only fundamental thing lacking is the ‘symbol' and ‘footprint' links.
Whilst I am sure that someone with better sql skills than myself could pick these and the other parameters from key:value pairs in the part.partparameters table but it would be much simpler to include them in part.part.
**1. Set up a ‘view’ in Inventree**
```sql
USE inventree;
CREATE VIEW Capacitors_MLCC
AS
SELECT
part_part.part_id AS part_id,
part_part.description AS Description,
part_partparameter.data AS Capacitance
FROM part_part
JOIN part_partparameter
ON part_partparameter.part_id = part_part.id
WHERE category_id = 821 AND template_id = 52
```
**2. Demonstrate that the parameters are available from the database**
```sql
SHOW * FROM Capacitors_MLCC
```
```
part_id. Description Capacitance
3324 CAP CER 0.47UF 200V X7R 1210 0.47 µF
3325 CAP CER 20PF 50V C0G/NP0 0603. 20 pF
3330 CAP CER 10PF 50V C0G/NP0 0603 10 pF
3331 CAP CER 10UF 16V X5R 0805 10 µF
3335 CAP CER 0.1UF 16V X7R 0805 0.1 µF
```
**3. Setup a kicad_dbl file with links to the database and using the ‘capacitors_mlcc' table**
This is my test.kicad_dbl file. Obviously, to be more useful, more parameters e.g. voltage, dielectric type, tolerance, package size etc need to be added. Extracting this info from the key:value pairs in ```part_partparameter``` probably needs a pivot table.
```json
{
"meta": {
"version": 0,
"filename": "demo.kicad_dbl"
},
"name": "PartKeepr Database",
"description": "An demo database from Inventree",
"source": {
"type": "odbc",
"dsn": "Demo",
"username": "******",
"password": "******",
"timeout_seconds": 20
},
"libraries": [
{
"name": "Capacitors",
"table": "capacitors_mlcc",
"key": "part_id",
"symbols": "Symbols",
"footprints": "Footprints",
"fields": [
{
"column": "Description",
"name": "ki_description",
"visible_on_add": false,
"visible_in_chooser": true
},
{
"column": "Capacitance",
"name": "Capacitance",
"visible_on_add": false,
"visible_in_chooser": false
}
]
}
]
}
```
**4. View the components from within KiCad 7**
<img width="1334" alt="Screenshot 2023-02-26 at 13 24 27" src="https://user-images.githubusercontent.com/8401593/221415155-829eddee-8921-4b1b-8ad0-0f216fed39f7.png">
As you can see, the capacitance is now accessible as a parameter from the ‘view’ table.
Now, as I mentioned, the feature missing is a suitable place to store the symbol and footprint paths. This need only be two additional VARCHAR fields (if you are happy with paths <=255 characters) in ```part_part```. This info probably could be included as key:value pairs in the parameters but it would be simpler in the ```part_part``` table.
So, a read-only ‘View’ directly into the database with parameters available IS possible. I believe the risk of database corruption is absolutely minimal.
… On 24 Feb 2023, at 22:00, Francois ***@***.***> wrote:
See my comments above:
#4133 (reply in thread) <#4133 (reply in thread)>
#4133 (reply in thread) <#4133 (reply in thread)>
As I said library to database table is one-to-one matching.
InvenTree data is spread among many database tables.
KiCad .kicad_dbl does not allow to map different fields to different tables at the moment, or not that I'm aware of.
So if you want to load a database library in KiCad V7, you need a ALL the data (fields and properties) for all parts in the library to be contained in a single database table.
—
Reply to this email directly, view it on GitHub <#4133 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACADFOM7EIPAV4SSXGLELN3WZEVQHANCNFSM6AAAAAATOCJ6NM>.
You are receiving this because you were mentioned.
|
Beta Was this translation helpful? Give feedback.
-
|
Because a view is a virtual table that can bring in data from other tables and all the data is presented in a single table without needing to invoke an sql query. The 'database' function within Kicad is not a sql engine. It only allows you to select data from a single table. |
Beta Was this translation helpful? Give feedback.
-
|
So kicad should directly connect to the database? This sounds like a horrible solution in security and also software design aspects. Inventree would need to have some connection layer between. |
Beta Was this translation helpful? Give feedback.
-
|
Why is that ‘horrible’? The premise is that the design engineer should chose a validated part from an InvenTree database. The engineer is aware of which items have been ‘approved’ and are available. The intent is to present the engineer with sufficient parameters to facilitate a suitable choice. The database IS NOT and CANNOT be altered in any way by this choice or by the existence of the ODBC link. It requires no user intervention. It is as up to date as the InvenTree database. The database is only available via the KiCad_dbl file - a database link document that is simply a mapping device. I think you need to understand what (and how limited) is the KiCad ‘database’ - I’m not sure it is at all what you think it is. |
Beta Was this translation helpful? Give feedback.
-
|
Proof of concept. Reposted - hope the formatting works this time … Hacky example with a ‘View’ into a minimal ‘capacitor’ selection - Capacitors_MLCC. You can define a The only fundamental thing lacking is the ‘symbol' and ‘footprint' links. Whilst I am sure that someone with better sql skills than myself could pick these and the other parameters from key:value pairs in the 1. Set up a ‘view’ in Inventree USE inventree;
CREATE VIEW Capacitors_MLCC
AS
SELECT
part_part.part_id AS part_id,
part_part.description AS Description,
part_partparameter.data AS Capacitance
FROM part_part
JOIN part_partparameter
ON part_partparameter.part_id = part_part.id
WHERE category_id = 821 AND template_id = 522. Demonstrate that the parameters are available from the database SHOW * FROM Capacitors_MLCC3. Setup a kicad_dbl file with links to the database and using the ‘capacitors_mlcc' table This is my test.kicad_dbl file. Obviously, to be more useful, more parameters e.g. voltage, dielectric type, tolerance, package size etc need to be added. Extracting this info from the key:value pairs in {
"meta": {
"version": 0,
"filename": "demo.kicad_dbl"
},
"name": "PartKeepr Database",
"description": "An demo database from Inventree",
"source": {
"type": "odbc",
"dsn": "Demo",
"username": "******",
"password": "******",
"timeout_seconds": 20
},
"libraries": [
{
"name": "Capacitors",
"table": "capacitors_mlcc",
"key": "part_id",
"symbols": "Symbols",
"footprints": "Footprints",
"fields": [
{
"column": "Description",
"name": "ki_description",
"visible_on_add": false,
"visible_in_chooser": true
},
{
"column": "Capacitance",
"name": "Capacitance",
"visible_on_add": false,
"visible_in_chooser": false
}
]
}
]
}4. View the components from within KiCad 7
As you can see, the capacitance is now accessible as a parameter from the ‘view’ table. Now, as I mentioned, the feature missing is a suitable place to store the symbol and footprint paths. This need only be two additional VARCHAR fields (if you are happy with paths <=255 characters) in So, a read-only ‘View’ directly into the database with parameters available IS possible. I believe the risk of database corruption is absolutely minimal. |
Beta Was this translation helpful? Give feedback.
-
|
@Gasman2014 Thanks for sharing your approach and test, I was not aware of SQL views. One drawback to this method is still the one-to-one view to library matching... which add up to InvenTree's database. @wolflu05 and @matmair had a separate discussion on this and we think in the long-term it would be wise to develop a solid middle-layer to feed and manage a separate KiCad database, this middle-layer can be implemented via an InvenTree plugin. It would require a steep initial effort but should offer a "performant and scalable" solution (in @matmair's own words). |
Beta Was this translation helpful? Give feedback.
-
|
Just to extend my example (and to leave it here for anyone who is interested in using the 'View' approach), here is a way to generate a more comprehensive SINGLE table that pulls in parameters from the SELECT * FROM inventree.capacitors_mlcc;produces
The table is generated by using the following SQL setup. Rinse and repeat/adjust for any other components you chose - you can set up separate tables for THT or SMD components etc. by appropriate choice of CREATE VIEW Capacitors_MLCC
AS
SELECT
part_id AS part_id,
part_part.description AS Description,
MAX(
CASE part_partparameter.template_id
WHEN '52' THEN data ELSE NULL
END
) AS 'Capacitance',
MAX(
CASE part_partparameter.template_id
WHEN '51' THEN data ELSE NULL
END
) AS 'Tolerance',
MAX(
CASE part_partparameter.template_id
WHEN '49' THEN data ELSE NULL
END
) AS 'Dielectric',
MAX(
CASE part_partparameter.template_id
WHEN '36' THEN data ELSE NULL
END
) AS 'Case',
MAX(
case part_partparameter.template_id
WHEN '44' THEN data ELSE NULL
END
) AS 'Voltage'
FROM part_part
LEFT JOIN part_partparameter
ON part_partparameter.part_id = part_part.id
WHERE category_id = 821
GROUP BY part_part.id |
Beta Was this translation helpful? Give feedback.
-
This is a fair point but in practice you would probably only have half a dozen tables. I would expect that you would probably set up database links for Chip Caps and Resistors as these probably benefit most from knowing the parameters at time of placement. Possibly another table for electrolytics. Depending on your line of work, it might be good to have libraries for diodes or maybe an opto components library. However, if you really wanted everything in your database, it wouldn't really matter if you had twenty or more libraries - I would hope that KiCad offers more search functionality. I would be surprised if there was any significant performance hit unless you were running InvenTree on very marginal hardware. |
Beta Was this translation helpful? Give feedback.
-
15 libraries in fact, so 15 views... The limitation is clear, this is all hard-coded for each InvenTree instance and only knowledgeable people will figure out their way around it, because there won't be any template to rule them all. Anyway it looks like a nice hack to get a quick setup in place but by no mean re-usable by the many InvenTree/KiCad users. |
Beta Was this translation helpful? Give feedback.
-
|
@Gasman2014 the problem lies in using a cleartext config file - ie. you can get the inventree database user details from there. If users do not generate separate, least-privileged user accounts for accessing the DB they have a high likelihood of exposing their full database credentials as they might be laying around on a lot of endpoints. The view itself is no problem, as though not really scalable for users that are not used to databases. My comments about performance are a bit misquoted. A solution using direct database access (like yours) is much more performant than API requests that get the same done. |
Beta Was this translation helpful? Give feedback.
-
|
@matmair - Yes, I agree that there does need to be a bit of care taken with the endpoint and I fully concede that broadcasting authentication details could be a security risk. However, I guess this is only likely to be used by people who are already reasonably comfortable with databases and who can appreciate and mitigate this risk. For individuals running their own server in a small lab, it might be an adequate, if imperfect, solution. I put it out there as I think there are quite a few users choosing InvenTree for part management and who might be keen to try out the new KiCad database feature. Nevertheless, I entirely agree that a more fully formed solution would be desirable. Nevertheless, I'd still like the symbol and footprint fields 😉 ...
It would seem that 'Views' are supported in most major RDBMS - maybe others too. Views in Microsoft SQL Server |
Beta Was this translation helpful? Give feedback.
-
What about using the metadata model and write a custom plugin which adds a custom panel for editing that information? |
Beta Was this translation helpful? Give feedback.
-
|
Checking in here, after losing track of the discussion for a bit. @Gasman2014 an interesting approach, how would the kicad .exe gain access to the "view" - does it need to be on the same local machine, or do we expose the sql server to a common network? |
Beta Was this translation helpful? Give feedback.
-
|
Sorry missed this. SQL views are virtual tables that are derived from the result of a predefined SQL query. They provide a way to simplify complex queries, enhance security, and improve performance by storing frequently used or complex query logic as a named object. Views are virtual tables because they don't store any data themselves. Instead, they act as a lens through which you can look at the underlying data in the tables on which they are based. Views provide a layer of abstraction, allowing users to work with the data in a simplified manner. Instead of dealing with complex joins, aggregations, or filtering conditions directly, users can query the view as if it were a regular table. Views can encapsulate complex SQL logic and encapsulate commonly used joins, aggregations, or calculations. This simplifies queries and promotes code reuse, as users can query the view without needing to know the underlying complexity. Views can also enhance security by restricting access to certain columns or rows of a table. For example, you can create a view that includes only specific columns and rows based on certain conditions, and then grant access to that view instead of the underlying table. The Views are defined by preconfigured SQL statements residing on the server. The database access config file resides on the local machine running the KiCad executable. This file shapes the OBDC query to extract the data from whatever database it is pointed at. |
Beta Was this translation helpful? Give feedback.
-
|
I've been following the discussions here as I am also very interested in interfacing KiCad with InvenTree. I recently found a post on the KiCad forums A Database case study that uses SQLite3ODBC to access parts imported from existing CSV files into an SQLite3 database. I was inspired by this approach to create a generic "middleware" (appologies in advance for using that term) which uses SQLite3ODBC and SQLite3 virtual tables to pull data directly from the existing InvenTree API. A proof of concept with instructions is available here: https://github.com/clj/kom There is still a bunch of work to be done for this to become a usable solution, but it currently works for simple parts (e.g., passives that all use the same symbol) and the performance is (very unscientifically) pretty decent, hitting an Invetree instance hosted on a Digital Ocean VPS. I think there are some benefits to this approach, for example:
A significant downside is that it does require a bunch of configuration steps, including running SQL statements using SQLite. This could possibly be abstracted away by a GUI if somebody had the inclination to write some code to do that. There is still a bunch of work to do:
|
Beta Was this translation helpful? Give feedback.
-
|
@clj you can include parameter information in the same part query, by including the e.g. |
Beta Was this translation helpful? Give feedback.
-
|
Not fully ready but here is the beta link: https://pypi.org/project/inventree-kom2/ - I have to add some small auth stuff but 1.0 should go live within the hour |
Beta Was this translation helpful? Give feedback.
-
|
@clj the first version of the plugin is up; it can be used with any demo instance (ie using the test dataset). I am still debugging the interactive editor - will try to publish that this week; might take a bit longer as I am writing a blog entry meanwhile. |
Beta Was this translation helpful? Give feedback.
-
Ohhh, sweet! I wanted to get around to asking if something like that was possible. Thanks very much for the heads up! |
Beta Was this translation helpful? Give feedback.
-
|
@matmair Awesome! I'll have a look at that as soon as I have a spare moment... :) |
Beta Was this translation helpful? Give feedback.
-
|
The “views” approach is what I’ve been using but my implementation didn’t seem to be very popular due to a perceived security risk and the necessary individual configuration. It does require a fair bit of customised setup but, once done, is fairly solid. I’ve also done this with a series of views into a MySQL PartKeepr database which pulls in a number of parameters including stock availability. Views allow you to construct a new, conditionally determined table on the remote database with data from a number of related tables and built on the fly from an sql query.FWIW this also seems to be the approach used by the Altium Library project.issus/altium-library: Open source Altium Database Library with over 165,000 high quality components and full 3d models.github.comThis is why I think a views based approach would be useful as the work can be done on the server and the user can have permissions set just to query the views. The present KiCad approach needs those stored locally - so the Database Library would have to have fields to record the paths. I think there was some talk about allowing KiCad to access a symbol/footprint definition held as a blob on the database itself. Similarly how to access the 3d models which are also references to local files but could pull in a remotely held .step file. These are limitations of the current database implementation. On 9 May 2023, at 10:29, Lukas ***@***.***> wrote:
But what is with this sql views approach? Wasn't that using the inventree psql/MySQL db on a remote server so remote should be supported?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Hey, so I have been wondering about parts vs manufacturer parts for a while. Currently in the KiCad/InvenTree integration I'm just pulling parts and part IPNs. Those parts though, have potentially a number of manufacturer parts. Since I'm making an assembled board (using JLCPCB) I need the LCSC part numbers to be able to create a position and bom file for the assembly. And ideally, because I'm using KiBot this is all going to be embedded in the project or at least somehow in the repository so that all the relevant files can be built using the GitHub Actions automation that I have set up. I'm wondering how the workflow for that looks and whether the integration is doing the right thing here. Manufacturer parts can probably be pulled from the API and exposed the same way as metadata or parameters, but is that the right thing to do? I especially don't see how this works if there are more than one manufacturer part, then there is no way of selecting which manufacturer part that should be used. Or, should there be a separate step, using e.g. a KiCad PCBNew plugin that assigns manufacturer parts? Or something else? Has anyone had a thought about how this should work? |
Beta Was this translation helpful? Give feedback.
-
|
I'm coming at this from a hobby perspective, and have no idea about actual manufacturing processes, so please excuse any ignorance in my replies around this :)
The other issue (other than people having not set Manufacturer Parts up) I see is: how do I refer to them? Currently I'm using the IPN as the key (my "Library links" look something like this: And if Manufacturer Parts aren't set up, what then? Should there be an option to use just Parts? should the integration try to do something clever about how this is presented to the user, e.g. showing Manufacturer Parts if they exist, and just Parts if not? Or should it always show a combination of Parts and Manufacturer Parts (e.g.: Fetching the relevant information might now also require multiple fetches, unless there is a shortcut to also include Manufacturer Parts when fetching Parts (or vice versa)? I am also wondering if Manufacturer Parts from the same Part would always be considered interchangeable? Then it would seem to make sense to just use the Part and its IPN and never needing to change that (and any symbols or footprints) if I swap in another Manufacturer Part. The question is of course how one would swap another Manufacturer Part in, which is where my suggestion of having another KiCad plugin to be able to make selections of Manufacturer Parts and it could then add fields with the relevant information to the components on the board. Sorry, lots of questions there! :)
That could definitely be done. I currently have a work-in-progress KiCad plugin to push BOM changes to InvenTree: https://github.com/clj/inventree-bom, which is then a manually initiated thing. |
Beta Was this translation helpful? Give feedback.
-
|
The MPN can use the manufacturer's part number as a ref so that should work. TBH due to the very low number of participants in the user base surveys I have no idea how well manufacturer parts are used.
Having something in CI that pushes BOMs and files would be great because engineers always forget to |
Beta Was this translation helpful? Give feedback.
-
|
Hi, sidenote from a quite large real-world company making electronics - using MPNs as reference in drawings/BOMs is a very bad idea (unless it's actually a MPN shared by many mfgs - there are dozens of them making BC847, 1N4148 etc., but still it's not recommended use). For hobby use, it may be mostly fine, but not for serious use. If the manufacturer stops making the part and there's a replacement by other mfg, you have to change all drawings containing that part, because the drawing contains maker-specific PN. In our case, it could be hundreds of drawings if not more. Also, changing drawings might mean recertification, large ECOs, a lot of time invested and other added costs. Also, if it's a component which is made by several mfgs and often one of them will run out of stock, you would have to rotate the drawings often. Or you could reuse the MPN for another manufacturer and create "your" part with IPN the same as the original MPN. But soon enough, this will make a lot of chaos - for example, should you use the part which has MPN of XYZ or its replacement with IPN of XYZ next time you manufacture the product containing that part? The third option is to always have IPN for a part and have one or more mfgs and their MPNs assigned to it. Which is what we do. I'm not saying that these real-world observations shall apply to Inventree. The message is - we tried using MPNs as a reference and it has always caused trouble. |
Beta Was this translation helpful? Give feedback.
-
|
@MR-DOS thanks for your insights into this, that is super useful since I'm just coming at this from producing a few boards in my spare time. Could you shed a bit more light on how you actually manage your IPN and MPN mappings, when you say:
When and where do the MPNs get assigned to the various components? Is that mapping stored separately from the schematic or within the CAD files? I am wondering, since you say:
whether you would consider adding the MPN and Supplier Part number to the fields associated with components in the schematic as "changing the drawing"? I'm asking these questions because my current thinking is to have a small app that reads the schematic, including IPN for all components from the schematic (i.e. the Should I later want to do a production run with a different manufacturer parts (e.g. because some are out of stock) I can re-run the above app. I then assign a different component where required and commit this and generate a new BOM and placement file. The reason for storing this inside the schematic is that I can then use all the existing tooling (e.g. KiBot and the tools it uses) to generate a BOM and placement file using the MPN and the Supplier Part number. I have just done a prototype run using JLCPCB assembly service using a very early stage of the above, where KiBot runs as a GitHub action to produce all the relevant files from the KiCad project. This certainly works for me, but I'm wondering if this would scale and work for "quite large real-world company making electronics" :) Which perhaps isn't really necessary at this stage, but having a good ponder about how to do this right is probably still worthwhile. |
Beta Was this translation helpful? Give feedback.
-
|
Hi, we have our internal part numbers for each component we use. That's "just a random string" which indicates whether it's an external or internal part (manufactured by us or some other company), which category of component it is and whether it's SMD component or not - but this doesn't have any importance in this case. Then, each of these internal parts has several "sourcers" - we don't divide if it's a manufacturer or supplier since we also buy directly from manufacturers. However, I should warn that we don't use Inventree, but Helios (since our company is decades older than Inventree :-) ) and for electronics we use Altium so there might be some differences in implementation. The mapping is stored in our inventory system which is Helios in our case. There, we have an "inventory item" for the part and its mapping to suppliers. Also, we have another "database item" which connects the "inventory item", library item name (this is where Altium gets the name of the part to be created in database), filename of schematic symbol file, filename of footprint (this matches the files to the part in CAD library), prefix (U for ICs, Q for crystals etc.) and optionally other things like filename of SPICE model, port mapping between SPICE model and schematic symbol (needed for in-CAD simulations), alternative footprints, part parameters (max. voltage, max. current etc.) and so on. The manufacturers/suppliers cannot be seen from the CAD part - these things are handled in the inventory system and schematic only references the internal part number. So, if you want new mfg, you just add it to the "inventory item" (part in Inventree) - no need to change drawings since no change happened to them - IPN did not change, MPN did, but that's handled by the inventory system. Sure - there has to be some check, so if the new component is different, you have to check if it's a suitable replacement for all designs concerned (to automate this, there would have to be a system to specify required parameters of components in a schematic which is unlikely to ever happen as that would require deep analysis and a lot of effort which would likely be orders of magnitude larger than checking it manually even in a large company). In my view - MPN should never be a part of schematic / BOM exported from CAD. MPNs should always be handled by Inventree, not KiCAD. KiCAD should only see IPNs. For practical use, the MPNs should be all interchangeable (or the definition of the component has to match the worst of these MPNs) and you should use whatever you have in stock (given it's state is OK). If they are not, they shall have separate IPNs.
For example - we have our own assembly lines. Imagine you have PCB with large and tall components as well as tiny ones. The operator of assembly line has to make "assembly program" which tells the line what to do and in which order. If you do it the MPN way and automate the drawing changes, there is a risk of the line going out of sync with the production files (for example you may buy a tape where the SMD components are rotated by 90°). So they have to check each time they make a new batch if there has been a change in the production files and remake the assembly program. Also - will you make a new Inventree part for each new version of drawing just because you changed MPN? If not and you just replace drawings/BOMs, you lose documentation for older versions, at least in the inventory system which requires that you also have some other system set up for tracking documentation in case of an audit. If you just change it in Inventree (MPN on an IPN), Inventree is able of tracking batches and what is made out of what. |
Beta Was this translation helpful? Give feedback.
-
|
For information: There also are parallel actions on KiCAD side to integrate REST API access into KiCAD: |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, he is an active contributor here too ;-) |
Beta Was this translation helpful? Give feedback.
-
|
Hey everyone, a quick update! The HTTP library support has now been accepted and merged into the KiCad nightly builds! Very exciting, and congratulations to @afkiwers for his efforts to get this across the line. There is now also an InvenTree plugin which Andre and I have been working on over the last few days. Check out the documentation there - it is very easy to use and provides seamless integration of InvenTree data into your KiCad library. This has been a very long time coming, and I am super excited that it is finally here! Please do check out the plugin, and raise any issues over there. Note that you'll need to be running KiCad nightly builds until the next release on their end :) |
Beta Was this translation helpful? Give feedback.
-
|
Very exciting, congrats!! 🥳 |
Beta Was this translation helpful? Give feedback.
-
|
It's gonna get better even. There will be some sort of push data back to InvenTree functionality. Well TBD. 😉 |
Beta Was this translation helpful? Give feedback.
-
As discussed in the recent KiCad development blog, version 7 of KiCad will support external databases for component libraries.
Given that (for a lot of people) InvenTree is already integrated with their EE workflow (BOMs etc), perhaps there is a way of storing raw part data in InvenTree itself, for a very tight integration between these two pieces of OSS.
Ref: https://docs.kicad.org/master/en/eeschema/eeschema.html#database_libraries
Beta Was this translation helpful? Give feedback.
All reactions