ABD Freezing / Lag

Does anybody else experience the mystery freeze and/or lag when using ABD. They are like mini crashes that happen regularly, usually on attempting to select an object, but also when opening tools, mainly the stair tool and doors/windows but any others that access the dataset/datagroup also. 

Generally the freezes last an average of about 5 seconds, but can be 10/20 even 30 seconds. There is nothing in the logs, no errors in message centre, nothing to hint at what is causing them. i have tried for too long to try and find what was causing them. Firstly thinking that it must be something in my model, then that it must be something in the dataset/datagroup as mine was heavily customized. But no. I have stripped everything back, created a new dataset from scratch, moved all files from network to local, moved the dataset to local, tested all my files in vanilla and tried in empty files. I have upgraded hardware and tried removing other software from my machines but nothing makes any difference. It persists

So in conclusion it is a very annoying, and in my mind a major bug in ABD(it is worse in SS4 than SS3) and something that turns a very good piece of software into something troublesome, unreliable and very very frustrating. 

Does anyone know if this is still happening in SS5 beta? 

It is ridiculous, Bentley, sort it out. 

Parents
  • What build of ss4 are you using?

    There is an issue with some tools that need to convert the datagroup system to EC data on the fly, i.e. element selection, item browser.  (even docking element selection will general slow you down.)

    A little background:  Microstation, ABD's platform, stores data on elements using a system called EC data.  ABD uses the DataGroup system.  EC data does not support 100% of the features that the DataGroup systems has yet so ABD is maintaining the DataGroup system until they can be integrated completely.  This will come in a future version of the software.  This requires a conversion process when ever you want to use a platform tool that relies on EC data but needs to access data in the DG system.

    There was a variable introduced in the 08.11.09.622 build that will store the schema in a file that you can point to a location at the  project level for everyone on the project  to access:

    BB_DG_ECSCHEMA_CACHE = valid path to store the resultant file

    Setting this will speed up those tools that rely on converting DG data to EC data after the first time one of them is opened. (The first time the file gets created.  After that the file is accessed instead of the schema conversion happening each time.)  You can file a service request to get access to the priority builds of ss4.  (08.11.09.627 was the last priority build of ss4)  Priority builds are created to address specific issues that have been filed as Trouble Reports(TRs)  through TSG.

    There are also changes coming in ss5 that vastly improve the performance of the floor selector and file opens.

    I agree that opening the stair tool can be slow.  This is just because of the large amount of data that has to be accessed to load the tool.  Stairs are complicated and the tool is designed to have a stair ready to place right after you select it. (like all of the other Architecture tools.)  

    If you are experiencing other slowdowns, compare them to the out of the box configuration as a way to determine if it is your network/configuration/dataset or an issue in the software.  When you identify an issue, be specific and file service requests.  TSG is aware of the issues that are filed by other firms and can point you to solutions that already exist.  If there isn't an existing solution, then TRs are filed.  This is the only way that changes can make it into the development schedules.



    Answer Verified By: Duncan Gammie 

  • I am using build .593.

    Thank you for the answer. I have filed a service request and hopefully should have access to further builds soon. This explanation fits in with what I had supposed in terms of continually accessing the datagroup data.

    I will report back once I have further builds and am able to set the variable discussed.

    Thank You

  • Whilst I wouldn't say that build .627 completely got rid of the lag, the improvement is vast once the initial schema file is created. Still a slight lag at times, but this is split second as opposed to 5/10/20 seconds.

    Great

Reply Children
No Data