You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Compare output .xlsx lines
row42 & row49 - R1, R2, R26, R27 against R10, R14. The only difference is 100k vs 100K.
row50 & row52 - R11, R15 against R18. The difference is 10K vs 10k
There are two of us working on the design. We have slightly different styles for entering data. This will continue to happen.
Is there a reason for making Value case sensitive? Much of the industry (and many Windows users) assume upper and lower case represent the same values. A PCB vendor's automation [PcbFabExpress] balked at these as "Identical Entries". And there is the issue of "order time" with these "identical parts" existing on two separate lines. With these use cases in mind, it might make more sense to combine both cases as the same part.
Please consider treating, or at least giving the option to treat, the value field as case-insensitive, so the parts will be combined in KiCost .xlsx output.
Issue / Problem report
kicost --version KiCost v1.1.18
Write the command used to call KiCost (or the graphical interface configuration); kicost -w -i "bom.xml" --eda kicad
One BoM to reproduce the error (with the EDA version).
The text was updated successfully, but these errors were encountered:
I think you are right, KiCost shouldn't make "100K" and "100k" different.
The above patch solves the issue. But IMHO the problem is much deeper. What about 100k vs 100 k? And about 0.1 uF vs 100 nF. Higher level tools, like KiBot can handle it.
Compare output .xlsx lines
row42 & row49 - R1, R2, R26, R27 against R10, R14. The only difference is 100k vs 100K.
row50 & row52 - R11, R15 against R18. The difference is 10K vs 10k
There are two of us working on the design. We have slightly different styles for entering data. This will continue to happen.
Is there a reason for making Value case sensitive? Much of the industry (and many Windows users) assume upper and lower case represent the same values. A PCB vendor's automation [PcbFabExpress] balked at these as "Identical Entries". And there is the issue of "order time" with these "identical parts" existing on two separate lines. With these use cases in mind, it might make more sense to combine both cases as the same part.
Please consider treating, or at least giving the option to treat, the value field as case-insensitive, so the parts will be combined in KiCost .xlsx output.
Issue / Problem report
kicost --version
KiCost v1.1.18
Write the command used to call KiCost (or the graphical interface configuration);
kicost -w -i "bom.xml" --eda kicad
One BoM to reproduce the error (with the EDA version).
The text was updated successfully, but these errors were encountered: