Bug in Load Case List

[tony.ridley]

Hi,

I think there is a problem with the load case list, when defining a moving load.

I define a moving load case #101 "HS20-16a" and then run calculations.  Robot automatically creates  two more cases HS20-16a (+) and HS20-16a (-).  This is normal and OK.

I then define a combination call it #102 "1.2g + 1.5TRUCK".  

It appears in the calculations box, the load types box, and the combination table.  So far so good.  See pics;

Robot then automatically creates the (+) and (-) cases for the new combination case.  However unlike with the simple case, Robot duplicates the originally defined combinateion with a new case, #7.  There are now two combinations called "1.2g + 1.5TRUCK".  There is a difference between the two dialogue boxes.  See pic;

My steel design still checks case 102.  ;

This is actually VERY DANGEROUS as you may be checking an envelope of cases including #102.  You will only be told the controlling case, and may assume another case is the worst one, when actually Robot is just using Zero as all member forces for the case you intended to check for. 

Additionally, there is no case 102 in the drop down;

Please advise if this is a known issue and if it's planned to be fixed.  On top of that, it seems to me silly that Robot adds the two (+) and (-) cases into a different order on the list.  Makes organising the list of cases difficult.  If I manually change the case number, next time I run analysis it goes back to the previous.  😞  

Why can't the user specify the case number for the two additional cases? 

Cheers, Tony

[Rafal.Gaweda]

Tony:

http://forums.autodesk.com/t5/Autodesk-Robot-Structural/moving-loads-combination/m-p/3479840/highlig...

[tony.ridley]

No, it's different to the post you refer to.  I understand that I need to use the case with no (+) or (-), which I have done.  

The problem in this case is;  I defined my combination as case 102.  Robot has then created 3 (not 2 as usual) extra cases.  

The results are not shown in my case I created, but in the new duplicate case.  

Case 102 shows up in some dialogue box but not another.  Worse, the steel design module recognises case 102 which nas no results in it.  

[Rafal.Gaweda]

File please 🙂

[tony.ridley]

Any progress on this one?

[Rafal.Gaweda]

102 is used for design only in situation where 102 is ONLY on the case list for design. But you are right, it may be confusing. I will register it.

[tony.ridley]

Hi,

This moving load cases bug is creeping around again 😞

Please see pictures below.   I have 5 moving load cases.  Then I create 3 case combinations.

Case 100 is renamed to case 41.  I don't think it should be renamed, but it happens. 

Case 101 and 102 do NOT generate an envelope, and they DO NOT generate any internal forces / results. 

I will send file via email for checking.  Thanks,

Tony

[Rafal.Gaweda · Accepted solution]

comb 100 => 46656 components

100 + 101 + 102 => 3*46656 components > 64000 limit set in job prefs.

[tony.ridley]

hmmmmm that one.  bit embarrasing not getting that!  cheers,

SUGGESTION:  if robot has more cases than the default limit, the program can SHOW A WARNING MESSAGE!  hahah

Tony

[Rafal.Gaweda]

Good idea !

[Rafal.Gaweda · Accepted solution]

---

Rafal.Gaweda wrote:
102 is used for design only in situation where 102 is ONLY on the case list for design. But you are right, it may be confusing. I will register it.

---

Corrected in ARSA 2015 SP1.

[Rafacascudo]

What about the Moving load case numbering modified by robot itself?? Very annoying and dangerous!!

If I need to change something in the model ,add some other load case, whatever , I was very surprised that my envelope screenshots(updated upon printing) were not valid anymore because they´re are refering to the "old" moving load cases mumbers.

Ok , I edited them on printing preview, setting the correct load case numbers , printed them and it works. Then if I close printout composition , open P.composition again , and check these envelope screenshots ,they are all wrong again!!!

video  :  http://screencast.com/t/TqsTAUv5

[Rafacascudo]

Any news about my last post on this thread??

Any ways to avoid Robot changing the envelope(+ / -) load case numbers??

thx!

[Rafal.Gaweda]

Nothing has been changed in these area.

[Rafacascudo]

Hi Rafal,

    This can be really annoying (sometimes dangerous) when you have hundreds of combinations including moving load cases.

   You take your time (It can be a lot after an erratic renumbering) to create a group for some of those combinations , only to discover  that that group is no longer useful after you´ve added some other load cases or combinations,

because the combinations numbering has  totally  changed after the creation of the new cases/combinations.

   I hope something can be done to simply fix( no changes) the load/combination numbering after it is 1stly done by the user or by Robot itself (+/- envelopes load cases).

thx

[tim.wilson]

I've just spent the better part of the day dealing with this exact same load case auto generating and renumbering issue.

If I change the job preferences to have 0 allowable generated load cases it will still generate two extra load cases for the + / - and that's fine.

Unfortunately any combination load cases that include the primary moving load case will then have no results viewable. It seems I must let the system generate a + / - case for each combination case that includes the moving load.

Again that would be ok accept I do not want the system to re-number the load cases. The client for this particular project has a very specific primary and combination case numbering system to be used for all reports, modelling etc.

i.e. I am solving for primary cases #1 through to #21 and my combination cases are 41 to 45, 50 to 54, 60 to 63 & 101 to 102.

#12 is a moving load case for a crane rail.

When I run the solver everything is renumbered and case #41 becomes #24 (with 25 & 26 being the +/- variants), #42 becomes #27 (with 28 & 29 being the +/- variants) and etc. down through the LC's.

Other load cases that do not include the moving load in the combination are not renumbered and are then left in the middle of the pattern once the numbers catch up.

The whole numbering system is thrown out of whack. Is there no way I can have the additional case numbers start at 1001 or something and keep my created combination cases the clients defined numbers as they were?