Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failure on really huge schematics #19

Closed
bsdphk opened this issue Apr 18, 2022 · 2 comments
Closed

Failure on really huge schematics #19

bsdphk opened this issue Apr 18, 2022 · 2 comments
Assignees
Labels
bug Something isn't working

Comments

@bsdphk
Copy link

bsdphk commented Apr 18, 2022

I'm working with some really huge multi-page schematics for a retro-computing project (https://datamuseum.dk/wiki/Rational/R1000s400/2022_Project_Status) , and kiauto often fails because KiCad takes too long to load them.

In eeschema_do.py::wait_eeschema_start(), KI6_LOADING is passed as part of the other argument to wait_eeschema() and from there to wait_for_window(), where it raises ValueError instead of waiting for KiCad to gather its marbles.

I think that is a mistake ?

wait_for_window() has special handling of KI6_LOADING but that looks wrong as well, as it requires other to be a string argument, rather than a list argument ?

I'm not proposing a patch, because I have a hard time figuring out how what the intention/correct operation is in this case.

For me, removing KI6_LOADING from the argument to wait_eeschema() solves the problem.

@set-soft set-soft self-assigned this Apr 18, 2022
@set-soft
Copy link
Member

I'm working with some really huge multi-page schematics for a retro-computing project (https://datamuseum.dk/wiki/Rational/R1000s400/2022_Project_Status) , and kiauto often fails because KiCad takes too long to load them.

Is the schematic available?

In eeschema_do.py::wait_eeschema_start(), KI6_LOADING is passed as part of the other argument to wait_eeschema() and from there to wait_for_window(), where it raises ValueError instead of waiting for KiCad to gather its marbles.

I think that is a mistake ?

It gives another try to KiCad waiting 1 second before trying again. This gives KiCad 3 seconds to load the schematics. I never saw KiCad loading schematics for that long. Now I modified the code to wait upto 60 seconds.

wait_for_window() has special handling of KI6_LOADING but that looks wrong as well, as it requires other to be a string argument, rather than a list argument ?

Nope, it must be a list.

I'm not proposing a patch, because I have a hard time figuring out how what the intention/correct operation is in this case.

For me, removing KI6_LOADING from the argument to wait_eeschema() solves the problem.

Ok, then the new code should also work.

@set-soft set-soft added the bug Something isn't working label Apr 18, 2022
@bsdphk
Copy link
Author

bsdphk commented Apr 19, 2022

The schematics are in this repo: https://github.com/Datamuseum-DK/R1000.HwDoc

You must "make RebuildSymbols" at the top-level to produce the correct KiCad symbol file.

And yes, it is a very special case: 50 page schematics with a thousand chips is not how we build computers anymore :-)

I did a pull, and it seems to work.

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants