Metric Grid Options in schematic diagrams

Bug #593955 reported by brummig
30
This bug affects 6 people
Affects Status Importance Assigned to Milestone
KiCad
Won't Fix
Wishlist
Unassigned

Bug Description

If one switches pcbnew or eeschema to metric, the grid size options are equivalent in size to user-friendly imperial options (such as 25 thousandths of an inch). The result is the list of grid sizes in metric is user-unfriendly (25 thousandths of an inch becomes 0.635mm, for example). This is particularly problematic in pcbnew, as this works with real engineering components. It should be possible to have user-friendly metric grid options, such as 1mm, 0.5mm, 0.1mm. Metric is the measurement system of choice for engineers in all but one advanced country, so kicad needs to make proper use of it.

If one makes this step, clearly a simple imperial/metric switch is inadequate, as sometimes one might want to switch between user-friendly imperial, and user-friendly metric, and sometimes one will want to keep the grid size but just have pcbnew/eeschema display it in alternative units. There are many ways to solve that, but perhaps the simplest is to replace the current two buttons with four - one pair for switching units ('metric units/imperial units'), and one for switching grids ('metric grids/imperial grids'). Alternatively one of the two existing buttons could be 'metric units/imperial units', and the other could be 'metric grids/imperial grids'.

Revision history for this message
nobody (nobody-users) wrote :

Logged In: NO

There is more and more components with "metric" dimensions, like connectors with 2,5 mm pitch and some SMT IC. It's very useful to have a metric grid.
And in the schematic there is simply no reason to keep that stone-age units.

Revision history for this message
Stephen Eaton (seaton) wrote :

Tested in current stable (2010-05-05) and the grid units requested are in pcbnew, however not in eeschema.

Is there really need for these to be in eeschema also?

marking as won't fix

Changed in kicad:
status: New → Won't Fix
Revision history for this message
Jonas Stein (news-g) wrote :

I think metric units are important in eeschema and should even be the main unit.

Reason: Eeschema units are required for printing and plotting to files.
The paper format is often in metric units.
Metric units make sense, if a special size for a block is required for the printed symbol.

Metric units will be the first choice if KiCad should be used together with other software.
I see that mil is still important for PCB, because it is wide spread. However using mil for a drawing gives no benefit.

I suggest to let the user select between mm and mil in order to stay compatible with old schematics.

Please review this ticket and reopen it. Thank you.

Revision history for this message
gb (fezzik) wrote :

Can we reopen this? By default trying to draw lines in the library editor snaps lines to the grid, while I can change the grid resolution my options are very uncomfortable like: 0.635 and 1.27 mm which makes the X/Y position at the bottom useless when trying to size things. ie it shows 2.54 instead of 3. This further complicates trying to modify imported(from eagle) components since they are all aligned based on metric system. These sizes DO matter when they are printed and compared to older drawings.

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

The short answer is no. Eeschema uses 1 mil as it's internal units for coordinates which will not convert to an integer metric coordinate potentially causing wire and pin misalignment which would break schematics. At some point in the future, we are going to create a new schematic and symbol library file format which may allow for this. Pcbnew currently uses nanometers internally which solves this problem nicely. Using nanometers for schematics makes no sense so some thought must be given to ensure converting between metric and imperial units doesn't break the schematic. There was a proposal to use unitless coordinates which would solve the problem but there has been a lot of disagreement so that probably wont happen. At some point it will probably be resolve but not anytime soon.

Revision history for this message
Victor (lantcoder) wrote :

Please make a metric grid and possibility to switch between inches and millimeters. "Preferences" - "General Options" - "Measurement units" - switch between mils and millimeters. We will make our own symbol libraries (with metric coords of pins) and do not use libraries with mils coordinates anywhere. Ten years peoples ask for metric units! There's a so complicate to make a standard ISU units in millimeters?

Victor (lantcoder)
summary: - Metric Grid Options
+ Metric Grid Options in schematic diagrams
Revision history for this message
Eldar Khayrullin (eldar) wrote :

@Wayne,
Why simple to say assume 50mils it is 1mm. Use 1mil as internal unit. All conversion from mm to mils and vice versa do apply that 50mils it is 1mm.
Then pre-printing/plotting if selected 'Units in mm' then print/plot 50mils as 1mm.
In GUI show
100mils - 2mm
50mils - 1mm
25mils - 0.5mm
and ...
I have the same situation that Victor.

tags: added: eeschema metric
Revision history for this message
Wayne Stambaugh (stambaughw) wrote : Re: [Bug 593955] Re: Metric Grid Options in schematic diagrams

