Evolution from one user to two

[RaphMORIN]

Hello,

I've been working for many years as a single user on a single computer. In a few months we have planned to engage someone to face our increasing activity.

Of course, we will purchase a new computer with a new Creo licence, but I would need your advice concerning file management considering we won't use PDM. Where should we store files ? How do you deal with config files, such as config.pro ?

Any advice is welcome to make sure everything goes well with this evolution of our working methods.

Thanks.

This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.

[dgschaefer]

With two of you, it shouldn't be too difficult.

On file management, you need a "master' folder and each of you need your own working folders (WIP).  You'll need to be in consistent communication about who is working on what and a procedure for placing completed work back into the master folder.

You will have to resist the urge to fix things that you come across on models that you might not be actively working on.  For example, you bring in a 10 part assy to work on part A in your WIP.  You notice that there is a simple issue with part B, maybe is the wrong layer names.  When it was just you, you'd go ahead and fix it while you're there.  But now, perhaps your coworker is working on part B, or maybe he's working on the same assy but on part C.  When you fix B, now his B is out of date and he's got to go get a new one or you risk him overwriting your changes.

I'd also make sure you understand the ramification of the config settings for saving files and what happens when you use the save as command vs. the backup command.

On config files. Creo will load multipple config.pro files so you can have a "company" file and each of you can have your own file.  You may want to establish a config.sup for options that you don't want changed.  Creo will load them from these places, in order:

1. config.sup in the loadpoint/text folder
2. config.pro in the loadpoint/text folder
3. config.pro in the user's home folder (as set by Windows environment variable)
4. config.pro in the startup folder (as set by the start in field in the creo shortcut)

You can put the company files on the network and use a batch file to copy them in, or you can point your start in folder to the network location.

My general philosophy on config options is that the company only sets options that effect model quality and consistency or give users more flexibility in working. Things that are preferences, like UI colors or if the planes are on or off at startup are up to the user.

[mbonka]

Hello Raphaël MORIN

absolutly agree with Doug Schaefer . Place your company standard to network location.

See attached config.SUP and focus on end part AUTOMATIC DATA CONECTION AFTER CREO START.

    START TEMPLATES

    - start_model_dir

    - template_solidpart

    - template_sheetmetalpart

    - template_designasm

    DRAWING FORMATING

    - pro_format_dir

    - drawing_setup_file

    - pro_symbol_dir

    - symbol_instance_palette_file

    - pro_palette_dir

    - pen_table_file

    - pro_crosshatch_dir

    - pro_table_dir

     LOAD DATA FROM DIFERENT LOCATION

     - search_path_file (see attached search_path.txt --- it´s much more elegant solution, than search_path many times in your configs)

     MODEL ACCURACY

    - enable_absolute_accuracy

    - default_abs_accuracy (if you are using absolute accuracy)

    - accuracy_lower_bound

    GENERALL

    - pro_sheet_met_dir

    - pro_material_dir

    - pro_note_dir

    - pro_group_dir

    - pro_font_dir

    - 2d_palette_path

    - hole_parameter_file_path

See attached CONFIG_CREO_3_M010.pdf for more information.

Make some company modeling rules! "It doesn´t matter, if all of you are modeling the same BAD way or GOOD way. IMPORTANT is working the SAME WAY! Only at this situation you can get quick orientation in work of your collueages".

Who has saved last is the winner! It´s exactly what Doug Schaefer described. If your project are simply and it can be "one man show" than devide individual project between concrete persons. It eliminate substitute between persons, but on the other hand you will never lose data from above described reasons.

l´m sure someone else can say: "This is not important, delete it from config.SUP and put it in user´s config.PRO files." But it dependes on a freedom, that you want in your company.

Hope it can help...

Regards Milan

[dschenken]

Give each user their own sandbox directory and set the config option so that changed files are never saved back to their origin. Spend some time and create a utility to copy files from the sandboxes and change the version suffix to be one higher than the ones that are already there. This ensures that only files that are definitely needed are moved out of the sandboxes. AutoIt, AutoHotkey, or Excel VBA would work well enough.

If you want version control, create a directory for each revision level and set up search paths that evaluate them backwards (Library, sandbox, Z,Y, X, W, ... C, B, A, Preliminary) so that the most recent version will be retrieved first. There will be a performance hit eventually, but by then you'll have Windchill or some such.

I would also suggest setting up a Trello account. Trello website. Srcoll down to see the interface.While just turning and telling someone something is easy enough, there needs to be a means better than sticky notes for when they aren't there and for planning purposes. The price is right and there's nothing to install, but it probably isn't a good fit for Secret information.

[RaphMORIN]

Hello all, thanks for these precious answers. In fact, we work on quite simple projects, "one man show" as you say Milan, so there won't be problems working on the same parts or assembly.

