4 Replies Latest reply on Apr 11, 2019 6:11 AM by johnduquette

    PADSVX.2.4 Logic to PADSVX.2.4 Designer library & Databook  migration


      I´ll try to explain myself.

      We´re using PADS Standard Plus Vx.2.4.

      Recently we created a complete library from PADS Logic and I would like to know the process to migrate correctly this library (multple *.pt9 files, each *.pt9 is a family, take for example resistors, capacitors etc...).

      Each component in the *.pt9 files has already a symbol and a footprint, but also multiple attributes such as manufacturer, PN, value etc...


      I know I can use the library migrator but, when migrating one of the *.pt9 files we found the following issues (after configuring to my needs the CLMigrator.cnv) :


      Please find these thre first question regarding the Library Migrator:


      1.- One of the attributes of the components is Geometry.Height and it´s set to mm. It seems PADS Designer Height property is set in "th" (mils) and it can´t be changed (already checked the "Property Definition Editor" of the Central Library and it seems to be a system property so it can´t be changed....).


      Is there any way to solve this?


      2.- Resistors, caps and inductors "Value" field seems to be converted to PADS Designer numeric field. I understand this is because "Value" field in Designer is real field and

      it detects the "k", "u", "n"... preffixes for each family and converts it to numerical value.


      So, how good is this conversion? Do we have to check all the value fields after migration? I understand we should always do this...I only want to know.

      Could you please confirm?


      3.- Other components such as ICs, or transistors, have their PN typed in the value field so that PADS Logic is capable of showing this value when placing a component in the schematic. But when migrating it seems to be a problem as Value is a system property and is a numerical value. Logically, when integrating an IC with PN in "Value" field OP3964 will make the migrator remove that field from the PADS Designer Central Library side.

      Could you please confirm the only thing will happen here is that the field "Value" will not be added to the part?




      Now, regarding Databook and library management:


      So, once the migration is done all parts have been added to the library and each part has all the attributes in the central library.

      Now, what really worries me here is the following:

      If I want to use Databook for component management I find I will have attribute duplicities for each part of the central library, correct?

      This is, the attributes migrated using the library migrator and stored in each part of the .lmc and the attributes shown in the databook

      tables (let´s take for example I use Access). For example, the field "Manufacturer Pn" will be stored in the central library and in the database...

      This architecture is kind of unstable and will make component management a pain...if one attribute is changed in databook but the lmc part still has the

      old value for that attribute...which one is correct?...This is not a good way of managing and controlling the library.


      On the other hand, I tested one thing:

      Connecting a Central Library with only symbols and footprints (no parts) to a Databook.

      This makes much more sense to me as the unique ID and part is stored as a unique entity in a unique place, in the Access, database or excel used to fetch the data using the ODBC. Following this architecture the databook was able to link each component to the schematic symbol, but not to the footprint.


      So, what really worries me here is the following:


      If I want to add a new component to my database, do I have to:


      1.- Create a new part in the central library with the same Part Number

      2.- Add a new component in the Access, Excel or database with the same Part Number.


      Really????? sorry but it sounds strange. Can anyone explain me the reason for this?

      Is it really necessary to create a "New Part" in the lmc when the new part is already created in the Access, Excel or database?


      So, in case this is correct, I think a way around to manage this without duplicating all attributes, only Part Number would be (using Excel for example):


      1.- Export al components as .lst file from Logic and format the document to fit PADS Designer

      2.- Remove all attributes from components in PADS Logic. * This has to be done to remove any attribute duplicity (is there any option to remove all attributes from all parts in the central library? That would be great!)

      3.- Migrate to PADS lmc. Componénts will be migrated without any attribute

      4.- Create new connection to Databook

      5.- now components in Databook will link to parts in lmc by Part Number.


      Please give feedback on this.


      Thank you.



        • 2. Re: PADSVX.2.4 Logic to PADSVX.2.4 Designer library & Databook  migration

          There are lots of questions, and unfortunately I don't have a license to VX.2 anymore so I can't give full answers.  I can say that you are on the right track. I don't see any questions where your best guess is incorrect. 


          I've gone through this process before and it isn't easy.  One item to know that (at least as of VX.2.2) Designer would use the Central Library while Layout is still using the pt9 and pd9 libraries.  You have to make sure they stay in sync.


          I know in Logic you can define 'geometry height' as 1000th or 25.4mm; hopefully the 'translator' can figure out the unit conversion.


          The Value field needs to be 'real' for the prefixes to work, and then they work really well.  Your text values will need to get shifted to another property.


          Good luck.

          • 3. Re: PADSVX.2.4 Logic to PADSVX.2.4 Designer library & Databook  migration

            Please tell me that PADS Designer and PADS Layout use the same central library in version VX.2.4, because if not I really don´t understand a thing about the people that have developed this piece Software.

            For sure a migration is not straight ahead, but the bulky and not easy, not fluid workflow of PADS Designer + PADS Layout makes it much harder, including multiple inconsistencies in data integrity (such as the one of having to add a PART TYPE in the *.lmc when it has already been added in the Databook, for example, this one, being a critical issue in library data management).


            Nonetheless, as I´m going to work much more with this ECAD I will for sure summarize my opinion of all PADS Standarad Plus ECAD framework to make it visible to all ECAD designers on how it differs from others, including positive and negative things about it.

            This is of course personal opinion, but for sure will enlighten multiple user that are not decided on which ECAD to use.

            • 4. Re: PADSVX.2.4 Logic to PADSVX.2.4 Designer library & Databook  migration

              All the library files for DxD and Layout are in subfolders in the same Central Library folder.