These aren't limitations of Voxel Link (VL) per se but are questions we've seen arise during projects that are easier to deal with and know about up front rather than trying to change gears deeper into the project.

  • The RAM and Revit model names are intended to remain consistent throughout the life of the project once they have been paired with Voxel Link. The settings and map files use the model file names as identifiers. If you change the original model name, the renamed model looks like a new model, and you end up with duplicate elements everywhere. To avoid breaking the model pairing, do not rename the active RAM or Revit model files after they have been paired in Voxel Link. For milestones or issued versions, create dated copies such as Project_thru2026-04-09.rss and Project_thru2026-04-09.rvt, and continue working in the original active files.
  • The default modeling definition for RAM is that story elevations represent the top of steel (TOS) of the floor framing, not the finished floor. When element coordinates are received from RAM, the Z elevation is the story elevation. If you are sharing a model with the design team/contractor(s) and specify the story height to be finished floor, the top of all the steel beams will be flush with the finished floor in all the other design team models. You could change the z Offset Value for all the beams to be (minus) the slab thickness. That feels a bit complicated. We recommend setting the stories in RAM modeler to be TOS for each floor. Generally, the first floor is 'off' and the rest are floor-to-floor heights.
  • A related issue happens with the story names. VL imports the story names and elevations as defined in RAM. If all of the stories in RAM are meant to reference a TOS elevation but the project definition is the story name is for finished floor, there is a conflict.  Revit will allow you to have two levels with the same elevation but not the same name. To avoid the duplicate names, you could see what the project level names are (e.g. LEVEL1) and set up the structural story labels in RAM as Level1 (level names are case-sensitive) then deal with the offset for slab thickness. However, using the top of steel elevation for the story elevations in RAM and labeling the story as Level1 will definitely be confusing for everyone else - your beams are dropped down to TOS, but the level label says Level1, the same name everyone else is using for finished floor. We have found labeling our stories in RAM with a "TOS" suffix (e.g. LEVEL1 TOS) resolves this level naming conflict. VL is designed to avoid duplicate level names in Revit but can't help with the confusing part. The "right" answer for addressing this issue might be different between structural firms but knowing about the issue is half the battle.
  • RAM actually stores coordinates in inches even when you're working with feet in the dialog boxes. Revit allows for element placement to 1/256th of an inch. That's 3 significant decimal places for inches and 4 for feet. RAM has some quirky behavior for input values for grids and beams spacing when you work in feet. You can type in values with 4 to 5 (or more) significant figures but the display gets truncated to 3 for some values. If you use that 'default' value again, you only get the displayed value, not the one you originally typed in. That can create dimensioning issues (weird fractions) in Revit if you're not careful. Try modeling all the grids and framing in RAM in inches, not feet. It's a bit of a pain but we have found it resolves almost all weirdness in Revit. It's only really an issue with dimensions that repeat, like 1/12, and fractional inches. But if you get in the habit of working in inches, or remembering to switch to inches when necessary, all is good!
  • There is a lot of work going on in VL especially for the first import - adding levels, searching for and adding structural families on the fly, writing elements (beams and columns), creating plans and annotating plans. Annotating plans seems to be the most intensive for the initial creation. You end up writing three tags +/- for each beam - three times the work. However, subsequent updates for all of the elements take a fraction of the time - checking and updating is much quicker than adding. To help with this in the early phases of a project where concepts are changing frequently, a toggle button option was added to the settings dialog to turn on/off the annotation of members. For a large project, this can save a significant amount of time up front. Once the framing has settled down or plans need to be sent out, rerun VL with that feature checked, and let it grind through the annotations once. Yes, the Revit version of beam annotation generation appears to be quicker, but Revit doesn't have the filter for a min reaction. VL does!
  • There are occasional warnings from Revit when processing beams that a member is very slightly off axis. These can be ignored. They do not affect the functioning of VL.