Sorry Jon, I don’t think the last part of your comment is very fair.
I also think is is not unreasonable that if you are specifying something it does what you say it does. If you bought a car, say, which stated it does 80mph on the motorway but you find it actually does 50 how would it make you feel? Then, when you highlight it to the manufacturer they just say “but it takes to the supermarket OK” and “I think you are complaining for the sake of complaining” - how would it make you feel?
You invite us the users to participate in KiCAD but when we comment on something you (the developers) don’t like, often you guys not only forcibly ‘shut the door’ on a poster but make a snidey comment.
This seems to be an increasing trend - It’s not nice and needs to stop.
If an importer performs correctly on thousands of components, but makes an error on one component, I wouldn’t consider the importer to be broken or not performing according to specification. There’s no specification saying that everything will be converted perfectly.
IMHO the importer should be considered to be a tool that helps the user, not a solution that does all the work. It’s still much easier to import and correct, than to redraw from scratch.
When one footprint among thousands is imported incorrectly, I would consider this a bug. Bugs should be reported and might eventually be fixed. They will however be prioritized and may not be fixed right away. Even if they are fixed right away, they will most likely not be included in the next release if that release is already in feature freeze.
Importers are usually based on reverse engineering samples as there is no published structure specification to use.
Then you get the mismatch of the different systems layer use, coordinated systems, etc etc to work around.
Look at how long Libreoffice has been trying to get an accurate import of a Word document
In general in the software realm “open” means high-fidelity and “import” means lower fidelity.
Specifically in KiCad, we consider a fidelity bug in “open” to be high priority (or even critical if some data is lost), and a fidelity bug in “import” to be medium or low priority (depending on prevalence).
M852 moved their discussion (and I’m using that word generously) of Altium importer to this thread. If a moderator stops by, I think all the posts since m852 started posting in this thread could be moved back to tthe original Altium thread.
Where in the KiCad “specification” does it say that KiCad can import Altium boards perfectly with no errors, guaranteed?
I don’t take issue with anyone pointing out problems with the Altium importer. What I take issue with is:
People expecting that an Altium importer can’t be present in KiCad unless it is perfect
People vaguely pointing out (or ranting about) issues instead of reporting specific bugs on GitLab
People expecting a stable release to be delayed until the Altium importer is perfect (???)
If you think I’m being overly snide or harsh to m852, I suggest taking a look through their post history and see how people keep trying to explain over and over again how KiCad development works and how they can be a useful participant, and they keep ignoring this information.
I’m not asking for an ideal importer, but just a working one … because how to find a component that the importer broke among 1000 others is either impossible or very difficult … if you declare this function, then it should work sanely, otherwise such a function is not needed … this function is very important to increase the number of users and to sculpt to sculpt there is a github for this…
I allow small bugs, for example, in fonts or in color … but sorry, when the program draws something that is not on your board, then this tool can be considered not working … which cannot be said about the reverse conversion …
Starting from version 7, I started using the importer and gross errors began to come out, but except for me, for several months this is unnecessary for message users 0 ) I conclude that it is not necessary, they do not use it
I’m loosing focus in this thread.
My topic has nothing to do with importers.
Note that M852 also started a thread on altium importer 3 weeks ago:
I’m tempted to delete this post, as it adds nothing here and I posted in the Schematic editor is very slow on large schematic thread before retiredfeline cleaned up that tread (many thanks). However I also dislke the “topic deleted” posts and I’ll leave it for “completeness”.
solid and others work fine with the step format, so the problem is solved there … this also applies to drawings in dwg format … altium and cost are a relative concept … I already lost more working time on the converter in this topic than altium costs … in my country, altium was generally banned for sale, I think you yourself know)))
It’s not solved at all, take a Solidworks file export to STEP and then import that to anything else . . . you then have a block that you can’t see design intent or how it was constructed, you can’t adjust any parametric values, etc, etc. That’s like saying Altium exports to Gerber so that problem is solved . . .
For finished parts, sure. For parts part way through design or development then no, if you have to change CAD system part way through design or development it’s better to start again re-drawing the part in the new CAD system.
How to import footprints from altium library free of charge? When specifying a footprint in the settings of libraries in the Altium format, the message “Access denied” constantly appears… How is the import done and what format should the footprint be in?
Footprint for example PCB - RESISTOR - CHIP - RES 0603_1608 RF.zip (569.6 KB)