Lack of efficiency within Robot/Revit link?

Hi everyone,

Our chief Revit technician at our company has spent the day with me (structural engineer) trying to work out the workflow processes between Revit and Robot.

We have hit something of a wall however, as even though we both understood the principle that you couldn't work on a model in one program while the other was updating the model in the other, the Revit technician thought at the very least that he could annotate the Revit model, set up new sheets, take sections etc while I played around with the model in Robot.

This does not appear to be the case, as even the most minor change in the Revit model, while I am changing the model in Robot, seems to break the link (an error message pops up telling us that the Revit model is no longer the same as the one that originally created the Robot model). As such, we are wondering if this is correct?

If it is, it somewhat makes a mockery of the the whole selling point of this process, that being that it is supposed to increase efficiency. How can it be efficient when either the engineer or the Revit technician has to twiddle their thumbs and wait while the other person updates the model in the other program?

Hi!

I can assure you that this is most definitely not intended to work in the way that you have experienced. The round-trip workflow is intended to be quite fluid and I've found it to more or less work quite well. The link will even handle a quite large change to the model like moving columns or grid lines. (see attached). The model I sent was more or less square and then while the model was out in Robot, I manipulated the model dimensions as you can see. On update, the analytical model is adjusted to the configuration that was in Robot (this is expected) and the warnings give you a trail that you can follow to figure out what the Revit Technician did in the meantime. (so you can make a decision about whether to adjust your analytical model and re-run the analysis/design)
Attachment 86716

I've just done two experiments using both the send-direct option as well as the send via an .RTD file, modifying the Revit model in the meantime and successfully updating the model after adding sheets, annotations etc. in Revit while the model was out in Robot. (with no warnings other than the ones I expected, shown in the screenshot)

I'm working in Revit Structure 2013 and Robot Structural Analysis 2013, are you perhaps working in an older version of the software? I'd like to help you sort this out if you can give me some more details and/or perhaps post your model(s) or some screenshots of what you're seeing that would be helpful. One thing that I can't easily test is sending the .RTD file to another machine but I don't believe that it should matter (though anything is possible when it comes to software bugs)

Thanks,
Ken

Hi Ken,

Thanks for your swift reply. We've been at the same problem again today, and we've seemingly moved on from what we are able to do from yesterday, but we are now getting a similar, if slightly different problem.

We had originally been working off the same master Revit file from a central location, but to model the likely working environment of a project where Revit is being used, the Revit tech suggested that the usual way to operate is to have a master file in a central location, with each person then taking a copy of the Revit file and then synchronising back when they had completed their work.

This seemed to work up to a point. We were able to each take a copy of the master Revit file onto our own C drives, and while I updated beams etc, the Revit technician annotated the model, set up new sheets etc. I then passed the robot model back into Revit and synced it with the master file, and so did the Revit tech. This seemed to work fine as we both ended up with the updated model in Revit with some new annotated plans.

However, when we tried to take it onto the next level like we were trying yesterday, everything seemed to fall apart once more (but in a slightly different way to yesterdays efforts). Essentially, we once again took copies of a master Revit model, with the Revit tech then editing some beams while I simultaneously pushed the model into Robot and edited a column. What happened next is attached in the pictures.

Fig 1: Revit technician took the model and made beams at level 2 smaller in size.

Fig 2: I took the model, pushed it into Robot, and changed the column to the bottom left to a small rectangular hollow section.

Fig 3: I synced my Revit model with the one just changed by the Revit technician so I now had his updates in my Revit model. I then tried to pass the Robot model, with the changed column, back into Revit and got the standard "The Robot Structural Analysis model was created from another Revit Structure model", which was to be expected (we did try to not sync the Revit models first, but this seemed to create more problems. There appears to be a live link between all models, so as soon as the Revit tech has edited the main model, and I try to pass my model back from Robot to Revit, I get the same error message that my model is no logner the same one as originally made the Robot model, even without syncing)

Fig 4: As with your example, I then got the "analytical-to-physical model distance exceeded" warning.

Fig 5 and 6: This is where it got a bit strange. We tried this on several models, and it appeared to happen on all of them. As you can see from the image, a structural analytical beam has moved diagonally. Also it can be seen that the column to the North of the image has disappeared, and finally, the column I have changed, instead of being on the left hand side of the model, is now on the right (attached to the beam that is running along the floor)

As I said, we had a far larger model than this, and the random disappearing columns, diagonal members etc when trying this process happened there as well.

Thanks in advance for your help.

