Project sharing - no collaboration

[Stefan B.]

Hey,

 

We have tried out project sharing in our company and are struggling with some things, and find it hard to collaborate. We can work on the same file but at different times. I think this is user error, and are seeking assistance from the more experienced users.

 

1. Sheet layers

My work flow for creating sheet layers is a every project starts from a template file, this template is empty but has a sheet layer and some classes and layers preset. When more sheet layers are needed i right click the sheet layer and select duplicate, renames it and do the changes needed for this new sheet layer.

 

When doing this in a project sharing file however, doing this also alters all other sheet layers stacking order. So i need to check out EVERY sheet layer to duplicate a sheet layer. Doing this well, requires no one else to work on these sheet layers. Making it impossible for to or more users in the final stage of a project to create their sheet layers at the same time. The alternative method is to create a completely new sheet layer and setting the page up from scratch. But well... not very productive.

 

I tried now to import a sheet layer from another file, but this list of sheet layers in the selected files where incomplete, and not showing all or none sheet layers to import. Side note, this list have two columns Sheet number and Sheet description, not sheet title that one most likely use. The import does not allow to import sheet layers with same sheet title, and they simply don't show, no rename option. The title block border does not come with a sheet layer import.

 

2. Data tags

I just opened a shared project and was starting my day to add datatags to a hanging position. Simple data tag that displays the position name and height. This gave me this request for check out:

 

 

So to add datatags to a hanging position I have to check out everything hanging in the hanging positions. Again making it quite impossible for my college to also do hes work. Or if he is already working on these fixtures, I cannot add a datatag to my truss.

 

 

Please, we must be doing something wrong in our workflow, this cannot be by design?  Can anyone point us in the correct direction?

[TomWhiteLight]

Hi Stefan

 

Sheet layers...

 

In my current project sharing file, I can duplicate sheet layers without having to have all of them checked out. In Tools - Organization and clicking duplicate. It temporarily checks out the objects I am duplicating on each sheet but I could then save and comit.

 

Other entertainment customers currently doing project sharing usually have the sheet layers set up before work commences, Or in some firms its the CAD managers responsibility to create sheet layers. Either way I would recommend setting up the organization first.

 

Design Layers

 

How have you and your colleagues decided to work? It looks like you are just making edits and then any affected objects are being forced to be checked out. I would not reccomend working in this way.

 

The best way to work is for each user to check out the layer before commencing work, they can then leave a message to their colleagues that they are working on that layer within Vectorworks itself. Once they have finished they can save and commit.  It's really about the layer structure...

 

Project sharing works well when a lighting designer is collaborating with other disciplins such as Scenic,  Video and Audio. By each department having its own set of layers to work in there are very few conflicts.

 

It becomes tricky when multiple lighting people need access to the same layers at the same time. This is tricky and can often be resolved by the creation of a temporary layer and then a designated person (admin) who can re-assign objects.

To be honest project sharing is not something I would attempt without setting all of this up first. You also need to establish groundrules with all stakeholders before you get going.

Also make sure everyone not only saves and commits but also waits for their cloud service provider to finish writing the file to the cloud. Also make sure that there are at least 2 admins in case one is not around when layers are needed to be forced to be released. 

 

Also do not put your working file in the same place as your project file. Backup your working file as a .vwx each night Each day DELETE yesterdays working file and create a new file by opening the vwxp. This is the only way you can be sure of no sync errors.

 

[Nicholas Lazzaro]

Hello Tom, 

 

Thank you for describing a certain workflow to help with Project Sharing conflicts.  I believe Stefan is having a similar issue to how our entertainment organization works with the Project Files, and we have setup Layers and workflows like you described. We also have detailed "Project Sharing Etiquette" and "Layer/Classing Rules" that we send out before one can access the Project File.  For each department discipline (LX, Scenic, Audio, Rigging,....) each has its associated layer where one person from each those departments works on drawing at a time checking out their layer entirely before commencement of work.

We start seeing conflicts specifically with the Rigging Layer, as all departments at some point are hanging on the Rigging layer which those objects then associate with that truss/ pipe that it is hanging from.  I understand to get the all the BW calculations elements need to attached or associated with a truss/structural object , but these associations jump across departments, or layers.  So editing a particular truss in the Rigging Layer VW wants to check out those lights that hung on that truss, but the Lighting Layer is checked out to the LX designer which include those lighting units. Thus rigging specifically ends up playing tag with the department heads or designers.   

 

 Sheet layers/ Title Blocks:

 

