Let me tell you about an Oshape classroom train wreck

brian_brady

So I've jumped on the OS bandwagon and am using it to teach solid modeling to college juniors in Mechanical Engineering Technology. Previously I've used Creo (and Pro/E prior to the name change). I will still use Creo for FEA in the latter portion of the semester though.

During the first 3 hour lab session I shared a drawing with my class to quickly demonstrate how we could use OS for collaboration and assisting one another. I followed one of the students to show that functionality and everybody seemed pleased, I know I was. The document I shared with them had a part pattern of a small extruded name tag. The tag was 2.5" by 1.5" by 0.03" thick. Each tag had the text "Name:" cut from it with an extrude. I used one sketch for the tag shape and the text and extruded that tag then used a 5x5 part pattern to make enough for everybody. I renamed the parts created by the pattern to match the students' first names and last initial. 

I told the students that they were to find their specific part, select the front surface of it, create a sketch with their name, and extrude/cut their name from the tag. This is where the train wreck started. Once 14 students tried to select their parts and make sketches, everybody's system slowed to a crawl while using OS. If anybody hid another part (or parts) to better focus on their own part, those same parts were hidden from view for everybody else. This makes one of Onshape's "advantages" a serious failure in my opinion. If multiple users cannot work within the same Part Studio on different parts, hiding those that are in their way, then don't see how using multi-part Part Studios can work for collaboration. Thus one of the best features of Onshape gets tossed aside.

The train wreck continued when somebody (or multiple somebodies) was able to delete the pattern or the initial extrude and blow the whole Part Studio up for me and everybody else. I could not easily determine who and when this happened by inspecting the history, because multiple people were trying things at the same time and the history items did not relate one to another in a linear fashion. Student one may have added a sketch then the next item in history would not be their extrude but somebody else's sketch or extrude to even a hide or a deletion. One history item stated so-and-so deleted two items, but did not state which items. This seemed to be where the deletion occurred, but it did not track with the items above and below in the history. If I would have rolled the history back to that point, I would have lost a number of edits that other students where essentially doing at the same time.

I ended up having to remove everybody from the share of that document and am still rethinking how I can roll it out again. Ideally I would protect the initial sketch, extrude, and pattern from deletion (at least by everybody but me) and only allow other users to add features to what is there, but I know that ability does not exist in OS.

By the way, after cutting out their names, students were to get 10 extra credit points if they exported their part as STL and took it to our Maker Space to have it 3D printed.

owen_sparks

How about having each student derive a copy of your blank badge into their own partstudio, and then have them add their own text?

Your blank stays protected.
They each have their own tab, so nothing to hide to get to their work.
They each have their own feature list, so helping with problems is simpler.
Finally when all is sorted move all studios into a folder with the lesson name and date.

Jst thinking out loud.
Owen S

brian_brady

owen_sparks said:

How about having each student derive a copy of your blank badge into their own partstudio, and then have them add their own text?

Your blank stays protected.
They each have their own tab, so nothing to hide to get to their work.
They each have their own feature list, so helping with problems is simpler.
Finally when all is sorted move all studios into a folder with the lesson name and date.

Jst thinking out loud.
Owen S

Good thinking. I have a total of 52 students across 3 sections... lots of tabs. Or I could share a different document with each section, fewer Part Studio tabs in each. I may give this a try. It will give me a chance to show how Derived features work.

Thanks for the input.

coleman

In all fairness....15 people collaborating in the same document is a large group of people and might extend beyond the normal realm of team collaboration. 

brian_brady

coleman said:

In all fairness....15 people collaborating in the same document is a large group of people and might extend beyond the normal realm of team collaboration. 

I understand that. My primary issue is that hiding of parts/sketches for one user hides them for all others. Essentially making it impractical to work in the same Part Studio at the same time.

coleman

It seems the best way would be to create a tab folder for each student.  Each student folder could contain the part studio, 3d print file etc. 

lougallo

Obviously we have done and do this as a load testing exercise internally... however some things we know is that when working in a single Part Studio having full client visibility settings is key (hide/show/render/etc..) but more importantly, nobody does this in practice.  Most will do one of two things:

1) Work in different branches all derived from a single common version
2) All will work in different part studios in the same workspace, leaving collaboration in a single assembly.

In the case of creating a start part, Have a start part document with your sketches, snapped in a version and share with your team (classroom).  Then have them derive a sketch into their part studio as a linked document and start from there.  The students could be in one doc, each with their own PS or have them create a new doc named the exercise and have them just reference your version of the start sketch, part etc...  This also would work well for any lessons where you are providing some start entity...

3dcad

I had same problem with hide/unhide with my collague a while back. We needed to create very fast a model of real world two piece accessory. It had base plate and simple device connected to base.

We were in same room so we could talk while working but the problem was that every now and then we had to hide each others part to access certain faces.

