Un petit message d'erreur "softlimit exceed on y"

Salut David,

J'avais installé le logiciel de FAO sur ma station de travail fixe, et aussi sur mon ordinateur portable.

Je me souviens avoir changé les caractéristiques de l'outil sur le portable, commencé à travailler sur le projet sur le portable pour ensuite rouvrir le même fichier sur le fixe qui embarquait d'autres caractéristiques du même outil.

Peut-être que le problème vient de là ? Bizarre effectivement mais bon !

A bientôt,

Alain

Peut-être que le problème vient de là ?

Oui, c'est bien possible ... mais c'est quand même étrange que ça ne bug pas sur les arcs du 1ier fichier, et que sur le 2ieme ça ne bug que sur un arc du 1ier niveau d'usinage et pas sur les autres ; si c'était juste une incohérence de Ø d'outil, ça le ferais partout .... il y a un "gremlins" quelque part dans le soft ... ça arrive que des bugs arrivent à se cacher pendant des années et ne surviennent que dans des conditions très particulières ...

++
David

C'est vrai... D'autant plus que cela ne survient que quand j'usine des formes droites... Pour les courbes le problème n'apparaît pas.

A bientôt

Alain

C'est exactement la même version du soft sur tes 2 PC ? ... avec Cambam il m'est arrivé que certains paramètres ne passent pas correctement d'une version à l'autre.

++
David

Oui David, exactement la même hormis les bibliothèques d'outil que j'ai changé entre les deux stations. A l'époque du début je n'y connaissait rien et ai fait un peu n'importe quoi.

Aujourd'hui, je n'y connais pas grand chose (c'est tout de même un progrès depuis rien du tout).

Mais je vais tout de même écrire un message à Vectric pour leur signaler la chose, peut être m'expliqueront ils... Et si oui, je te dirai leur réponse.

Alain

Salut à tous,

Juste pour l'histoire, j'ai pu reproduire l'erreur mais cette fois volontairement.

Dans la bibliothèque d'outil, on peut paramétrer différentes valeurs d'outil dont la profondeur de passe.

Ces renseignements sont intégrés automatiquement lors de la création d'un parcours d'outil dans le logiciel de FAO qui va déterminer le nombre de passes nécessaire. Jusque là pas de problème et tout se passe bien sans erreur.

Lorsqu'on cherche à modifier ensuite la profondeur de passe en éditant l'outil dans la bibliothèque, la mise à jour du parcours créé initialement ne se fait pas correctement. Le parcours n'intègre pas forcément automatiquement la mise à jour de l'outil après validation.

D'où très certainement le Gremlins dont parlai David dans la génération du Gcode.

Bonne journée à tous,

Alain

Salut,

Et un bug de trouvé .. tu vas pouvoir faire un rapport de bug au développeur ; en tant que développeur, savoir qu'il y a un bug c'est bien, mais être en mesure de le reproduire c'est encore mieux pour avoir une chance de le trouver !

Il ne se produit que quand tu fais des usinages en plusieurs parties ?

++
David

Oui tout à fait David que sur une opération de tuilage.

Et encore une autre trouvaille sur ce problème. Exit la recréation d'outil dans la bibliothèque d'outils ce n'est pas la peine en fait.

Le problème est plus profond que cela. C'est en fait la combinaison du calcul de "nesting" (organisation automatique des pièces pour économiser le brut) et du calcul ensuite de tuilage qui provoque ce truc bizarre.

Et c'est facilement réparable. Lorsque tout est terminé question calculs, il suffit de sélectionner toutes les pièces, de les décaler dans n'importe quel sens même de 0.01 mm puis de recalculer.

Et plus du tout de gremlins dans le Gcode.

Bizarre bizarre

A +

Alain

il suffit de sélectionner toutes les pièces, de les décaler dans n'importe quel sens même de 0.01 mm puis de recalculer.

Tiens, ça me rappel quelque chose ! ; plusieurs bug sur CamBam se résolvaient de cette manière ... souvent c'est lié à des problèmes d'arrondi dans les calculs de trajectoire: pour un humain, 10.20 et 10.1999999999999999 c'est la même chose, mais pas pour un ordi et ça peut parfois produire des résultats curieux ! (ou des messages d'erreur de Mach3)

++
David

Oui sans doute. J'ai remarqué également que ce bug m'envoyai l'origine y0 à y-0.001 ou approchant, ce qui peut expliquer aussi l'erreur.

A+

Alain

Bonjour Dh42 et bonjour à tous,

Je sais, le sujet est vieux mais j'avais oublié de poster un truc qui me semble intéressant pour les autres.

quelque chose qui servira peut être un jour à quelqu'un sur le sujet de soft limit exceed.

Depuis, les problèmes ont disparus, sauf une fois et là j'ai tenté quelque chose.

J'ai simplement déplacé tous mes tracés de 0.1 mm vers le haut sur le logiciel et relancé la création du gcode.

Disparition du problème. Donc Dh42 c'est tout à fait ce que tu disais un problème logiciel sans doute.

Moralité, si un lecteur est confronté à ce problème déplacer l'ensemble du dessin de très très peu (ca suffira), régénérer le gcode et cela devrait passer.

Alain