VALUE attribute also used to update the Value

Am 30.03.2012 16:45, schrieb Christian Bohrer:

Currently, the VALUE attribute is always used to initialize the Value of a part in a schematic, whatever its status (ON / OFF).Very well!

YES!

The problem is that it only happens the first time the part is added in the schematic.

If I replace the part or if I change its technology, its VALUE is not updated.

The VALUE of the part remain this one of its first placement.

That's NOT so nice...

It is not only very annoying but it is also a source of errors!

YES, that's quite definitely a source of errors!

This is why I propose that the VALUE attribute (if exist) is also used to update the VALUE in the replacements and changes of technology.

YES, please! The algorithm could look a little bit more sophisticated,

e.g. as follows:

  1. If the component is REPLACED, the current value is ALWAYS replaced

     by the VALUE attribute of the NEW component (in case such an

     attribute exists). If NO such attribute exists, proceed as

     currently implemented.

  2. If the component PACKAGE is changed AND the new package contains

     a VALUE attribute AND the current component's value has NOT been

     changed from its default, change the component's value to the

     new package's VALUE attribute. Otherwise, proceed as currently

     implemented.

  3. Same as (2), but for changing the TECHNOLOGY.

The above would assure that component default values UNCHANGED by the

user would automatically be changed to their new counterparts, and, in

case the user DID change something, this change would NOT be destroyed.

Andreas Weidner

Hello,

On 04/02/12 10:29, Andreas Weidner wrote:

Am 30.03.2012 16:45, schrieb Christian Bohrer:

>> Currently, the VALUE attribute is always used to initialize the Value

>> of a part in a schematic, whatever its status (ON / OFF).Very well!

 

YES!

 

>> The problem is that it only happens the first time the part is added

>> in the schematic.

>> If I replace the part or if I change its technology, its VALUE is not

>> updated.

>> The VALUE of the part remain this one of its first placement.

 

That's NOT so nice...

 

>> It is not only very annoying but it is also a source of errors!

 

YES, that's quite definitely a source of errors!

 

>> This is why I propose that the VALUE attribute (if exist) is also used

>> to update the VALUE in the replacements and changes of technology.

 

YES, please! The algorithm could look a little bit more sophisticated,

e.g. as follows:

1. If the component is REPLACED, the current value is ALWAYS replaced

    by the VALUE attribute of the NEW component (in case such an

    attribute exists). If NO such attribute exists, proceed as

    currently implemented.

2. If the component PACKAGE is changed AND the new package contains

    a VALUE attribute AND the current component's value has NOT been

    changed from its default, change the component's value to the

    new package's VALUE attribute. Otherwise, proceed as currently

    implemented.

3. Same as (2), but for changing the TECHNOLOGY.

 

The above would assure that component default values UNCHANGED by the

user would automatically be changed to their new counterparts, and, in

case the user DID change something, this change would NOT be destroyed.

 

Andreas Weidner

 

 

Thanks for your ideas !

Currently nothing in this direction happens, it was like this also in V5.

This is a tricky and confusing topic. There are at least 2 more cases:

1. The existing part/element's device has no attribute VALUE, but the new device has one.

2. The existing part/element's device has no attribute VALUE and also no user defineable value.

To make things simpler I tend to say that in any case (change package, technology

and replace) the values get overridden if there's a VALUE attribute in the new device.

In both case I would prefer to update the value by the VALUE attribute.

So the general rule would be:

If a user uses devices with an attribute VALUE by whatever command, he gets the

value of VALUE as part/element value.

This can be compared with the behaviour of other attributes:

If a user has a part/element with a device with library attributes and changes this with

replace/change package or technology, all attributes get replaced by the new

package's or technology's attributes and their values.

This is for library attributes, not for schematic or board attributes !

These attributes will be kept in any case.

Originally we thought that a device's value is something that should be defined in the

schematic or board. Supporting value definition in the library by an attribute VALUE

is more like a workaround and no standard case.

Regards,

Walter Spermann

--

-

Walter Spermann

Softwareentwicklung

CadSoft Computer GmbH

Pleidolfweg 15

84568 Pleiskirchen

Tel.: 08635/6989-10

www.cadsoft.de

-

Registergericht: Amtsgericht Traunstein HRB 5573

Geschäftsführer: Thomas Liratsch

-

Hello,

On 04/02/12 10:29, Andreas Weidner wrote:

Am 30.03.2012 16:45, schrieb Christian Bohrer:

>> Currently, the VALUE attribute is always used to initialize the Value

>> of a part in a schematic, whatever its status (ON / OFF).Very well!

 

YES!

 

>> The problem is that it only happens the first time the part is added

>> in the schematic.

>> If I replace the part or if I change its technology, its VALUE is not

>> updated.

>> The VALUE of the part remain this one of its first placement.

 

That's NOT so nice...

 

>> It is not only very annoying but it is also a source of errors!

 

YES, that's quite definitely a source of errors!

 

>> This is why I propose that the VALUE attribute (if exist) is also used

>> to update the VALUE in the replacements and changes of technology.

 

YES, please! The algorithm could look a little bit more sophisticated,

e.g. as follows:

1. If the component is REPLACED, the current value is ALWAYS replaced

    by the VALUE attribute of the NEW component (in case such an

    attribute exists). If NO such attribute exists, proceed as

    currently implemented.

