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

A useful capability that Alibre does not have.

Discussion in 'General Discussion' started by JST, May 16, 2019.

  1. JST

    JST Alibre Super User

    Some CAD programs have the ability to link to supporting documents. Those may be data sheets on stock parts, or the calculations etc for a part that was designed, or any other information that would be handy to have when using the part..

    While it is most typical of PC CAD programs, a version of this was present in 2D AutoCad, for instance.

    The full version of the feature has the ability to select the outside document, by right click or other means.
  2. NateLiqGrav

    NateLiqGrav Alibre Super User

    This could easily be done in AlibreScript. If someone doesn't get to it first, then I will.
    Mika likes this.
  3. Lew_Merrick

    Lew_Merrick Alibre Super User

    I argue that the Package system needs to become significantly more flexible and powerful. No 1 on my list would be to incorporate all Drawing files within a Package (as an option). No 2 on my list would be some means of "associating" external files (say: documents, spreadsheets, and the like to Alibre Design files) such that they get "included" into the Package. No 3 on my list would be for the Un-Package function to allow the user to select a "make all "subsidiary Directories" to be created "below" the primary (if you will) "Project Un-Package Directory." So says somebody who will not have to develop such code.
  4. JST

    JST Alibre Super User

    Yes, I think both of us, and others, have suggested that.


    The directory should be able to be temporarily over-ridden at any time, but should default back to the selected work directory. It should be stored with the project, so that ALL saves or opens, prints, etc default to that location.

    It is NON-PROFESSIONAL to have a save or fetch come from some other location that just happens to be the location used for that action back last week for some other project. MULTIPLE people who use the program for paid work have mentioned this, and some others have said that it was a prime reason why their employer refused to consider Alibre.... because there were not "persistent" settable default directories for ALL actions, on a per-project basis.

    Work directories are a necessity, and I am VERY DISAPPOINTED that Alibre considers them so unimportant and perhaps even actively opposes allowing them.

    Should we expect that next year's release might have this? I do not wish to seem snippy about the matter, but really, the issue of setting a default work directory for a model/project seems as if it would take relatively little programming compared to other "bling" features that HAVE been implemented.
    Last edited: May 17, 2019
    Mika likes this.
  5. Lew_Merrick

    Lew_Merrick Alibre Super User

    Organizing Project Data:

    Let's discuss the organization of "Design Data." I normally discuss such things in terms of a "Project." Thus, I begin witha "Project Directory." It will contain the "Installation Model" (often called "Top Assembly Model"); documents thatdefine4 the goals and requirements for the Project; authorizations for undertaking the Project; componet Parts used within the "Installation;" Drawing(s) of the "Installation;" and the Sub-Directories providing "design and documentation space"for (if you will) "Major Assemblies." [I am coming to believe that a "Standard Hardware" for things such as: nuts,bolts/screws, washers, dowel/roll pins, and the like is worthwhile as a "Top Sub-Directory" is worthwhile as well.]

    Thus, my "Project Directory" will have (immediate) Sub-Directories of (say) "Major Sub-Assembly 1," "Major Sub-Assembly 2," "Major Sub-Assembly 3," ... "Major Sub-Assembly X," "Common Hardware;" and "Parts." Each "Major Sub-Assembly" (Sub-)Directory will be comprised of "Sub-Sub-Assembly 1." "Sub-Sub-Assembly 2." "Sub-Sub-Assembly 3." ... "Sub-Sub-Assembly X." Continue this direction to (say) "Sub-Sub-...Sub-Assembly" and you should be able to see where I am heading with this.

    Now, let's discuss (say) "Sub-Sub-Sub-Sub-Assembly" "90°Weld Gusset 4-00 X 9-00 Tall.AD_Asm." It is actually used across several "Sub-...Sub-Assenblies" defined within different portions of the "Project Directory Tree." This is why a "Parts List" (as defined by U.S. MIL-Q-9858) becomes improtant. I started building such "Parts Lists" in 1983 using the "Project GNU" spreadsheet developed at MIT as it allowed "hyperlinking" files to spreadsjeet cells. Thus, it is relatively simple to track where and how many of each component Part or Assembly is used within a Project. Among the advantages of this approach, knowing that Part "XYZ" is made from (say) ASTM A36 Bar that is .500 X 1.500 X 8.50 Long it is relatively easy to see that (say) 16 of them are required to create one "Project" and that 136 (plus a skoosh) inches would be needed. As such "bar" is usually stocked in 12 ft (144 inch) long pieces, ordering it as a "12 Ft Bar" is both less expensive and is faster for the supplier to make it ready for pick-up.

    More to the point, it is relatively simple to "sort" entries in a spreadsheet to finmd all the Parts being made out of "ASTM A36 Bar .500 X 1.500" stock and place them together into a single "material order." These kinds of advantages stack up in a hurry creating the type of "project management, oversight, and documentation" that is "promised" (but never "delivered") by "ISAO-9002." We could make this a reality!
  6. Mika

    Mika Senior Member

    This sounds like a pdm projects, or siemens teamcenter alike datasets etc.
  7. JST

    JST Alibre Super User

    Don't make it more than it is.

    You COULD take it that way. Let's don't do that.

    What I suggest instead is to have one entry set the save/fetch/print directory, for all the disk-interactive commands. That way, anything you do or save defaults to one place, and things do not get lost into places they are not intended to go.

    If you open any model in a directory, that action should automatically set the default directory for all actions to be that location.

    There are refinements, which I can go into, but that is the basis.
  8. Mika

    Mika Senior Member

    Ok. Then it should be the inventor like ”single user project”, where you can define that ”project” working folder. Yes, that would be nice addition to Alibre.
  9. Mika

    Mika Senior Member

    It just need some kind of project root file, which one include that base data. So if you want to continue working with fresh installed alibre, you can easily bring back that working folder on the front page of Alibre....No need any cloud/vault crap, just a root file and locator/activator on the front page.
    NateLiqGrav likes this.
  10. Mika

    Mika Senior Member

    Yes, please. If you need some help or more ideas, just send me the PM.

  11. JST

    JST Alibre Super User

    I think it has to be in Alibre...... not a script.

    A script to change all the references would last only as long as the first time a save etc was made to a different location. Then that last save location would be the NEW default, just as it is now. That is what the idea is intended to avoid.

    The idea here is that you could override the default for one save or fetch, but that the default would still be in effect after that temporary override. I think a script would be very complicated to handle that, as it would need to be invoked every time a save etc was done.

    The problem is in the Alibre code, and it needs to be fixed there.
    Mika, NateLiqGrav and albie0803 like this.
  12. albie0803

    albie0803 Alibre Super User

    We need this!
    Mika likes this.
  13. idslk

    idslk Alibre Super User

    Hello colleagues,

    see this as only a "workaround"...

    upload_2019-5-19_12-30-26.png upload_2019-5-19_12-30-37.png

    -it has to be manually configured ("hardcoded" in this version)
    -the folderlist is independent from the part or assembly
    #Define Projectfolder and Names for the Dropdownlist
    #format ([ Name to see in Dropdownlist , folderlocation in filesystem ])
    projectfolders = []
    -it adds automaticaly the file extension (this version only AD_PRT and AD_ASM)
    -it does not check if a file would overwrite an existing file


    Attached Files:

    oilman likes this.
  14. NateLiqGrav

    NateLiqGrav Alibre Super User

    To get rid of confusion I was talking about making an Alibre Script that simply lists names and links to additional supporting documents. The Topic changed drastically after I said that to now include at least 2 other things (which I think are also need but requires Alibre to fix internally).
  15. NateLiqGrav

    NateLiqGrav Alibre Super User

  16. JST

    JST Alibre Super User

    The linking is part of one package with the "other topic". Mixing the two would be the ideal, so that a complete design package with linking can be put one place.

    It is possible to do it now, but only externally, through a PDF design document which is assembled or produced separately from Alibre. The good news about that is that it can be read by anyone. The bad news is that it is not nearly as helpful during the design process.

    I realize that I am one of those on here who see, and use, Alibre as a design tool. That totally changes my approach to it, leading to ideas for features which are not ones needed for using Alibre as a simple drafting and documentation tool.
  17. Lew_Merrick

    Lew_Merrick Alibre Super User

    Actually, it is the Project Form that was required by the Unix Version of MIL-Q-9858 in the late-1970's. I stole it fair and square!
  18. H-L-Smith

    H-L-Smith Senior Member

    You folks are way ahead of me on the specifics here, but I very much want to encourage this conversation. My work volume isn't high enough to really justify the computing resources (& complexity) of a PDM. However, I have many times come back to a project in 6 months wondering, "Where the h*ll did I put that part {drawing, assembly, etc}." This idea of project working directories, "bundled" drawings, etc., sounds very good to me. Organization is our friend.
  19. Lew_Merrick

    Lew_Merrick Alibre Super User

    Adding to this Discussion, it is useful (and in certain industries required) to add Rev level and Drawing Change Notice (often shorthanded as ADCN) to the Filename so impacted. Thus, many of my Models and Drawings get named (say) "ABC-xxxxx -- This Thing -- Rev New -- ADCN 0" at their initial Release. As things change, the "ADCN 0" gets changed sequentially to "ADCN 1," "ADCN 2," etc. and "Rev New" gets changed to: "Rev A," "Rev B," etc. There should be a simple way to make such "revisions" within the context of the Project (and to have the General Properties->General=>Part Data update in accordance with such a Filename change. Similarly, there should be (if you will) Text Blocks associated with such Revision and ADCN values where descriptions as to what has been changed and why such a change was required that becomes part of the Model and Drawing hisorical documentation!

Share This Page