I upgraded to the latest version 22.05.00.131 from 22.04.00.40 and the changes on the way it designs the horizontal bracings is very different, and now all my horizontal bracings are failing, what happened to the program? what has changed?
Right now I had to change from member truss to member release and the section from previous version was a WT6x17.5 and now WT6x32.5 and barely passing.
Adding a little more to this issue, the axial forces in member truss as an example is 120 kips and for member release is 26 kips, this is very odd. It is only affecting my horizontal and vertical bracings when assigned as member truss.
Turn on track changes and look to see what changed? Like Tank said, check for one load combination only by using LOAD LIST. Also, turn on TRACK 2 for the member you are checking to get a report of what STAAD is calculating for that member.
I would also look at the change log for v22.05. They maybe fixed a code check for the code you are using, which is why it gives different results.
I downgraded, therefore I am not dealing with this anymore. I hope Bentley can replay and let me know what to do.
Could you please attach your model here for the investigation?
Piperack_Bentley ckeck.std
Moestas, has there been any resolution to this? I was going to upgrade but I'm waiting to see what's going on.
I took a look at this issue today and it seems very odd that the actual axial compression in the member varies so widely between the MEMBER TRUSS and MEMBER RELEASE scenarios. The design capacities ( Axial compression ) reported between the versions seem to be pretty close and so the difference in design results seems to be related to the difference in the actual compression forces. I have reached out to our development desk on this and will revert back with an update soon.
An update on this issue. After further investigation it has been found that when a member has TRUSS specification and has temperature load applied to it, the STAAD.Pro CE Update 5 is reporting a much higher axial force than the actual value and this is incorrect. A Bug# 510695 has been posted and it will be addressed ASAP. Our apologies for the inconvenience.