[FEATURE] KiCad 7 support

[neilenns]

KiCad 7 is out. I gave it a whirl with KiBot and it didn't work (not surprised). Any plans to update and support KiCad 7?

[set-soft]

I'm working on it, but it has many bugs. I reported various before the release, like this one: 13841 But the maintainers delayed it for 7.0.1. So I guess 7.0.0 won't be supported. The problem is that they put a fixed release date "january 31", I wasn't ready, but they didn't want to move the date too far. IMHO this is a bad policy, release should be done when you they are ready, not at a fixed date.

I'll update the current status of bugs affecting KiBot:

• [X] pcbnew print not centered when using custom scale (prints outside the page)
  • Prevents the use of scaled PCB prints (pdf_pcb_print and svg_pcb_print).
• [X] [Python] new PLOT_CONTROLLER.SetPlotOnAllLayersSelection member doesn't work as the dialog option (does nothing).
  • Prevents the frame/title print for the all the outputs using the plot interface (dxf, gerber, pdf, svg, ps, pcb_print, etc.)
• [x] [Python] CONNECTIVITY_DATA.GetNetItems arguments are no longer usable [7.0.0 and 7.99].
  • We can't check the PCB/SCH parity (update_xml preflight).
  • Can be fixed by Fix the CONNECTIVITY_DATA::GetNetItems Python API
• [x] KiCad 7 Python DRC problems with lib_footprint_issues check (incomplete initialization for this new test)
  • All footprint lib parity checks (new on v7) fails for KiCad standard libs
  • Can be fixed by Load the global fp-lib-table before running the Python DRC

Non-critical:

• [x] gerbers rounding errors (KiCad 7)
  • Works, but when looking at the gerbers you'll see ridiculous coordinates, like 139999999
  • Can be fixed by Fix rounding errors in gerber files

Other tools:

• KiKit
  • [x] Stencil 3D is broken (missing stuff in pcbnewTransition) Patched in the forked repo (v1.3.0-4).
  • [x] Stencil for jig is broken (use of float where integers are needed) Patched in the forked repo (v1.3.0-4).
  • [x] Plugin is broken (interferes with KiAuto and hangs KiCad v6 on exit) Patched in the forked repo (v1.3.0-4).

[neilenns]

Thanks for the update. I agree, fixed release dates are dumb now that software comes via download link instead of physical media.

[KenwoodFox]

I heard that v7 actually had a couple things builtin that iirc, kibot does the manual way, like renders and exports. Might be anecdotal but was curious.

[set-soft]

Hi @KenwoodFox !

KiCad 7 adds kicad-cli something really good because years ago the maintainers refused the idea of having a command line interface. I guess they now allowed it because this is implemented in a separated binary.

It implements some things that KiAuto does, and in fact KiAuto 2.2.0 is using some of them.

Currently rendering isn't available, the best thing available is schematic plot. It handles footprint and symbol stuff, I'm not sure what exactly does, but doesn't seem to be usable for KiBot.

For the schematic it can generate the netlist, and KiAuto 2.2.0 is using it (for both: KiCad native and XML netlists). As I mentioned the schematic can be plotted in PDF and SVG formats, and KiAuto takes advantage of it. But only if you plot all the pages. Note that 'ps', 'dxf' and 'hpgl' aren't supported yet.

For the PCB it can generate the drill and some of the plot formats. But in this case this is supported by the Python API, so we don't need it. Also: not all options are implemented. Can also generate the position files, but this is something we manually do, and I think is better to do inside KiBot to allow for more control of the output.

The kicad2step tool is now part of kicad-cli, so KiAuto also uses it for STEP file generation.

I hope more stuff is available in the future, in particular render will be really nice. But there are a lot of things that KiAuto does that aren't implemented yet.

[mundodisco8]

Keeping an eye on the update to KiCad7. I guess the CLI will make some things easier, right?

I can't imagine how much work you need to put everything back in order, the only thing I can do is just thank you for your effort!

[mdeweerd]

@set-soft Thanks for your update on this. The KiCAD team is pushing towards using version 7 as they are not maintaining version 6, and when reporting an issue for version 6 we have to validate it with version 7... .

Anyway, I'll be updated about posts to this issue so if there is a docker image with version 7 that I can test, I'll go ahead - the current nightly is too old vs. the 7.0.0 file format apparently.

