This is indeed very helpful information! Thank you very much for sharing. I will fix this issue as you suggest, just ignoring the TRUNK (and TRUNKREF) entries for the time being.
I will do this after feature freeze though (i.e. after 30th September), since I’m dedicating as much of my spare time as possible at completing the CADSTAR schematic importer before feature freeze. I only have a few days left but hopefully should be able to complete it in time so that it can be a feature of KiCad v6. Progress so far can be seen here: https://gitlab.com/kicad/code/kicad/-/merge_requests/410
The schematic importer was now merged into the master branch. This should trickle into nightly builds over the next few days. Thanks a lot to @craftyjon for spending the time to do the final review before merging!
Please report any import issues you find in this post.
I am also working on a Project importer similar to that found in the Eagle importer.
Why not combine the extensions filter in schematic import dialog? I.e. instead of forcing user to select the right file type just display all supported ones.
I am a fairly new C++ programmer and I wouldn’t know immediately how to achieve this but I think it would require an architectural overhaul to do so. At present, the decision on which importer to run (e.g. EAGLE, PCAD, Altium or Cadstar importer) is based on which file type filter has been selected by the user.
Changing this interface requires thinking about some logic that determines which importer to run. Unfortunately checking for the file extension wouldn’t enough as several EDAs share file extensions (e.g. EAGLE file extension is same as KiCad old file extension).
An extra layer would be required to read the file header and then determine which importer to run based on this. There is some work done on that already but more is required to cover all importers as well as the high level code that does the importer selection.
I think this can be considered in KiCad v7 though. If there isn’t one already, would you be able to create a wishlist item in gitlab to track this request?
I was talking about much smaller scope change, let me clarify.
In the native file open dialog that pops up when you choose File->Import->Import Non KiCad Schematic...
This dropdown can be combined so that we don’t force the user to choose the extension beforehand.
In most programs there is 1 combo option that has filter for all supported formats and also separate options to filter each specific format for convenience. But the default is always the combo filter.
@qu1ck yes I understood the request however it isn’t as simple as it appears (at least not to me). At the moment the decision on which schematic or PCB importer to call is based on this file extension filter.
Making a “All supported formats” option requires adding logic for deciding which importer needs to run when the file is selected. EAGLE importer and also KiCad legacy importers both share the same file extension so reading of the file header would be required in order to determine which of the two to run. In my limited understanding, I believe this would require an architectural change so won’t make it for v6 since we are already on feature freeze.
One of the developers can correct me if I’m wrong - maybe there is an easier path to achieving the same result that might be acceptable for v6?
@qu1ck you are absolutely right! It seems I misunderstood what the code was doing when I first read it. I had thought it was using the file extension filter but as you rightly point out that dialog just returns a full path and not the filter that was used.
After looking at the code again in more detail, I found out that the logic for deciding which importer to run is based on the file extension alone, so yes, it should not be as difficult as I thought. I’ll work on something this weekend (not sure if it will get merged for v6 as not strictly a bug but we will see).
I wanted to also mention that a new layer mapping dialog was merged to master yesterday (see MR 443. This allows the user to map CADSTAR layers that do not have an obvious conversion to KiCad.
Examples of this are older versions of CADSTAR that just had “Non-electrical layer” type, so the only way to tell what the layer actually represented was via the name. The importer handles this via string matching but that doesn’t work in every case (e.g. non-English boards).
This new dialog allows the user to override the assumptions made by the importer.
@rrascher I’m in process of fixing the TRUNK import issues that you highlighted. I want to be able to process TRUNKREF segments as well. Would you be able to send a sample of what these look like, similar to the sample you sent for TRUNK?
Excellent! Thank you very much! I’m fixing a bunch of different bugs with the importer, so it will take a little time as I’m bundling all the fixes together.
@rrascher One other question, does your design have TRUNKREF elements inside VIA statements? In you example these elements are only inside CONN and JPT statements, but I am assuming they might also be inside VIA as well.
Also, do you know if these statements might be anywhere else other than within the NET statements?
Sorry for all these questions but unfortunately my CADSTAR license does not include Trunk routing so cannot do any testing and am relying on your knowledge.
@Qbort I do not have a CadStar license, nor did I ever design a layout with CadStar. The design I have is done by an external layout office. So sorry I can’t answer all your questions. However I have attached an
extract of the Cadstar ASCII design with all the occurrences of TRUNK and TRUNKREF. It is very big,
so I zipped it. I hope that will help you. trunkref.zip (184.6 KB)
