Discussion Groups

Robot Structural Analysis

Reply
Distinguished Contributor
PatrickEC
Posts: 206
Registered: ‎04-10-2012

Re: Instability type 3

07-27-2012 03:33 PM in reply to: tony.ridley

Tony,

 

Why do you think that nodes/edges will move after each calculation? Maybe I am missing something, but I would think that all inaccuracies are corrected during the first run and during later calculations there is nothing to correct, so nodes will not move. Could you please elaborate on this behavior?

Please use plain text.
Valued Mentor
tony.ridley
Posts: 653
Registered: ‎09-07-2011

Re: Instability type 3

07-29-2012 06:50 AM in reply to: PatrickEC

Hi Patrick

 

Indeed you are correct in that once the model is "corrected" it will remain in this position and therefore not require further moving.  The problem I have encountered is this (sample case):

 

  1. Set up a model with many panels (say 100).  Vertical and horizontal panels, all kinds of geometry (not necessarily rectangles);
  2. Some geometry may be out by a few points of a mm;
  3. Robot automatically "corrects" these small discrepancies;
  4. I then try to mesh panels.  Maybe a wall here or there does not mesh, due to some panels being "warped" etc;
  5. I then delete out offending non-meshing panel and re-draw it.  Since the adjoining panel was shifted due to "model correction" (step 3), it now is not matching my newly drawn one (step 5).  
  6. The panel already shifted in step 3 now shifts again to match the new panel in step 5.  You can see that at an intersection of 4 or 5 panels this becomes very tiresome when one or two panels will just not mesh no matter what.  Each time I delete and re-draw a panel, 4 other panels shift to accomodate it.  So I say "OK, I'll just run more tolerance", and set tolerance to 10mm.  
  7. I now have many panels "warped" to suit the adjoining one by up to 10mm but still no better off trying ot mesh everything beautifully, and I also have many panels visilbly out of alignment.  
  8. Meshing the intersections of all of these slightly "out" panels takes forever is is not useful for calculation anyway.  

Hope this helps explain better to you the issues I've come across.

 

 My workflow is now thus;

  1. As soon as I open a new model I set tolerance to ZERO;
  2. Build model (either from Revit import or build in Robot);
  3. Run Rafal's magic spreadsheet (search forum) and make sure my geometry is EXACTLY how I want it;
  4. Then mesh and run the model generation.

 This is why I have been pushing Autodesk development (via this forum) to allow Robot to round element dimensions to the same number of decimal points as the overall units setting.  It will avoid having numbers such as 2.000054876 that just show up as 2.000 in the object inspector etc (which is the starting point for 99% of all meshing problems / slow calculation time / general frustration I experienced in Robot).  

 

For the benefit of others who have not experience this I have attached a PDF explaining the situation graphically.  

 

Tony

Please use plain text.
Product Support
Artur.Kosakowski
Posts: 5,115
Registered: ‎12-17-2010

Re: Instability type 3

07-30-2012 01:10 AM in reply to: tony.ridley

Tony,

 

Rounding coordinates seems to be smart solution but unfortunately it is not (good for planes that are parallel to the main coordinate system but fails badly for sloping ones - we have tried this approach :smileyhappy:). What I would recommend is:

1. Freeze the meshes of the panels that you are pleased with before correcting the geometry of the model (meshes of not frozen or not meshed panels will try to adopt to the position of nodes of the existing meshes).

2. Use adjust to plane / structural axes correction rather than increase the model tolerance. This is the powerful tool yet intended to be used in specific cases (when you know what a change is going to be and it is a local adjustment of the model) rather than to be applied blindly to a complex model where you are not able to check what unwanted effect it can possibly have.

 

BTW: After running bar intersections to determine the shortests bars check if they exist due to the inaccuracy in the model or just because of the intended positions of other bars or objects in the model. Very often this (3 cm bar) is just the feature of the model itself rather than the lack of accuracy. Please mind the check Patrick made:

 

As Artur suggested, I did a small test and applied the same section to all members and then the Istability type 3 warning did not show up.



Artur Kosakowski
Please use plain text.
Product Support
Rafal.Gaweda
Posts: 5,604
Registered: ‎04-26-2010

Re: Instability type 3

07-30-2012 02:19 AM in reply to: tony.ridley
Please use plain text.
Distinguished Contributor
PatrickEC
Posts: 206
Registered: ‎04-10-2012

Re: Instability type 3

07-30-2012 07:35 AM in reply to: PatrickEC

I read with great interest your posts guys and now I understand what problem Tony was referring to.

 

But, my question as related to short members and type 3 instability was left unanswered...


Now I am not sure if I understand what "Tolerance of structure model generation" does. Is it not supposed to merge any nodes that are less than 30mm apart?

How is it possible that after model generation I would still have elements shorter than 30mm?

Please use plain text.
Product Support
Artur.Kosakowski
Posts: 5,115
Registered: ‎12-17-2010

Re: Instability type 3

07-30-2012 07:42 AM in reply to: PatrickEC

Now I am not sure if I understand what "Tolerance of structure model generation" does. Is it not supposed to merge any nodes that are less than 30mm apart?


 

True, but not e.g. calculation nodes. Please try to follow these steps:

 

1. Select all model (CTRL+A) and run intersection (Edit > Intersect)

2. Find the shorter bars and determine why their end nodes are in such locations

 

Knowing this I believe you should be able to answer your question :smileyhappy:



Artur Kosakowski
Please use plain text.
Distinguished Contributor
PatrickEC
Posts: 206
Registered: ‎04-10-2012

Re: Instability type 3

07-30-2012 08:55 AM in reply to: Artur.Kosakowski

Ok, I see what happens. The end nodes get snapped together. But if there are elements coming into other elements in between nodes, they are not adujsted, only calculation nodes are created at the intersections.

 

 

Please use plain text.