File Management? Git? Something else? What are you using to stay sane?

[PaulGupta]

I'm trying to figure out my workflow with Alibre, as I've discovered I have a tendency to write over old versions and thus lose prior work when fiddling with dials and adjusting fit of certain designs. How do you all manage your workflows and designs?

I'm coming from Fusion360 which automatically versioned each save and let me roll back. Is that feature available or do I need to do something like manual git snapshots?

Looking forward to hearing how others achieve this or how the software supports this workflow.

Thanks!

 

[DavidJ]

Coming in version 28, Alibre PDM. Hopefully some details about exact capability will be made available fairly soon.

 

[PaulGupta]

I'm more curious what people *have* been doing for 27 version instead of looking forward to first-release solutions. (Especially since I'm a new user who can't afford to upgrade this year)

 

[PaulGupta]

I was thinking:

1. New part/Project: new git repo
2. Define MVP/README.txt/Measurements.txt/etc for keeping files organized
3. Start designing a part
4. When a part is "finalized" or sent off for review, commit the .ad_prt file
5. Repeat

Does anyone else do this or something similar? I've noticed some "version" stuff in the file save menus, but I'm not exactly sure what they are. Are these files saving changes internally already?

 

[NateLiquidGravity]

I use M-Files which was include with some Alibre Design purchases many years ago. I'm currently the only user on it at my job, but it does have some organizational product flow built in. I mainly use it because every time a file is checked in it's a new version, so I can roll back to a specific version if I need to. It also lets me rename files since it doesn't use the filename for linking.

It is no longer included with any Alibre version and I believe it is priced rather high to purchase independently.

 

[PaulGupta]

I use M-Files which was include with some Alibre Design purchases many years ago. I'm currently the only user on it at my job, but it does have some organizational product flow built in. I mainly use it because every time a file is checked in it's a new version, so I can roll back to a specific version if I need to. It also lets me rename files since it doesn't use the filename for linking.

It is no longer included with any Alibre version and I believe it is priced rather high to purchase independently.

I saw that while searching for solutions! Glad it's working for you. Any recommendations?

 

[NateLiquidGravity]

I saw that while searching for solutions! Glad it's working for you. Any recommendations?

I can't say because I haven't used any other systems in years. I'm really hopeful that the new Alibre built system works even better.

 

[albie0803]

I also use M-Files and acquired it the same way.

 

[simonb65]

I was thinking:

1. New part/Project: new git repo
2. Define MVP/README.txt/Measurements.txt/etc for keeping files organized
3. Start designing a part
4. When a part is "finalized" or sent off for review, commit the .ad_prt file
5. Repeat

Does anyone else do this or something similar? I've noticed some "version" stuff in the file save menus, but I'm not exactly sure what they are. Are these files saving changes internally already?

Hi Paul, I use my own workflow outside Alibre for version control. It used to be CVS, but I've now ported my CVS repo over to GIT (preferred CVS as it was much simpler!). I usually commit when I reach a versionable model (usually when it's used in a project or released to a customer or sent out for manufacture) and I tag my Alibre 'common parts library' before installing a new major version of Alibre, so I always have a snapshot of all my models that I can roll back to if I roll back to an earlier version of Alibre (if it's not behaving or a few new bugs have crept in!).

Hopefully the new v28 PDM covers these simple version and tagging functions and that the PDM not only covers the Alibre files but all the other files associated with a design (i.e. pdfs, requirements, change notifications, release notes, etc) ... which is why I chose a generic 'file' version control system like CVS years ago as it doesn't care what application the file belongs to, it just archives it and allows you to revert changes and have a 'paper trail' of how you got to the project endpoint!

If v28's PDM is not generic, but Alibre centric, I'll be sticking with the process I already have. It's worked flawlessly for the last 20 years and if it ain't broke .. don't fix it, plus I don't want to rely fully on a PDM that embedded in a product that may change, disappear (like previous system have), become obsolete, Alibre change their minds again or I stop using Alibre and move on to something else!

 

[PaulGupta]

Hi Paul, I use my own workflow outside Alibre for version control. It used to be CVS, but I've now ported my CVS repo over to GIT (preferred CVS as it was much simpler!). I usually commit when I reach a versionable model (usually when it's used in a project or released to a customer or sent out for manufacture) and I tag my Alibre 'common parts library' before installing a new major version of Alibre, so I always have a snapshot of all my models that I can roll back to if I roll back to an earlier version of Alibre (if it's not behaving or a few new bugs have crept in!).

Hopefully the new v28 PDM covers these simple version and tagging functions and that the PDM not only covers the Alibre files but all the other files associated with a design (i.e. pdfs, requirements, change notifications, release notes, etc) ... which is why I chose a generic 'file' version control system like CVS years ago as it doesn't care what application the file belongs to, it just archives it and allows you to revert changes and have a 'paper trail' of how you got to the project endpoint!

If v28's PDM is not generic, but Alibre centric, I'll be sticking with the process I already have. It's worked flawlessly for the last 20 years and if it ain't broke .. don't fix it, plus I don't want to rely fully on a PDM that embedded in a product that may change, disappear (like previous system have), become obsolete, Alibre change their minds again or I stop using Alibre and move on to something else!

What do you make sure to export?

So far I've been thinking at a bare minimum any STL(with STEP) files, technical drawings (if needed, not going to do a drawing if I've got the STEP), plus any documentation relevant to the product.

I just saw in a YouTube tutorial that if an Alibre file is in a .zip, when you open it everything will be greyed out, so I plan to start zipping my files to force myself to never overwrite them by accident.

