kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #31973
Re: Migrating old designs best practice
It's interesting that only happen if I rescue symbols.
Anyway, thanks for the help and I'll keep an eye on properly wired
schematics to see if all goes OK.
Thanks,
Diego
On Sun, Nov 26, 2017 at 5:23 PM, José Ignacio <jose.cyborg@xxxxxxxxx> wrote:
> This might be related to the wire optimizer/junction management code.
> Eeschema used to allow degenerate connections like that, where an L was
> superimposed to a wire, connecting into a junction.
>
> On Sun, Nov 26, 2017 at 4:59 AM, Diego Herranz <
> diegoherranz@xxxxxxxxxxxxxxxx> wrote:
>
>> Please ignore the previous attachments. They should have been these.
>>
>> Thanks.
>>
>> On Sun, Nov 26, 2017 at 10:55 AM, Diego Herranz <
>> diegoherranz@xxxxxxxxxxxxxxxx> wrote:
>>
>>> Hi, Nick
>>>
>>> Changes like: (- is removed, + added)
>>>
>>> -Wire Wire Line
>>> - 12550 700 12600 700
>>>
>>> -Wire Wire Line
>>> - 12700 700 12700 700
>>>
>>> Wire Wire Line
>>> - 22250 14500 22250 11600
>>> + 22250 9200 22250 14600
>>>
>>> - Wire Wire Line
>>> - 22250 9200 22250 14600
>>>
>>> - Wire Wire Line
>>> - 22700 750 15350 750
>>>
>>> Wire Wire Line
>>> - 16650 750 16650 750
>>> + 15350 750 22700 750
>>>
>>>
>>> This happens on a dummy schematic which I've got for basically trying
>>> things out in KiCad, and to test nightlies. So the schematic is basically a
>>> mess.
>>>
>>> Thant means I've got crappy connections (before.png), which the rescue
>>> process broke (after.png). Maybe it wouldn't have happened if the
>>> connections were nice in the first place, but I wasn't expecting them to
>>> break.
>>>
>>> Thanks!
>>>
>>>
>>>
>>> On Sat, Nov 25, 2017 at 9:15 PM, Nick Østergaard <oe.nick@xxxxxxxxx>
>>> wrote:
>>>
>>>> What modifications are made to the wires?
>>>>
>>>> 2017-11-25 21:28 GMT+01:00 Diego Herranz <diegoherranz@xxxxxxxxxxxxxxxx
>>>> >:
>>>>
>>>>> Hi,
>>>>>
>>>>> Related to this, I'm migrating an old design (~2 month old nightly) to
>>>>> the current master. First I faced some problem with '/' characters (
>>>>> https://lists.launchpad.net/kicad-developers/msg31705.html) but there
>>>>> have been some improvements since then so I'm trying again.
>>>>>
>>>>> When opening the schematic, 2 dialogs are shown:
>>>>> 1) Rescue symbols dialog: it offers to rescue a couple of symbols
>>>>> which use '/' in their name. It seems to rescue them properly
>>>>> on xxxx-rescue.lib (replacing '/' by '_')
>>>>> 2) Remap dialog: Everything gets remapped properly except the symbols
>>>>> mentioned in 1). That is because xxxx-rescue.lib is not in sym-lib-table
>>>>> yet. After adding it to sym-lib-table, I can edit those broken symbols
>>>>> ("?") to point those rescued in xxxx-rescue.lib and it all looks OK.
>>>>>
>>>>> After this, which I think that can be challenging for many people (it
>>>>> has been for me), it seems everything should be OK now. However when I push
>>>>> the netlist to pcbnew, it shows a few changes and I wasn't expecting any.
>>>>> Comparing the schematic file with a text editor a few wires have been
>>>>> modified.
>>>>>
>>>>> I've don't some testing it seems the wires get modified when doing 1).
>>>>> If I skip the rescue, no wire gets modified.
>>>>>
>>>>> Why is that happening? I wouldn't expect the rescue process to modify
>>>>> wires. Am I doing something wrong?
>>>>>
>>>>> Many thanks,
>>>>> Diego
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Nov 25, 2017 at 3:00 PM, Wayne Stambaugh <stambaughw@xxxxxxxxx
>>>>> > wrote:
>>>>>
>>>>>> On 11/24/2017 05:01 PM, hauptmech wrote:
>>>>>> > On 25/11/17 02:14, Wayne Stambaugh wrote:
>>>>>> >> This is *the* fatal flaw with the cache library. User's assume it
>>>>>> is
>>>>>> >> stale symbols or a temporary copy. It is not. It is a snapshot
>>>>>> of the
>>>>>> >> current library symbols linked to the symbols in the schematic.
>>>>>> It gets
>>>>>> >> refreshed every time the schematic is saved. Once you delete this
>>>>>> file
>>>>>> >> or keep an out of date copy using cvs, all bets are off. It is
>>>>>> only a
>>>>>> >> matter of time before one of your symbol libraries changes or gets
>>>>>> >> removed and you will end up with a broken schematic. The rescue
>>>>>> code
>>>>>> >> depends on the cache being up to date in order preserve you
>>>>>> schematic.
>>>>>> >> If the cache is not current, the rescuing cannot be guaranteed.
>>>>>> >
>>>>>> > I don't think it's necessarily a flaw. And your description above is
>>>>>> > indeed a cache. That's not a bad thing. I recall that I left it out
>>>>>> of
>>>>>> > version control because I wanted to make sure fixes to my symbols
>>>>>> were
>>>>>> > always propagated to the design. In the repo I'm referencing for
>>>>>> this
>>>>>> > discussion I had 10 project files all using the same local library.
>>>>>> I
>>>>>> > didn't want to have to manually update each schematic to propagate
>>>>>> > changes. Deleting untracked files was what I did instead. At the
>>>>>> time no
>>>>>> > one was making breaking changes to system installed symbols, so the
>>>>>> > system libs were stable for this workflow.
>>>>>> >
>>>>>> > I'm trying think of the least effort way to migrate an old design in
>>>>>> > these circumstances.
>>>>>> >
>>>>>> > Can we have the rescue code fail if no cache file is found? That at
>>>>>> > least lets the user know they are in uncharted territory. Then if a
>>>>>> lot
>>>>>> > of users come complaining you will know if it is worth doing a bit
>>>>>> more
>>>>>> > in the rescue code.
>>>>>> >
>>>>>> > If the cache is not available during rescue you can load a copy of
>>>>>> the
>>>>>> > libraries that were current at the schematic save date and either
>>>>>> > re-cache them or rescue them directly. But this is only worth doing
>>>>>> if a
>>>>>> > significant number of users are affected.
>>>>>>
>>>>>> AFAIK, the rescue code doesn't do anything if there is not cache file
>>>>>> because the cache file is used for the comparison. I actually
>>>>>> considered adding a check on schematic load to warn the user with a
>>>>>> list
>>>>>> of all of symbols linked to the cache library so they could fix them.
>>>>>> I'm not sure this is desirable but at least users would know that
>>>>>> symbols were missing from their libraries and the links were falling
>>>>>> back to the cache which is tenuous at best.
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>> More help : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help : https://help.launchpad.net/ListHelp
>>
>>
>
Follow ups
References
-
Migrating old designs best practice
From: hauptmech, 2017-11-23
-
Re: Migrating old designs best practice
From: Wayne Stambaugh, 2017-11-23
-
Re: Migrating old designs best practice
From: Nick Østergaard, 2017-11-23
-
Re: Migrating old designs best practice
From: Wayne Stambaugh, 2017-11-23
-
Re: Migrating old designs best practice
From: hauptmech, 2017-11-24
-
Re: Migrating old designs best practice
From: Nick Østergaard, 2017-11-24
-
Re: Migrating old designs best practice
From: hauptmech, 2017-11-24
-
Re: Migrating old designs best practice
From: Wayne Stambaugh, 2017-11-24
-
Re: Migrating old designs best practice
From: hauptmech, 2017-11-24
-
Re: Migrating old designs best practice
From: Wayne Stambaugh, 2017-11-25
-
Re: Migrating old designs best practice
From: Diego Herranz, 2017-11-25
-
Re: Migrating old designs best practice
From: Nick Østergaard, 2017-11-25
-
Re: Migrating old designs best practice
From: Diego Herranz, 2017-11-26
-
Re: Migrating old designs best practice
From: Diego Herranz, 2017-11-26
-
Re: Migrating old designs best practice
From: José Ignacio, 2017-11-26