I know this is not ideal workflow but as it is possible with Onshape - why not if it suits for team/project?

I have requested for local level hide part feature which would only hide part from current workspace (ie. not from assembly / drawings etc..) from single user so others can still see the part.

brian_brady

lougallo said:

2) All will work in different part studios in the same workspace, leaving collaboration in a single assembly.

It sounds like you are saying that one of Onshape's "advantages," i.e. using multi-part studios is not really an advantage and we should design with one part per studio just like all of the other CAD systems. You need to change some of your marketing material. 

brucebartlett

To me the major advantage of the multi-part studio is very stable reference between part's as opposed to references across unstable assemblies. I can't really see the advantage of having a whole class all trying to model in the in the 1 part studio, using the derived master part with each student having their own tab sounds like a better solution.

coleman

@brian_brady
I think you are off base here a little.  It seems like for your application in the classroom, each student should have a separate tab.  This does not negate the advantages of multipart design. 

brian_brady

I ended up having each student use the Derived tool (thanks owen for the idea) to place a base part into their own Part Studio. That worked fine. However, just because this specific case is better done this way, it does not change that their are shortcomings in having multiple users accessing a common multi-part Part Studio, whether it has 2 or 25 parts in it. If the multi-part approach is better for a design, then multiple users may need to work on a part or parts in that Part Studio at the same time as another user. In doing so, they may have the need to change the view state (hiding or showing) and doing so should not affect what the other user is trying to do on their end. Actual changes to sketches and parts need to be updated in real time for both users, but I don't believe view states should be.

This entire exercise started as a demonstration of the multi-user collaboration capabilities of OS. I was also highlighting that multiple parts can exist in the same "file" unlike most CAD packages and can start from a common reference sketch. This is not how I plan on running other assignments. For team/group projects, the number of users will be more tenable, likely 3 or 4. However, students in teams may decide to use a common Part Studio to model fixed parts that relate to each other and this would happen simultaneously, so they have to know that they cannot hide/show parts as needed if another team member is currently working on another part.

SquidLord

I'm curious, Brian. How many times have you seen one workflow work for every single possible methodology? I mean, if that was reasonable there would be only one way to do a lot more things than there are only one way to do.

Basically, for a singular use case, you've discovered that shared view states make things more difficult. Congratulations, you've found a use case where the default behavior doesn't work. You've also discovered that extremely large teams all trying to use a singular workspace doesn't work very well, either. Congratulations, you've discovered something that would be true regardless of view states, underlying technology, or toolset – something that anyone that's ever worked with a classroom or a team has already figured out.

So, let's consider a use case where shared view state is important: when you are actually collaborating with one or more other people, in communication with them, and need to refer to something that they could not otherwise see because a part that exists in that space is blocking the view. Sure, you could say "now turn on viewing for this object or the set of objects," but it's obviously much more effective and efficient to make that change yourself and call it out.

So now we have two different use cases, both of which are relatively uncommon, which have different interface requirements.

Because I'm clever and stuff, I'm actually going to suggest a fix. Not an architectural fix, not a procedural fix, not something that will require vast amounts of coding, a small change to the UI that will actually allow for all the above use cases without impeding the common use case.

If OS adds an option in the view management interface that usually hovers on the right side of the screen, where isometric and diametric views live, which is effectively just a toggle which determines if view state changes get propagated to any other currently connected clients the problem goes away. The default should be on, of course, following the principle of least surprise.

Problem solved. All it requires is a slight UI addition which modifies what state is transferred between connected clients. Different clients can have that set differently because they may have completely different needs at the same time. It all just works.

You can leave 50 bucks on the dresser by the door on the way out.

brian_brady

I like this idea a lot.

I was not trying to say that there is only one use case, only that the current setup precludes multiple users from independently working on different parts in a single Part Studio if they need to hide/show different parts. For example, designing an assembly line fixture with 50 to 100+ parts in a single (or relatively few) Part Studio makes sense because most of the parts are static and need to relate to each other. After a designer creates the primary driving sketches to set relationships, I can see handing the detail design to more than one detailer. (We did this in my previous life) Once this happens, each designer will need access to each other's most recent parts some of the time and the driving sketches most of the time, but will need to get parts/sketches out of their way or make them visible quite often. Simple if working totally alone with the current methodology. More difficult if they don't have a way to turn off view state propogation between users.

