Multiple users on a single model/assembly

I think that this working simultaneously by several people on a model in SE is a myth. Maybe you could do a little research, Bo, and confirm this alleged functionality. I tried, on the SE website, checking this brochure, for example

but could find nothing about concurrent design defined as several people working on the same model/assembly simultaneously. The site does, however, offer lots of resources for you to become acquainted with SE's actual capabilities, or at least their own exaggerated claims, but claims which are not so exaggerated as to include this simultaneous feature creation/editing by several people. Functionality which, BTW, is not even offered on the high end big brother, UG. Let me take this a step further and suggest that the idea is so radical, startling and amazing that were it to become a reality, we'd be reading about it on the front page of the WSJ and, quickly, everyone in the world would know about it. IOW, the first place we'll hear about it won't be as a rumored functionality of a midrange modeller (that's them) alleged on an obscure newsgroup (that's us).

There are collaboration claims made for "Insight" PDM. Check out the advertizing in this brochure:

this seems like the PTC product, Division Product View, which lets diverse groups of people view and markup models and drawings or this, combined with data management, releasing, etc. PTC, on the other hand, does a little more advanced form of collaboration with Pro/COLLABORATE, design teleconferencing software which lets groups in different areas view and edit the same model which everyone sees on their screen, text message on screen and pass control back and forth between people, all in real time. Pro/e is capable of several forms of design collaboration which you can check out here: will all eventually be absorbed into Windchill ProjectLink and PDMLink or, at least that's been the claim for a few years now.

Not at present, and I don't see, within the sequentially created features which constitute a model, you could have two people working simultaneously without them 'treading on each others toes'

If you want to have a bunch of people work on an assembly, that's different. If possible, break the assembly down into subassemblies, and assign ownership of each subassembly to one designer, and make someone responsible for making the whole thing work, and you should be able to make this fly. Most pdm systems have some tools intended to help with this sort of collaboration. Make sure the various people working on the assembly can talk to each other without getting out of their seats, or they won't.

Hello to all

There is (limited) possibility for two or three operator to work on single part simultaneously using Pro/E. I've used this practice in the past (with Pro/E Ver18) and I'm still using it now (WF I). I'm (we're) using the fact, that Pro/e is not overwriting the part file, it just saves it versions. The procedure we're using is as follows:

1. Part (or/and) assembly is stored on central server, so each operator is saving the files in same directory (this is not absolutely necessary, but it simlifies the work)
2. With colleagues we decide, on which "sector" of part will someone conduct his/hers work (zone functionality just might help to cower up not needed "sectors" of part). It is wery useful to decide which features (Datums are the best for this) should each of collegaues use for primary refrencing. It's also wery useful that each of colleagues puts it's features in one group (if possible).
3. Each of us is doing it's stuff on part.
4. After finishing the work (all colleagues have stored their versions of part) I clear the memory an open last version of part again.
5. I'm copying the features from parts versions, saved by my collegaues (using feature operations>copy feature>from different version) into opened part (groups of features which were grouped up from colleagues could be of great help during this step). If IRC, this was much easier in Pro/E Ver18, where some kind of "merge different versions" command was inplemented. Now this functionality has moved to Pro/Intralink :-(
6. After all features from diffrent versions are copied into my part, this one is saved as last (and actual) version.

It's obvious, what kind of limitations this kind of work has (Operator should seat near one to another, they have to thorougly discuss their wokr in advance, merging different versions of parts can be cumbersome task....), but It has greatly helped me during time bottlenecks and still does.....

And may Pro/e respond to Your commands...

Kind regards from Solvenija

Joze BARBARIC

We´re using Pro/E as a multiuser modeler exactly this way for some time. With a lot of discipline (about references) this works like a charm! But what if someone lacks it... nights of painful patchwork.

How often did I wish the program could do the patchwork all by itself? Stupid repetition of work already done: that´s what computers should do.

And it would be nice to have a selectable visualization on screen of ones colleagues work currently in progress - to avoid collision and to increase synergy.

Btw., I know of an editor (nedit) that frequently alerts me to reload when "another program has modified the file"... so it must be possible to have multiple users work on the same file (in different sections?).

