Well, it does work, but such functions do have their limits. There are also multiple different ways to do so, depending on the situation. One way is to drag a footprint with the d key while tracks are attached, but this does not work well with parts with many connections or rotated parts such as your uC. It also does not work well in cramped area’s. But if there is some room and the parts are simple (such as resistors), then it works quite well.
Another method is with PCB Editor / Route / Interactive Router Settings. But you have to put the interactive router into the Shove mode, and in your project it was set to the Highlight Collisions mode, and then shoving does not work.
KiCad development is a bit chaotic, which is common with Open Source projects. There are many useful functions, but they do not all work very well or in each combination. Over the last few years all the “big gaps” have been ironed out, but there are 1000+ open feature requests (and bugs) listed on github, and there is only a limited amount of hours available for all KiCad developers. Lots of functions get improved over time, but some functions also get left behind a bit because the amount of developer hours is such a scarce resource for KiCad. But overall KiCad is still the best EDA suite I have ever worked with, and it is improving rapidly each year.
sorry. I think we are talking about different things. I’m only talking about moving tracks. I can move single track without disconnecting them. But I want to move more than one track together - without it disconnecting them. If more than one track is selected, it always cuts them up. No matter how the interactive autorouter is set.
That’s why I created a small record.
Does everyone now understand what my question is?
No, or maybe yes. It’s the same thing, but you are mixing up different functions. The Shove mode works only when dragging things or while creating new tracks. It does not work when moving items (or a selection of items) I see @00:58 that Shove mode was on, but you did not use it. Try grabbing a single track in the middle of the bundle and then just drag it to the side, or do it with a via.
For the bigger picture, I have completely changed the way I do routing in KiCad. I just start with making connections (The f key for finish while routing is another nice speedup) first, and then later I just shove things aside to make a bundle of them, or shove things apart to make room for an extra track or via.
It works and I hadn’t understood it the whole time. Thanks. However, this changes the distances between the tracks. Some of them also change abruptly. It remains to be seen whether this really brings an advantage in the end.
Kicad has a big problem. There are too many possibilities but hardly any of them are thought through to the end. It would be better if there were fewer options that could be better used.
It seems that different people are programming the schematics and layout editor and not talking to each other. A standardized operating concept is needed here. The schematics sometimes offer better options for the same things. Although it has improved with version 8, it would be better to put a stop to features and subject everything to a concept. Otherwise the programmers won’t be able to keep up.
Kicad has grown quickly. Perhaps too quickly. Now is the time to tidy things up. You can also see this in the Footprint Editor. Some footprints are missing the 3D model. The path is there but does not exist or is wrong. These are certainly all clinical issues, but all in all they are always annoying. That’s why things should be tidied up before new things are added. I don’t think anyone has anything against tidying up first.
Thank you for your help. I hope that KiCad will go the right way. I hope it never becomes as opaque and buggy as Altium. I hope so.
Yes, Ideally KiCad should only have just a single menu button which always does what the user wants.
To be more realistic. Refactoring is taking place. Sometimes even big things such as the complete file format overhaul introduced in KiCad V6, and with it both all used symbols and footprints are embedded in the project. A lot of things have good or historical reasons for why they are as they are as explained by eelik in the link posted by jmk.
I know you mean well, but I have followed KiCad development for several years (being a forum moderator, issue database janitor and having contributed a couple of lines of code) and it’s apparent you don’t know how KiCad development works. The code is being refactored slowly, the UI and UX has been made internally consistent slowly, quite much has already been done to make KiCad consistent between different parts. Usability is important for the core developers. The KiCad codebase or architecture isn’t falling apart.
Of course there are things which could be made better. But the developers plan ahead, know what they are doing and don’t allow contributions which would rot the code base or the UI. You can have your opinions about details, so do I, and I don’t always agree with the decisions. But in general the project is going forward in all areas. The problem is – always and in all respects – that the resources are limited and must be spread over several needs, plans, features, bugfixes etc.
Actually some commercial projects have more of the problems you mention. The development is in the end driven by commercial interests and the resources are put where the money is. There are two possible paths: either the code and UX continue rotting slowly and becoming more and more difficult to manage, or it is rewritten from scratch. KiCad has managed to take the superior path, slow but steady refactoring and enhancement, taking the needs of the end users and the developers into consideration.
The horizontally marked segments should remain on the Y axis. Then I try to move only the 45° segments to the right. In doing so, it moves the horizontal segments downwards. Exactly what it should not do.
The function has to be modified. I don’t think anyone wants it like this. You would have more rework as it helps. Don’t be angry with me, but it doesn’t work like this.
The important thing for you to learn is to stop worrying about trivial details. You fist set up the net classes to proper track widths and clearances, and after that you just connect the tracks. It simply does not matter at all whether the horizontal tracks move or not. If you don’t like their position, then you can move them afterwards. You probably have to move them again in an hour, tomorrow or nest week because you then decide to put some via’s or resistors in between those tracks.
Another thing that would help is if you would stop blaming KiCad for your own lack of knowledge / experience of how to work with it. Instead, just accept the way it works, and figure out how you can use KiCad’s features to your advantage, instead of fighting it.
For me this dragging track feature is also hard to use. After drag one track I have to drag all others.
I have to set minimum clearance to 0.18 as my main controller has 0.4mm raster and 0.22mm pads. As it is main IC even I would try to have its nets in special class to have bigger clearance for the rest these rest would be may be 20% of tracks.
But when routing I prefer to have bigger distance between tracks (taking in mind crosstalk for example) so I keep this distance manually. Then if I have to drag one track the distance decreases so I have to manually drag all the rest.
Why this cares. For example you have TXD and RXD lines in paralel but they go under shield and have to be filtered at shield border. I place capacitors out of shield, but as close to border as possible (I don’t use through shield capacitors) and then inside shield resistors also just near shield border as possible. Resistors are to decrease disturbance re emission inside shield.
So inside shield you have TXD line strongly driven by controller and next to it RXD line that is driven by resistor (practically you have many output and input lines mixed).
When I was searching information about crosstalk I found that practical solution is to have tracks distance 3x track width.
I think I can’t stop worrying about trivial detail of track distance at their way. At the end they have to be at 0.18mm from one to another but I push them away from each other as fast as I can.
@Piotr I agree that it’s a good idea to make clearances wider if there is room to reduce capacitive coupling. I’ve been experimenting a bit with custom rules to do this.
First, I created a simple rule area and gave it the name “narrow1” and nchecked all basic rules.
And on itself this works. I can now set a narrow clearance to be able to reach the pads, and the track segments that intersect the rule area do get a wider clearance.
But in practice, it does not really work. This rule area interferes with the interactive router. As you can see from the screenshot, it says there is a DRC violation, but if I force that location with [Ctrl], and then do a DRC check, there is no violation. On itself, the concept is useful enough to try to make it work but I am encountering too many difficulties with it at the moment.
Maybe I should report this on gitlab, but I have very little experience with custom rules.
You can also make a custom rule to modify the clearance when you are inside the courtyard of a particular IC. These custom rules are quite powerful things (Assuming you can make them work as intended).
Also, in your example:
You can use here 0.18mm tracks and 0.22mm clearance (Sum is also 0.4mm) if you use a custom rule to reduce the clearance inside the couryard. This prevents the pads from thowing clearance violations, while still being able to increase the clearance for the tracks a bit.
I didn’t tried to use any custom rule yet.
I think that it is mainly useful when you have complicated PCB or when someone else sets the rules and someone else designs. Specially when someone else makes schematic he can know there are some requirements that PCB router (person) can not know.
As my projects are simple and schematics are done by me I have all signals in my head. When routing each track I know if its state changes once a day or if it is up to 50MHz SPI bus.
anyone who answers arrogantly has to deal with a headwind. But it’s interesting that you first complain but then realize how stupid that is. If the operation becomes too complicated, it won’t be used. You are faster manually.
And such arrogant answers are even more pointless. The point is to make a program more usable. Many people just don’t understand that because everyone thinks of themselves in the same way.
Stop your arrogant answers and we can talk to each other normally.
I could answer if I will understand you. Be more clearly, please.
On what I complained?
What I realized is stupid?
I’m not sure what you mean as for me your sentence (thanks to word ‘but’) looks like speaking about two opposite reactions then complaining and seeing something being stupid are not one to opposite the other but rather the same side reactions but with different level.
You were kind to omit from the quote your statement to which this was a reaction. If you use word ‘stupid’ describing KiCad actions (I even don’t know what exactly so stupid KiCad did) then for me (and I believe not only for me) you express your opinion about KiCad developers as a whole as most KiCad actions are not the result of chance, but of a concerted decision.
Of course bug happens, but in such case instead of using word stupid it would be better to help and report that bug.
So if you came here to insult people who created something as good as KiCad in their spare time, wouldn’t it be better to exercise your right not to use it instead of expressing your upset about the stupid behavior of the program?
There is no less true or more true. Something is true or not true. Is there anything not true in my sentence?
However, this changes the distances between the tracks. Some of them also change abruptly. It remains to be seen whether this really brings an advantage in the end.
