journal

C4R – I’m Still Missing Too Many Elements! (Part 2)

So last week you went through how to fix the ‘too many missing elements’ error, but after clearing your cache and sourcing replacement files you’re still seeing the error.

This means things are a little more serious, but there is still a potential solution.

Search the Journal for Missing Element Warnings

This time around, you need to review the journal file and look for the error specifically related to missing elements.

The journal file is located in %LOCALAPPDATA%\Autodesk\Revit\Autodesk Revit 201x\Journals you need to be opening the journal file that will have recorded the error. If there error has just occured, it will be recorded in your most recent journal file.

The easiest way to find the most recent file is to change your file sorting by date modified with the newest files at the top.

Open the journal in a text editor (Notepad or Notepad++) and search for the name of the model causing the problem.

This time you want to search for the text missing elem within your journal file.

If you can’t find the text in your most recent journal file, don’t panic! Using Notepad++ you can actually search for a string in all files located in a folder.

The search results will appear at the bottom of Notepad++ showing which files it has found the search string in.

You will soon have a list of elements that are missing from your model. The numbers represent the element ID of the missing elements.

Repairing the damage

To recover your file, locate the most recent backup file that contains the missing elements. You can restore backups from your local cache in the same way you have always been able to restore backups with Revit, it’s just now there is an extra step in finding the GUID of the RVT file before you can restore a backup.

Search for the name of your Revit file in the journal. This will give you the GUID for the project and file.

Once you have found the name of the model,take the model GUID and search for it in your CollaborationCache folder. You need to find the folder named <revit model GUID>_backup

From the Collaborate tab of the ribbon, select Restore Backup

Paste your backup folder path into the folder name location, it should follow the format C:\Users\<user name>\AppData\Local\Autodesk\Revit\Autodesk Revit 201x\CollaborationCache\<local cache id>\<project GUID>\<model GUID>_backup

Select the most recent backup and work your way back until you find a working copy.

Save the file in a new location. Don’t open the file just yet.

Browse to where you have saved your backup file and then open the file with the audit box checked.

Once you have successfully opened the model, using the Select by ID tool, search for the elements in your backup model.

Make sure that all the elements display correctly and work as expected.

The audited model becomes your new central model. You need to run through the process of loading the model onto C4R.

If anyone else is working on the project, their local cache will no longer synchronise with the newly created cloud model. Others in the team will need to rename or delete the folders in both their CollaborationCache and PacCache folders.

And that’s it! You’re done!

One final note..

When speaking with Autodesk, they advised that the best way to prevent this missing elements error is to always open your C4R models with the audit check box ticked. It’s a little bit of extra pain, but if it saves you from having to manually recover models, then happy days!

Final note for real this time..

In addition to the above, both Revit 2017 and 2018 have had updates released since I originally wrote this post. Autodesk’s urge anyone that is experiencing too many missing element errors to update their entire team to Revit 2017.2.2 and/or 2018.1.1. The patches for both fix the problems that cause these errors.

C4R – So You’re Missing Many Elements? (Part 1)

If you’ve been working on C4R for even just a little while, you have probably seen the dreaded ‘too many missing elements’ error.

When you’re opening a Revit model, there could be more elements in the central model than there is in your local model. Usually Revit will synchronise the changes with your local and the endless grind of office life moves on. Sometimes though, things just don’t work out and you’re presented with this

Luckily, there are solutions to get your files working again.

Step 1 – Clearing the Local Cache

First, we need to clear the C4R local cache on your machine. You have two choices here, either blow away everything in the cache, or just try to clean out the file that you’re having issues with.

The Cache Location

The local cache is located in %LOCALAPPDATA%\Autodesk\Revit\Autodesk Revit 201x\CollaborationCache where Autodesk Revit 201x is the version of Revit you are using.

The files and folders in the local cache are coded with unique GUIDs.

The first folder is your local machine code

The second level of folders are the projects. The files within the folders are the models related to the project.

 

In addition to the collaboration cache, there is another folder named PacCache which is located in %LOCALAPPDATA%\Autodesk\Revit\PacCache

The PacCache is where all the delta file transfer information is cached for all the C4R models that you have worked on. The PacCache isn’t split into individual projects, or even individual versions of Revit. Everything is lumped in the same folder.

This is where you take the easy way, or the (not really very) hard way.

