Re: [Kicad-developers] DXF export generates non-closed polygons, and other problems interchanging data w/ Sonnet
It would be helpful if you could generate a minimal example file where a polygon is not closed and create a bug report with that file. To my knowledge, polygons are closed in the dxf plotter (at least the code is written in such a way as to attempt to do this). We do not yet support real drill outlines in the plotter. We've added this to the printer and could probably do the same for the plotter. Here, again it will be helpful to submit a bug report requesting this feature. Multiple layers in a single dxf has already been requested but has not yet been implemented (https://gitlab.com/kicad/code/kicad/-/issues/2526) Best- Seth On Wed, Sep 2, 2020 at 4:17 PM Andrew Zonenberg wrote: > Hi, > > Kicad's DXF export seems to be broken, causing many tools (such as the > Sonnet field solver) to not import layouts correctly. > I contacted Sonnet support and they did some digging; it seems like > KiCAD is producing malformed DXFs that have non-closed polygons in them. > > I've also encountered two other problems getting KiCAD designs into Sonnet: > > 1) Sonnet's DXF import expects a *single* DXF, with one drawing layer > per PCB/via layer. KiCAD generates one DXF per layer and I don't think > there is currently a way to do a multilayer export. This isn't a fatal > problem as I can just do multiple imports, but it's annoying. > > 2) More seriously, There does not seem to be any way to get via drill > *outlines* in DXF format. The "drill map" file just has an X at each via > location which is useless when trying to import layout into an external > tool. > > Anybody have suggestions on how to proceed, or interested in helping to > fix this? I'm not super familiar with the DXF file format although back > in the v4.x days I did do some work on the microvia/blind via Excellon > drill export code so I've done at least a little bit of work there. > > Andrew > > ___ > 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 > -- [image: KiCad Services Corporation Logo] Seth Hillbrand *Lead Developer* +1-530-302-5483 <+12126039372> Davis, CA www.kipro-pcb.comi...@kipro-pcb.com ___ 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] DXF export generates non-closed polygons, and other problems interchanging data w/ Sonnet
Hi, Kicad's DXF export seems to be broken, causing many tools (such as the Sonnet field solver) to not import layouts correctly. I contacted Sonnet support and they did some digging; it seems like KiCAD is producing malformed DXFs that have non-closed polygons in them. I've also encountered two other problems getting KiCAD designs into Sonnet: 1) Sonnet's DXF import expects a *single* DXF, with one drawing layer per PCB/via layer. KiCAD generates one DXF per layer and I don't think there is currently a way to do a multilayer export. This isn't a fatal problem as I can just do multiple imports, but it's annoying. 2) More seriously, There does not seem to be any way to get via drill *outlines* in DXF format. The "drill map" file just has an X at each via location which is useless when trying to import layout into an external tool. Anybody have suggestions on how to proceed, or interested in helping to fix this? I'm not super familiar with the DXF file format although back in the v4.x days I did do some work on the microvia/blind via Excellon drill export code so I've done at least a little bit of work there. Andrew ___ 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] Evaluating cross-selection between the 3D-Viewer and Pcbnew
I'll second what Ian has said with one caveat. When we replace the Kiway
interface in v7, we'll be ripping out all previous interfaces, so I think
we should be fine even if there is a new probe from pcbnew->3d Viewer.
That said, we are about 1 month away from feature freeze, so any
implementation would need to be on that timescale.
Best-
Seth
On Wed, Sep 2, 2020 at 6:25 AM Ian McInerney
wrote:
> The 3d viewer does have access to the kiway, but I really think we need to
> think about how this is done before we just go adding a cross-probing
> interface between pcbnew and the 3d viewer. As our kiway is written
> currently, adding the cross-probing will basically be adding a brand-new
> messaging protocol between those two frames - and I would like for us to
> avoid adding a new cross-probing specification when we already have two in
> existence (the pcbnew <-> eeschema one and eeschema <-> simulator) that
> both are different.
>
> Jon, Seth and I had been discussing the future of the kiway off and on for
> the last few months, and I think we are going to propose upgrading the
> kiway to be a more structured interface (possibly using something like
> JSON-RPC, but that hasn't been spec'd yet and I don't want to start the
> discussion at this moment) with every frame listening on a local port for
> the messages (instead of the current wx-event system relying on passing
> strings/objects in memory) for v7. The thinking is then we define a
> "cross-probe" command in the new RPC system that will be sent over the
> kiway and all frames receive it and act on it if they want (so then you can
> select a module in pcbnew and it will send a single cross-probe request
> that can be ingested by both eeschema and the 3d-viewer instead of having
> to send two different requests in possibly two different formats).
>
> I don't think Seth, Jon or I will have much time in the next month to
> write up a spec on this new interface yet since we all have work to do
> before feature freeze. But I think this can definitely be something we
> ensure is inside the kiway spec so it will be implementable in v7.
>
> The part I have never been sure of is how the actual 3d-viewer parts would
> be implemented, because it is not obvious to me if there is a nice way to
> show the selection in the rendering, or if we can get user-input to select
> models in the 3d viewer and then cross-probe them back to the board in our
> system. This is something that is possible in the OpenCascade viewer system
> though, so we might be able to add similar functionality to ours.
>
> -Ian
>
> On Wed, Sep 2, 2020 at 2:04 PM Wayne Stambaugh
> wrote:
>
>> It's part of the kiway mail messaging system. Take a look at the
>> kiway*.{h/cpp} files. I'm not sure if the 3D viewer is derived from
>> KIWAY_PLAYER. If it is, this should be fairly straight forward assuming
>> you can figure out the component position from the model geometry and
>> translate that back to the board position. If not, you will have a lot
>> more work to do. I do no want to add another messaging protocol to the
>> board editor.
>>
>> On 9/1/20 6:15 PM, Mário Luzeiro wrote:
>> > Hello all,
>> >
>> > I'm evaluating how/ if it will be possible to implement some kind of
>> cross footprint selection between the 3D-Viewer and Pcbnew.
>> > I know that it works with Schematic and Board so I believe there are
>> already some existent mechanisms.. but I don't know what exists in KiCad
>> source-code for that.
>> >
>> > Could someone point me where can I find relevant code that is already
>> used or implemented for this purpose?
>> >
>> > I have the following questions do clarify:
>> > - Can I notify 3D-Viewer to update the render from pcbnew/eeschema?
>> > - How can I flag/or select a footprint and notify pcbnew/eeschema?
>> > - Does a footprint has a flag that says it is selected? or there is
>> some other list of selected footprints?
>> >
>> > Any other concerns or things that I should have a look?
>> >
>> > Regards,
>> > Mario Luzeiro
>> >
>> > ___
>> > 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
>
--
[image: KiCad Services Corporation Logo]
Seth Hillbrand
*Lead Developer*
+1-530-302-5483 <+12126039372>
Davis, CA
Re: [Kicad-developers] Evaluating cross-selection between the 3D-Viewer and Pcbnew
The 3d viewer does have access to the kiway, but I really think we need to
think about how this is done before we just go adding a cross-probing
interface between pcbnew and the 3d viewer. As our kiway is written
currently, adding the cross-probing will basically be adding a brand-new
messaging protocol between those two frames - and I would like for us to
avoid adding a new cross-probing specification when we already have two in
existence (the pcbnew <-> eeschema one and eeschema <-> simulator) that
both are different.
Jon, Seth and I had been discussing the future of the kiway off and on for
the last few months, and I think we are going to propose upgrading the
kiway to be a more structured interface (possibly using something like
JSON-RPC, but that hasn't been spec'd yet and I don't want to start the
discussion at this moment) with every frame listening on a local port for
the messages (instead of the current wx-event system relying on passing
strings/objects in memory) for v7. The thinking is then we define a
"cross-probe" command in the new RPC system that will be sent over the
kiway and all frames receive it and act on it if they want (so then you can
select a module in pcbnew and it will send a single cross-probe request
that can be ingested by both eeschema and the 3d-viewer instead of having
to send two different requests in possibly two different formats).
I don't think Seth, Jon or I will have much time in the next month to write
up a spec on this new interface yet since we all have work to do before
feature freeze. But I think this can definitely be something we ensure is
inside the kiway spec so it will be implementable in v7.
The part I have never been sure of is how the actual 3d-viewer parts would
be implemented, because it is not obvious to me if there is a nice way to
show the selection in the rendering, or if we can get user-input to select
models in the 3d viewer and then cross-probe them back to the board in our
system. This is something that is possible in the OpenCascade viewer system
though, so we might be able to add similar functionality to ours.
-Ian
On Wed, Sep 2, 2020 at 2:04 PM Wayne Stambaugh wrote:
> It's part of the kiway mail messaging system. Take a look at the
> kiway*.{h/cpp} files. I'm not sure if the 3D viewer is derived from
> KIWAY_PLAYER. If it is, this should be fairly straight forward assuming
> you can figure out the component position from the model geometry and
> translate that back to the board position. If not, you will have a lot
> more work to do. I do no want to add another messaging protocol to the
> board editor.
>
> On 9/1/20 6:15 PM, Mário Luzeiro wrote:
> > Hello all,
> >
> > I'm evaluating how/ if it will be possible to implement some kind of
> cross footprint selection between the 3D-Viewer and Pcbnew.
> > I know that it works with Schematic and Board so I believe there are
> already some existent mechanisms.. but I don't know what exists in KiCad
> source-code for that.
> >
> > Could someone point me where can I find relevant code that is already
> used or implemented for this purpose?
> >
> > I have the following questions do clarify:
> > - Can I notify 3D-Viewer to update the render from pcbnew/eeschema?
> > - How can I flag/or select a footprint and notify pcbnew/eeschema?
> > - Does a footprint has a flag that says it is selected? or there is some
> other list of selected footprints?
> >
> > Any other concerns or things that I should have a look?
> >
> > Regards,
> > Mario Luzeiro
> >
> > ___
> > 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] Evaluating cross-selection between the 3D-Viewer and Pcbnew
It's part of the kiway mail messaging system. Take a look at the
kiway*.{h/cpp} files. I'm not sure if the 3D viewer is derived from
KIWAY_PLAYER. If it is, this should be fairly straight forward assuming
you can figure out the component position from the model geometry and
translate that back to the board position. If not, you will have a lot
more work to do. I do no want to add another messaging protocol to the
board editor.
On 9/1/20 6:15 PM, Mário Luzeiro wrote:
> Hello all,
>
> I'm evaluating how/ if it will be possible to implement some kind of cross
> footprint selection between the 3D-Viewer and Pcbnew.
> I know that it works with Schematic and Board so I believe there are already
> some existent mechanisms.. but I don't know what exists in KiCad source-code
> for that.
>
> Could someone point me where can I find relevant code that is already used or
> implemented for this purpose?
>
> I have the following questions do clarify:
> - Can I notify 3D-Viewer to update the render from pcbnew/eeschema?
> - How can I flag/or select a footprint and notify pcbnew/eeschema?
> - Does a footprint has a flag that says it is selected? or there is some
> other list of selected footprints?
>
> Any other concerns or things that I should have a look?
>
> Regards,
> Mario Luzeiro
>
> ___
> 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] New dependency in docker image - tigervnc - xvfb
I have added xvfb to the docker images used for CI (both the Fedora 31 image and Ubuntu 18.04 image). -Ian On Fri, Aug 28, 2020 at 8:36 PM Sylwester Kocjan wrote: > Hi again, > > > On 23/08/2020 02:12, Ian McInerney wrote: > > Are you wanting to add new QA tests that need a window to the main unit > test suite? > > Yes, that's correct. > > On 23/08/2020 01:28, Seth Hillbrand wrote: > > Could you explain further why you would need this in the official docker? > Can you not specify your own docker for your tests? > > 1. Based on this great tutorial I made changes in qa tests which allow to > use wxFrames in test suite. > > http://www.remy.org.uk/tech.php?tech=1407951209 > > 2. I used these kind of tests with my development in following merge > request (commit 3542e2da9b9 and later): > > https://gitlab.com/kicad/code/kicad/-/merge_requests/215 > > 3. I want to add more of these tests, namely: I want to cover > DIALOG_SIM_SETTINGS with tests and add new types of simulation in the > future. > 4. Sure I can install what I need on my own docker image, but I want to > make it working with CI as well. Otherwise it makes no sense. > 5. I was hoping that other developers can benefit from this change as > well. > > On 23/08/2020 02:12, Ian McInerney wrote: > > If so, we should not use a VNC server to run them we should use xvfb to > emulate an X server interface. > > Good point, this can be used as well, but xvfb is not available in > official KiCad image. Can we consider adding it? > > I hope it's not a big deal. Are there any obstacles (maybe I'm not aware > of something)? > > Best regards, > Sylwester > > > On 23/08/2020 02:12, Ian McInerney wrote: > > Are you wanting to add new QA tests that need a window to the main unit > test suite? If so, we should not use a VNC server to run them we should use > xvfb to emulate an X server interface. > > -Ian > > On Sat, Aug 22, 2020 at 11:31 PM Sylwester Kocjan wrote: > >> Hello, >> >> Can I ask for updating docker images with additional dependency, >> according to attached patch? >> >> I was trying with running wx frames in qa test application and this >> change will be helpful for me. >> >> Best regards, >> Sylwester >> >> ___ >> 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