[set-soft]

Keeping an eye on the update to KiCad7. I guess the CLI will make some things easier, right?

As I mentioned before it helps a bit. Plotting the schematic in PDF now is fast.

But the really interesting stuff will most probably be implemented in 8.0 (i.e. 3D View, DRC/ERC, etc.).

[set-soft]

Hi @mdeweerd !

Anyway, I'll be updated about posts to this issue so if there is a docker image with version 7 that I can test,

I'll try to create a 7.0.0 package using current git code and the CONNECTIVITY_DATA.GetNetItems patch. So I can create a nigthly image. Note that this will be a 6.0.11+7.0.0 image. This means you'll need to define KIAUS_USE_NIGHTLY=7.0 before invoking KiBot so it uses 7.0.0.

Just KiCad

with stable KiBot

with deb and all the heavy tools

All tagged as nightly. Not yet tested, will try to test them tomorrow. Really experimental.

[set-soft]

Ok, the nightly images now are good enough to pass the regression tests.

As today they contain the 2 patches that are waiting for approval.

[mdeweerd]

Thanks for the update - No success yet running kicad 7 - I get kicad 6.

I think that the extra pcbnew_path should be prepended to the path list in the next line. While changing it you might want to use os.pathsep instead of the explicit ':'. https://github.com/INTI-CMNB/KiBot/blob/master/kibot/__main__.py#L97

I have the following in my docker

docker run --rm -it -v /tmp/.X11-unix:/tmp/.X11-unix -e DISPLAY=host.docker.internal:0.0 -v 'D:\User\KiCAD\STAR:/root/workdir' --env NO_AT_BRIDGE=1 --workdir=/root '--volume=D:\User\KiCAD\kibot/.cache/kicad:/root/.cache/kicad:rw' setsoft/kicad_auto:nightly /bin/bash -c 'cd workdir/. ; kibot --version ; export KIAUS_USE_NIGHTLY=7.0 ; kibot <restoftheoptions>'

I saw that kiauto also uses it, so I am going to check that next.

[mdeweerd]

In KiBot's main.py just after the if setting nightly to True, I added

logger.error(f"{os.environ.get('KIAUS_USE_NIGHTLY')} {os.environ['PYTHONPATH']} {nightly}")

I get:

ERROR:7.0 /usr/lib/kicad-nightly/lib/python3/dist-packages True (kibot - __main__.py:102)
DEBUG:KiBot 1.6.0 verbose level: 1 (kibot - __main__.py:309)
DEBUG:Detected KiCad v6.0.11 (6.0.11+dfsg-1~bpo11+1 6000011) (kibot - __main__.py:199)

So KIAUS_USE_NIGHTLY is propagated correctly, but it's still KiCAD v6.0 that is detected.

Using:

nightly: Pulling from setsoft/kicad_auto
Digest: sha256:54a0ba914c6463a4760f63233c9660cac04e7995c8b69e916865890a171ccd5e
Status: Image is up to date for setsoft/kicad_auto:nightly

[mdeweerd]

I think I found what is causing this.

In kibot/__main__.py the line from . import dep_downloader loads GS which loads pcbnew and it was imported before PYTHONPATH was updated.

