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.
@qu1ck That seems like an interesting idea.
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.
Similar to pcbnews import graphics dialog
1 Like
@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?
It’s a native dialog, IIRC it doesn’t even give you access to what filter user chose, it just returns a full file path.
Also I’m not sure why you bring up KiCad legacy format when we are talking about import non kicad schematic dialog.
I’ll take a look at the code later, I may be wrong but it seems to me things are much simpler in this specific case.
@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).
1 Like
Yeah, I think fileFilters here should just be extended with a combo option:
Merge request created: https://gitlab.com/kicad/code/kicad/-/merge_requests/446
I also did the import non-kicad board dialog.
It was a very simple fix indeed - thanks for the advice @qu1ck !
1 Like
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.
1 Like
@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?
Thank you!
1 Like
@Qbort I have attached a extract of a net which contains the TRUNKREF.
Hope that helps.
trunkref.txt (1.3 KB)
2 Likes
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.
Thanks.
@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)
1 Like
Excellent! Thank you very much for sending this through. It does seem that the elements are only within CONN and JPT statements so hopefully the fix I’ve developed will work.
I’m fixing a few other bugs with the importer and will be opening a merge request this weekend with a bunch of fixes. I’ll let you know once merged into master so you can test your design the latest nightly.
@rrascher Just a quick ping to let you know that the issues you reported should now hopefully be fixed in the latest windows nightly build version 18334 or later.
Could you try to import your board with all the TRUNK elements and report any issues you find?
Perfect, thanks. The design now imports without errors. However I tried to
import another design and on that I get the following error messages:
Unknown node ‘EXITS’ in ‘PADEXCEPTIION’. I’ve attached the screenshot.
KiCAD Version
Thank you for the report! I’ve opened a merge request to fix the issue you report: https://gitlab.com/kicad/code/kicad/-/merge_requests/492
Once merged it will be available in the following nightly build.
In the meantime, if you have time, for the designs that you did manage to open, could you do a visual comparison between Cadstar design viewer and the imported design in KiCad? I will be fixing a few issues I’ve already noticed but it would be good to have a second pair of eyes looking for more import errors 
Yes, I have the same problem !
Here the ASCII Cadstar Code
---------------------------------------------------------------
(PAD 2 (PT 10146000 10000000) PC855 TOP
- (ORIENT 180000)*
- (EXITS N E S W NE NW SE SW)*
- (PADIDENTIFIER “2”)*
-------------------------------------------------------------
it’s just the permission for how to trace get out of the pad, you could ignore it…*
Hi @MirkoB
Welcome to the forum!
I believe I fixed this in the last MR. Can you try downloading the very latest windows nightly build version 18516 or later and let me know if that works?
Also @rrascher could you try again with your design and check it works with the latest nightly build?
Thank you.
Qbort