@Eldar, the original bug report made no mention of printing or plotting
but rather the actual dimensions used for editing library symbols and
schematics which is a far more difficult problem to solve (please see my
previous comment). I would reject any patch that blindly converted
100mils to 2mm. I am going to look into the possibility of using metric
internal units in the new schematic and symbol library file formats but
that still is an incomplete solution. Even if we implement wire to pin
snapping in Eeschema to handle mixing metric and imperial symbols, I'm
pretty sure this would result in an undesirable schematic. There is no
way it's going to get resolved with the current file formats which are
imperial (0.001") and design of Eeschema which uses integers of 0.001
(where 1000 = 0.001) to ensure pin to wire connections. There is also
the question as to what to do with the huge number of existing symbols
and schematics.

On 1/8/2018 1:12 PM, Eldar Khayrullin wrote:
> @Wayne,
> Why simple to say assume 50mils it is 1mm. Use 1mil as internal unit. All conversion from mm to mils and vice versa do apply that 50mils it is 1mm.
> Then pre-printing/plotting if selected 'Units in mm' then print/plot 50mils as 1mm.
> In GUI show
> 100mils - 2mm
> 50mils - 1mm
> 25mils - 0.5mm
> and ...
> I have the same situation that Victor.
>
> ** Tags added: eeschema metric
>

Revision history for this message
Eldar Khayrullin (eldar) wrote :

@Wayne,
My solution don't change the file format.
People who use metric units don't see that internal units in mils.
Current Schematic symbols and created with my solution align in one grid (50 mils equal 1mm)-library symbols compatible.
Peole who use imperial units they continue to use it and nothing change for them.
My solution gives comfortable conditions for metric guys to draw in mm units and then print/plot result in mm.

Revision history for this message
Victor (lantcoder) wrote :

Wayne, maybe solution of this problem would be to create a new file format - just slighly changed, with new parameter stored (measurement units) in every file? Users who use existing libraries - use "old format" without measurement units determined. Users can store their files in both formats, old (without) and new (with determined measurement units), but new format is preferable. There will be two formats in use.

There is a sample file with circuit with three wires, without component

* * *

EESchema Schematic File Version 4
LIBS:test-cache
EELAYER 26 0
EELAYER END
$Descr A4 11693 8268
encoding utf-8
Sheet 1 1
Title ""
Date ""
Rev ""
Comp ""
Comment1 ""
Comment2 ""
Comment3 ""
Comment4 ""
$EndDescr
Wire Wire Line
 3650 3650 3650 3050
Wire Wire Line
 3650 3050 5300 3050
Wire Wire Line
 4850 3750 5700 3750
Wire Wire Line
 5700 3750 5700 3300
Connection ~ 5700 3750
Wire Wire Line
 5700 3750 5950 3750
$EndSCHEMATC

* * *

Changes of file format:

EESchema Schematic File Version 5 (next step)
EEUNITS [mil/mm] (new parameter)

That's all in file format!
Program must determine string "EEUNITS" in file and multiplicate all dimensions of schematic.

Revision history for this message
Wayne Stambaugh (stambaughw) wrote :

@Victor, this is going to be reviewed during the new file format
implementation which will happen during v6 development. I do not have
time to discuss this issue further until after v5 is release. When I
open the discussion on the new schematic file formats, feel free to comment.

On 1/8/2018 3:02 PM, Victor wrote:
> Wayne, maybe solution of this problem would be to create a new file
> format - just slighly changed, with new parameter stored (measurement
> units) in every file? Users who use existing libraries - use "old
> format" without measurement units determined. Users can store their
> files in both formats, old (without) and new (with determined
> measurement units), but new format is preferable. There will be two
> formats in use.
>
> There is a sample file with circuit with three wires, without component
>
> * * *
>
> EESchema Schematic File Version 4
> LIBS:test-cache
> EELAYER 26 0
> EELAYER END
> $Descr A4 11693 8268
> encoding utf-8
> Sheet 1 1
> Title ""
> Date ""
> Rev ""
> Comp ""
> Comment1 ""
> Comment2 ""
> Comment3 ""
> Comment4 ""
> $EndDescr
> Wire Wire Line
> 3650 3650 3650 3050
> Wire Wire Line
> 3650 3050 5300 3050
> Wire Wire Line
> 4850 3750 5700 3750
> Wire Wire Line
> 5700 3750 5700 3300
> Connection ~ 5700 3750
> Wire Wire Line
> 5700 3750 5950 3750
> $EndSCHEMATC
>
> * * *
>
> Changes of file format:
>
> EESchema Schematic File Version 5 (next step)
> EEUNITS [mil/mm] (new parameter)
>
> That's all in file format!
> Program must determine string "EEUNITS" in file and multiplicate all dimensions of schematic.
>

Revision history for this message
Victor (lantcoder) wrote :

Waine, so, what's new about this feature?
Version 5 have released. Maybe... ?
(open discussion about file format)?

Revision history for this message
Jeff Young (jeyjey) wrote :

@Victor, we had some serious issues with GTK3 which require moving eeschema to a modern canvas so there is going to be a 5.1 release for that. After that Wayne will open up the 6.0 development.

(5.1 is scheduled for early 2019.)

Cheers,
Jeff.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.