A toggle would be perfect. I think placing it in the part tree might be better. Use the current eye (or Sauron's eye) icon for global visibility and a pair of binoculars or a magnifying glass for local visibility. Make the global setting a user wide switch, this way any user could toggle global show/hide for everybody when performing a review meeting or show/tell. 

billy2

Brian-

I don't think any of us can explain how to set up a collaborative environment since it doesn't / hasn't existed before. Your experience is the 1st valid attempt that I've heard about. I'm not sure you're setting it up right when having everyone reference one feature in a part studio. Not sure I'd blame onshape for this. Collaboration will require some form of higher level management, rules or understanding amongst the participants.

I'm excited about 3 engineers working together on a project using one database and not having to sync or copy files around trying to get something designed. I'm sure in any project when all engineers try and work on the same feature, there will be problems. I think in reality with a large project, collaboration will require guidelines and management. I'm sure 2 engineers will never be working in the same sketch at the same time if the architected collaborative environment is correct. That'd piss me off if someone kept moving one of my holes to a location they wanted. It's my hole and it goes here. This isn't collaborating, this is fighting.

I'm trying to understand these collaboration rules and guidelines and waiting for the 1st to tell me how.

I was trying to get Adam @ solidsmack to come up with a good collaborative schema but it never materialized.

Do you want to be famous? Come up with a good use case study showing us how this works and share with us. It's disparately needed. Please don't explain how it doesn't work, but instead, show me how it can work.

3dcad

I'm afraid it takes another year or more to see these. I suppose after configurations, sheet metal, boms + some enhancements Onshape could make it to larger companies than 1-2 designers.
After Onshape reaches 'standard professional 3d cad feature set' they have done the easy part, the hard part will be getting big companies to change their system from existing already paid and trained production ready to something completely new - even though Onshape is fresh breeth of air into cad basement, users aren't usually the ones who make the decision for the software choice in bigger companies.
This needs global localized marketing and sales divisions to each country, similar to SW, Inventor etc. That needs B I G money, I hope we still can afford Onshape if / when they go for it.

We all are still early adopters.

brian_brady

billy said:

Brian-

I don't think any of us can explain how to set up a collaborative environment since it doesn't / hasn't existed before. Your experience is the 1st valid attempt that I've heard about. I'm not sure you're setting it up right when having everyone reference one feature in a part studio. Not sure I'd blame onshape for this. Collaboration will require some form of higher level management, rules or understanding amongst the participants.

I would just like to say that each student was not working on the same feature in a Part Studio. Each student had their own named part in a Part Studio that they were told to add a sketch to and extrude it. I would hope that multiple members in a team are not assigned the same task, i.e. creating or modifying the same part/sketch. But if multiple parts exist in the same Part Studio, I would hope that different members would be able to edit different parts without getting in each other's way.

Thanks for the comments everybody. I have changed what I do based on suggestions made in this thread.

billy2

brain-I was thinking each student having their own part studio and then all are added to a master part studio using derived commands. 

It'd be nice if the students shared their files with you, and in turn you add them to another part studio then share it back with them. What if they view only share with you? How would you construct your your master part studio so they all know what to do and can assemble their own part studio inside yours. 

The ultimate goal is to have 14 students making something better in 1/14 the time. Currently projects are so poorly constructed that half the engineers are cleaning up what the other half do. 

What I'm interested in is the top level structure controlling the design yet insuring everyone can get their working done. Controlling referencing between engineers so you don't end up with a rats nest of references. In the beginning, you'll need to provide a project skeleton which establishes datums so engineers know what to hang their designs on. Every project no matter how big it is has a 0, 0, 0 location. Where is it?

Orchestrating this will be very similar to a conductor conducting an orchestra. It's not trivial by any means and not currently being practiced in industry.

No body pays attention to these details, even the crappy file base systems, someone needs to show us the way.

3dcad

@billy wise words..

It tends to be forgotten among all software that it is not the goal to be able to make something in a new way - the goal is to make something easier and more efficient.

Do you think Onshape needs some sort of higher level management console to be able to control group of designers?

Efficient team work will be interesting area of development / discussion..

SquidLord

billy said:

The ultimate goal is to have 14 students making something better in 1/14 the time.

This will happen roughly the same time nine women can make a better baby in one month.

john_mcclary

What you could do to show how the collaboration is affecting everyone, while still using owen's derived method (Which I would agree is desired in this case)

Try this:
Have an assembly open that has each student's name tag laid out. (project that assembly on the big screen for everyone to see (if you have one) otherwise have them keep another tab open with the assembly and go split screen.

As students modify their name tags, you will see the assembly updating.

Now half way through the process, make a change to the name tag they are deriving. Like add a punch hole to the top, or change it's color.
They should all see the name tag update while they are working on their parts, as well as see all the name tags updating in the assembly.

To be honest, hind sight would suggest having multiple copies of the name tag in the same studio would be bad practice anyway. In the real world perhaps you may have tried configurations, or derive after a while. I know I started using derives more when making similar parts for my projects. As long as your base part is simple enough, it doesn't affect performance.

But remember, like all CAD packages, if you make a dramatic change early on in the tree, you could dereference all your student's sketches, which it sounds like that happened when someone modified the original extrude.

Which could be a great opportunity for them to learn WHY they should always be aware of the tree, and understand how face ID's and entities are created and destroyed.