Now it’s getting confusing.
KiCad coordinates do not change on the fly.
KiCad libraries are carefully maintained for each pin to fit on a 50mil grid.
The screenshot posted by MuratUrsavas suggests some kind of scaling issue. Not only for the pin locations, but for all graphics. Have a look at capacitor C49, which is missing one of the plates.
Because of the screenshot size of1795x1066 I strongly suspect this scaling issue is related to HiDpi settings. Murat also used a very small grid.
Murat apparently has this issue with V5.99 while Jim has this with the stable KiCad, but nobody posted complete version info.
@Jim_HiTek:
Can you first: Eeschema / View / Grid settings and set the grid to “50 mil” and then make a screenshot and post it here?
Do you also use HiDpi settings?
If you do, do the problems go away when using 1:1 scaling?
Okay, thanks for the help…KiCAD was on 50 mil grid and I changed it to 10 mil so everything is back to normal now. I think. Seems to be anyway. My help files seem to have disappeared or weren’t ever installed so I couldn’t find how to adjust the grid. Thanks! Now I know.
I don’t see anyway to write ‘SOLVED’ on this thread…atm anyway.
You don’t necessary need to use the same grid as others. The only real restriction is that you can not use a grid larger than what your symbols are designed for. Symbols in the official lib use 50 mil for their pins. Which means if you ever want to use one of them then you should use 50 mil or smaller.
In KiCad V5.1.8 and earlier there was no snap to pin function whatsoever for aligning wires to schematic symbols and connections were completely dependent on perfect alignment of endpoints, and a tradition grew to never use a grid smaller then “50 mil”.
If you’re used to working on a “10 mil” grid it’s probably still doable, but when you change the grid to “1 mil” it will get really hard to connect wires to pins.
I assume this was Jim’s issue: Using a “10 mil” grid for some time and then having the grid default to “50 mil” after an update.
MuratUrsavas has a completely different issue with the scaling.
I cannot recall how I ended up with a 10 mil grid. I generally try to use industry defaults. Let’s just caulk this up to some sort of weird alien mind control.
I did create a 3 digit 8-segment LED module and to get the fine appearance I was looking for I may have set the grid to 10 mils but that was in the library. I don’t recall setting the schematic where I used it to that but perhaps…
Hi
You might consider upgrading, KiCad has Ubuntu PPA with newest versions.
I used procedure as standard Ubuntu repository does not have latest version.
Have found designing symbol in my case start with pins on 50mil and then switching to various grids for design features and then switch back to 50mil and save symbol. If using 10 mil the same would follow and switch to 10mil and save.
Man this thread is a mess. @MuratUrsavas in the future please make your own topics about issues that you see. Especially as you are a user of nightlies and most users are typically using stable.
@Rene_Poschl, I wouldn’t add my issue at here if I knew this was a completely different problem than OP’s. At first it was looking like the same, but turned out different later, this is why.
Yes, this thread has become a big mess. Sometimes it happens, part of human nature I guess.
Therefore its also a bit unfortunately that you posted on gitlab:
The most precious resource of the KiCad project are the developers, while “ordinary” users are plentiful. I think there are over 6000 users on this forum alone.
A sentence like “I don’t want toe get int uninportant details as …” does not add anything to a bug report. In a clean bug report it’s better to just state your observations (such as the missing fractions).
If you really want to help (which I believe you do, It’s already a small percentage of users that bother to make a bug report) then you can help more by:
Creating a new thread for this, as it is a separate issue from Jim’s.
Revert to a previous version from your git repository.
Do the conversion to V5.99 again.
Try to figure out where the conversion goes wrong, which coordinates get lost.
Update the gitlab report with any info you find.
Add a screenshot to gitlab that makes your issue clear. The gitlab bug report should have all the important information you have and links should only be to circumstantial findings or some background info.
If you can put in half an hour to narrow it down so a developer saves 10 minutes in analyzing your info then it’s a win.
Have written many explanations lines why I did this, but erased all of them. Because you look from a very narrow window. You just assume that everything was known from the beginning.
I’m gonna delete all of my posts in this thread and make it clean like it should be.
Already done that. My posts and its references were not helping to OP’s case anyway. Also removed the bug report reference, improved the explanation like you’ve suggested. The re-conversion result can be found in the bug report, which was posted earlier than your message.
