Jump to content
  • 10

Project Sharing - Does this really work in the wild?


Tom Klaber

Question

We gave the project sharing its first test yesterday - and it was a disaster.

 

Some but not all information would be seen after a commit and refresh.  It would not allow editing of certain objects and layers because it claimed for each of us that the other had permission.  Then it would not let us commit because it said the other had taken our permissions away. 

 

Then the really strange things started to happen - all of our general notes disappeared.  All of our title blocks were converted from title block boards to "Parametric Objects" that were no longer editable. 

 

This was a small basic model of a kitchen renovation.  Thank goodness we did not try this on a project of any real size.   I have met with friends at offices who have given it good long test runs - and report that it is a constant stream of errors, crashes, and bugs like the ones here.  Is anybody using this in the real world with success??  If so - if anybody has any ideas about what would be causing our issues - it would be much appreciated. 

 

Thanks,

Tom

  • Like 1
Link to comment

Recommended Posts

  • 0

We use a Synology DS218+. It runs two hdd's on SHR (Synology Hybrid Raid). No Dual Network only common Gigabit connections. The hardware of the workstations don't seem to have any influence on PS related stability and speed. We also use Windows 10 64bit. Our files are about 500-1000MB size. All layouts are stored in one single file. Sometimes the model is referenced from multiple files to one layout file. Some of the references are normal files, others are also ps-files. We don't save viewport cache in the project file but we do it only in the work files. This saves a lot of network traffic. We only activate this for specific project phases when we don't want to re-render viewports on every machine. But when we do we keep an eye on the file size so it doesn't get too big. We send our changes on a regular base at least twice a day. The more you do, the faster it is. When you do a lot of work on viewports, send the changes more often. Working on viewports seems to cause the most sending lag. Slow updates is the only complain we have with PS but with this workflow we keep sending times in a usable range (some seconds up to some minutes). Most of our PS experience is based on Vectorworks 2017. We don't change the vectorworks version if the project is already too far progressed. Although in 2018 we experienced faster sending times.

Edited by herbieherb
Link to comment
  • 0

Thank you very much.

 

It seems our file sizes are smaller, about 2-300MB. 

 

Your file setup and workflow seems similar to ours. Our commit times are from a couple of minutes to even 15 minutes (!).

 

It is very strange that while PS seems to work fine for some and others have a multitude of issues. 

 

I was looking at task manager yesterday, and it seems the software is just thinking during these commit times and not using network except for a brief period at the end. There is no network traffic for most of the time. So perhaps it has nothing to do with the network then.

 

Link to comment
  • 0

It's the single core speed thats bottlenecking. Not much network traffic meanwhile. When i open a file i hadn't opened for a week, where others had made a lot of changes i also have to wait about 10 minutes to get the changes. The only recommendation i can give you so far is to not postpone sending your changes when you do a lot of work on viewports in the layouts. This seems to affect the time to send changes the most.

We've located most of the problems we had in front of the machines. You can do a lot of bad things with PS. Copying your workfile or getting a new one without checking out leads to objects, that can't be changed by anybody. Afterwards the users misused admin-rights leading to data loss. Deleted classes can be recreated by accident when others copy objects that had the class and they didn't received the changes yet etc. We had a lot of problems with vw2016 and PS untill i found out that one single employee regularly reconnected his backup files with the project file. You have to give your employees workflows a very close look to find out whats going wrong.

Link to comment
  • 0

Thank you.

 

We keep our working files on c:\. Using backups is not allowed for reconnecting. There is only one Admin (I). We try to check out complete DL's and save and commit multiple times a day. I find that being away even for one day easily causes a 5min update time. For us it seems to be the crashing (daily) that most often causes the errors.

 

We have about 10-20 simple dwg references, updating these sometimes takes an amazing amount of time, even if though these are simple line drawings from electrical engineers etc.

 

 

Link to comment
  • 0

Here is one of the recurring issues: Different wall styles don't keep their L-joins (or other joins). These walls have been previously beautifully joined.

 

This was discussed with other users at the Nordic Design Day and they confirm this behaviour. It ruins all drawings if you don't notice it in time.

 

One user described how they ignore the opened joins and rejoin them only immediately before publishing.

 

In our example below, no-one had done ANY operation on the walls or wall styles, this is just something that popped up. We were working on completely other, 2D things at the time.

 

 

 

 

 

 

Capture.PNG

Capture2.PNG

Link to comment
  • 0

@Tolu for completeness, this post wasn't only about Tom Klaber's use of Google Drive. 

 

For completeness, read every post.

 

For completeness, everyone on this post already agreed and established Google Drive (Google Backup and Sync/Google File Stream) doesn't work for VW PS.

 

The various posts here demonstrates that various people are having problems with project sharing, and these problems should not be overlooked. 

 

Also for completeness, I have spoken to other users on this forum, and the feedback is that you ( @Tolu ) tend to dismiss issues raised by users. 

 

As a final point on completeness. Have you worked a day in an Architectural Firm? How often to you actually use Project Sharing in real-life situations creating models and drawings that output to actual clients and construction sites?

 

People with daily encounters and experience here are offering a complete view of this project sharing issue, and deserve to be listened to.

 

  • Dislike 1
Link to comment
  • 0

Users tend to think the problem is in the software when in fact it's sitting in front of the screen or in the hardware.