Our organization does have sheets built associated with each department as Base Template as described above.   But the organization as whole shares a single title block format. This TB format is the same across departments, so when one department is working on their sheet layers, editing the "Sheet Data" (even though the edits are local to that specific sheet) the whole TB ends up be checked out by another department working on their sheets. 

 

 Admin Release does not work all the time. 

 

I would say our biggest issue is that the Administrative Release does not always work, which puts a hold the whole layer until it can be resolved.  Sometimes the person working on their layer/department finishes their work and hits the save and commit and decides to close their laptop, then they jump on a plane for vacation...(Yes this actually happened). 

Now the Project File is "waiting" for this computer to finish the commit process and there is nothing anyone can do other than have that person get to a place to finish their upload or Admin Release.  Usually this person only made a couple of edits and is fine with loosing their work, but the admin release does not actually work.  When clicking the admin release I see the green bar at the bottom of the page go through its process and completes, but it does not seem to release the person.  Sometime we even try to delete that user entirely from the Project File also with no luck.  Sometimes it works, but a lot of the time is does not and we have to wait until that person can get back their computer to finish the commit. 

 

All in all Project Sharing is turning out to be better than relying only on reference files (besides huge size of single project file), but there are a few kinks that can be ironed out, and people need to understand there is an etiquette to using Project Sharing.

 

-Nick  

[Stefan B.]

ey @TomWhiteLight,

 

I need to bump this a bit since project sharing still is problematic in regard to checkout conflicts. And I do not really understand the idea from Vectorwork's side.

 

Now, I think there is a bug. So Not every time, but when another user has made changes and I refresh/save&commit one of the Design Layers(from a reference file) gets stacking order 1 and not 19 as it has in all working files and project files. This is the Venue we are drawing on and the venue is referenced. There are two Design Layers from this reference file, but only the one with venue changes stacking order. So, when I try to drag the layer down to be stacked as nr 19 again, I need to check out all sheet layers to change the stacking order.

 

Sorry dialog boxes does not apperar on the video.

 

In regards to structuring Layers and agreeing on how to work. Would you care to share some best practices or tips on how to do this? As I'm exceptionally creative, but here I get stuck on a good way of collaborating and actually getting done. As of how project sharing is right now, and everything connected to a truss

 

If I have checked out the rigging layer with all the trusses and motors, the light tech cannot set DMW addresses to the fixtures attached to my truss. I cannot add point loads to the truss the light tech has checked out for setting DMX addresses. And since refreshing and committing is a manual process I cannot really see what's going on before I try. Also, I do not know if my colleague is done before I manually refresh.

 

It is for the most part impossible to collaborate while working on objects that are a truss or is connected to a truss.

 

Are we supposed to have design layers for each and every truss in the drawing? And what about the stuff connected to that truss? Is that going in the same Layer as the truss? or separate layers? For it is normal to separate by category(Rigg, Light, Audio, Video, Scenography etc.), meaning every truss has indefinite numbers of layers, and the more people collaborating the more layers it requires.

 

 

 

 

 

[Nikolay Zhelyazkov]

Hello @Stefan B.,

 

About the stacking order change and TBB checkout. Can you please try to finish this operation by checking out the TBBs, then committing the operation and retrying it again. If the second stacking order change does not require a checkout of all TBBs in the file this means that the first checkout was caused by an outdated file name stored in the TBB Project Data. And if we have the reason for this we will be able to work on a fix.

 

Thanks,

Nikolay Zhelyazkov

[Stefan B.]

On 10/6/2023 at 5:05 PM, Nikolay Zhelyazkov said:

Hello @Stefan B.,

 

About the stacking order change and TBB checkout. Can you please try to finish this operation by checking out the TBBs, then committing the operation and retrying it again. If the second stacking order change does not require a checkout of all TBBs in the file this means that the first checkout was caused by an outdated file name stored in the TBB Project Data. And if we have the reason for this we will be able to work on a fix.

 

Thanks,

Nikolay Zhelyazkov

 

I will give this a try and report back with my findings.

[Stefan B.]