Method 1 – The easy way.
Just Kill Everything.

It’s listed first simply because it’s easiest. This should actually be the last method you try for clearing out your cache.

The easy way is to just wipe out everything in both the CollaborationCache and PacCache folders. With Revit closed, just browse to the folders in your favourite file explorer you can delete the contents of the PacCache folder and then move everything inside the CollaborationCache folder to another location. You can delete the contents of the CollaborationCache as well, however I highly recommend moving just in case you need to restore backups. That’s right! There are local backups of your C4R projects and they’re located in these folders.

Just keep in mind that when you do this, it means you need to cache all the files with your local machine from the cloud again, so it might take some time the next time you open up your models, especially if you have quite a number of projects and models hosted on the cloud.

Method 2 – Just The (not really very) hard way.
Removing a Single File.

The hard way is to remove just the single file giving you grief. It’s actually not very hard at all, you just have to poke around in the journal file to find the specific GUID for your file.

The journal file is located in %LOCALAPPDATA%\Autodesk\Revit\Autodesk Revit 201x\Journals if you have just experienced the error, then you will need the most recent journal file.

The easiest way to find the most recent file is to change your file sorting by date modified with the newest files at the top.

Open the journal in a text editor (Notepad or Notepad++) and search for the name of the model causing the problem.

Search for the name of your Revit file in the journal. This will give you the GUID for the project and file.

Once you have found the name of the model, you need to search for the GUID by copying and pasting it into the search box and move all the files and folders with that GUID from the local cache folders.

The files and folders will be located in both the CollaborationCache and the PacCache folders. You need to delete the PacCache folder, but for the CollaborationCache you should move the folder that has the same GUID of file that you’re having trouble with without the {curly braces} to another location. Again, you can delete everything but if you do you won’t be able to restore any backups after the files are deleted.

Method 3 – Definitely way harder than it needs to be.
Clearing out a single project.

Clearing the cache for an entire project is quite a bit more difficult due to the PacCache folder is not sorted into Revit versions or even into projects and you need to clear out the PacCache because otherwise you’re going to have a bad time.

If you really want to head down this path, the easiest way to find the project GUID in your journal file.

Get the complete local path to the project folder within your Collaboration cache folder. Move or delete the project from the CollaborationCache folder. Again the same warning applies if you choose to delete the contents of your CollaborationCache.

C:\Users\<user name>\AppData\Local\Autodesk\Revit\Autodesk Revit 201x\CollaborationCache\<your local machine code>\<project guid>

Open up Google Chrome (Edge and Internet Explorer will not work), copy the full folder location to your project and paste it into the address bar in Chrome prefixed with file://

What this does is it lists all the files from the CollaborationCache in your browser. Copy the GUID of each Revit file without the .rvt extension and search for those GUIDs in the PacCache folder.

Delete any results you find from the PacCache folder.

Step 2 – Re-populate your local cache

Method 1 – Just re-open from C4R

The first method is to simply open your file again from C4R. Revit will populate your local cache with brand new copies of the files that you’ve moved or deleted so you can start fresh.

From experience this works maybe 80% of the time.

Method 2 – ‘Borrow’ Someone Else’s File

Borrowing.. Stealing.. Fixing your local C4R cache. Call it what you will. This method only really works if someone else is also currently working on the model. What you’re trying to do here is get yourself the most recent working copy of the file so that you lose as little work as possible.

You need to find someone else that is working on the project without any missing element errors, find who has the most recent copy and take only RVT file only from their CollaborationCache, do not take anything from the PacCache.

From experience this works the other 18% of the time.

How to Fix the ‘Stacked Wall’ Error When Loading Families Into Revit

At some point, you’re probably going to look like this guy – loading a family and you’ll be struck with the error “Last type in system family “Stacked Wall” cannot be deleted. ” and pulling your hair out.

2015-11-30_16-26-03

What makes things more confusing is that the family that you try to load will likely have nothing to do with stacked walls, in fact both times I’ve had the problem has been with title block families.

To fix the problem, you need to open up your journal file which for 2015 is located at

Windows XP: %USERPROFILE%\Local Settings\Application Data\Autodesk\Revit\<Product name and release>\Journals
Windows Vista, Windows 7, Windows 8: %LOCALAPPDATA%\Autodesk\Revit\<Product name and release>\Journals