In fact the person we plan to engage is a student that we'll have for two years approximately and will be one week to school and the next week at the company, and so on. The objective is to form the student and hire him at the end. So, it's me who will give the working methods. After working for almost 7 years by myself, my working methods have much evolved and are getting good I think.

I'll apply the organization for the config files you gave and place them on network.

Thanks David for telling about Trello, I didn't know about it.

[TomD.inPDX]

If you have an intern for a year, you might assign this task to him.  I'm going through the same issue now with SolidWorks.

I have worked in a 4 people collaboration.  All the work was done from one server.  History was not a concern.  The server structure was a simple.  Part numbers were 5 digits assigned to groups to people.  The server has a folder for the first 2 digits so 999 parts/asm would be located in that folder.  The search path included all these folders.  A batch routing systematically removed wrongly placed files from the backup routine.  Using save-as backup is very useful, but as David pointed out, this requires maintenance of your server files.  Of course, the rest is due diligence.  For the most part, any wrongly placed parts were simple duplicates of the valid version.  Oddly enough, this rarely, if ever, caused a problem.  This database managed 10's of thousands of part numbers.  The one advantage we had was that people had their own projects and collaboration was limited where overwriting each other's files was pretty much a non-issue.  If it was, it was a simple as sticking your head around the corner into the other cubical.

[dgschaefer]

David Schenken wrote:

... Spend some time and create a utility to copy files from the sandboxes and change the version suffix to be one higher than the ones that are already there. This ensures that only files that are definitely needed are moved out of the sandboxes. AutoIt, AutoHotkey, or Excel VBA would work well enough. ...

Wouldn't simply using File > Save As > backup within Creo do the trick here?  If a file already exists in the target directory, Creo would automatically increment it.  If used on an assy, all the files in teh assy get backed up and incremented appropriately.  No script writing needed, but you do need to understand that it's a complete dump of the parent object and all related files.

[James62]

Yeah, Doug. The backup does work the way you describe, it's just not sure if the backup can be set up to include drawings. Well, at least drawings of the same name as their model references.

What David is proposing there is a utility that isn't really that hard to code, considering that AutoIt and Autohotkey fall into the category of more approachable scripting languages and the script created can be set up to run from Creo.

What Raphaël has to think of is what file types need to be driven and how. There could be files such as the ones generated using Creo NC like *.ncl.*, and also files generated by postprocessing *.nc, *.tap, etc. Should these be stored in the central repository so his new colleague can work on them? Should these go into their own subfolder or should just be purged and not allowed to go into the central repo? Those are the little things to consider.

[dgschaefer]

Good call on the drawings. I did a quick test with rename_drawings_with_object set to both, which should bring a same name drawing along with an assy.  I did a file > save as > backup on an assy with the same name drawing in session and the drawing did not come a long.  Of course, if you back up the drawing you'll get the assy and all the parts.

[dschenken]

Save-As -> Backup backs up all the models. So if a part was released at Rev A in directory A and the assembly was Rev D, the backup would dump the part or the assembly into the wrong directory, either A or D. If it is in the sandbox, it will still have to be moved to the right spot and may have the wrong increment.

I've seen a Back-up system and it becomes terrible. People will go to the release folder for a part and work on the part drawing and make a Backup release folder for that, but not go to the assembly release folder and change the part(s) that were backed-up there. Eventually the full-up assembly is missing changes that were made to parts.

[TomD.inPDX]

The one thing that I never found resolved in CAD is this very issue of when to update the using assembly.

Most systems allow you stop the propagation of revisions at some bin-replaceable subassembly level.  CAD is not that forgiving.

Once the changes are made per the change order, due diligence requires opening the using assemblies and drawings to confirm references were not deleted.

I could never get anyone to understand this until it was way too late.  And yes, the entire set of higher level assembly drawings just went to the crapper when they released a horde of contractors on documentation efforts.  And that with a PDM and a full IT team to manage it!

[dschenken]

The Contractor Horde - rewarded for doing -just their job- no matter the effect on anything else. I figure moving the drawing maintenance to Illustrator might be the way to go. That way there is no unexpected ripple effect and it requires skills more in line with what the Horde typically provides.

The thing about CAD is it should be treated more like software development, which it is. The features are like functions and the parts and assemblies are subroutines. Can you imagine if software development said - it's OK to just change the inputs and outputs expected for functions. Let the guy integrating the software figure it out?

At least in software the number of outputs is typically small for functions and subroutines and the number of inputs is also small. But a single nut has dozens of inputs to get the right shape and dozens of outputs in the form of edges, surface, and vertices. Add in datum planes and axes and it is growing to 50 possible output items that using assemblies might depend on.

