Hi Everyone.
is there a simplified way of writing a code or example of it that when I Write information in Excel, it can be brought to Revit and if Changed on Revit it can be automatically updated?
thank you all.
Samuel
do you think you could post an example of what you are trying to do? i.e. in Excel I can do this, how can that be done in revit thru Dynamo?
Thank you, Tom and Johannes, for your answers I really appreciate it.
First of all, in Excel I want to create a Roombook that can be send to my client so he can choose directly what type of elements will be required or he would like to have in a space, this is mostly related to Laboratory Design.
I have previously created a Roombook where I had a drop-down menu for each option of elements I require, for example, if the room requires Sewage, then there is a drop down menu with options in excel that has yes and no for answer, if the user wants says yes, I would like to relate that to a Yes/No Shared Parameter previously created for the room, and when the information from excel is read, then it will change, also, if in Revit I deactivate the checkbox for no, I would like to automatically update the values in the excel file.
So Far I have only created an initial path that links the value from excel to the shared parameter from Revit, I attach code.
That is why, my goal is to have a single bi-directional code, which I know it will be quite large since I have close to 300 shared parameters, and I was wondering if there was a simplified version of doing it.
I actually was previously working the same topic in Access but I got to the limit that each of the tables should not have more than 255 parameter types, and creating more tables to relate the information is not possible since the Revit DB Link will not import those tables that were created outside Revit.
Thank you very much and sorry for the long post.
Samuel
Samuel,
I am not lucky about yes/no parameters. E.g.: You want to paint doors and have 10 different colors, you would get 10 yes/no parameters. If you create a parameter âDoorColorâ you have one parameter and fill in a color code. It is a lot easier. ;-))
Johannes
1 Like
Also keep in mind how youâre going to control the bi-directional flow of information. How will Dynamo know when to push information to Excel and when to push to Revit? Youâll probably want an âoverrideâ parameter in Excel, for example - push Revit info to Excel by default; if info is changed in Excel, set override and have that information push to Revit instead.
Does that make sense?
Bi-directional is a myth. Requested workflow is more push client program into Revit, then confirm Revit content matches client program. That is you want compare what was asked for and what is currently owned. Hidden is a way to do that (assuming I used the feature right).
One way to check
First dynamo push is from clientâs input in the excel sheet into the model. Donât change that ever - in fact make it protected in excel to conserve the data. You will want it later. Set up a âcurrent comparisonâ sheet as well, which references back to the client data as Row 2, 5, 8⌠skipping two rows will be important later.
Second push is from the Revit model back to client, on a new sheet called Revit Data (date), and into a sheet called âcurrent dataâ which is then referenced into the âcomparison dataâ tab on rows 3, 6, 9âŚ
Row 4, 7, 10⌠of the comparison data sheet should have a formula along the lines of âA2=A3â and have formatting to highlight the false values. Any time you want to pull back the client input you can. Overwrite their old input with the new. Anytime you want to check your current Revit data against client export the data and use a filter or pivot table to only show the false values of the comparison data tab.
I agree that 300 y/n parameters is a bit much. A single string in a field âProgram Requirementsâ should suffice. I would look into building the value string from their input programmatically, something like List.Clean(A[1] == 1? "Sewer, ": null + A[2]==1? "Eyewash, ": null) should get you started. Once that is done the inverse can also be applied to go back to excel for the comparison with a String.Contains node. You could also pull the "Sewer, " from the headings of the room book from the client.
I am assuming that in the end you want to check to make sure there is a sewage connection in the lab space, and this set up would also allow you to check for family types in rooms based on that string.contains node by calling only one parameter instead of 300 parameters. WAY easier.
TLDR: As @Johannes_Meiners said, write the door color donât have a yes/no for every possible door color.
Dear Johannes_Meiners, Nick_Boyts, and JacobSmall
Thank you very much for your comments, they are all very constructive.
First Johannes_Meiners.
In The specifics yes, I do agree with you that rather than having a yes no for each of the colors of the doors, there should be a dropdown list that says what colors are available.
The thing is that I have previously reduced this values, it is similar as for how in Databases its called Standardization of Data.
Since in my office the projects we work are both related to architecture in some parts but at the same time with specifics like layout of the labs and MEP/HVAC systems, we created a 4 page room book that covers all we work on each project, that really reduces time and headaches when dealing with a lot of complex tasks, therefore it is obvious that this information that was created in Excel, should be displayed in Revit, also since there is a lot of standards to follow, the best is to have all the information available, and in some cases related, so that an architect that may work with it, do not necessarily needs to know all the codes/standards that apply when locating a specific element in the laboratory, in my opinion, the data that is being brought from excel, works as a guideline for what should be placed in the room.
Dear Nick_Boyts
After struggling, yes I absolutely agree with you that there should be two codes, one from pushing from Excel and the other for pushing from Revit, having everything in a single code may cause problems to know where the information should be updated.
Dear JacobSmall
I actually was creating a list that, instead of having multiple types of configurations of rooms with yes no options, was a key schedule, but in the end, at least what I have learned from laboratory design, it can always be modified by project requirements, user requirements, budgets, types of standards to use, and many more. so it is quite chaotic to have a key schedule since it may be a super long list and easy to forget how to work with it, initially only for finishes (Wall, Ceiling, and Floor Surfaces) I had around 180 types, so I think in this case is better to select it without have kind of a key schedule on the back. there are other options that should not have a key schedule like types of fume cupboards, waste management types, Safety features for normal or Bio Safety Labs, etc.
Thank you very much.
Samuel