Re: [Kicad-developers] What are dx and dy?

[Collin Anderson]

Hit space bar, it will set the origin for dx and dy.  It's useful for seeing 
where the cursor is relative to the most recent 'origin' set with the spacebar. 
 I use it all the time :).
-- 
"Violence is the last refuge of the incompetent." - Isaac Asimov

> On May 9, 2016, at 2:39 PM, Duane Johnson  wrote:
> 
> When I create a rectangle, or line, I frequently want to know what the size 
> of the rectangle is (width and height). I would have assumed that's what "dx" 
> and "dy" in the footer/status bar are for; however, it seems like in all 
> cases, they simply reflect the same values as "X" and "Y". Am I missing 
> something, or is this something to be fixed?
> 
> Thanks,
> Duane
>  14.37.18.png>___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] mode openGL issues after latest updates

[easyw]

Hi, I'm having an issue (crash) changing from default canvas to OpenGl

Comparing my settings to the dev pre-built it seems only gcc version is 
different; mine is gcc 5.3.0, pre-built is 5.2.0

is there anyone having this problem?

and here there are the settings:

Application: pcbnew
Version: 6776-dev, release build
Libraries: wxWidgets 3.0.2
   libcurl/7.46.0 OpenSSL/1.0.2e zlib/1.2.8 libidn/1.32 
libssh2/1.6.0 librtmp/2.3
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, 
wxMSW

- Build Info -
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.57.0
Curl: 7.46.0
KiCad - Compiler: GCC 5.3.0 with C++ ABI 1009
Settings: USE_WX_GRAPHICS_CONTEXT=OFF
  USE_WX_OVERLAY=OFF
  KICAD_SCRIPTING=ON
  KICAD_SCRIPTING_MODULES=ON
  KICAD_SCRIPTING_WXPYTHON=ON
  USE_FP_LIB_TABLE=HARD_CODED_ON
  BUILD_GITHUB_PLUGIN=ON


Application: pcbnew
Version: (2016-05-06 BZR 6776, Git 63decd7)-product, release build
Libraries: wxWidgets 3.0.2
   libcurl/7.46.0 OpenSSL/1.0.2d zlib/1.2.8 libidn/1.32 
libssh2/1.6.0 librtmp/2.3
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian, 
wxMSW

- Build Info -
wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8)
Boost: 1.57.0
Curl: 7.46.0
KiCad - Compiler: GCC 5.2.0 with C++ ABI 1009
Settings: USE_WX_GRAPHICS_CONTEXT=OFF
  USE_WX_OVERLAY=OFF
  KICAD_SCRIPTING=ON
  KICAD_SCRIPTING_MODULES=ON
  KICAD_SCRIPTING_WXPYTHON=ON
  USE_FP_LIB_TABLE=HARD_CODED_ON
  BUILD_GITHUB_PLUGIN=ON


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Track locking

[Clemens Koller]

Hello!

On 2016-05-09 17:50, Chris Pavlina wrote:
> If they are "locked", then yes, I think they should not be moved, neither by
> the user nor by PNS.

You might consider that we might need *different* levels of locking / 
protections
for traces, manually vs. pns/automatically routed, trace widths only,
vias to grids (serving as testpoints for bed of nails, etc.), ... in the 
long-run.

Regards,

Clemens

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Track locking

[Chris Pavlina]

If they are "locked", then yes, I think they should not be moved, neither by
the user nor by PNS.