Hey @Nikolay Zhelyazkov,

 

I think I tested this but I was a bit unsure what you instructed me to test.

 

1. I selected the TBB(Title block border) in my sheet layer, right-clicked the TBB, and checked it out.

2. I right-clicked the Sheet layer with the TBB I checked out, and selected check out.

3. I right-clicked the sheet layer and selected duplicate

4.

 

So, if I understood the assignment, it did not solve anything.

[Nikolay Zhelyazkov]

Hello @Stefan B.,

 

What you have done is a different workflow. When you duplicate the Sheet Layer you duplicate the TBB in it too, which means that the total number of active TBBs got increased (I suggest your TBB is active) -> that is why all the rest TBBs have to be checked out (project data was changed for all of them).

 

What I asked you to test out is this:

1) Open your project file

2) Change the stacking order of the design layers (what you have tried before)

3) Checkout all TBBs that it asks you to check out to finish the stacking order change

4) Submit the changes to the project file

5) Try to change the stacking order of the design layers again and see if it asks you to check out all the TBBs or not

 

Best Regards,

Nikolay Zhelyazkov

[Stefan B.]

Hi @Nikolay Zhelyazkov,

 

First, I assume you mean sheet layers and not design layers?

 

1. I selected all Sheet layers and checked them out, did a sheet layer duplicate to change some stacking order, saved, and committed. Then I tried to directly duplicate another sheet layer and got the same message as before, I need to check out every TBB.

2. Then I tried to check out all TBB(not the sheet layers) and did the same as above. Still the same result.

 

[Nikolay Zhelyazkov]

On 9/6/2023 at 6:24 PM, Stefan B. said:

So, when I try to drag the layer down to be stacked as nr 19 again, I need to check out all sheet layers to change the stacking order.

- @Stefan B. my initial comment was because of this statement from you where you tried to change the stacking order of the layers. Now when I ask you to test this again you continue to persist on duplicating layers instead of changing their stacking order... Duplicating of the layers with TBBs in them is completely different operation from reordering the stacking order of design layers with no TBBs in them and it is working as designed when it asks you to checkout your TBBs as I have mentioned above the total number of sheets has to be updated in all TBBs in the file -> they get modified and checked out.

[Stefan B.]

@Nikolay Zhelyazkov

 

I'm very sorry I misunderstood! Changing the stacking order of the design layer now requires me to check out all viewports and no TBBs.

[Nikolay Zhelyazkov]

Just now, Stefan B. said:

@Nikolay Zhelyazkov

 

I'm very sorry I misunderstood! Changing the stacking order of the design layer now requires me to check out all viewports and no TBBs.

- Great! Thanks for confirming. I have logged a bug about this checkout on the first stacking order change and will work on a fix for it.

[Stefan B.]

Hey,

 

I continue on this thread as I still find what I believe to be errors in the Project Sharing.

 

After the 2024 update many things seem to be smuuther with the project sharing, but one thing is new and not really understandable. Often not always, when I open my working file, and without doing anything I get the "This operation will require the following objects to be checked out. ..." At best, I might have rolled the mouse wheel before this popped up. If I hit no, I can't really see what is not done, and hit yes, I check out those Entities.

 

It seems to always be light stuff that needs to be checked out.

 

 

And now, I used the move-by-point function on objects in a Layer checked out. To take the full process: I checked out a complete layer, selected a class, and added some trusses, clamps, and pipes to this class and layer with no checkout requests from VW. Then I moved the "construction" I made to the correct position in the drawing, and still no checkout request from VW. Then I started the move-by-point function, selected move and duplicate, retain the original and 5 duplicates. Clicked my reference point and my distance point and got his checkout request as image below. This truss in request is on a different class, different layer, and is not in any relation to the construction I'm duplicating. When i CTRL>Z the move-by-point and repeat the process the checkout request is still coming.

 

Naturally, there are trusses that share the same record and class within each symbol(Rigging-Truss-Truss, etc), but this should not affect anything to my knowledge.

 

So in general what I'm experiencing is checkout requests coming with items/objects not relative to what I'm currently doing/working on.

 

[Stefan B.]

I can supply to my prevoius comment, i just now, opened another porject file to copy a symbol from one file to another. I selected the symbol in the recource manager, presset CTRL>C, swopped to the file i wanted to copy to(by selecting the file in the open file list along the top of the viewport) and got this checkout request:

 

 

 

