2024-11-08
12:37 AM
- last edited on
2024-11-14
12:33 AM
by
Laszlo Nagy
here is a small sampling of the t/w warnings I have been trouble shooting the past week. This feels like something is broken... or theres something else at play here (my tinfoil hat is on pretty tight right now). And these are about 1/4-1/2 of what I've been sent:
2026-02-10 02:31 PM
yes, if a bad railing or custom layer combo or missing model view option or bad library management causes archicad to not work, then archicad doesn't work... all possible issues they've suggested so far.
archicad needs to work in spite of various minor bad model/file management, or it's a broken tool
2026-02-15 12:58 PM
This is from a project which worked absolutely fine (Archicad 29 INT b3000).
I don't know what caused it, I created lots of interactive schedules before sending in.
The machine is both the client and is running the BIMcloud Basic instance serving the project, so I doubt it to be a network error.
My BIMcloud license is not revoked according to the manager, so "Archicad tried to perform an operation and the server refused it" is my guess.
No hints to troubleshoot, I just have to save a PLN, reupload, then discuss with my colleagues what was lost and stitch the current state again.
2026-02-15 03:36 PM - edited 2026-02-15 03:36 PM
It may also be a good idea to delete Local Teamwork Data as well before resharing when something like this happens.
2026-02-20 01:04 AM
yeah, managing work loss mitigation and discussing how lost work should show on time sheets is a big part of my workload these days...
I'm cautiously optimistic; last reports I heard form GS, they may have some leads on _some of_ the hang ups on teamwork opperations and failures to send or sync data...
I'm not holding my breath, but at least there is some target in sight on their side.
2026-02-28 01:49 AM
I wanted to share some critical findings from an internal IT audit regarding severe performance issues and sync errors we’ve been facing with BIMcloud SaaS. We are working with large project files (approx. 8GB) and complex hotlink structures, and the experience has been increasingly unstable.
Our IT team monitored our firewall metrics during a session where a hotlink update hung for over an hour. The report was conclusive: The bottleneck is purely server-side processing. During the entire "not responding" period in Archicad, there was virtually zero data transfer on our network. This confirms the delay isn't network transit; it’s the SaaS backend struggling with internal computations (diffing, merging, and updating the master copy).
This has escalated beyond just "slowness." We are now seeing frequent sync errors and warning messages. It seems that when multiple users work simultaneously, the backend delay creates a desynchronization between the master copy on BIMcloud and the local cached copies. Because the server takes so long to process a single request, subsequent syncs from other users appear to be hitting a "moving target," leading to conflicts that shouldn't exist in a healthy teamwork environment.
We reached out to graphisoft support, hey ran performance tests and claimed they couldn't replicate the issue, stating everything worked fine on their end. However, despite saying there was "no problem," their official recommendation was for us to downgrade and move our files to a local BIMcloud Basic server to regain performance.
This raised a major red flag for us. If the SaaS environment is performing as expected, why suggest moving to a Basic on-prem server as the primary solution? It feels like an admission that the SaaS infrastructure isn't scaling to handle high-complexity projects with multiple active users.
Based on our IT's advice, we are looking at two tracks:
Hybrid approach: moving the 8GB site plans and heavy hotlinked projects to an on-prem server to get LAN speeds (where our IT tests showed delta syncs completing in seconds).
Delta Cache: Upgrading to a full BIMcloud license to use a local caching proxy, hoping to bypass some of the SaaS latency and mitigate these sync conflicts.
I’d love to hear if others are seeing this "zero data transfer" hang during heavy processing or if you've received similar "downgrade suggestions" from support.
2026-02-28 11:03 AM
Ah, a newbie on this subject! Let me assure you you’re not alone on this subject.
German forum: https://community.graphisoft.com/t5/Teamwork-BIMcloud/Es-ist-ein-Fehler-während-der-letzten-Teamwork...
Int’ forum: https://community.graphisoft.com/t5/Teamwork-BIMcloud/Archicad-29-is-unusable-due-to-Teamwork-errors...
… and a lot more besides this thread
2026-02-28 10:27 PM
It is possible that the sheer size of the file (and therefore the amount of data contained in it) is itself what causes the performance issues. A file this size is of critical size. We usually teach on the BIM Manager course that over 2 GB the file size is critical. You should be dividing your project file into smaller files.
You can split the model into several files, or you can make two files, one for the model only and another for the documentation only, or you can divide them even further.
There are articles that talk about file size and performance:
2026-03-02 09:54 AM
BIMcloud SaaS is like any SaaS or Cloud software; is just someone else's computer.
Or to be more precise; someone else's shared computer with added remote latency.
So them recommending you to use a local server instead is not surprising to me. Even less, when a employee in the year 2026 tells you that +2GB is considered big 😂
But performance is not the issue we are facing here in this thread. That is why I would recommend opening up another thread.
2026-03-02 10:18 AM
Hello,
According to our GS rep Delta Cache in house server wont solve the issue. Your approach is the one that he recommended me. Use a local computer.
Do I like it? Of course not; We would rather offload the IT and scalability questions to a Software As A Service service.
As for now I've removed the BimmTool plugin and the pointcloud from the TW file and things are a little better. Our file has currently 1.9GB in TW. Let's see how it goes.
2026-03-02 09:34 PM
I completely agree. This is a legacy file that has evolved over many years, and while we are currently restructuring our BIM workflows, this specific project remains a challenge. Notably, the file is only 2.2GB as a PLN, yet it balloons to a staggering 8GB once shared on BIMcloud. It’s worth mentioning that prior to our update to Archicad 29, this file was perfectly manageable, with no history of crashes or significant latency issues.