Strange behavior in push and shove

Hi to group

I have a 8 perallel lines diagonal lines 45 degrees in one pcb top left to down right direction . If i grab the top right line and move down-left i can drag all lines and all work fine . If i grab the the lower left line and drag top-right program refuses to move all lines . No obstable exist in both directions . Any ideas what is going on ?

It is KiCad V8 unfortunately. KiCad V6 and V7 were much better at shoving multiple tracks. I’m guessing that some errors slipped into the push 'n shove algorithm

Please create a bug report in KiCad issue tracker. If you can attach a minimal example demonstrating the issue, it would let us fix it quicker.

Best,
T.

2 Likes

I will not create a bug report myself for this right now, as I want to verify behavior in the nightlies first before doing so, and I can’t run these at the moment.

I also discovered it pretty late, as I do not design many “real” PCB’s. It’s barely enough to keep familiar with KiCad to be able to answer forum questions. But to me, the downgrade in behavior is so evident that I would be really surprised if this has not been reported before.

@paulvdh I was not asking you to create a bug report. Why do you need to hijack almost every thread on this forum?

@mixkef I’m in the process of fixing a lot of issues in ther outer. A copy of your board would be really, really helpful. Most of P&S issues are quite subtle and difficult to reproduce without having the affected PCB file.

T.

1 Like

Hi

We are a small firm with experience in many eda programs

I hope i can be of help .
No need to make something special .Please go to gitub and download this project
GitHub - martinribelotta/h730duino: STM32H7 Arduino form factor and software compatible board

It’s not my project but i checked it there just to be sure it’s not my pcb that creates the problems
Go in bottom layer and try to move this group of tracks . Check the diagonal lines . Get first line from left in group Up right shove always has an issue . But bottom left is fine .

Best regards

MK

1 Like

Thanks, it looks like it works just fine in my dev branch (which is good news, as the patches there will reach master soon).

T.

2 Likes

to be fair to paul . . .

. . . you did post this directly under @paulvdh 's post rather than replying specifically to @mixkef so it looked very much like you were replying to paul

2 Likes

HI,

That’s good news to hear . Sorry for my asking but some features are really important to have
1.please have a file format that we can export import that can be used in all editions. What if something
goes wrong in next edition .Access to file from previous editions is blocked so that’s a dead end.
Some plugins also don’t work with latest editions .Even if all goes wrong someone can find solution
2. It would be invaluable to have a "find similar " option .Similar pads , similar vias etc …The idea i have found in
Altium and Easyeda has adopted it successfully .
I stop here . Too many things come in mind
Kicad is very productive and i’m surprised by the quality of graphics which is much better than multi k USD programs .
Keep up the good work .

BR

MK

KiCad has a mayor release schedule once a year, and this seems to settle on early February, a bit before FOSDEM A few months before that there is (at east sort of) a feature stop, and focus for (at least some) of the developers is more on stability. But every mayor release there is a very noticeable increase in minor bugs along with the new features. Lots of people start using the new KiCad version, which means a lot more eyes to discover bugs, and the first few minor releases (updates in the 3rd digit) fixes those. But if you’re a company and your productivity depends on KiCad, then it’s generally recommended to wait a few moths to half a year before adopting a new mayor KiCad version.

I like some form of future compatibility in KiCad, but as of yet there is none. KiCad is still a relatively small project, with 1000+ new features waiting to be implemented, and limited available time for the developers. The project can’t do it all at once. But for regular users, future compatibility is not such a big deal. If there really is a mayor bug that crashes KiCad, it’s going to be fixed really quickly.

I see two use cases for forward compatibility. One is casual collaboration with “others”. They have to be on the same mayor version, and if you work with projects from sites like github & gitlab, then you pretty much have to use the latest stable, or you’ll quite often bump into a project from a future version.

The other use case is for testing. At the moment I am not very much interested in working with the nightlies, because I am guaranteed I can not open a project from the nightlies in a stable version. So if the nightlies break, I can not resort to a stable version and continue on a project until the nightly is fixed. I once had a project that got sidelined for several months because of this (that was in the KiCad V3 or V4 days, and the project was not terribly important). I guess that if KiCad has future compatibility, a lot more testing would be done on the nightlies.

Another subject:

From your screenshot:
image

Do not make long rows of vias like that. It is bad for signal integrity to make such big cutouts in the GND plane. Spread the via’s around a bit so the GND plane can connect to itself in between the via’s is much better. You can also use PCB Editor / Tools / Remove unused pads to remove the pads on internal layers, which allows both for more GND fill, or for extra tracks on internal layers (For example in between DIP IC’s).

I don’t know who did it, but someone flagged this post as “off topic”.
I edited it to get it back.

I guess I missed the remark of:

But it’s still relevant to other reading this topic, as long as the original screenshot is posted.

@twl I was wondering whether it was directed at me, and would not have posted if you had replied directly to mixkef here.

As for the hijacking, I often do not restrict myself to the direct subject of the current topic. I believe it has added value, both for OP and for others reading the topic later to see ideas and variants of solutions. I do not consider these “hijacks”. Quite often it lets people think about a part of KiCad they had not thought off yet, or simply did not know about. Recently I dropped a link to SKiDL in a post where it was only partially related, and got a positive reaction back of someone who never considered use of SKiDL before. And like the row of vias though the GND plane. Sure it’s off topic, but relevant to OP’s project, and it’s a reminder for others reading this thread later.

And for people searching the forum later and looking for “quick fixes”, there is the system where posts can be marked as “The Solution” and they can skip all the side stuff.

If people want to respond to this, and it goes out of hand, it’s easy to split this off into a separate thread. Am I deviating too much from forum threads?

2 Likes

In my opinion: Not.
and some not needed by anyone (except forum software) chars…

1 Like

Seems that this thread is solved and now sufficiently diverging

3 Likes