- This topic has 11 replies, 5 voices, and was last updated 3 years, 10 months ago by
.
-
Posts
-
-
I have an object that uses complex profiles to generate its geometry. I need to be able to extract the name of the profile to run a SPLIT command to automatically fill in other parameters.
E.g. Profile names: Sleeve Type S01; Sleeve Type S02.
I would SPLIT the profile name “Sleeve Type S01” to extract the number (i.e. 1) and then run further tests, fill parameters, and run schedules.
E.g.
n = REQUEST ("Name_of_Profile", myProfileIdx, pName) IF n THEN p = SPLIT (pName, "%s", txt1) IF txt1 = "Sleeve" THEN ! Correct profile chosen n1 = SPLIT (pName, "%s %s %s %n", txt1, txt2, txt3, num1) ELSE num1 = 0 ENDIF IF n1 THEN IF num1 >1 THEN cond = "Strengthened" ELSE cond = "Carbon Wrap" ENDIF ENDIF PARAMETERS cond = condThe only problem with this, is that I can’t use the REQUEST (“Name_of_Profile” in either the Master or Parameter scripts (it’s a project dependent request), and the other scripts can’t write parameter values. I’m stuck. Anyone got a solution?
www.brucepwalker.com
https://www.mindmeister.com/65450406AC20 6005 AUS Full & AC 21 3009 NZE Full | Win 10 Pro 64 | Intel i7-7700HQ 2.80GHz | 16 Gb RAM
NVIDIA GeForce GTX 1060 8Mb -
Hi Bruce,
You can not and should not reach any data of a profile from parameter script (including master, when it runs before parameter script). If you would be able to do so, that could cause inconsistent data in a plan file, as you can place an object using profiles, after that if you change anything in the profile that won’t be followed by a parameter script run, so your object could easily store outdated information or invalid, inconsistent data.Gergely Fehér
Team Leader, Library Team
GRAPHISOFT SE -
Thanks Gergely – I had suspected that was the reason. I take it from your answer that there really is no way for me to achieve what I need. No matter.
It makes me try to think of a use for the REQUEST (“Name_of_Profile”… what use would it be in the 2D / 3D script?
www.brucepwalker.com
https://www.mindmeister.com/65450406AC20 6005 AUS Full & AC 21 3009 NZE Full | Win 10 Pro 64 | Intel i7-7700HQ 2.80GHz | 16 Gb RAM
NVIDIA GeForce GTX 1060 8Mb -
I’m now running into the same problem with trying to intelligently produce door schedules with leaf & frame finish fields. I want the schedule to read the finish surface of the leaf or frame, and run a SPLIT or STRSTR command to extract the finish code from the description.
The problems I’m encountering:
1. I can’t run a REQUEST (“Name_of_material”,…) command from the parameter script – for the above mentioned reasons I’m presuming.
2. I can’t run a SPLIT command in the properties, as I can’t reach object parameters from properties
3. I can’t shorten the schedule column to obscure the description of the surface, as it adds a ‘…’ to indicate there is more information.This is resulting in three separate entries for the same data – not a good practice: 1. User selects the right surface inside the object. 2. User selects the finish code from a properties-specific options list for the leaf. 3. User selects the finish code from a different (but containing multiple duplicate values) properties-specific options list for the frame.
This is bad!
An example of a surface name would be “TM-104: Timber veneer” – and I just want the “TM-104” part.
Ideas?
-
Assuming with this naming scheme the surfaces are specific to the library parts: create the surfaces from the library parts or a MASTER_GDL. You can then use a string type parameter to select the surface, and transform the name into another string.
Péter Baksa
Library Platform, Software Engineer
GRAPHISOFT SE -
I don’t think I quite follow.
The same door library part may have different surfaces for separately placed instances. Our surfaces are named such (code + description) so they are a little more informative to the user; and there may be multiple entries of the same code, but with a different vectorial fill (e.g. timber grain direction), which requires a different descriptor. However, in the schedule, just the code is required.
I don’t think I can hard code the surface into the part.
I’m not familiar with master_gdl, as every practice I’ve worked for has prohibited their use. However, I might dig into it further.
-
-
So I’ve experimented with the Master_GDL, and I don’t think it will do what I need.
On a project, the material codes are selected by the designer. There can be >100 selections, each with their own code (see example in my second to last post). The materials are NOT object specific: the same material can be used on doors (leaf, frame, glass), walls, objects etc. Therefore, we need to list the code when we schedule out our elements. I cannot figure out a way to do this in schedules inside Archicad. I suppose I could export the schedule to Excel, and run a formula in there – but it would be very handy to be able to extract this somehow inside Archicad.
Maybe the addition of an ID and Description field within the surface itself – similar to building materials?
I’m kind of stuck.
-
I am not sure if I follow the exact problem here.
If your material is set by a parameter in the object then there is no need to REQUEST anything, as you already have the parameter value.Otherwise, can you create a property with an expression that splits the material name into its code and description components?
Then you can schedule that property value.
This method could be used on other elements (walls, slabs, etc.) as well as objects.Barry.
Versions 6.5 to 22
Dell XPS- i7-6700 @ 3.4Ghz, 16GB ram, GeForce GTX 960 (2GB), Windows 10
Dell Precision M6800 - i7 4700MQ @ 2.40GHz, 16GB RAM, AMD FirePro M6100 (2GB), Windows 7 64bit -
Let’s take the specific example of the door schedule:
– we schedule the leaf finish, and frame finish in the schedule
– this finish needs to be a code, e.g. TM-104
– this needs to be read directly from the relevant parameters in the doors to ensure integrity of information: in this case “gs_leaf_mat”, and “gs_frame_mat”
– the Surface name in the project attributes is actually “TM-104: Timber oak dark stained”, therefore I need to SPLIT the Surface name so only “TM-104” will show in the schedule
– I cannot use a Property, as Properties cannot read object parameters
– I cannot use a SPLIT command, as I cannot REQUEST the Surface command in the Parameter script
– I cannot cheat by narrowing the column, as different codes have different widths
– I cannot change the Surface names to just be the codes, as there are exceptions to this that require the description
– I may be able to set up an IFC field that will SPLIT the Surface name, but so far I haven’t been able to get this to work – and there could be performance issues associated with this.I understand the reason GS gives for not being able to REQUEST the Surface name in the parameter script, but surely there’s a better way?
-
– I cannot use a Property, as Properties cannot read object parameters
No of course not – I wasn’t really thinking there – sorry.
– I cannot use a SPLIT command, as I cannot REQUEST the Surface command in the Parameter script
Again, sorry.
I was thinking the parameter is already a name, but of course it is an index number.
You still have to REQUEST the name for that index number.I understand the reason GS gives for not being able to REQUEST the Surface name in the parameter script, but surely there’s a better way?
I don’t.
When is the material ever going to be different other than when you change the parameter in the object – and doesn’t that mean the parameter script is run?
Unless Gergely is saying it is because someone may edit the name of the surface (material) attribute in the attribute manager and then the object script is not being run to get the changed name.Barry.
Versions 6.5 to 22
Dell XPS- i7-6700 @ 3.4Ghz, 16GB ram, GeForce GTX 960 (2GB), Windows 10
Dell Precision M6800 - i7 4700MQ @ 2.40GHz, 16GB RAM, AMD FirePro M6100 (2GB), Windows 7 64bit -
That’s why, I think. The underlying Surface could be changed, and without running each parameter script again, the values in the objects would no longer be correct.
I have two notes: 1. It would be good for this to be up to the individual / BIM manager to manage – not to have this functionality shut out unilaterally. 2. Does the parameter script run when producing schedules? I don’t know.
-
- The forum ‘Parameter connections’ is closed to new topics and replies.