Report Generation - Discussion

[mdeweerd]

I just had a go at the report generation.

Before going onto expressing some critics, this is overall great and the list of data provided is more that I expected.

Regarding the templates: at some point you showed results with schematics, and PCB. Do you have a template in progress to start from?

My board size is 123.50x70.60mm and it's reported as 40.38x95.89 mm (1.59x3.78 inches) .
I think there are two potential reasons for this:

1. I keep my board edges in a component (so that I can easily change them and share them between versions);
2. I have internal edges and the reported size seems to be the bounds of these internal edges. (I am sorry for doing "crazy" stuff, and part of it is now even patented).

I ran the report through pandoc:

• Not due to kibot, but may become helpful: Pandoc or my script did not like the original filename - either to long, or the '-' in the name. renaming to a.md before converting did the trick.
• Post generation action:
  • Generate the PDF from the markdown file.
    • The output filename being variable, I can't do it in the Makefile.
    • Because the generation runs in docker, and the md to pdf conversion is native, I have to do it in the makefile.
    • => How to get the filename of the generated output(s) to do it "outside" kibot?
    • Doing it in the docker instance would require to have pandoc installed there.

[set-soft]

I just had a go at the report generation.

Before going onto expressing some critics, this is overall great and the list of data provided is more that I expected.

:-)

Regarding the templates: at some point you showed results with schematics, and PCB. Do you have a template in progress to start from?

Take a look at the full report:

#?schematic_svgs
# Schematic
#?schematic_svgs

#?schematic_svgs
#schematic_svgs:![${comment}](${path}){ width=16.5cm height=11.7cm }${new_line}


#?layer_svgs
# PCB Layers
#?layer_svgs

#?layer_svgs
#layer_svgs:![${comment}](${path}){ width=16.5cm height=11.7cm }${new_line}

I know is cryptic, but it will collect all schematic and PCB layers generated in SVG format (from svg_pcb_print and svg_sch_print) and put them in the report.

Of course you can create a template that is more selective and adds only the SVGs you want (and in the order you want). But the default will generate a good enough report.

My board size is 123.50x70.60mm and it's reported as 40.38x95.89 mm (1.59x3.78 inches) . I think there are two potential reasons for this:

1. I keep my board edges in a component (so that I can easily change them and share them between versions);
2. I have internal edges and the reported size seems to be the bounds of these internal edges. (I am sorry for doing "crazy" stuff, and part of it is now even patented).

Interesting. Does this component have lines in the Edge.Cuts layer? Can you share a small PCB with such a component?
The code is looking at the board level, so yes edges in a component aren't detected. But adding it isn't complex, just a scan in the components list.

I ran the report through pandoc:

• Not due to kibot, but may become helpful: Pandoc or my script did not like the original filename - either to long, or the '-' in the name. renaming to a.md before converting did the trick.

Ok, but we currently don't call Pandoc, so I don't know how can we help here.

• Post generation action:

  • Generate the PDF from the markdown file.

    • The output filename being variable, I can't do it in the Makefile.

Why not? Makefiles can scan files, i.e. by their extension.

* Because the generation runs in docker, and the md to pdf conversion is native, I have to do it in the makefile.
* => How to get the filename of the generated output(s) to do it "outside" kibot?

Use a special extension, lets say .md, then process all .md files.

* Doing it in the docker instance would require to have pandoc installed there.

I'm tempted to create such an image. Not sure if it will be simple.

[set-soft]

I'm tempted to create such an image. Not sure if it will be simple.

And this is how the sea level risen 1 µm and a couple of insects got extint :-)))
Ok, I added pandoc (and some texlive goodies) to kicad_auto_test image.
I succesfully tried:

pandoc --from markdown --to pdf light_control-report.txt -o result.pdf

This is from the test_report_simple_1, I also generated the SVG targets (manually, not included in the test) and got a nice PDF.

[mdeweerd]

Thanks for adding this - I started updating a sample project but got interrupted by my son.

Regarding the report, I did select the "full" report but did not get any images in the report - I'll check differently.

I'll follow up here with a sample project.

[mdeweerd]

Here is a testcase with a component representing the board edges.

The design is in designs.
tc5.tar.gz

This is in a github repository .

The project yaml is in ./designs/tc5/tc5.kibot.yaml.
The included yaml is in ./yaml/common.kibot.yaml where I added a report target.

The report indicates:
Board size: 42.08x9.2 mm (1.66x0.36 inches)

The measured size is 59.230x26.550mm :

And you can see the holes in the boards, also in this 3D view::

[set-soft]

Regarding the report, I did select the "full" report but did not get any images in the report - I'll check differently.

Remmember that the template collects SVGs, not PDFs, this is related to the size + quality we already discussed.