Once in the journal file, search for the term ‘ 0:< DBG_WARN: which is where the information you’re looking for starts. The following is from my journal file:

Jrn.Data “TaskDialogResult” _
, “You are trying to load the family Project-A3 SHEET, which already exists in this project. What do you want to do?”, _
“Overwrite the existing version and its parameter values”, “1002”
‘ 0:< DBG_WARN: Family contains category id -2009630, gstyle type 2, gstyle id 558659. That category id and gstyle type map to a gstyle id of invalidElementId in the project. (In practice, this is most commonly caused by a mismatch between the version number passed to addNewGStyles and the version number in the table in ProjectStyles.cpp, due to an incomplete renumbering of an upgrade.): line 503 of d:\ship\2015_px64\source\revit\revitdb\settings\GStyleElem.cpp.
‘ 0:< DBG_INFO: Write access to host’s DocumentHistory from content doc: line 4573 of d:\ship\2015_px64\source\revit\revitdb\document\Document.cpp.
‘ 0:< Unnecessary nesting;Family\FamilyDocument.cpp;642;FamilyLoad__UpdateReplicasInSmallDoc;N++EB(NB);
‘ 0:< Error posted:
‘ 0:< Last type in system family ‘Basic Wall’ cannot be deleted.
‘ 0:< Error posted:
‘ 0:< Last type in system family ‘Stacked Wall’ cannot be deleted.

In this instance there are 2 item id’s that are listed, you may have quite a few more than just two. Either way what you need to do is open up your family and using select by id tool, select and delete the elements listed as causing the problem.

2015-12-07_10-34-46Once the items are deleted, purge and audit for good measure and load back into your project.

Job done!

Modifying That Journal Script to Actually Reduce Family Sizes

A long time ago I was looking for a solution to automatically purge a folder full of families, if like me you had a quick search around the interwebs you would have found this purge script that utilises journals from Revit Randoms that I mentioned in my previous post about converting files from imperial to metric.

Some people however report that the resulting files saved are anywhere up to 30% larger in file size after purging, personally I have seen files more than double in size after running them through the script and considering the idea of purging a file is to make it smaller, larger file sizes are just not a result that you should accept.

Some suggested to repeat the following code at the end of the script 3 times to act like a compacted save

Jrn.Command “Internal” , ” , ID_REVIT_SAVE_AS_FAMILY”
Jrn.Data “File Name” , “IDOK”, namepath

But that never made any difference for me either.

You may have noticed though when you save a file as another name, the compact file option is automatically checked which in turn results in a smaller file by default, when simply saving the file over the top of itself, the compact file option is not selected and you can not select it using journal scripts, trust me I’ve tried!

Sure it means a little bit of extra work, but the simplest way to achieve this is to modify line 108 of the script to read

Jrn.Data “File Name” , “IDOK”, namepath & “_new.rfa”

The script is the same format of the SP.Writer code that I previously wrote about, the & “_new.rfa” simply appends _new.rfa to the end of the file name and path, meaning if you have a file named c:\upgrade\family.rfa it will be saved as c:\upgrade\family.rfa_new.rfa

If you’re upgrading files to a new release, you could even change the code to & “_2016.rfa” and when 2016 is finally released you have upgraded files without the risk of accidentally losing the previous version.

There are probably cleaner but more complex ways to do this, but for the purpose of keeping the excerise as simple as possible by only adding 10 or so characters to a single line of code, this works perfectly fine.

Helpful Tips

If you don’t add the *.rfa extension, you won’t be able to open the purged files afterward even after renaming to *.rfa.

 

Once the script is completed, all you need to do is separate or delete all the *.RFA files and rename the *.RFA_new.rfa files back to *.RFA, you could automate renaming the files with a tool such as Better File Renamer or a free alternative such as Bulk File Rename Utility.

The files I’ve run through the script are families that have geometry imported from Solidworks models, even though not the greatest of examples, you can clearly see the improvements of this simple change.

As shown in the screenshots below the files started out at 1.34gb, after running the unmodified script on them, the increased in size to 1.7gb, after running the modified script over the original file, they reduced to 920mb.

2015-03-26_14-32-29

An extra few minutes work but the process still remains mostly automated and you have the bonus of actually achieving the desired solution of smaller file sizes which makes it absolutely worth it.