X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-Virus-Scanned: amavisd-new at cloud9.net
Date: Mon, 7 Dec 2015 09:48:00 -0500 (EST)
From: "Stuart Brorson (sdb AT cloud9 DOT net) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: "Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject: Re: [geda-user] gsch2pcb after refdes-renum? (If implemented
 syncronization detail)
In-Reply-To: <20151207153821.c2ac19e6f24b1776a3595e4a@gmail.com>
Message-ID: <alpine.BSF.2.00.1512070943490.84172@earl-grey.cloud9.net>
References: <56658683 DOT 401 AT envinsci DOT co DOT uk> <CALT8Ef4=tMf=WmjYmp-2B3rN0SBmoqF5RkCoWZEm=+2hTBTENA AT mail DOT gmail DOT com> <20151207153821 DOT c2ac19e6f24b1776a3595e4a AT gmail DOT com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

I'm pretty sure that refdes_renum will only renumber components which
aren't already numbered.  For example, a cap C38 will not be
renumbered, but a cap C? will.  As long as the component retains its
refdes, it won't be removed in PCB, so you should be fine.

If you do want to cause refdes_renum to give all components a new
refdes, use the --force flag when invoking it.  This will wipe all old
refdeses off your components and give them new ones.  In turn, this
will remove all the renumbered components off your pcb, and you'll
need to re-place them.

I recommend you make a backup of your design directory and then try
the renumbering.

Stuart




On Mon, 7 Dec 2015, Nicklas Karlsson (nicklas DOT karlsson17 AT gmail DOT com) [via geda-user AT delorie DOT com] wrote:

> I guess it should not be to hard to implement this way: Differences RefdesOld-->RefdesNew are stored in a file although it have the small annoying problem it have to be executed exactly once.
>
> It should only be a problem for the refdes since this is used as an object identifier. For others it should be possible to apply a set function several times with the same result. I have seen update produce a list of ChangePinName(...) functions although the name may be a little bit confusing it set the pin name to a value regardless of which value it had earlier so it should no be a problem to apply more than once.
>
> Do anybody have a simple solution how to check update of refdes have been done exactly once? Or have this already been dealt with?
>
> One possibility is file deleted immediately then update have been done. Another solution is some kind of changes are made to file so change of refdes is executed only once. There is always the small annoying problem to get stuck in the middle.
>
>
> Nicklas Karlsson
>
>
>
>> They won't be updated in place. You'll have to relocate them. More
>> importantly, if something has it's number changed to a pre-existing
>> number without a change in footprint, it won't be moved / removed at
>> all.
>>
>> Shashank
>>
>> On Mon, Dec 7, 2015 at 6:45 PM, Matt Rhys-Roberts
>> (matt DOT rhys-roberts AT envinsci DOT co DOT uk) [via geda-user AT delorie DOT com]
>> <geda-user AT delorie DOT com> wrote:
>>> Hello, I'm about to renumber a large amount of schematic components, to
>>> modify an existing pcb design.
>>>
>>> Not got time to experiment, so could anyone please tell me if renumbered
>>> components are updated in-place, or will they require relocating from the
>>> stack of revised components that piles up at the origin?
>