[mdeweerd]

Remmember that the template collects SVGs,

I hoped so 😉 (and I know). I just get a report not referencing any image, so I need to check into that.

[set-soft]

The report indicates: Board size: 42.08x9.2 mm (1.66x0.36 inches)

The measured size is 59.230x26.550mm :

The last patch solves it.

[set-soft]

I hoped so (and I know). I just get a report not referencing any image, so I need to check into that.

Now you can play with the test_report_simple_2 test. It generates a PDF.

[mdeweerd]

• Board size: ok on actual PCB design as well 👍

• Eurocircuits class: NOK. The actual class of my board is 4A, I get 10B.

  My vias are: 1.0/0.5 mm (39/20 mils) - so OAR is (1.0-0.5)=0.25 and drill is A class because this is a PTH. But "Outer Annular Ring" is reported as Outer Annular Ring: 0.0 mm (0 mils).

The Eurocircuits class for the test case above also needs some tweaking.

I uploaded this :
PCB.zip
And got this report:

I'll be playing more with the report generation as soon as I can.

[set-soft]

• Eurocircuits class: NOK. The actual class of my board is 4A, I get 10B.
  My vias are: 1.0/0.5 mm (39/20 mils) - so OAR is (1.0-0.5)=0.25 and drill is A class because this is a PTH. But "Outer Annular Ring" is reported as Outer Annular Ring: 0.0 mm (0 mils).

I need a test case. May be you have some pad that has 0 copper, is all drilled, and it generates the problem.
BTW: You could post the full report, it contains a lot of information that could help to understand why OAR was computed as 0. A quick look at the code suggests this is a problem with a via.

[mdeweerd]

I am going to check the reason behind the classification differences.

A suggestion:

• Propose option(s) to set the target class and generate warnings or errors for items (or the first item) that violate(s) this target.

[mdeweerd]

I added the last line in the following code in out_report.py:

        # Drill class
        self.drill_class_min = get_drill_class(self.via_drill_min)
        self.drill_class = get_drill_class(self.via_drill)
        self.drill_class_d = get_drill_class(self.via_drill_d)
        logger.debug("Drill class: %s:%s %s:%s %s:%s", self.via_drill_min, self.drill_class_min, self.via_drill, self.drill_class, self.via_drill_d, self.drill_class_d)

Which resulted in:

