I have just merged the patches.
On 02/28/2018 12:38 PM, Russell Oliver wrote:
> Hi Orson,
>
> All I can say is thanks for taking the time to polish this further.
>
> Just went through the matching code and am now kicking myself that i didn't
> think of that approach before.
No worries, it was
Hi Orson,
All I can say is thanks for taking the time to polish this further.
Just went through the matching code and am now kicking myself that i didn't
think of that approach before.
Good pick up on the missing junctions.
Kind Regards
Russell
On 28 Feb 2018 22:14, "Maciej Sumiński"
I think I have finally reached the point where I am completely satisfied
with the Eagle import results. I do not see any changes when invoking
'Update PCB from schematics'. No connectivity issues observed and pretty
local net labels are used whenever possible.
Thank you Russell, your patch to use
Awesome,
I'm excited to finally see v5 come to pass. I think we should nickname the
release, Godot, since we have all be waiting for it for so long.
Russ
On Mon, Feb 26, 2018 at 9:59 PM Maciej Sumiński
wrote:
> Hi Russell,
>
> I plan to merge your changes, I have
Hi Russell,
I plan to merge your changes, I have almost finished the refactor to use
KiWay mail. I will test the patches a bit and given no extra issues
appear, I will push them to the master branch.
Regards,
Orson
On 02/25/2018 10:30 PM, Russell Oliver wrote:
> Just wondering what approach we
Just wondering what approach we are going to use for v5? Global labels or
my latest matching algorithm?
Kind Regards
Russell
On 25 Feb 2018 08:43, "Russell Oliver" wrote:
> Hi Orson,
>
> I looked at the Kicad project from the and I don't see any global labels,
> just
Hi Orson,
I looked at the Kicad project from the and I don't see any global labels,
just local labels. The PCB will still have the global nets though, since
they are created during import of the eagle pcb file.
Just to be clear my patches are intended to only generate global labels
when
Hi Russell,
On 02/19/2018 08:25 PM, Russell Oliver wrote:
> Hi Orson,
>
> I wasn't sure about using the KiMail, since I didn't know how immediate
> those calls are processed plus I didn't have the time to implement it using
> that anyway.
That is fine, no problem. I realize it takes more time
Hi Orson,
I wasn't sure about using the KiMail, since I didn't know how immediate
those calls are processed plus I didn't have the time to implement it using
that anyway.
I'm a bit puzzled by the statement that you are getting global labels using
the Arduino project. Can you send me your copy of
Hi Russell,
I am grateful for your continuous support. I confirm your patch handles
local net labels and zones in the attached example (orphanzonetest.zip)
correctly, but I am still getting global labels with the Arduino project
mentioned by Wayne. Reverting "Fix netlist mapping for zones and
here are the patches again after the relevant sections being uncrustified.
Kind Regards
Russell
On Mon, Feb 19, 2018 at 3:07 AM Wayne Stambaugh
wrote:
> This looks a lot more reasonable to me although there may be some corner
> cases that we haven't thought about but we
This looks a lot more reasonable to me although there may be some corner
cases that we haven't thought about but we can fix those as they pop up.
I'm sure user's reactions to the all global label solution will be
WTF. At least that was my reaction. The amount of work to go back and
fix this
Yes there should be a way to match them up.
The logic for it is as follows, for the complex case:
An eagle project with 2 nets (A and B) that are used for zones and
stitching vias and each appears only on separate sheets, Y and Z
respectively.
During the import two subsheets are created.
After
I'm not too sure about our global label solution. The results are
rather heinous. Take a look at the Ardunino ATMega 2560 board[1] that I
demoed at FOSDEM imported using the new label semantics. I don't think
users are going to be OK with this. Is there no way we can use normal
labels properly
I'm not too sure about our global label solution. The results are
rather heinous. Take a look at the Ardunino ATMega 2560 board[1] that I
demoed at FOSDEM imported using the new label semantics. I don't think
users are going to be OK with this. Is there no way we can use normal
labels properly
I'll work on it further and hopefully it can be included in maybe a point
release or v6.
My main concern is that zones and stitching vias aren't left on orphaned
nets after the netlist is first synced with the schematic during import,
which the global labels solve.
On 17 Feb 2018 21:54,
Hi Russell,
No worries, the change was easy. I was mostly interested in your view
about the change, and you confirm the main concern is the appearance of
imported schematics.
I am not sure if netlist updater is able to link a symbol and its
corresponding footprint when sheetpath is not complete,
Hi all,
Sorry I didn't get to it sooner. Been busy at a new job.
I was going to say that globals will work fine except for the visual
aspect. Though I think just replacing the global net on the pcb with the
net from the schematic with the matching end label ( ignoring any sheet
path) should
Alright, I switched the importer to use global net labels. Perhaps
schematics are not always the prettiest ones, but at least they are
equivalent to the original project.
Cheers,
Orson
On 02/16/2018 02:59 PM, Wayne Stambaugh wrote:
> If using global nets resolves the issue and doesn't cause any
If using global nets resolves the issue and doesn't cause any other
issues, it has my vote as well.
On 02/16/2018 08:36 AM, Maciej Sumiński wrote:
> I vote for switching to global nets. I may handle this, just want to be
> sure Russell has not started already working on it, so there is no work
>
I vote for switching to global nets. I may handle this, just want to be
sure Russell has not started already working on it, so there is no work
duplication.
Regards,
Orson
On 02/16/2018 02:17 PM, Wayne Stambaugh wrote:
> Gentlemen,
>
> What is the status of this bug fix? I know there was some
Gentlemen,
What is the status of this bug fix? I know there was some discussion
about this patch. Do we have path forward on this yet? I would like to
get this into rc1 if possible.
Thanks,
Wayne
On 02/14/2018 08:17 AM, Russell Oliver wrote:
> Please find the attached patch for this issue.
If memory server's me correctly, I scan all eagle the sub sheet, for net
name match, if the label match's, for different sub sheets I make global,
else local, this works fine in my conversation script, at
https://github.com/lachlanA/eagle-to-kicad
you can check the code there.
Lachlan
Hi Russell,
Thank you for the patch. I should have thought about one issue earlier,
but the current approach solves the problem only for single sheet
schematics. If you create a zone with a net that exists only in a
subsheet, then such case will not be handled correctly, i.e. zone will
have
Please find the attached patch for this issue.
On Tue, Feb 13, 2018 at 2:34 AM Maciej Sumiński
wrote:
> Hi Russell,
>
> On 02/11/2018 05:41 AM, Russell Oliver wrote:
> > Hi All,
> >
> > I've discovered the cause of a problem when importing Eagle Projects and
> > getting
Hi Russell,
On 02/11/2018 05:41 AM, Russell Oliver wrote:
> Hi All,
>
> I've discovered the cause of a problem when importing Eagle Projects and
> getting the schematic and boards synced.
>
> Currently when importing an Eagle schematic, labels for nets that are only
> found one Eagle sheet are
26 matches
Mail list logo