However, then we run into the following mismatch:

  File "/usr/lib/python3/dist-packages/kibot/gs.py", line 93, in GS
    kikit_units_to_kicad = {'mm': pcbnew.IU_PER_MM, 'cm': 10*pcbnew.IU_PER_MM, 'dm': 100*pcbne
w.IU_PER_MM,
AttributeError: module 'pcbnew' has no attribute 'IU_PER_MM'

[set-soft]

Hi @mdeweerd !

Take a look at the regression tests: https://github.com/INTI-CMNB/KiBot/suites/11194728904/artifacts/572273828

They are detecting KiCad 7.

The problem is that you are trying to use the stable 1.6.0 version, you must use the current dev version, which logs:

DEBUG:KiBot 1.6.1 verbose level: 1 (kibot - __main__.py:308)
DEBUG:Detected KiCad v7.0.0 ((7.0.0-111-g673d06d498-dirty)-fork+24a63eb304+deb11 7000000) (kibot - __main__.py:198)

[set-soft]

The images are "nightly", not "nightly"+"dev". So you should do a repo checkout and run the dev branch code. Just like the CI/CD is doing.

I generated a dev_k7 image: docker pull ghcr.io/inti-cmnb/kicad_auto_test:dev_k7

[mdeweerd]

@set-soft Thank you for the hints.

I modified my setup to use the dev version of Kibot in the image I was using and that works better ...

DEBUG:ERC report: /root/workdir/STAR_11_20230219_star/STAR_11_20230220-erc_star.txt (kibot.pre_run_erc - pre_run_erc.py:55)
- Running the ERC
DEBUG:Executing: /usr/bin/eeschema_do -r -v run_erc -o /root/workdir/STAR_11_20230219_star/STAR_11_20230220-erc_star.txt -w -f /root/workdir/STAR_11_20230219_star/kibot_errors.filter /root/workdir/STAR.kicad_sch /root/workdir/STAR_11_20230219_star/ (kibot - kiplot.py:182)
DEBUG:Failed with error 1, retrying ... (kibot - kiplot.py:192)
ERROR:Time-out waiting for eeschema, giving up (eeschema_do - eeschema_do:199) (kibot - kiplot.py:131)
DEBUG:Output from command:
> INFO:Loaded 37 error filters from `/root/workdir/STAR_11_20230219_star/kibot_errors.filter`
> INFO:Waiting for "Main eeschema window" ...
> INFO:Waiting for "Main eeschema window" ...
> INFO:Waiting for "Main eeschema window" ...
[...]

The info "> INFO:Waiting for "Main eeschema window" is because when "retrying" it detects the schematic is already open - possibly not closed on the first try. The video of the first try is overwritten. I had to set "retry = 1" in the code to see that this was a timeout issue - I defined kiauto_time_out_scale to 4.

It turns out that even if the ERC violations are computed, there still is a TimeOut. (And I see that I am getting "off grid" violations that were not reported on Windows' KiCAD 7.0.0).

DEBUG:Output from command:
> WARNING:Missing KiCad main config file /root/.config/kicad/7.0/kicad_common.json (eeschema_do - misc.py:198)
> INFO:Loaded 37 error filters from `/root/workdir/STAR_11_20230219_star/kibot_errors.filter`
> INFO:Waiting for "Main eeschema window" ...
> INFO:Waiting for "Main eeschema window" ...
> INFO:Open Tools->Electrical Rules Checker
> INFO:Waiting for "Electrical Rules Checker dialog" ...
> INFO:Run ERC
> INFO:Open the save dialog
> INFO:Waiting for "ERC File save dialog" ...
> Traceback (most recent call last):
>   File "/usr/bin/eeschema_do", line 893, in <module>
>     eeschema_run_erc_schematic(cfg)
>   File "/usr/bin/eeschema_do", line 473, in eeschema_run_erc_schematic
>     eeschema_run_erc_schematic_6_0_n(cfg)
>   File "/usr/bin/eeschema_do", line 429, in eeschema_run_erc_schematic_6_0_n
>     wait_for_window('ERC File save dialog', 'Save Report to File')
>   File "/usr/lib/python3/dist-packages/kiauto/ui_automation.py", line 410, in wait_for_window
>     raise RuntimeError('Timed out waiting for %s window' % name)
> RuntimeError: Timed out waiting for ERC File save dialog window
>  (kibot - kiplot.py:197)
WARNING:(W054) Time out detected, on slow machines or complex projects try: (kibot - kiplot.py:199)
WARNING:(W054) `kiauto_time_out_scale` and/or `kiauto_wait_start` global options (kibot - kiplot.py:200)
ERROR:ERC returned 1 (kibot.pre_run_erc - pre_run_erc.py:72)

[set-soft]

Hi @mdeweerd

I modified my setup to use the dev version of Kibot in the image I was using and that works better ...

I added a dev version of the images (docker pull ghcr.io/inti-cmnb/kicad_auto_test:dev_k7)

About the time-out: Is the time-out generated because the ERC is taking too long? (783 violations) Or the ERC finishes and KiAuto is unable to detect it?

About the out-of grid: Is this a correct ERC warning? I mean: are the drawings out-of grid? 0.635 mm looks strange. Or is that KiCad isn't interpreting your grid correctly?

[mdeweerd]

I added a dev version of the images (docker pull ghcr.io/inti-cmnb/kicad_auto_test:dev_k7)

Thank upi, it will surely be easier to manage ;-) .

About the time-out: Is the time-out generated because the ERC is taking too long? (783 violations) Or the ERC finishes and KiAuto is unable to detect it?

According to the video the ERC is finished in less than 5 seconds and the image does not change anymore until the end of the video which is at 42s .

About the out-of grid: Is this a correct ERC warning? I mean: are the drawings out-of grid? 0.635 mm looks strange. Or is that KiCad isn't interpreting your grid correctly?

When running on windows I have a grid of 0.635 mm and inside the docker container it is 1.27mm . 0.635mm is proposed as one of the standard grids. When running interactively with kicad from the container and changing the grid to 0.635mm it is fine. KiCAD is verifying against the grid selected in the UI which does not seem to be saved in the .kicad_sch file. I think I selected 0.635mm a long while ago (KiCAD 5). I am "fixing" the placements - a simple move is not enough (wires not connected to components are not always aligned with the components).

[mdeweerd]

I fixed all the off grid warnings, and then the ERC check was "stuck" like this:

I then disabled the rules that resulted in the 3 errors, and the popup shown below disappears after 4/5 seconds:

And this still resulted in a timeout:

> INFO:Waiting for "ERC File save dialog" ...
> Traceback (most recent call last):
>   File "/usr/bin/eeschema_do", line 893, in <module>
>     eeschema_run_erc_schematic(cfg)
>   File "/usr/bin/eeschema_do", line 473, in eeschema_run_erc_schematic
>     eeschema_run_erc_schematic_6_0_n(cfg)
>   File "/usr/bin/eeschema_do", line 429, in eeschema_run_erc_schematic_6_0_n
>     wait_for_window('ERC File save dialog', 'Save Report to File')
>   File "/usr/lib/python3/dist-packages/kiauto/ui_automation.py", line 410, in wait_for_window
>     raise RuntimeError('Timed out waiting for %s window' % name)
> RuntimeError: Timed out waiting for ERC File save dialog window
>  (kibot - kiplot.py:197)
WARNING:(W054) Time out detected, on slow machines or complex projects try: (kibot - kiplot.py:199)
WARNING:(W054) `kiauto_time_out_scale` and/or `kiauto_wait_start` global options (kibot - kiplot.py:200)

At that point I found that a lot of containers were still running, so I deleted all of them and ran again.

The ogv file then showed that the erc step timed out with this :

When running kicad interactively (from the container) on an X-Server, I can execute the ERC and click on the "Save" button.

[set-soft]

(And I see that I am getting "off grid" violations that were not reported on Windows' KiCAD 7.0.0).

Tomorrow I'll commit a patch allowing to indicate the grid to use for ERC. This is a big limitation in 7.0 that won't be fixed until 8.0 (Jon Evans scheduled it for 8.0 with priority medium).

The ogv file then showed that the erc step timed out with this :

Try to use the maximum debug info and look for the interposer log. ERC is passing in CI/CD without any problem. So we must see what is failing in the interposer dialog at your system.

[mdeweerd]

Thanks for following up.

Regarding the "off grid" errors, I modified the schematic to adjust all the placements.

Try to use the maximum debug info

I suppose that this is more than just the "-v" option but I could only see debug options for the panelize target.

This is the log I had with -v - and the target directory only has kibot_errors.filter + the ogv file.

kibot.zip

What option should I add for more output?

[set-soft]

Thanks for following up.

Regarding the "off grid" errors, I modified the schematic to adjust all the placements.

I saw it, but it won't be the first time people hits this problem.

Try to use the maximum debug info

I suppose that this is more than just the "-v" option but I could only see debug options for the panelize target.

KiBot supports upto "-vvvv". You can add more vs but they won't help.

This is the log I had with -v - and the target directory only has kibot_errors.filter + the ogv file.

kibot.zip

What option should I add for more output?

Use level 4, you'll get a much bigger log.

[mdeweerd]

KiBot supports upto "-vvvv". This was not clear for me from the documentation - maybe you want to add something.

I think one or more changes to KiAuto/KiBot fixed the issue. Prior to updating my local copies (whic were up to date a few days back), the run failed. Then I tried the dev_k7 image, which reported 12 ERC issues (which is good), and then I updated my local copies of kibot/kiauto and that then worked as well EDIT: I still get the time out doing that.

For completeness, here are the logs when it failed, but IMHO the issue is fixed.

kibot_vvvv.zip

I'll now exclude some ERC errors and try to complete the full flow.

[mdeweerd]

I am surprised about the ERC warnings (dev_k7):

• I think I updated symbols to match the 7.0.0 version - at least my Windows Version does not complain;
• I am sure that I "unsexified" the connectors for KiCAD 7 - but I get Symbol 'Conn_01x08_Pin' not found in symbol library 'Connector' (before that was called Conn_01x08_Male) .

After adding the exceptions for the ERC messages, all files were generated, so I now checking those.

[set-soft]

KiBot supports upto "-vvvv". This was not clear for me from the documentation - maybe you want to add something.

I think one or more changes to KiAuto/KiBot fixed the issue. Prior to updating my local copies (whic were up to date a few days back), the run failed. Then I tried the dev_k7 image, which reported 12 ERC issues (which is good), and then I updated my local copies of kibot/kiauto ~and that then worked as well~ EDIT: I still get the time out doing that.

For completeness, here are the logs when it failed, but IMHO the issue is fixed.

kibot_vvvv.zip

I'll now exclude some ERC errors and try to complete the full flow.

For some reason you are not using the interposer. Not using the interposer is prone to time-out errors, it can be a slow system, overloaded, big projects, etc. The question is why you don't get interposer.

• Make sure that KIAUTO_INTERPOSER_DISABLE isn't defined.

The other conditions should be ok for a docker image:

    interposer_lib = os.path.abspath(os.path.join(os.path.dirname(__file__), 'interposer', 'libinterposer.so'))
    if (not os.path.isfile(interposer_lib) or  # The lib isn't there
       args.disable_interposer or              # The user disabled it
       os.environ.get('KIAUTO_INTERPOSER_DISABLE') or  # The user disabled it using the environment
       platform.system() != 'Linux' or 'x86_64' not in platform.platform()):  # Not Linux 64 bits x86
        interposer_lib = None
    else:
        os.environ['LD_PRELOAD'] = interposer_lib
        logger.debug('** Using interposer: '+interposer_lib)

[set-soft]

I am surprised about the ERC warnings (dev_k7):

The new ERC/DRC tests are tricky.

• I think I updated symbols to match the 7.0.0 version - at least my Windows Version does not complain;

The problem here is that KiBot is using your config for a regular KiCad:

KICAD7_SYMBOL_DIR = "/usr/share/kicad/symbols"

But this is a nightly build, so the 7.0 symbols are at /usr/share/kicad-nightly/symbols. With your current settings KiCad is comparing to the 6.0 symbols.

• I am sure that I "unsexified" the connectors for KiCAD 7 - but I get Symbol 'Conn_01x08_Pin' not found in symbol library 'Connector' (before that was called Conn_01x08_Male) .

Most probably the same problem

[mdeweerd]

interposer_lib = os.path.abspath(os.path.join(os.path.dirname(file), 'interposer', 'libinterposer.so'))

I do not see a particular reason why this is not detected inside the docker image, so Ill try to find out more.

Observations:

• I have a clone under windows (/cygwin) of kiauto - that I map into the docker image.
• I find an interposer directory there with the so file for x86-64;
• That is where interposer.py is looking according to the code - so it should be ok inside the docker image as well.

[mdeweerd]

Good news: kibot succeeded in generating the output files. So great job of adjusting kibot to Kicad 7.

My diff output for the PCB is not useable (comparing between KiCAD 6 version and KiCAD 7 version) - there is an offset between the PCBs - while I did make adjustments and am checking the TearDrops, I did not move the PCB.

Yet the diff output shows a shift on the X-Axis.

The symbol issues are also gone by settting the KICAD7_SYMBOL_DIR environment variable.

I ran into some issues with KiCAD 7 - not related to KiBot itself. I get DRC errors for "too narrow" zone fils and track widths that are 0.249999mm according to the DRC on some diagonal tracks that are exactly 0.25 mm, but I only get them in windows, not with the nightly.

[mdeweerd]

I just noticed that the STEP output of my design has a virtual component, while I have the no_virtual: true argument - this was not the case with the previous version.

If I need to set up a test case for this, let me know.

[set-soft]

Good news: kibot succeeded in generating the output files. So great job of adjusting kibot to Kicad 7.

:-)

My diff output for the PCB is not useable (comparing between KiCAD 6 version and KiCAD 7 version) - there is an offset between the PCBs - while I did make adjustments and am checking the TearDrops, I did not move the PCB.

Yet the diff output shows a shift on the X-Axis.

I saw various differences. Some of them were fixed. Make sure to reset any diff cache.

The symbol issues are also gone by settting the KICAD7_SYMBOL_DIR environment variable.

I ran into some issues with KiCAD 7 - not related to KiBot itself. I get DRC errors for "too narrow" zone fils and track widths that are 0.249999mm according to the DRC on some diagonal tracks that are exactly 0.25 mm, but I only get them in windows, not with the nightly.

I submitted a patch today to fix gerber issues with rounding. If you can narrow the problem may be we can find the problem.

With the gerber was "simple", KiCad switched from using integers for the internal units to floating point, but some code still using integers, so converting double -> int -> double generates small problems for some numbers

[set-soft]

I just noticed that the STEP output of my design has a virtual component, while I have the no_virtual: true argument - this was not the case with the previous version.

If I need to set up a test case for this, let me know.

Yes, please create a test case so I can see if this is KiBot's fault

[mdeweerd]

If you can narrow the problem may be we can find the problem

I submitted https://gitlab.com/kicad/code/kicad/-/issues/14131 and https://gitlab.com/kicad/code/kicad/-/issues/14130 .

[mdeweerd]

I saw various differences. Some of them were fixed. Make sure to reset any diff cache.

I cleared the cache (and it got filled with new cache files) - the X-offset persists. I checked the PDF files - there is an offset between the outputs of the two versions.

EDIT: the SCH comparison is ok, the issue is only with the PCB comparison.

[mdeweerd]

If you can narrow the problem may be we can find the problem

I submitted https://gitlab.com/kicad/code/kicad/-/issues/14131 and https://gitlab.com/kicad/code/kicad/-/issues/14130 .

And already fixed ...

[set-soft]

I checked the PDF files - there is an offset between the outputs of the two versions.

From the image you sent it looks too big. In my tests the differences are smaller. Can you try to find a small example?

[mdeweerd]

Can you try to find a small example?

I'll work on a test case for the differences and also for the virtual component (which I think is likely a KiCAD bug - https://gitlab.com/kicad/code/kicad/-/issues/14125 .

[set-soft]

I'll work on a test case for the differences and also for the virtual component (which I think is likely a KiCAD bug - https://gitlab.com/kicad/code/kicad/-/issues/14125 .

The DNP falg is too fuzzy, this is why I opened a discussion so we determine the best way to handle it in KiBot

[mdeweerd]

I got a test case for the step output issue:

The output will be in tc7_01_20211224_header/STEP/tc7_01_20211224-3D_header.step (...tc6...tc6... when generating using kicad6).

You can see by the size of the step file if the virtual component is included or not - the step file is either bigger or smaller than 1MB.

The virtual component is the programmer connector you can see here:

git clone -b STEP_VIRTUALOTHER_ISSUE git@github.com:mdeweerd/kibot-testcases.git
cd kibot-testcases
docker compose run --rm dev_k7
# To generate fom kicad 6 design files with kicad_6:
docker compose run --rm dev_k6

[KenwoodFox]

I got a test case for the step output issue:

The output will be in tc7_01_20211224_header/STEP/tc7_01_20211224-3D_header.step (...tc6...tc6... when generating using kicad6).

You can see by the size of the step file if the virtual component is included or not - the step file is either bigger or smaller than 1MB.

The virtual component is the programmer connector you can see here:

git clone -b STEP_VIRTUALOTHER_ISSUE git@github.com:mdeweerd/kibot-testcases.git
cd kibot-testcases
docker compose run --rm dev_k7
# To generate fom kicad 6 design files with kicad_6:
docker compose run --rm dev_k6

Sidenote I didn't even know there was a tag connect 3D model, that's cool!

[mdeweerd]

I didn't even know there was a tag connect 3D model, that's cool!

;-)