Regards,

DTJ

Just attaching picture No.6.

Hi DTJ,

I just ran through a worksharing scenario on my local machine (it's a little like juggling blind-folded but doable) where I tried to simulate the workflow you mentioned. I should say that I'm working in Revit 2013 and RSA 2013, are you in 2012 or 2013 (or...)? The link software as well as the Revit software could be significantly different between these two versions especially in this area. The first test that I did and posted above (or below depending on how you have your forums set) was just me working back and forth between Revit and Robot on my machine. When I set up a workshared environment and played both engineer and tech I ran into some interesting messages (I didn't expect exporting to Robot to take editability of elements but it's probably not a terrible approach) but it seems like most things were fairly well protected. The whole idea of editability being that you shouldn't both be able to make changes to the same element that would collide with each other.
I wasn't able to reproduce the issue you are seeing though I have some theories about what might be happeneing and I've asked the team that develops the link to take a look.

In the meantime, try putting the beams/columns on a workset and check it out before you run analysis. That should allow the Revit Tech to create sheets/views, annotate, dimension etc but not allow them to alter the nature of the structure (since the member sizes are probably more your area but that's totally up to your workflow. Having editablity of the workset will just prevent inadvertent changes to the members you need to modify (potentially) with Robot)
I will continue to work on this with our link team but if you'd like me to dig in more deeply on this particular issue I would need to either have very specific steps (what each of you did, which worksharing errors you got at which points and who saved/changed what first. It's important because whoever does something that takes editability first now is borrowing or "owns" that element that won't be resolved until a sync and relinquish) the journal files for the session from each machine would tell me most of that. If you'd like to post those, it would be best to have both of you start "fresh" with each of you opening your local files, do the series of operations which causes this and then send those journal files. (they should be fairly short maybe 200k)
At this point, my other suggestion (and probably the best one) is to contact your reseller so that they can help out as well, they may have seen this issue before.
Thanks,
-Ken

Hi Ken,

Thanks for getting back again. After spending a second day at this, we finally worked out what the problem was. It appears that at our company we have set up our own UK beam size families. The introduction of these into any Revit model seems to be the problem (we had always started our models in Revit before trying to pass them back and forth, and so obviously the Revit technician used our own member sizes). However, when we went the other way (Robot to Revit), we found that there was no issue when we tried to alter the model (even simultaneously) while using member sizes automatically generated in Revit from the Robot model.

This obviously poses a new problem, and given that I am the engineer who works primarily on Robot, it's a outside my area of understanding. However, the Revit Technician I have been working with will hopefully see this in the morning and he's signed up so he'll be better placed to explain in much greater detail what the problem is from a Revit viewpoint.

Regards,

DTJ

Hi Ken,

At risk of going over some things that have already being mentioned I will start form the very beginning.

We have spent a few days exploring the link between Revit and Robot, and started out building a model in Revit, setting up a central file so the Engineer always has a local copy of the Revit model which they work with when importing / exporting with Robot, and the Revit operator having a local copy of the model. We tried passing that information from Revit through to Robot, making a change to the model within Robot and passing the information back to Revit.

That works perfect.

The next step was to make a change to this model in Revit and pass that model back to Robot.

That works perfect.

We then thought about workflow, it isn't practical having the Revit operator sit waiting for the engineer to finish, so we tried passing the Revit model back into Robot, then simultaneously work in Revit making annotations, setting up views, etc. whilst the engineer was making updates to the model in Robot. We faced a few worksharing issues but once the saves / relinquishes were done this worked perfect. I was able to annotate the model whilst the engineer made design changes.

The next step was to make changes within the Revit and Robot environment to the model elements, so for example the engineer changed the size of a beam, and I changed the size of a specific column, when we pushed and pulled this information back into Revit and Robot the model updated perfectly.

Here's where the problem comes.

The members that Robot pushes into Revit are specific to Robot. We obviously have our own libraries set up with object styles etc. so from a documentation point of view, we need to make sure we use our own in house families.

When I change one of the robot members to be one of our in house Revit members as the engineer simultaneously changes something within Robot it seems to fall down, without even syncing the model, when we try push the Robot info back into Revit we get the error message that the Robot model was created from a different Revit file, and Robot basically copies the whole model into Revit and we finish up with duplicate members in the same planes. Not to mention members ending up off axis.

So it would appear the issue lies with changing a family from the Robot specific element that was pushed into Revit, to one of our own. Which I will add are simply an amended version of the out of the box Revit content delivered by Autodesk.