DEBUG:Drill class: -1:F -1:F 500000:B (kibot - out_report.py

The reports indicates "3F" and Eurocircuits validates the board as 3A .
I suppose that 500000 translates to 0.5 mm, but that is not the tool size for a PTH. The tool size for a PTH is the finished hole + 0.10mm.

This explains the classification as determined by KiBot of the board I examined.

For another board I got "Drill class: 500000:B 500000:B 500000:B " and it is validated by Eurocircuits as a class A as well. (KiBot says it's a 10B board, and its a 4A board).

[set-soft]

The tool size for a PTH is the finished hole + 0.10mm.

I'm not sure about it. In KiCad you specify the size of the tool, not the size of the hole. KiCad generates drill files using the size you selected. Are you implying that the manufacturer will add 0.1 mm to all the tools in the drill file?

The rest: too much words, no example, I can't do anything.

[mdeweerd]

For the second board I checked, the TC-2030 footprint I got has some "rounding" differences: 0.991 vs 0.996 for instance. After fixing those, I got:

Pattern class min: 0 200000 400000 -> 10 (kibot - out_report.py:539)
Pattern class: 250000 200000 400000 -> 4 (kibot - out_report.py:541)
Pattern class d: 0 200000 400000 -> 4 (kibot - out_report.py:543)

through the log messages I added like this:

        # Pattern class
        self.pattern_class_min = get_pattern_class(self.track_min, self.clearance, self.oar_min)
        logger.debug("Pattern class min: %s %s %s -> %s", self.track_min, self.clearance, self.oar_min, self.pattern_class_min)
        self.pattern_class = get_pattern_class(self.track, self.clearance, self.oar)
        logger.debug("Pattern class: %s %s %s -> %s", self.track, self.clearance, self.oar, self.pattern_class)
        self.pattern_class_d = get_pattern_class(self.track_d, self.clearance, self.oar_d)
        logger.debug("Pattern class d: %s %s %s -> %s", self.track_d, self.clearance, self.oar_d, self.pattern_class)
`` 

And the report mentionned "4B" for the class, so the "4" is correct after fixing the footprint, the "B" has to be "A" for reasons mentionned before.

[set-soft]

I'm not sure about it. In KiCad you specify the size of the tool, not the size of the hole. KiCad generates drill files using the size you selected. Are you implying that the manufacturer will add 0.1 mm to all the tools in the drill file?

Are you sure the manufacturer will change it? If don't then adding 0.1 mm is not a good idea.

[mdeweerd]

For a plated via, the hole specified is the final diameter. To make the plated hole, the manufacturer drills it with a +0.10mm tool, then plates it with copper.

So for the plated holes, the manufacturer has to drill bigger, for the non plated holes the specified drill applies.

[set-soft]

Ok, we are using Eurocircuits classification and Eurocircuits clearly does it. So now by default we assume the manufacturer will add 0.1 mm to all plated drills.

I'm adding a global option extra_pth_drill, it defaults to 0.1 mm, but anybody can change it to 0 mm or wherever the manufacturer uses.

This changed some stuff in the logic, so now the _1 members doesn't exist and we have _real members. The real members are drill values taking the above difference.

[mdeweerd]

Got closer to the target: 10A ;-). 👍

Small typo for 'meassured' in out_report.py

        self.drill_class = get_drill_class(self.drill_real, 'meassured')

lines above that , and apprently "Patter " is missing an 'n' according to the log:

Eurocircuits Patter class for `minimum` is 10 because the clearance is 0.2, track is 0.0 and OAR is 0.0 (kibot - out_report.py:66)
Eurocircuits Patter class for `meassured` is 10 because the clearance is 0.2, track is 0.25 and OAR is 0.0 (kibot - out_report.py:66)
Eurocircuits Patter class for `defined` is 10 because the clearance is 0.2, track is 0.0 and OAR is 0.0 (kibot - out_report.py:66)

Now I have to find where OAR 0 is coming from (and track 0.0?):

# Important sizes

Clearance: 0.2 mm (8 mils)

Track width: 0.25 mm (10 mils)

- By design rules: 0.0 mm (0 mils)

Drill: 0.6 mm (24 mils)

- Vias: 0.6 mm (24 mils) [Design: 0.6 mm (24 mils)]
- Pads: 0.9 mm (35 mils)
- The above values are real drill sizes, they add 0.1 mm (4 mils) to plated holes (PTH)

Via: 1.0/0.5 mm (39/20 mils)

- By design rules: 1.0/0.5 mm (39/20 mils)
- Micro via: no [0.25/0.1 mm (10/4 mils)]
- Burried/blind via: no

Outer Annular Ring: 0.0 mm (0 mils)

- By design rules: 0.0 mm (0 mils)

Eurocircuits class: 10A

Edit:
Actually, I thought that I had the correct pattern class yesterday.

Edit2:
The reported class should not depend on the design rules IMHO.

Edit3:
I forgot I reverted my design to the committed version, updated the TC-2030 footprints again, and the class is 4A ;-) 👍 .

[set-soft]

Edit2: The reported class should not depend on the design rules IMHO.

You have 3 classes:

1. The one you specify in the design rules
2. The one measured on the actual PCB
3. The minimum between the both above

So 1 and 3 must depend on the design rules. The reports uses 2.

Edit3: I forgot I reverted my design to the committed version, updated the TC-2030 footprints again, and the class is 4A ;-) +1 .

Ok. What produced it? I think we should add a warning

[mdeweerd]

@set-soft Here is a test case - it's basically https://github.com/mdeweerd/kibot-testcases/blob/main/designs/tc5/tc5.pretty/TC5.kicad_mod causing that.

tc5.tar.gz

[set-soft]

@mdeweerd, looking at Eurocircuits again I think we are computing the OAR wrongly. The OAR must be computed using the TOOL_SIZE, not the Finished size. Their drawing is confusing because they use an example where both are the same, but the text (and common sense) says you must use the TOOL_SIZE.

[set-soft]

Ok now we will know the faulty pads.

[mdeweerd]

https://www.eurocircuits.com/faq/annular-ring-oar-iar/
https://www.eurocircuits.com/oar-outer-annular-ring/

I agree that the drawing is very misleading, the text on the first link is clear.

Here they indicate that PHD is the same as Toolsize (I guess the drawing was not made by a PhD 😃 ).
https://www.eurocircuits.com/phd-production-hole-diameter/

I did not want to mention it, but rounding also comes in play - https://www.eurocircuits.com/pcb-design-guidelines/drilled-holes/ .
So I try to round values in my footprints.

[set-soft]

Here they indicate that PHD is the same as Toolsize (I guess the drawing was not made by a PhD smiley ).
https://www.eurocircuits.com/phd-production-hole-diameter/

:-)

I added the rounding stuff. Also added a mechanism to list the real drill tools needed for the board, and the oval holes.

[set-soft]

A suggestion:

• Propose option(s) to set the target class and generate warnings or errors for items (or the first item) that violate(s) this target.

I added an option to specify the target and a warning that explains why we are failing