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

Data/BOM/PDM?

Discussion in 'Using Alibre Design' started by PaulProe, May 22, 2019.

  1. PaulProe

    PaulProe Senior Member

    I am working on a project that involves the entire drivetrain and most bodyparts of an automobile. Up until now, I've been able to keep track of things in my feeble mind. But that is becoming more and more difficult. (Not sure if it is the project or my mind, but that's a different discussion)

    I do not have M-Files on my machine and I haven't been able to get my arms around any form of project data management system. I am not a big shop, so the large dollar systems just don't fit my budget. On top of that, I'd sure like to have something that integrates with Alibre, I am committed to that platform.

    Can anyone make suggestions or ideas on how I can come up with a workable system. Would be nice if it were automated into Alibre, but I realize that isn't going to happen. Any ideas on other work-arounds?

    Thanks

    Paul

    ps: Max & company; is this something that Scripting could handle or is there a developer account that would allow access to some of the basic data in the drawings? Maybe a simple connection could be made to another program?
     
  2. idslk

    idslk Alibre Super User

    Hello Paul,

    there are similar questions about a "PDM" in different threads. The latest One of them seems to be this one...

    Regards
    Stefan
     
  3. Lew_Merrick

    Lew_Merrick Alibre Super User

    Hi Paul -- It is not truly simple, but if you creae BOM lists of eash Assembly you can Export them as CSV files. So, you can create "lists" of component Parts and Sub-Assemblies that will tell you how many of each Part or Sub-Assembly goes into each Assembly. It is then "merely" a case of "sorting" each component Part or Sub-Assembly into a "list" and copying such data into another worksheet where the components are "listed" in an "offset area" such that each "progressive Assembly" gets a Column such that you can define how many of "X" Parts and Assemblies get applied to other Assemblies making up the Project. Creating a "Total Quantities Required" (Columnar) listing "merely" takes effort. You then end up with what was defined under MIL-Q=9858 as a Parts List Matrix. I am trying to work with NateLiqGrav to automate this process. It is not trivial.
     
    NateLiqGrav likes this.
  4. NateLiqGrav

    NateLiqGrav Alibre Super User

    Without knowing your specific needs I can't say for certain what is best for you. Please describe how you would need it to work.

    I have made a cool script that lets you embed links to additional files right into your Alibre Parts and Assemblies. I will release it tonight.

    I have another script that lets you make a project matrix from an assembly. This is nearly done but not done yet.
     
  5. TimoCAD

    TimoCAD Senior Member

    Something like the "Solidworks Explorer"?

     
  6. idslk

    idslk Alibre Super User

    Hello Nate,
    using SetUserData and GetUserData? ;-)
    grettings
    Stefan
     
  7. NateLiqGrav

    NateLiqGrav Alibre Super User

    Yeah - but you know me - I went overboard.
     
  8. Lew_Merrick

    Lew_Merrick Alibre Super User

    The following is a "General Guide" -- though I want to take it much further...
    Parts List Example.PNG
     
    swertel likes this.
  9. PaulProe

    PaulProe Senior Member

    Lew, does this process also include the path/folder where the components are listed? One of the biggest issues I face is 'where is stuff'

    Paul
     
  10. NateLiqGrav

    NateLiqGrav Alibre Super User

    Yes, When I release the Project Matrix script it will. Until then there are a few options available.

    Option #1
    In Windows Explorer; Right click on an Alibre file and click Constituents for a tree of all parts required for that drawing/assembly/part.
    OR
    In the Alibre Home window; Click the Utilities Tab, then Show Constituents, then select the Alibre file.

    Option #2
    Run this Assembly Tree script in the assembly. Note: This will list each part/subassembly every time it sees it.
    https://www.alibreforum.com/forum/index.php?threads/assembly-tree-v2.20690/
     
  11. NateLiqGrav

    NateLiqGrav Alibre Super User

  12. swertel

    swertel Alibre Super User

    That is a beautifully matrixed BOM / parts list.
     
  13. Lew_Merrick

    Lew_Merrick Alibre Super User

    Paul -- If you check out virtually any of my (posted in Resourses) Libraries you will see that I maintain a worksheet where File Paths are maintained such that it is trivial to create concatenation llists that allow (in a spreadsheet) direct hyperlinks between the Part Number: call-out and the associated File.

    I have an alternate spreadsheet format that allows me to assign Part Numbers, Descriptions, and Revision Levels to a Project as it is being defined. There are a number is "instances" where such an "assignment" includes such information as: Type of Assembly (Installation, Major Assembly, Minor Assembly, Sub-Assembly, Sub-Sub-Assembly, etc.), Type of Part (Make, Buy, Critical Inspection, etc), and the like. Thus my File Name consists of "Part Numbe" -- "Description" -- and "Revision Level." I can copy that from my "Project Part Number Identity Spreadsheet" directly into (A) the File being created as well as the appropriate location within that File as well, if required, into the {Parts List.

    Does this make sense to you?
     
  14. JST

    JST Alibre Super User

    One can do a lot with a hierarchical directory structure, but the way Alibre does store and retrieve can make that very difficult to work with. Things go into places you do not want or intend them to go, unless you are very, very careful.

    There are some simple solutions that could be put in the program, but they do not solve the issue of large designs and many sub assembly levels of the product.

    Ultimately, Alibre ain't Catia...... but it could be a lot better. Just one simple change could make it acceptable to more businesses.... setting up work directories as the default place things are stored or obtained from.

    Stefan, that is not, or was not intended to be PDM.

    I'd be reasonably happy if we could just set a work directory where ALL files and file types were saved and retrieved from by default, with the ability for one-time exceptions, after which it returned to the default. Automatically re-established when an assembly is opened, or settable.

    The linked document idea might go with that, but I would not make them one request, the work directories are far more important..
     
  15. Max

    Max Administrator Staff Member

    JST, et al., in as much detail as possible could you describe what the options for work directories would do, what it would look like, etc.

    Example: when you create a new assy, does it prompt you to set your work dir? Is it larger than that, for example you dont start with parts or assemblies but rather New Project... etc.
     
  16. JST

    JST Alibre Super User

    This is something that can get as complicated as you want it to be. I think keeping it simple for now is best. Once it is available. many folks will probably have ideas. And I think is should be a settable global option, some will be fine as it is now, and won't like being forced to do things differently.

    The problem to be solved is that the various saves of different things default to whatever THAT function last saved to. So things from THIS project may be erroneously saved to THAT project, which happens to be the one that last used that function.

    The plan is to have ALL the storage interface commands at least optionally using one location, so every store goes there by default, and every fetch comes from there by default.

    This is ALREADY TRUE for parts.... they save to the place they came from. But it is not universally true.

    I think it should be optionally possible to set a project directory that is the default location for everything until further notice. A global setting of "use project directories" vs "classic directory usage" (what we have now) would probably satisfy everyone.

    When you start a new part, it would show the default of the current work directory when you save, but give you the option to change work directories. Same for the first part opened when you fire up the program.... something like "do you want <new location> to be the new work directory?".

    You should be able to open from or save to a different place. But you should get a notice that you are doing so, and be offered the chance to change the working directory. If not, the default should remain the same.

    Possibly there should be a check box for selecting NOT getting the notice and just defaulting back to the current directory after the one-time save or fetch. In that case you would have to use the "change working directory" command to make the change.

    Some of this can be "directed" by the selection of "SAVE" vs "SAVE AS". "SAVE" would go to the current with no questions, but "SAVE AS" would ask the question. You might want to do just a one-time "SAVE AS" to a different place, or you might actually want to make a new project location.

    But some other things may not distinguish between a "SAVE" and "SAVE AS". I can never recall which always go to a predictable place, and which do not, so I get caught by this regularly.

    If you follow the lead of the PWB layout programs, there could be sub locations for filetypes, as with PWBs. Assemblies in a top level, parts in one subdirectory under that, BIP in another, export files in a different one, JPEG, etc in their own. While I kind of like that, I am in "be careful what you ask for" mode here, and I do not want to get too fancy. That segregation could be good, but it also might have issues that I have not and maybe cannot foresee. Unless it is dead easy to see where that goes, I'd not fool with it.

    If there are logical consequences that seem ambiguous as to what is wanted, feel free to ask, I may not have seen the issue.
     
    MikeHenry likes this.
  17. dwc

    dwc Alibre Super User

    And, most importantly, it must be possible to create library directories for standard parts or assemblies that are never changed.
    Parts or assemblies in a library directory will not be saved (and create no file save error) even by a "save all".
    Some kind of override must exist to be able to create library parts.
    Don
     
  18. JST

    JST Alibre Super User

    That actually is at least partly COVERED by my suggestion.....

    The one-time fetch from the library would afterwards DEFAULT to saving in the work directory, and would be sourced from there when working on that project.

    I realize that is not perfect, in that the library part might be updated, etc, etc. and the "real" solution always loads library parts from the library and only from the library. I know that what you (and I also) really want is the ability to have a part always be sourced from the library (unless "packaged out"), but NOT EVER be stored back into the library unless separately and deliberately by an authorized person. OK.

    That ideal situation is totally compatible with the work directory. But for the moment, the work directory would at least avoid a "save-back" into the library, so it is a workable first step.

    Yes, I want a real library capability, where the new parts are stored into the work directory, and library parts DO NOT GET STORED from a model, but only if the library part is formally opened for editing. But I do not want to ask for too much at one time.
     
  19. NateLiqGrav

    NateLiqGrav Alibre Super User

    From a previous discussion of default save locations:
     
  20. JST

    JST Alibre Super User

    A useful extension is to pull in some of the others as well. Such as template and blank drawing.

    Global setting for each of those: "Normal" (what it is now) or "from current work directory"
     

Share This Page