All it takes is one guy to open that hexagonal sketch, delete a line and put in another one, and 10 or so of those former outputs are toast, leaving any part depending on them with a hole in its program. Or worse, decide that they want to start over with a revolve instead of an extrude and all those outputs are wiped out.

Not happy with the layers? Sure, why not delete one? Or toggle its status because it's easier to work on the nut that way.

5 levels up in the assembly structure a ton of items are no longer placed and the drawing is missing, seemingly randomly (though there is nothing random about it) dozens of leaders and BOM balloons, and possibly a view origin or a view boundary locating point are missing. And the deleted layers? Those Set Datums that were hidden are back, with a vengence, but sometimes they are buried in a complex model and it takes a while to notice the extra bit.

I planned a talk for PTC Live two years ago about dealing with CAD using methods that have been found good for software, but they called to tell me there was no interest in the topic. I guess they were right.

[TomD.inPDX]

That is an excellent analogy, David.

Thank you!

[dgschaefer]

I love this analogy.  I'm not a programmer, but I've done enough hacking of HTML & batch files to get the concepts.  This is how I naturally think of parametric CAD work anyway, and it pays huge dividends.  Creo responds well to this approach, other packages don't.

It's a bit what I tried to communicate with my "How to Talk to Creo" presentation at the 2008 conference.  I got very favorable responses from some folks, probably the folks who were already thinking this way.  I felt like I didn't quite connect with the masses, however, and I've always wondered how I could have done better.  Perhaps your programming analogy would connect with more people.

[dgschaefer]

We use a backup based system, but it requires a dedicated database manager (DBM) to implement.  Users dump their changed files into an "incoming" folder, the DBM then opens them and integrates them into the master database. In the case of a single part or a drawing of a single part, it's fairly easy (although skeletons add some complexity). For assemblies, the DBM has to know what parts the user had ownership of and then understand the order in which Creo retrieves the files. Then they need to retrieve unchanged files from the master first, and in the right order, then retrieve the user's assy and only then back the whole thing up.  If you don't know the rules and don't pay very close attention, it's very easy to make a mistake.

I'm intrigued by your rev folder based system.  So in the master folder, you'd have a number of subfolders for each possible rev level (A, B, C, D, etc) and when a part, drawing or assy gets rev bumped, it's moved to that folder.  Then you'd have a search path file that looks first in the highest rev folder and then on down to ensure the newest file is retrieved, in case old ones somehow get left behind.  Users work in their own WIP folders, with whatever files they need, but when the work is complete and ready to be released, only the changed files are moved to the master folders.

That would make updating the master less error prone, but would make finding the latest version perhaps a bit more cumbersome.  Right now, I sometimes have to open a part but don't know the P/N and therefore the file name.  Now, I can turn on review add fumble around the master folder until I find it (or give up and look it up or open an assy that I know contains it).  Not possible when it could reside in several different folders.

[dschenken]

You lost me at the last bit - how do you know what to open if you don't know the filename or part number?

Other than that, sure. If one wants to encapsulate a complete work, then retrieve the top level(s) and then export a backup. I guess one might complicate it a bit by adding a revision parameter and running a Creo batch file to open any new files in each revision directory to force the parameter to match so external users know what they have,

[dgschaefer]

I need to open the whatzit part, but I don't know the part number off the top of my head.  I might have an idea of what it might be, so I open the preview pane and start selecting files until I see it. Yeah, it's probably a silly way to do things, but our main database isn't that big and I generally know the prefix anyway, which narrows things down.  With no PDM, I can't search by a parameter.

Bottom line, looking it up in the Excel P/N log isn't that hard.

[dschenken]

A further enhancement to a move-files routine is that it can notify other users (even if it's only the two of you) to alert that a file has been altered and for a few extra bits it can check the sandboxes and copy the latest version there as well, so the next time it's opened, it's up to date. It won't be long and there will be an entire PDM system spec, so I'll just stop here.

[James62]

hi David,

After I was just done by setting up my own Git server, I've started learning J-Link at the beginning of this week. So far I've only managed to make a message window pop-up, display a message in message log, and write some text to a file. No big deal, but today I ran into something very interesting.

Have a look at this page and all it's subsequent pages Pro/E Toolbox - Peer to Peer PDM Idea

It explains in details some marvelous piece of work on a great idea of distributed PDM. There is also a source code. Looks like all of this has been made public not a long ago.

The whole idea of having PDM without a central server is just fascinating, and the description is also very well put together. Also, I kinda like the name Gitchill.

Regards,

~J

[dschenken]

That seems like an interesting approach.

[bmüller]

Hi,

you can just copy the whole Creo folder to another PC.

You'll have no file associations one the new PC (no double click to open a file), but out colleagues only use the open dialogue from Creo.

For a quick view you can use Creo View.

if you want equal setups - install Creo on a test PC or uninstall it and copy it back.

br Bernhard