While I'm not sure which file this checkout is done from, I cannot see the need for this checkout either.

 

and it continues...

 

I now was on my way to investigate what fixtures(lightning device) were checked out, I only pressed Visibility to on in the Navigation - Design Layers palette, and got this:

 

 

I click yes, and am trying to investigate a bit, but it is really hard to see what is going on. Most lights are checked out by me, but not all. and not symmetrical or by any system I can see. If I try to select a fixture, only selecting, not anything else, I get a checkout request.

 

 

 

 

[Stefan B.]

No respond? Like, we are trying to find the error? As it is VERY hard to use your project-sharing module. I screen recorded my screen just opening a project where I did the following:

 

 - Opened the file

 - Refresh the working file (my gosh why is this not done during the 1min and 30sec of opening the file???)

 - Draw a brand new 3m truss from the library

 - turn on layers to see stuff.

 

I must ask and I do wish for an honest reply, Is this working as intended?

 

Actually using project sharing, is extremely difficult. Whatever one does Vectorworks requires you to check out random stuff from other layers. We have to constantly communicate and ask each other to commit to releasing stuff the other needs to continue working. We have tried several approaches, and it does not change anything. Check out parts, and layers and it still needs random checkouts to just draw a line, and turn on/off the visibility of layers. Editing sheet layers is a nightmare. 

 

And now lately, we get metadata errors. After a "Clear project metadata" it lasts approximately 24 hours before it pops up again.

 

2023-11-10 09-31-51.mkv

This video is just 7 minutes of my day and is full of pain already. I wish for someone from Vectorworks to view my screen for a day and see the struggles we have with this project-sharing function. This is a super function, it just does not work.

 

I'm sure my workflow is full of mistakes, but... come on...

[TomWhiteLight]

Hey Stefan,

Nikolay is the best person for this, I would also recommend opening a case with premium tech support. The forum is useful but Vectorworks staff respond as and when they have time, however there is a good chance a Beta tester or other user might also help out which is great. Remember as a Vectorworks Customer you qualify for tech support.

Of all of my customers that are using project sharing there are only a handful (in fact currently only 1) with issues. So we need to get to the bottom of whats causing your problem.

Is this in 2023? We changed the project sharing engine in 2024, I think we resolved all large syncing issues with this change. Let tech support know which version you are using and if this is still happening in VW 2024

"Refresh the working file (my gosh why is this not done during the 1min and 30sec of opening the file???)"

OK this is a workflow issue, you should not be using the same working file on a day to day basis, creating a new working file while opening the master will avoid this from happening.

I recommend the following....

1. Arrive at work and open the master file
2. It creates a new working file which I spend the day working in, saving and committing when required.
3. End of day backup file, File Save a copy as (Save as .VWX) Then DELETE THE WORKING FILE (Please ensure that there are no other .VXW files from this project on your machine at the end of the day).
4. Next morning open a new master file and repeat the process.

 

[Stefan B.]

Hey Tom,

 

Thank you for your reply! Yes, I can open a support ticket for this matter. What industry is your one client that has issues in and what about the others? I think this works a lot better in architecture, where a wall on the second floor is not really connected to everything else in the drawing. While in entertainment, Vectorworks has made everything connected somehow.

 

New work file every day, that one is new. Is this just your recommendation? Or is this a general Vectorworks recommendation? As I have read manuals, seen videos, and used Vectorworks with no message that this is the proper workflow. But I will definitely give this a go.

 

If this is the correct workflow, would it not be a nice feature, to have "good practices" pop up when creating a new project file? And have a selection or button in the commit window "Move WF to backup folder". I commit several times during the day, as I guess most do, but at one point I'm going home, and this function can be automated from VW side. If this is the recommended workflow I mean.

[_James]

26 minutes ago, TomWhiteLight said:

1. Arrive at work and open the master file
2. It creates a new working file which I spend the day working in, saving and committing when required.
3. End of day backup file, File Save a copy as (Save as .VWX) Then DELETE THE WORKING FILE (Please ensure that there are no other .VXW files from this project on your machine at the end of the day).
4. Next morning open a new master file and repeat the process.

 