Any recommendations to add onto my plan? Looking for solutions like yours.

I think the STEP is vendor agnostic enough that if for some reason I can't use Alibre anymore I should be set, although I'm pretty confident that I'll continue to be able to use it.

The other reason I'm trying to make a habit of exporting STEP files is for if I need to share source files with people, it's a relatively universal standard to export/import between different packages.

 

[simonb65]

What do you make sure to export?

Every single file in my project directories gets committed in version control when changed or added, so that's .pdf, .docx, .xlsx, .stp, .step, .ad_prt, .ad_asm, .ad_bom, .ad_drw, .ad_pkg, etc. all my keyshot textures, materials, material templates, .bip.

From a 'source' point-of-view, I don't skip any files that were used to create models or render them. If you version the 'sources', you have something to roll back to and re-edit if required.

All the 'Output' files also get commited, so that includes keyshot renders, .ad_drw drawings that are exported as a .pdf., any .step files that get distributed to customers, some get archived just in case I move away from Alibre and I need to import into another CAD package, etc.

The storage space on my server (primary NAS) is big enough not to throw anything away ... as you never know when you'll need it! I even have every release of Alibre installer back to 2012!

... and it all gets backed up onto another NAS every week for safe keeping.

Sounds like a lot of work, but it isn't. After 20+ years, it's just second nature now!

 

[MichaeeeL]

Basically in order to save revisions I made different versions of a same file just adding, to the file, a revision index and save It in the "OLD" folder. Part1_revA...

 

[PaulGupta]

Basically in order to save revisions I made different versions of a same file just adding, to the file, a revision index and save It in the "OLD" folder. Part1_revA...

I'm very much so trying to avoid this. I saw a meme once about how every CAD user (I think it was actually KiCAD, but the principle follows) has a work directory filled with "Version 1.ext, Version 002.ext, VersionFINAL.ext, VersionFINAL002.ext" and it was a hilarious mess. I can't deal with that long term it drives me insane. To each their own, and you're probably getting real work done while I post about file management in a web forum!
-----

Every single file in my project directories gets committed in version control when changed or added, so that's .pdf, .docx, .xlsx, .stp, .step, .ad_prt, .ad_asm, .ad_bom, .ad_drw, .ad_pkg, etc. all my keyshot textures, materials, material templates, .bip.

From a 'source' point-of-view, I don't skip any files that were used to create models or render them. If you version the 'sources', you have something to roll back to and re-edit if required.

All the 'Output' files also get commited, so that includes keyshot renders, .ad_drw drawings that are exported as a .pdf., any .step files that get distributed to customers, some get archived just in case I move away from Alibre and I need to import into another CAD package, etc.

The storage space on my server (primary NAS) is big enough not to throw anything away ... as you never know when you'll need it! I even have every release of Alibre installer back to 2012!

... and it all gets backed up onto another NAS every week for safe keeping.

Sounds like a lot of work, but it isn't. After 20+ years, it's just second nature now!

Do you use git branches or anything like that? Or just commit everything to main/master and keep rolling with it?

 

[simonb65]

I'm very much so trying to avoid this. I saw a meme once about how every CAD user (I think it was actually KiCAD, but the principle follows) has a work directory filled with "Version 1.ext, Version 002.ext, VersionFINAL.ext, VersionFINAL002.ext" and it was a hilarious mess. I can't deal with that long term it drives me insane. To each their own, and you're probably getting real work done while I post about file management in a web forum!

The other BIG problem with this is that if those directories have been copied in windows explorer and not been created using Alibre 'Save As' functionality, then that WILL break a whole pile of internal links in your projects, as every Alibre entity is assigned a unique ID internally. That's how Alibre maintains associated links and constituent links. Break this at your own peril!

A flat file system is not suited to multiple versions of the same Alibre parts/assemblies. It needs to be built on itself, in place using a version control system, unless you want to open a massive can of worms and cause yourself much pain. Saying that, it is perfectly doable, IF you follow the Alibre file management rules consistently and every time.

 

[PaulGupta]

IF you follow the Alibre file management rules consistently and every time

I feel like these are learned slowly, over time, and painfully. Any specific ones I should watch for?

Also, does Alibre not look for parts in assemblies with relative paths? Or are the paths hardcoded full absolute paths?

 

[Ex Machina]

I use OneDrive to do basic version control and backup.

 

[simonb65]

Also, does Alibre not look for parts in assemblies with relative paths? Or are the paths hardcoded full absolute paths?

Sadly, it's a combination of absolute path names and the GUID (globally unique ID). Relative paths would have been so much better! So, moving files and/or copying in windows explorer is a big no no! After all the trouble people have gotten into over the years (loads of discussion on this forum), Alibre have subsequently added a warning to the help manual to help alleviate the headaches ...

 

[HaroldL]

Alibre have subsequently added a warning to the help manual to help alleviate the headaches ...

That works IF people read the help manual.

 

[PaulGupta]

Sadly, it's a combination of absolute path names and the GUID (globally unique ID). Relative paths would have been so much better! So, moving files and/or copying in windows explorer is a big no no! After all the trouble people have gotten into over the years (loads of discussion on this forum), Alibre have subsequently added a warning to the help manual to help alleviate the headaches ...

View attachment 40839

We're I'm glad I started this thread! That's a good page and I never would have found it in the help. Thanks for the share!

 

[PaulGupta]

That works IF people read the help manual.

As someone who has used a lot of different software over the years, I have not read the manual thoroughly yet. I do plan to peruse that though.