2. If the component PACKAGE is changed AND the new package contains

    a VALUE attribute AND the current component's value has NOT been

    changed from its default, change the component's value to the

    new package's VALUE attribute. Otherwise, proceed as currently

    implemented.

3. Same as (2), but for changing the TECHNOLOGY.

 

The above would assure that component default values UNCHANGED by the

user would automatically be changed to their new counterparts, and, in

case the user DID change something, this change would NOT be destroyed.

 

Andreas Weidner

 

 

Thanks for your ideas !

Currently nothing in this direction happens, it was like this also in V5.

This is a tricky and confusing topic. There are at least 2 more cases:

1. The existing part/element's device has no attribute VALUE, but the new device has one.

2. The existing part/element's device has no attribute VALUE and also no user defineable value.

To make things simpler I tend to say that in any case (change package, technology

and replace) the values get overridden if there's a VALUE attribute in the new device.

In both case I would prefer to update the value by the VALUE attribute.

So the general rule would be:

If a user uses devices with an attribute VALUE by whatever command, he gets the

value of VALUE as part/element value.

This can be compared with the behaviour of other attributes:

If a user has a part/element with a device with library attributes and changes this with

replace/change package or technology, all attributes get replaced by the new

package's or technology's attributes and their values.

This is for library attributes, not for schematic or board attributes !

These attributes will be kept in any case.

Originally we thought that a device's value is something that should be defined in the

schematic or board. Supporting value definition in the library by an attribute VALUE

is more like a workaround and no standard case.

Regards,

Walter Spermann

--

-

Walter Spermann

Softwareentwicklung

CadSoft Computer GmbH

Pleidolfweg 15

84568 Pleiskirchen

Tel.: 08635/6989-10

www.cadsoft.de

-

Registergericht: Amtsgericht Traunstein HRB 5573

Geschäftsführer: Thomas Liratsch

-

Am 03.04.2012 10:27, schrieb Andreas Weidner:

Therefore, you type 'a ad797s' and get this opamp in the

SO-8 package. Quick and simple. BUT under normal circumstances,

the device value now shows 'AD797S', and my students often

ask me to buy this AD797S, because the stock is empty. It

ISN'T empty, of course, but this IC is NOT labelled 'AD797S'

by Analog Devices, but 'AD797ARZ'.

As a matter of fact, about one minute ago, a student did INDEED ask

EXACTLY that question: It was about the 'S' suffix in some (old)

schematic, and it was even the AD797. Strange...

Andreas Weidner

Am 02.04.2012 17:27, schrieb Walter Spermann:

To make things simpler I tend to say that in any case (change package, technology

and replace) the values get overridden if there's a VALUE attribute in the new device.

THAT of course is also possible. It's perhaps not as nice as one wishes,

but it's still MUCH nicer than apparently implemented now, and it has

the benefit of simplicity. Yes, please.

Originally we thought that a device's value is something that should be defined in the

schematic or board.

Yes: For devices with VALUE=ON, that's nearly always the case.

No: For devices with VALUE=OFF, the value comes from the LIBRARY and is

automatically created by a mathematical construct, which, QUITE often,

does NOT yield the desired text.

Examples:

  1. Manufacturer's IC suffixes are not standardised and therefore

     rather confusing. In order to not having to memorise all

     thousands of suffixes, our libraries use the suffix 'S' for

     (standard) SMD packages - independent of manufacturer.

     Therefore, you type 'a ad797s' and get this opamp in the

     SO-8 package. Quick and simple. BUT under normal circumstances,

     the device value now shows 'AD797S', and my students often

     ask me to buy this AD797S, because the stock is empty. It

     ISN'T empty, of course, but this IC is NOT labelled 'AD797S'

     by Analog Devices, but 'AD797ARZ'. Therefore, one wishes for

     an EAGLE value of either 'AD797' (ignoring the suffix, because

     one SEES what package is necessary) or 'AD797ARZ' (which is

     the manufacturer's code).

  2. The diode 1N4148 has about 24 different packages in our

     library: Pad distances of 0.1", 0.2",..., 1.2", each with

     large pads (easily solderable for our students) and smaller

     pads (for dense layouts). WITHOUT default values in the

     library, you would get either NO value at all (VALUE=ON) or

     values like '1N4148-01N', '1N4148-02N',... (VALUE=OFF).

     Here, for ALL cases, one would like to see JUST '1N4148'

     as value.

  3. All ICs in our libraries have SEVERAL flavours of DIP

     packages: One with large pads (easily solderable), one with

     long pads (easily solderable, through-pin routing possible)

     and one with reduced pads (for dense layouts). The value

     of ICs using EITHER of these packages should be the SAME,

     because it will be the SAME component (just the board copper

     changes).

Supporting value definition in the library by an attribute VALUE

is more like a workaround and no standard case.

As shown above, the possibility of DEFAULT values in libraries does NOT

seem to be a workaround for me, but a QUITE valuable addition, because

ALL devices (defined with VALUE=OFF) in ALL my libraries will be

equipped with such a thing...

And since we have THOUSANDS of devices with VALUE=OFF, but only a

limited number with VALUE=ON, the 'workaround' with the value attribute

will become OUR standard (at the moment, I simulate this with a

self-made attribute called TYPE, but this doesn't work anymore in

version 6 in case variants are used).

Andreas Weidner