Interesting - I have never heard/read anyone recommending this before.

 

Unfortunately I think this shows the fragility of project sharing in 2023 and previous versions if this is what's required. I hope 2024 is more stable but I haven't tried it yet.

[Christiaan]

On 11/10/2023 at 9:32 AM, TomWhiteLight said:

OK this is a workflow issue, you should not be using the same working file on a day to day basis, creating a new working file while opening the master will avoid this from happening.

I recommend the following....

1. Arrive at work and open the master file
2. It creates a new working file which I spend the day working in, saving and committing when required.
3. End of day backup file, File Save a copy as (Save as .VWX) Then DELETE THE WORKING FILE (Please ensure that there are no other .VXW files from this project on your machine at the end of the day).
4. Next morning open a new master file and repeat the process.

This is really interesting. I've noticed that generating a new working file is often much quicker than syncing changes. It's a little convoluted compared to the sync button but I really like it; I particularly like the ritual of manually creating a backup at the end of the day and not leaving this to automation. This is how we're going to work from now on.

[TomWhiteLight]

1 hour ago, _James said:

 

Interesting - I have never heard/read anyone recommending this before.

 

Unfortunately I think this shows the fragility of project sharing in 2023 and previous versions if this is what's required. I hope 2024 is more stable but I haven't tried it yet.

Hi James.

This is how we teach the project sharing workflow at Vectorworks, I don't think it exposes fragility in anyway, its faster and also you have the added benefit that when you open a new master file you can see that the file is syncing.

There are many ways to use Vectorworks but nothing beats actually asking us what the best workflow is.

[TomWhiteLight]

Hi @Stefan B.

I only work with entertainment customers so that does restrict the background of my users. In terms of my recommendation this is how I was taught this feature internally at Vectorworks.

Some of the common issues I have resolved over the past couple of years include...

Sync issues caused by poor broadband upload speed (below 25mb), External reference syncing issues caused by multiple origins, Lightwright Data XML sync issues. failed master sync due to multiple working files (this happens alot and is usually user error).

I had one ConnectCAD customer who was receiving the Metadata is too large error. This was resolved by updating the file to 2024.
 

[TomWhiteLight]

I will suggest adding these tips to our home page. I think the other issue is that alot of our project sharing training content is done by external users and might not always be representative of our intended workflow.

[TomWhiteLight]

Just circling back on your comment regarding which industry this works better for.

Yes, you are correct, Entertainment can be a little more complex.

I think its probably worth re-visiting layer structure. Putting all connected objects (lights and truss) on the same layer would make this more reliable but then you remove the ability for users to check out multiple layers and instead check out objects which makes the process a bit of a 'bun fight' as users try and check out unavailable objects. So this is tricky. One customer I knew worked on a project sharing file where everyone had their own 'temporary/their name' design layer. As they each updated their layer. They would then re-assign their objects to the 'proper' layers. Allowing an admin user to run Braceworks calcs on the connected objects. This worked well but editing and updating still required checking out.

We recently had a customer feature request categories of layers (not filters) So for example all of the rigging layers can be selected and worked on as a set, Any layers that have flown equipment could be categorised and edited together.

This enhancement could enable easier workflows for connected objects in project sharing. 

My colleague Nikolay might also have some thoughts on this.

[_James]

40 minutes ago, TomWhiteLight said:

Hi James.

This is how we teach the project sharing workflow at Vectorworks, I don't think it exposes fragility in anyway, its faster and also you have the added benefit that when you open a new master file you can see that the file is syncing.

There are many ways to use Vectorworks but nothing beats actually asking us what the best workflow is.

 

It's certainly possible that i've missed it, but I have never seen this method of working with project sharing described in any official Vectorworks help articles or project literature and it seems that i'm not alone. Therefore the method you describe seems to be a workaround to give better performance than the standard way of working with Project Sharing which has some issues, hence my fragility comment. If it wasn't susceptible to error, no workaround would be required.

 

Nonetheless I appreciate you engaging and trying to improve people's experience. We will give it a try in the office, although the first reaction from colleagues was "that seems a lot of effort".

 

If this is the "official" way to do it then I hope in future we just get rid of working files altogether and everyone opens the project file daily. Perhaps a working file is created in the background but there's no need for a user to manually back it up and delete it each time.

[Stefan B.]