On Mon, May 09, 2016 at 05:43:24PM +0200, Maciej Sumiński wrote:
> I have noticed there is an option to mark tracks & vias as 'locked' in
> the legacy canvas (right click on a track->Set Flags->Track: Locked.
> 
> According to my observations, it is only used by Global Deletion dialog.
> Should we make locked tracks & vias behave like locked modules, so they
> cannot be moved without explicit permission from the user? Now it might
> be a bit confusing, as we use the same wording for different things.
> 
> Regards,
> Orson
> 



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Track locking

[Wayne Stambaugh]

Yes!  This should have been done on the legacy canvas as well.  When I
lock an object, I don't want it to be changed in any way unless I
explicitly unlock it.  This concept seems pretty straight forward to me.
 I believe there are few bug reports against legacy canvas on this.

On 5/9/2016 11:43 AM, Maciej Sumiński wrote:
> I have noticed there is an option to mark tracks & vias as 'locked' in
> the legacy canvas (right click on a track->Set Flags->Track: Locked.
> 
> According to my observations, it is only used by Global Deletion dialog.
> Should we make locked tracks & vias behave like locked modules, so they
> cannot be moved without explicit permission from the user? Now it might
> be a bit confusing, as we use the same wording for different things.
> 
> Regards,
> Orson
> 
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Track locking

[Maciej Sumiński]

I have noticed there is an option to mark tracks & vias as 'locked' in
the legacy canvas (right click on a track->Set Flags->Track: Locked.

According to my observations, it is only used by Global Deletion dialog.
Should we make locked tracks & vias behave like locked modules, so they
cannot be moved without explicit permission from the user? Now it might
be a bit confusing, as we use the same wording for different things.

Regards,
Orson



signature.asc
Description: OpenPGP digital signature
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Maker Faire SF KiCad Presentation

[Adam Wolf]

Thanks!

Adam Wolf

On Mon, May 9, 2016 at 9:26 AM, Wayne Stambaugh 
wrote:

> Hey Adam,
>
> Thank you for representing KiCad at Maker Faire SF.  I wish I could join
> you.  Maybe one of these years I'll be able to make it.
>
> Take a look at the version 5 road map[1] for ideas on what the goals are
> for the next stable release.  Please keep in mind that this is the goal,
> what actually will get implemented remains to be seen.  As for the
> user-facing Eeschema changes, we hope to GALify (at least an initial
> pass) and get the new file format implemented which will change the
> library management code more along the lines of the Pcbnew.  Maybe we
> will get few features like gate/pin swap implemented and don't forget
> Tom's board update feature (no intermediate netlist file required).
> Feel free to borrow any of my 2016 FOSDEM presentation if it helps.  It
> should be available on the FOSDEM website.  If not, let me know and I
> can send you a copy of it.
>
> Cheers,
>
> Wayne
>
> [1]:
>
> http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/v5_road_map.html
>
> On 5/9/2016 10:13 AM, Adam Wolf wrote:
> > Hi folks!
> >
> > Once again, I'm doing a presentation on KiCad at Maker Faire SF.  It's
> > in a few weeks, and I'm looking for ideas on what to include.
> >
> > The idea, in essence, is a yearly report on KiCad, focussing on what's
> > recently happened, and what's in the near-term roadmap, but there are so
> > many people who have absolutely no idea what KiCad is, that there's a
> > few slides in the beginning that are basically the same every year.
> >
> > Previous things we've talked about are the improvements in pcbnew, the
> > then-upcoming release, and the fact that we had nightly builds on lots
> > of platforms.
> >
> > I'll still cover most of these things, but much abbreviated.
> >
> > I plan on talking a bit about the 3D work.  Do we have a good handle on
> > the upcoming eeschema changes, especially user-facing things?
> >
> > Any other thoughts/suggestions?
> >
> > Adam Wolf
> > Cofounder and Engineer
> > W
> >
> >
> > ___
> > Mailing list: https://launchpad.net/~kicad-developers
> > Post to : kicad-developers@lists.launchpad.net
> > Unsubscribe : https://launchpad.net/~kicad-developers
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Maker Faire SF KiCad Presentation

[Wayne Stambaugh]

Hey Adam,

Thank you for representing KiCad at Maker Faire SF.  I wish I could join
you.  Maybe one of these years I'll be able to make it.

Take a look at the version 5 road map[1] for ideas on what the goals are
for the next stable release.  Please keep in mind that this is the goal,
what actually will get implemented remains to be seen.  As for the
user-facing Eeschema changes, we hope to GALify (at least an initial
pass) and get the new file format implemented which will change the
library management code more along the lines of the Pcbnew.  Maybe we
will get few features like gate/pin swap implemented and don't forget
Tom's board update feature (no intermediate netlist file required).
Feel free to borrow any of my 2016 FOSDEM presentation if it helps.  It
should be available on the FOSDEM website.  If not, let me know and I
can send you a copy of it.

Cheers,

Wayne

[1]:
http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/v5_road_map.html

On 5/9/2016 10:13 AM, Adam Wolf wrote:
> Hi folks!
> 
> Once again, I'm doing a presentation on KiCad at Maker Faire SF.  It's
> in a few weeks, and I'm looking for ideas on what to include.
> 
> The idea, in essence, is a yearly report on KiCad, focussing on what's
> recently happened, and what's in the near-term roadmap, but there are so
> many people who have absolutely no idea what KiCad is, that there's a
> few slides in the beginning that are basically the same every year.
> 
> Previous things we've talked about are the improvements in pcbnew, the
> then-upcoming release, and the fact that we had nightly builds on lots
> of platforms.
> 
> I'll still cover most of these things, but much abbreviated.
> 
> I plan on talking a bit about the 3D work.  Do we have a good handle on
> the upcoming eeschema changes, especially user-facing things?  
> 
> Any other thoughts/suggestions?
> 
> Adam Wolf
> Cofounder and Engineer
> W
> 
> 
> ___
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Maker Faire SF KiCad Presentation

[Adam Wolf]

Hi folks!

Once again, I'm doing a presentation on KiCad at Maker Faire SF.  It's in a
few weeks, and I'm looking for ideas on what to include.

The idea, in essence, is a yearly report on KiCad, focussing on what's
recently happened, and what's in the near-term roadmap, but there are so
many people who have absolutely no idea what KiCad is, that there's a few
slides in the beginning that are basically the same every year.

Previous things we've talked about are the improvements in pcbnew, the
then-upcoming release, and the fact that we had nightly builds on lots of
platforms.

I'll still cover most of these things, but much abbreviated.

I plan on talking a bit about the 3D work.  Do we have a good handle on the
upcoming eeschema changes, especially user-facing things?

Any other thoughts/suggestions?

Adam Wolf
Cofounder and Engineer
W
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Kicad Fields, was Re: [RFC] On net ties, microwave tools & custom pad shapes, altogether.

[Wayne Stambaugh]

On 5/4/2016 10:40 PM, Strontium wrote:
> I split this from the net-ties, etc RFC because its drifting off topic
> from that discussion.
> 
> I am not sure I understand the rationale to "It should also
> be limited to passing information to external tools such as simulators
> and scripts such as Tom's proposal"?

Any feature that is internal to kicad should not be handled through
fields.  Other than the 4 mandatory fields, fields are reserved for user
defined data.  For example, the gate and pin swapping information could
be passed via fields.  However, this will be a internal kicad feature in
the future and will be implemented as part of the file formats rather
than using fields.  The only exception I know of is the spice netlist
formatter with uses text notes and/or fields to generate spice netlists.

> 
> Both the Footprint and the Component Reference are "Fields" and
> key:value pairs.  I would imaging these are the first Fields that any
> new Kicad user works with.
> 
> Kicad has functionality to work with those "Fields" and they are core
> information NOT just for external tools, they also convey information
> from Schematic to PCB.  Yet they are also just Key:Value field pairs.
> 
> I agree that it requires documentation if the number of fields grows,
> especially if they are not explicitly included like the default Field
> list automatically includes Footprint and reference.  Surely one way to
> mitigate that is to have a list of "standard" Fields that can be
> selected from in addition to typing them in.  It would also be possible
> to have a validator or entry dialogue for a "standard" fields "value",
> similar to the footprint field.  This is not a design proposal, merely a
> suggestion of how this could be handled.
> 
> It would also still be very "generally" useful to be able to add fields
> to nets, and for that information to be able to propagate to the PCB
> elements they reflect.  Alternatively (and I actually think its
> preferable) some mechanism to query that information from the schematic,
> given a PCB object, eliminates the need to propagate it into the PCB
> file and keeps it DRY.
> 
> Whether for a core feature or not, Properly implemented, I can easily
> imagine fields that carry arbitrary information between Schematic/PCB
> being a killer feature, especially for scripting. It would then make it
> easy to create scripts for all sorts of purposes and for their operation
> to be generally parametrisable and documented in the schematic. 
> Something which now is not possible.

User defined fields can contain any information that the user can think
of and are available to scripts in both the schematic file and the
netlist file.  There is nothing preventing you from parsing this
information with any script and doing whatever you want to do with the
user defined field information.  This is outside the scope of kicad and
is left up to the imagination of the user.  The key difference is "user"
defined feature versus "kicad" defined feature.

> 
> Examples: You could have a python script which produces tuned antennas
> parametrically, and does it based on the parameters specified in the
> schematic.
> In the schematic, you place a component for a "mounting hole" you
> declare for the "mounting hole" its actual co-ordinates, as it is a
> constraint.  Now a script run on the PCB can ensure that the mounting
> holes are located in "exactly" the correct location as specified in the
> schematic.
> You could create a schematic representation for your board
> "outline", and the field is the name of a DXF. In pcbnew, a script can
> read that, and automatically load the DXF and draw the outline on the
> outline layer.  Change the DXF and the PCB can easily and quickly be
> updated to redraw the outline layer.
> 
> It would clearly be up to the developer of the script to document the
> parameters and how the script is used, as its not "core" functionality. 
> BUT, a full library of "extended" functionality could grow around this
> feature and it makes kicad significantly more powerful and significantly
> easier to extend.  I believe users would quickly become accustomed to
> looking in the library for the "extended" features they want, as their
> needs grow.
> 
> 
> 
> 
> On 04/05/16 22:57, Wayne Stambaugh wrote:
>> The use of fields for arbitrary data is indeed powerful.  It should also
>> be limited to passing information to external tools such as simulators
>> and scripts such as Tom's proposal.  Anything that is supported as a
>> feature in KiCad should be part of the schematic file format and fully
>> supported by the schematic editor.  The problem with using fields is the
>> user has to know how to define all of the attributes correctly which
>> requires thorough documentation.  I don't see this as a good solution
>> for the average user.  This is a bit like using regular expressions.
>> They are really powerful but only a small number of users (typically
>> developers) will actually 

Re: [Kicad-developers] [RFC] On net ties, microwave tools & custom pad shapes, altogether.

[Wayne Stambaugh]

On 5/4/2016 4:11 PM, Tomasz Wlostowski wrote:
> On 04.05.2016 16:48, Wayne Stambaugh wrote:
>> How are you saving this auto generate flag and width/length parameters
>> in the schematic?  If you are using component fields or text that's
>> fine.  However, please keep in mind that using component fields and text
>> is for passing information to third party tools that are not part of
>> kicad.  If we are going to support net ties and micro wave component
>> generation, we should do that as part of KiCad proper rather than treat
>> it like a third party tool which you are proposing. 
> 
> Hi Wayne,
> 
> I would store the microwave dimensions as key:value pairs, just like the
> current schematic fields. I think microwave components will be best
> handled by python scripting. These scripts should be IMHO permanently
> included in Kicad distribution, not a 3rd party tool. I chose component
> fields to pass the dimensions information because with every new exotic
> shape (e.g. a Wilkinson power divider instead of a simple microstrip
> line), we would need to add new tokens to the SCH file format and
> netlist specification.

Hey Tom,

Would it be easier to provide a python script with a UI to input the
dimensional information used to generate these complex microwave
footprints and just associate them with a schematic symbol rather that
trying to squeeze all of that dimensional information into a field?
This may be more natural for the user to handle.  I understand the
temptation to use fields to do this but I'm not sure this is the easiest
path for users.  I just don't see users be comfortable with this in
terms of usability.  Developers will have no issues with it but I'm
trying to see this from a typical user's point of view.  It might be
worth getting some feedback on the users forum.

> 
> For net ties, there's no schematic/netlist format changes, only PCB.
> 
> I'm wondering how to handle the auto_generate flag. Maybe this one
> justifies a separate file format entity connected to a checkbox in the
> sch library editor and a text field specifying which plugin/script to run...

The only risk I see with using a field as an auto_generate flag is field
namespace pollution.  If someone inadvertently uses the auto_generate
field name, I image a bunch of script errors would be a bit confusing.
This risk is low but it is something to consider.  My proposal would
eliminate the need for an auto_generate flag.

> 
>> I don't want the
>> component fields and text used for kicad features.  If you want to
>> provide this as an interim solution, I am OK with that.  However, you
>> may be creating more work for yourself when we finally get around to
>> supporting net ties and micro wave component generation as part of the
>> schematic editor. 
> 
> How do you see the role of the schematic editor in generation of
> microwave components (in my proposal there's none)?

I agree.  I don't pretend to be a microwave expert but AFAIK most if not
all microwave features are complex geometrical shapes which should be
treated as footprints and associated with a schematic symbol.  I don't
see why the schematic editor would need to know anything about microwave
footprints other than possibly passing parametric information via a
field to the board editor.

> 
> Cheers,
> Tom
> 

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp