Wat zijn de meest resource-intensieve beperkingen?

Hallo

Heeft u een idee van de beperkingen die prioriteit moeten krijgen om systeembronnen te besparen?

Is de diabeperking meer "hebzuchtig" in middelen dan bijvoorbeeld twee toevallige beperkingen (vlak/vlak)?

Is er een classificatie naar type beperkingen?

Bij voorbaat dank

 

1 like

Goede vraag de! Als je de test hebt gedaan, ben ik benieuwd naar een relatie :)

Tijdens een training was de enige informatie die ik erover had dat je de onderdelen zoveel mogelijk moest blokkeren om te voorkomen dat SW steeds de vrijheidsgraden opnieuw moest berekenen. Net als bij een concentriciteit van een schroef bijvoorbeeld, moet je "de rotatie vergrendelen". 

Van mijn kant is het meer de opeenstapeling van beperkingen die verband houden met flexibele assemblages die me het systeem vertragen. We hebben verschillende onderdelen in vertalingen, aangedreven door roterende onderdelen (zelf geconfigureerd in een subassemblage). Wanneer ik een limietafstandsbeperking in de subassemblage, een limiethoekbeperking en een groefbeperking in mijn assemblage plaats, heeft deze de neiging om een beetje te worstelen in de buurt van de limietposities. 

2 likes

Ik zou geneigd zijn te zeggen dat hoe meer entiteiten er in de beperking moeten worden geselecteerd, hoe omslachtiger het zal zijn om te berekenen.
Samenvattend zijn standaardspanningen lichter dan geavanceerde spanningen die lichter zijn dan mechanische spanningen

3 likes

De vraag is interessant, maar ik zie niet in hoe ik het "gewicht" van de beperkingen afzonderlijk kan beoordelen.
De functie "Prestatie-evaluatie" vat het aantal beperkingen samen, maar zegt niet meer. 
De functie "Assemblagevisualisatie" beheert alleen onderdelen, ongeacht hun beperkingen.

Anders denk ik a priori net als @stefbeno dat de hiërarchie van beperkingen standaard, geavanceerd en vervolgens mechanisch is.