Hello,
I would like to ask if I understand FdScript correct.
Marco said this could be used to set parameters that is not available in API se post: Discussion on FdScript
If I would like to change crack width a Fdscript, it would look something like this?
I interpret that as the analysed structure needs to be static.
Having the API creating the object will cause a new randomly generated guid every time API is run, causing guid given in the Fdstript to be “out of date”?
Depending on your case study, you can do something like the following to statically set the Guid of an object.
As a note, Fdscript Guid always refer to the analytical Guid which is the one on the attribute.
slab.Guid = new Guid( "{F42D2623-FB17-4F39-9A21-EDDA24944298}");
slab.SlabPart.Guid = new Guid("{A951B736-3394-4FE4-B38F-D17F1161EB3A}");
If needed, we can implement the features so that you can use it by C#.
In that way, you can avoid in creating the text file manually.
Sorry in advance for long post
I have done an honest attempt even if I find quite a lot of work learning a different coding concept with separate files just to do a thing, I think is quite essential for concrete construction.
In element creation:
// Set static Guid
SlabBPL.SlabPart.Guid = new Guid(“A951B736-3394-4FE4-B38F-D17F1161EB3A”);
SlabMUR.SlabPart.Guid = new Guid(“F42D2623-FB17-4F39-9A21-EDDA24944298”);
SlabBPLMUR.SlabPart.Guid = new Guid(“2E290437-E86A-4E36-AF7D-ACDE6A6146C8”);
Have you any clue what can be wrong with my FdScript?
Sidenote: In bridge construction exposure class is important as surfaces often is subjected to water or chlorides. Example in road environment leading to affecting reinforcement needed for design. I asked my colleague that works designing buildings and according to him crack width is also relevant for him when designing foundation and other concrete surfaces that can be subjected to water/chlorides (even if the corrosive environments are more important in bridge design).
In conclusion, cracks are important for most reinforcement design and can affect utilization rate. Therefore, my opinion is that crack width should be easy to control within the API.
Feels like it relates to this old post about setting “design parameters”.
Maybe setting crack width can be implement at the same time?
Thanks for your help!
Now the .FdScript work if I run it with Tools -> Run script SetCrackwidth.zip (947 Bytes)
But when the script is run though the API with FemDesignConnection.SetConfig(string filepath) I get the following error message (with a bunch of other message of successful script runs “Script file finished”):
Have edit cfg.xml in the project folder so it matches the .FdScript C:\Users\kpn\VS local\FemDesign.KPN\RetainingWall
Is this the correct? I also see that there is a cfg.xml in: C:\Users\kpn\VS local\FemDesign.Core\Calculate\Config
Thank for all your help Marco!
I will try to summary what I learned.
Maybe it will help someone else
If I would do some other configuration setting with API I would follow this steps:
Set the desired configurations and use the following command in Fem-Design
FYI:
We will implement those ConfigSettings so that you can avoid using the xml file.
We want our users to be able to do something like:
new calcShellRc = new CALCPARAMSHELLRC( foo, foo1, foo2 );
new calcShellRc = new CALCPARAMSHELLRC( foo, foo1, foo2 );
var config = new Config(calcShellRc );
connetion.Setconfig(config);