Pro/E´s opulent feature dependency tracking should be capable of that. At least avoid the deletion or redefinition of features required by some others currently under work of another user.

Didn´t I-DEAS have some check-in/check-out multiuser functionality? I never quite got how that one was supposed to work, though.

Walther

P.S. : a quick and dirty solution for multiple users on the same part (when deadlines are near) is to merge parts of parts into bigger ones. If you have to export a file for tooling (IGES, STEP) then you´re done. Otherwise it is a bad habit because of dead feature chunks in the model.

I started by responding to the exaggerated claims of a victim of SolidEdge propaganda. That's obviously not the whole story. Thanks to Joze BARBARIC and Walter Mathieu for relating some ingenious ways of addressing the problem of several people working on the same model. In so doing, they highlighted the difficulties, possibilites and limitations of this approach to modelling. A couple conditions are clear, though: 1) constant communication between participants to make up for the fact that the software isn't/doesn't; 2) using neutral references from original model or creating references offset from original; 3) additive approach to modelling (as opposed to subtractive [big block, make lots of cuts]) produces far fewer lost references; 4) the big issue for all of these kludgy solutions is reconciling/synchronizing all the individual models: normally, in typical OS synchronisity, the latter overwrites the former, NOTHING HAPPENS SIMULTANEOUSLY. So, here is the beauty of GROOVE.... it fools the OS into thinking that all those people participating are the SAME person. The limitation, it seems, is not Pro/e but the OS (Windows, Linux, Unix)-- they share the same aversion to multiple users accessing the same data set, unless it is a database (Oracle has no similar problem with mulltiple, simultaneous user inputs). But GROOVE has the same serial limitation... no simultaneous user input. Or is it just how quick serial is, IOW, two things happening in quick succession APPEAR to be simultaneous. So, is the difference between GROOVE serial and apparent simultaneous just computer speed and some programming tricks!?!

If it were a matter of a shared network memory space, reserved for simultaneous working on such models, your model would update with a feature created by another user, as if she were yourself and you had magically created the feature in 'your' model (as there would be no aritifical distinction between 'your' model and 'her' model). You would be, in fact, working on the SAME model.

This might be in the realm of the PDM/PLM system which could provide a shared multiuser memory space. But, it wouldn't amount to another kludgey trick for reconciling parts with disparate geometry. They can't be reconciled in the PDM realm; they must be reconciled in the part realm

Thanks for pointing out not only some of the possiblities but the inherent weaknesses. I was thinking, while you guys were showing alternatives and workarounds, that there was even more stuff, like maybe ^C ^V, copy features or copy geom from other model or copy shrinkwrap froom other model or merge from other model or inheritance. Also, thanks for pointing out that most things get you a dumb, nonparametric, featureless, surface-based "solid". None of these things answer the challenge presented by the SE user~~simultaneous feature creation on a single model. So far, it is not posssible, while the kludges that have been presented ought to be possible on ANY modelling sytem. While the ultimate isn't possible, the GROOVE approach comes closer than anything previously conceived to this goal of multiuser, simultaneous modelling.

David Janes

CADDS5 had a thing called CAMU and that allowed mutliple people t work in/on pieces of assemblies. The functionality worked great. PTC owns CADDS5 since they aquired CV (ComputerVision) I've alway been surprised that the CAMU functionality hasn't been incorporate in to Pro-E

A bit off topic, kind of

Glenn |B

Maybe it has but maybe it was transformed, bastardized, gutted, turned into a subset of top down modelling. Who knows. I always had the impression that CV was mainly a wireframe/surface modeller. In which case, lacking the kind of history/p-c/dependecy relations that "feature based, parametric, solid modelling" was based on, CV might have had far fewer obstacles to implementing multi-user, near-simultaneous access to models/assemblies. I know that surface modelling (which remains surfaces/quilts until 'solidified') is less of a hassle re:simultaneous modelling than are features which naturally form associations and dependencies with each other (which avoids surfacing "merge" challenges). Surfacing just involves far fewer history and dependency challenges than do solid features, so working in CV with multiple users might have involved fewer complications from the outset. I've only ever seen CV products and never used it so I could be all wet on this. Remarkably, CV CADDS5 is still a viable product and continues to sell.