While that is not a model I made, I sometimes make some using openscad converted by freecad. I shared some models for pogopins (only a few are validated against physical ones).

My offer to @set-soft still stands - I can create a 3D Model of 16x02 LCD Screen with a custom text.

[mdeweerd]

I checked the PDF files - there is an offset between the outputs of the two versions.

From the image you sent it looks too big. In my tests the differences are smaller. Can you try to find a small example?

It may have to do with the size of the board or - the "small" testcase does not show the issue...

[set-soft]

I checked the PDF files - there is an offset between the outputs of the two versions.

From the image you sent it looks too big. In my tests the differences are smaller. Can you try to find a small example?

It may have to do with the size of the board or - the "small" testcase does not show the issue...

In INTI-CMNB/KiDiff#4 we see the problem is when changing the size of the board. In this case the diff isn't easy to understand.

[set-soft]

The virtual component is the programmer connector you can see here:

Next time please also include a simple config, it isn't obvious what options are really used.

This is a KiCad v7 behavior. In order to make the component virtual you must select "Exclude from bill of materials"

If you select it the component goes away. You can just try:

kicad-cli pcb export step --no-virtual --subst-models  tc7.kicad_pcb

On my system I used:

KICAD6_3DMODEL_DIR=/usr/share/kicad/3dmodels/ kicad-cli-nightly pcb export step --no-virtual --subst-models  tc7.kicad_pcb

