I’m currently working with Tekla Structures and using the Grasshopper-Tekla Live Link to place a custom connection component automatically in the model. The component was created in Tekla and is designed to position bolt groups based on the dimensions of certain plates. It uses internal logic to determine things like bolt count and spacing depending on the geometry of the connected parts.
The problem I’m facing is that when I run the Grasshopper definition to place the component in the model — and this happens especially when the component hasn’t been used before in that model — the component doesn’t behave as expected. It gets placed, but it doesn’t seem to react to the geometry or apply the logic that’s built into it. The bolts don’t appear correctly, or sometimes not at all, and it looks like the internal parameters or calculations aren’t being applied.
Interestingly, when I manually double-click the component in Tekla, don’t change anything, and just click OK, the component suddenly updates and behaves exactly as it should. The bolt groups are generated properly, and everything adjusts according to the geometry as intended. After doing this once, the component also seems to work correctly for future placements, even through Grasshopper.
I’m not sure what causes this behavior or how to deal with it. It only seems to happen the first time the component is placed via Grasshopper in a model where it hasn’t been used before. I’m wondering if anyone else has come across a similar issue when using custom components in combination with the Grasshopper-Tekla workflow.
Any thoughts or shared experiences would be appreciated. Thanks!
Yes, this issue is indeed occurring with this component. Here’s a quick explanation of how the component works:
It looks for longitudinal and transverse beams that are close to each other and are meant to be connected via an angle plate. For this connection plate, the Tekla component creates so-called BoltGroups, whose arrangement depends on the profile of the angle plate.
Grasshopper is used to automatically search for all relevant triplets – that is, one longitudinal beam, one transverse beam, and the appropriate connection plate – and feeds them as input into the component.
In the attached image, you can see two variants of the bolt arrangement.
The current problem:
If you first place the component manually in the model (even just once), then delete it again and afterwards run the placement via Grasshopper, everything works correctly – the component becomes “intelligent” and adapts to the specific plate situations.
However, if you place the component directly via Grasshopper into the model (without any prior manual placement), then the plate parameters defined inside the custom component are not queried. As a result, the bolt group does not adapt correctly.
I hope this explanation makes sense.
Sorry, I forgot to share the script and the component itself.
From what I’ve been able to test I don’t see a difference between inserting from Grasshopper and inserting manually. But I might be testing it the wrong way despite trying to use fresh input parts.
When inserting manually the component sometimes becomes yellow and I need to click Modify in the dialog to get it green again, or vise versa. The prompt says “could not create bolts”. Not sure if that indicates some instability.
What if you place them with Grasshopper, and then run the definition again to trigger a Modify for the components that were inserted in the first pass? Or if you right-click the component in GH and “Delete components in Tekla” after the first pass, then re-run the definition? Does this make them adapt?
Or what if you right-click the component in GH and turn off “Run in background”?
My guess is that this is related to the fact that you’re using formulas to calculate values for the parameters that are shown in the component dialog. These dialog value fields will only be adaptable if you haven’t changed them from the default value. But since the values come from a formula, what’s considered the default values might change every time the API inserts a component, meaning that the old values might become fixed rather than allowing the next component to use recalculated values. Or something along those lines, hard to tell as I haven’t been able to reproduce the issue with my model.
Maybe instead, for any parameters that should be shown in the dialog, you could have a static default value in the “Formula” field. This value could represent e.g. an offset from a calculated hidden base value, rather than the base value itself. This parameter/value can then be referenced by other (hidden) parameters for calculations.
thanks a lot for your detailed reply!
I’ve tried your suggestions – both using Recompute Component and Delete Components in Tekla to remove the previously created components and place them again. Unfortunately, that didn’t solve the issue.
I also tested with Run in background turned off, but the behavior remains the same.
What’s interesting though: when I create a completely new Tekla model and simply copy the beam structures from the old model (where the problem occurred) into it, the Rhino automation suddenly works perfectly fine. I open the Tekla model first, then Rhino, run the Grasshopper definition – and this time the components behave as expected, are placed correctly, and update automatically.
So my question is: could this behavior be model-specific – for example related to certain model settings, attributes, or project data that might have been inherited from the original (partly BE-based) models?
In the new model I haven’t changed anything besides copying the beam geometry.
Do you have any idea which Tekla-specific properties or attributes could affect the GH component behavior here?
Really curious behavior. I don’t really have a theory on how this might be related to model-specific or other settings but that’s of course a possibility
I still think this might be the culprit. Having defaults that are re-calculated based on the input you pick is not something I’ve seen a lot, but it might be common out in the wild. I can see how that might break down when inserting the components through the API, and thought that solving things synchronously might help (although you confirmed that turning off Run in background didn’t make a difference). I would need to be able to replicate what you’re seeing to be able to test further.
