Module complétaire

[oussou-kicho_e2404243]

Bonjour à tous.

J'ai développé un module complémentaire pour exporter automatiquement mes descente de charges de Robot mais après exportation, je remarque que mon modèle devient lent. Est ce un comportement normal ?

[Stephane.kapetanovic]

Bonjour,

Oui, cela peut arriver après un export via un module complémentaire, mais ce n’est généralement pas normal si la lenteur persiste.

Les causes les plus fréquentes avec Robot sont :

• références RobotOM non libérées (objets COM conservés en mémoire),
• création d’un grand nombre de cas ou charges lors de l’export,
• rafraîchissement graphique actif pendant les modifications du modèle,
• appels Robot effectués hors thread STA.

Pouvez-vous préciser :

• le nombre d’objets créés lors de l’export (charges / cas),
• si la lenteur apparaît immédiatement après l’export,
• si elle disparaît après redémarrage de Robot ou de l'ordinateur ?

Cordialement.

[Stephane.kapetanovic]

Quelques sujets à propos de l'export de réactions existent sur le forum anglais :

Only reaction for new model (API), Elevated water tank foundation calculation under sismique loads, Export / import reactions table to Excel, Only reaction for new model (API)

[oussou-kicho_e2404243]

Merci pour votre commentaire.

Le problème survient parce que je fais une capture d'écran de la structure depuis mon code. La solution que j'ai trouvée, c'est de générer une vue, différente de la vue principale et de faire une capture de cette vue là. Une fois la capture faite, je supprime la vue créée et je continue mon travail sur la vue principale qui n'est pas lente. 

[Stephane.kapetanovic]

Oui, je vous rejoins sur l'idée de créer une vue indépendante de la vue principale pour la flasher avec tous les paramètres possibles (attributs, rotations, zoom, textes, etc.). 

Pour les captures, plusieurs choix s'offrent à vous, enregistrement sur disque, classement vers la composition d'impression, manipulation à partir du presse papier pour insertion vers votre suite bureautique. 

La première option est la moins pénalisante.

En matière de vues, comme chacune peut représenter de 300ko à plusieurs Mo, il ne faut pas en laisser une seule derrière vous. 

Travaillez en png et affinez la résolution de la capture pour présenter des vues de qualité à l'endroit où le lecteur les attendent le plus.

Sur un poste de développeur, il faut régulièrement inspecter le presse papier, vider la corbeille, effectuer les redémarrages si nécessaire.

Là où il faut se montrer très prudent c'est à destination des tableurs et éditeurs de texte qui peuvent eux même transformer les images à l'insertion.

C'est vrai pour les images mais aussi pour les tableaux de données ou de résultats.

N'oubliez pas qu'un processus abortė peut représenter jusqu'à un giga si celui-ci n'est pas terminé durant un processus asynchrone.

Il y a plusieurs publications du forum anglais qui pourront vous aider à trouver la meilleure solution pour vos applications.

Cdt

Voir aussi : https://forums.autodesk.com/t5/robot-structural-analysis-forum/api-command-vba-projection-capture-of...

[oussou-kicho_e2404243]

Merci pour votre retour

Effectivement, j'ai opté pour l'enregistrement de la capture sur mon disque avant de l'insérer dans mon fichier Word. 

J'ai également vu votre programme en VBA sur le forum Anglais. Il est claire.

Merci.

Je vous note quand même que j'ai codé tout mon module en python (je maîtrise pas le VBA correctement ni le C#). J'ai utilisé une bibliothèque de Python qui m'a permise d'accéder à l'API de RSA.

[Stephane.kapetanovic]

Parfait

En effet, Python ne faisait pas partie des langages couverts par les documentations officielles, historiquement dédiées à C#, VB et C++. Mais avec le temps, les utilisateurs ont fini par aborder la plupart des sujets et publier des bibliothèques.

Reste que Python, bien que simple sur le papier, se révèle plus délicat à installer et à manipuler dès qu'on touche aux objets COM. Beaucoup d'exemples du forum ne sont pas directement transposables pour un programme occasionnel en Python, car la dette technique liée à l'absence d'équivalents de bibliothèques est rarement évoquée et les solutions, de fait, rarement exposées publiquement. Pour déboguer à distance avec un internaute, le forum n'est pas l'endroit idéal, encore moins pour intervenir sur son matériel, surtout quand le temps presse.

D'autres forums plus spécialisés existent. C'est aux développeurs de venir chercher ici des traductions de leurs besoins dans les FAQ et obtenir de l'aide sur l'API.

Pour être honnête, dans des langages comme C# ou VB, tout est cadré : interfaces clairement définies, modèles, structure de classes solides. Avec Python, on ajoute une couche de "débrouille" à ce qui est déjà technique : pas de typage fort, pas d'interfaces formelles. Réutiliser du code ou structurer proprement son projet demande donc plus de rigueur personnelle.

J'entends toutefois votre demande de voir votre langage plus utilisé à l'avenir, garantissant des passerelles d'interopérabilité entre logiciels menées de bout en bout avec Python.

Cdt

[Stephane.kapetanovic · Accepted solution]

bonjour @oussou-kicho_e2404243 

Je comprends que votre module a été rédigé en Python et que celui-ci n'a pas été présenté lors de notre discussion.

Vous cherchiez des informations et des conseils sur le forum pour les croiser avec vos connaissances actuelles afin d'objectiver la lenteur que vous aviez constatée suite à de multiples opérations effectuées graphiquement. Les réflexes consistant à créer une vue dédiée, fermer les instances, travailler sur fichier plutôt qu'avec des copies mémoire des captures réalisées ont permis de réduire l'impact du flashage.

Sans en savoir plus sur le fonctionnement de votre outil, il m'est difficile d'aller droit au but. En espérant que notre discussion ait pu vous apporter de l'aide, et dans l'intérêt de la communauté, n'hésitez pas à approuver les solutions et laisser un like.

Cdt.