I don't understands why you don't just use variants for this. You have more control.

[mdeweerd]

I don't understands why you don't just use variants for this.

I want to enable/disable the 3D components that are virtual in the interactive 3D view.

IMHO "Virtual" has been replaced with "Other":

Just that change makes the component part of the "virtual" group in the 3D view - where it is now no longer called "Virtual", but "Unspecified" type - but still toggled using the "V":

[set-soft]

IMHO "Virtual" has been replaced with "Other":

Not really. KiCad 6 changed the concept of virtual components. 'Unspecified' doesn't mean virtual.

When KiCad 5 files with virtual components were imported by KiCad 6 it marked them as "Exclude from pos file" and "Exclude from BoM". The unespecified means just what the word means: the flag for SMD is 0 and the flag for THT is 0. KiCad 5 was a value 0, 1 or 2 (THT, SMD, Virtual). In v6 they are flags, you can have a component that is both SMD (bit 0) and THT (bit 1) (I mean in memory, not that the GUI allows it). So for v6+ unspecified is "(attributes & 3) == 0", not virtual.

I'm not sure if the KiCad 7 behavior for the STEP is on purpose or just a bug.

[set-soft]

Looking at the v7 code:

The current flag is "Exclude from BoM"

    step->m_includeExcludedBom = !m_argParser.get<bool>( ARG_NO_VIRTUAL );

    EXPORTER_STEP_PARAMS params;
    params.m_includeExcludedBom = aStepJob->m_includeExcludedBom;