We looked for the causes and eliminated them. This results in PS working stable for years now in our daily work. Some were in the software, some in the hardware, some in front of the screen. From our point of view the ones in the software are mostly solved since VW2017, at least for Windows users. Apple unfortunately has problems with the implementation of SMB, while AFP is not developed further. Not only Vectorworks has to struggle with this. I can't tell if that's better now, because we have no Apple computer in the office since about a year.
Since PS is not only a tool in Vectorworks itself, but has to work in a network, you also have to do an error analysis outside of Vectorworks. Which protocols do you use? Where is the server located? What kind of device is this? Do you use a cloud? Dropbox? The easiest way to eliminate all these sources of network related errors is to make a local copy of the project-file and try to send/receive its changes to this local file. You can't completely rule out network problems yet. The file may have been corrupted before you took it off the network. Nevertheless some network problems can be excluded like this.

If it has nothing to do with the network, you have to try to reproduce the error. All project participants have to communicate exactly what they did. Often someone just played with the admin rights without knowing it and shot down other users. In 2016 we had a lot of problems with PS until I found out that an employee kept linking his backups to the project file. Recently someone complained in the German forum, until he found out that a coworker regularly released his checked out objects with its admin rights. Many users also think that Vectorworks crashed just because it didn't respond for a few minutes. Then they quit the program manually. Depending on which phase they do this in, they may corrupt the project file.
Simply blaming the software for the errors is easy, but not helpful. If you have excluded incompatible hardware and users as sources of error, you can still rightly complain to Vectorworks.

  • Like 1
Link to comment
  • 0
On 9/30/2018 at 11:47 PM, Amorphous said:

 

 

Hey @twk since you are the only one reporting good success so far, can you tell us what your save and commit times are?

 

I recorded a video of our save and commit, see below, and it is 6 minutes. 

 

The file with the biggest issue is a 1000-sqm residential alt and adds , with 300+ pages of documentation. Everything lives in one single file, lots of hatches, wall types, slab types, worksheets etc. Is that the type of project you are using VW for? I'm interested to know.

 

Save And Commit.mov

 

Sorry for the late one, below is our refresh and then commit times for comparison. This is a six story building with 3 wings/towers. Separated files for plans and details. Working file sizes - 1Gb, Project File size - 400mb

 

We had experienced slower commit times in 2017. Just updated the project to 2018 to make use of the multi-vew viewport feature, which is a major game changer for a project this size.

 

Refresh time : 50seconds

Save and Commit : 1minute

 

What was being updated: Structural members for whole of level 5 (floor beams/roof beams/columns/etc)

 

Pluses for 2018 Project Sharing:

- less crashes than 2017 (relative term here)

 

Minuses:

- connection/link to master file drops sometimes. Solution is to save working file. Restart vectorworks, and then open the saved working file again, and we see the connection is restored. This is by turning on the project sharing options icon, we can see highlighted objects we have checked out.

- terribly slow calculations for worksheets. This could be due to scripts used in the worksheet + the size of the project.

 

 

 

Link to comment
  • 0
6 hours ago, twk said:

Minuses:

- connection/link to master file drops sometimes. Solution is to save working file. Restart vectorworks, and then open the saved working file again, and we see the connection is restored. This is by turning on the project sharing options icon, we can see highlighted objects we have checked out.

This error has not yet occurred with us. This seems to be more of a network-related problem. How is your network structured? Which operating system do you use?

Link to comment
  • 0

Well, it's 2019 SP2 now and we've given project sharing another go.

 

So far, so...same as before.

 

For some time I thought PS was working more reliably than in 2018, but alas, I was too quick.

 

Today, I was away from the office for most of the day and thus couldn't refresh. Apparently the to-be-refreshed pile of stuff grew too large in my absence. Another user was working on some other DL's than I.

 

Now I have a crash-o-matic speed-exiting VW every time I try to refresh or commit.

 

Well, off to bugsubmitting I go, added the files to our (me and tech support) shared debug directory, subdirectory number 019.

 

 

 

Link to comment
  • 0

We have absolutely no more problems with projectsharing in a similar network environment. We also run windows 10 and a synology nas. The only problem we had in the last few years was a recurring crash on a cheap Dell machine during sending/receiving. But the computer had too little power and has been replaced in the meantime.

What does the hardware of your computer look like?

Link to comment
  • 0

Sorry, the signatures were switched off, so I hadn't seen them. So your computing power is certainly not the problem.

You don't have to be happy for me. I just wanted to say with my post that Projectsharing runs smoothly with us, so there is hope for you too. You can exclude the hardware as a source of error, the network probably as well, the Synology as well. What remains is the user behavior. There's a lot of things you can screw up. Projectsharing is not a function that you just try out. You have to know how it works and all your employees have to understand it too, otherwise mistakes are inevitable. The best thing to learn this is to really get a small project done. Be prepared to create a new project file from time to time until you have eliminated all the mistakes that employees make.
I've already mentioned a few possible mistakes here. But the list is certainly not exhaustive.

On 10/16/2018 at 10:49 AM, herbieherb said:

If it has nothing to do with the network, you have to try to reproduce the error. All project participants have to communicate exactly what they did. Often someone just played with the admin rights without knowing it and shot down other users. In 2016 we had a lot of problems with PS until I found out that an employee kept linking his backups to the project file. Recently someone complained in the German forum, until he found out that a coworker regularly released his checked out objects with its admin rights. Many users also think that Vectorworks crashed just because it didn't respond for a few minutes. Then they quit the program manually. Depending on which phase they do this in, they may corrupt the project file.

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...