1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

File Properties->General->Part Data

Discussion in 'Using Alibre Design' started by Lew_Merrick, Jan 11, 2018.

  1. Lew_Merrick

    Lew_Merrick Alibre Super User

    For too long we have been limited by the exceptionally poor "offerings" made under the guise of "Part Data" in Alibre Design. Yes, it is possible to use one defined value for another purpose, but you have to document (and remember to check your document regularly) to get that approach to work.

    This thread is intended to provide feedback to Alibre as to how the Part Data system could be made useful.

    Attached Files:

  2. simonb65

    simonb65 Senior Member

    I think there should be standard 'built-in' fields which are not end-application specific and custom fields that can be user defined and added to, which are stored in a Part Template. That way, a template can be created depending on your end-application (like 2D drawing templates) and those have part data which is relevant.

    The custom fields should be similar to parameter data in their ability to be added at will. The template needs to have the ability to store a default value (even if that's blank, N/A, etc). Each field in the template needs a 'mandatory flag' to force the user to enter the data and not leave it empty! 'cos whats the use of having part data fields if you'll only occasionally use it!!

    All part data should be accessible in tables/2D drawings/formula as 'tokens', so the data can be processed, summed and/or just displayed down the line in 2D drawings.
  3. Lew_Merrick

    Lew_Merrick Alibre Super User

    Simon -- While I do not disagree with what you are saying, if you read the document I posted you will find specifics.
  4. simonb65

    simonb65 Senior Member

    Totally agree with you and the specifics/flexibility you document provides. I would add that wherever it is stored (i.e. template, csv, etc). The editing and management of that needs to be provided by the AD and not just an external 'text editor' or excel spreadsheet editing exercise. If the application uses the functionality, it must manage it too.
    It definitely is one area of the application that needs improving.
    JST likes this.
  5. PaulProe

    PaulProe Senior Member

    Like your ideas and also Simon's comment that some of the fields should be 'user variable' so it could be made to fit various industries or systems. If done properly, could it be a replacement for M-Files? A little app to manage drawings using these fields?

  6. Lew_Merrick

    Lew_Merrick Alibre Super User

    Paul -- [Dating back to Generic CADD days,] In my arguments with respect to Global Variables (which are not Parameters) one of the points i make rather constantly is that there should be a "path" to move a Local Variable into the Project Variables dataset and use it anywhere in a Project.
  7. RocketNut

    RocketNut Alibre Super User

    I use Global Parameters a lot when sub-assemblies have a common part that must be in sync. with each other. Like in my Variable AeroSpike Cowl model. Each pedal is linked to each other using a single Global Parameter.

Share This Page