But in v6 the kicad2step tool used "unespecified":

        if( !m_smd && !m_tht )
            m_virtual = true;

[set-soft]

I sent an e-mail to Mark Roszko, author of kicad-cli, lets see if he can clarify the intention of this change in behavior.

[mdeweerd]

@set-soft Thank you for identifying this change in the KiCAD code & asking the developer.

I had been preparing a message but let's see what the feedback is first.

[set-soft]

Thank you for identifying this change in the KiCAD code & asking the developer.

I didn't get a reply yet. But I found a bug report: https://gitlab.com/kicad/code/kicad/-/issues/14125

And I added some clarification because Jeff Young didn't realize all the problems.

[set-soft]

Hi @mdeweerd !

I checked the PDF files - there is an offset between the outputs of the two versions.

I moved this issue to KiDiff: https://github.com/INTI-CMNB/KiDiff/issues/4

Now the code checks the bounding box of the PCBs. If they are different we use the whole page (not scaled). Otherwise we use the automatic scale.

So now you shouldn't see the offset. The KiDiff 2.4.5 implements it.

[mdeweerd]

So now you shouldn't see the offset. The KiDiff 2.4.5 implements it.

👍 - I already tried to test it. I am waiting for ghcr.io/inti-cmnb/kicad_auto_test:dev_k7 to be up to date (there is no urgency to update it - I'll check from time to time).

(I checked the ticket on KiCAD - for now I will be "the user").