Strasbourg Plobsheim Model Club

Salut Armand,

J'avais effectivement vu que le parcours trochoïdal faisait partie des options de ton logiciel. Lorsque je me suis lancé dans mon projet, j'ai passé en revue les différents logiciels disponibles et comparé leurs possibilités, et Estlcam en faisait partie. J'attends que ma machine soit opérationnelle pour faire quelques tests. Mais c'est une autre étape, j'ai encore du boulot de construction et de câblage.

Bug en cours de découpe

Je viens de rencontrer pour la seconde fois ce que je considère comme un bug en cours de découpe.
Dans les deux cas il s'agissait de découpe de dural 3 mm avec plusieurs passes pour atteindre la profondeur.

En cours de fraisage le programme s'est subitement arrêté, la fraise est devenue immobile et le moteur continuait à tourner.
Le programme sur l'ordinateur ne réagissait plus, il n'était même plus possible de le fermer avec un clic de souris sur la x en haut à droite.
Pour l'interrompre il a fallu passer par CTRL-ALT-SUP pour l'arrêter avec le gestionnaire de tâches

la photo ci-dessous montre trois essais avec blocage, (en cours de découpe du trou central), avant de parvenir à une découpe complète. Les arrêts étaient aléatoires et pas au même endroit du programme
Ci-dessous deux captures d'écran suite à deux des interruptions. On ne se situe pas au même endroit dans le G-code
Je n'ai pas trouvé d'explication pour le moment. Pb de génération du G-Code par Estlcam, compatibilité de Estlcam avec mon mon ordinateur (sous Windows 10), bug de mon ordinateur ???

je pense qu'on peut exclure un mauvais fichier dxf car après plusieurs essais tout fonctionne normalement.

La première fois que ça m'était arrivé avec un autre fichier le bug se produisait dès le percement du premier trou qui nécessitait 6 passes. mais le fichier était complexe avec des traits de construction masqués. Lorsque je l'ai simplifié tout est revenu dans l'ordre.

ici je suis parti d'un fichier très dénudé (uniquement les traits nécessaires) et les plantages ont tous eu lieu dans la phase découpe du trou central (un hasard je suppose)

J'ai trouvé quelques alertes dans ce sens sur le forum en anglais du logiciel mais je n'ai pas vraiment trouvé la cause.

Faut-il incriminer Estlcam ???
On peut aussi penser aux drivers des moteurs pas à pas ou à la carte Arduino ?
J'ai tendance à exclure les drivers car dans les deux cas évoqués, pour le premier c'était en cours de déplacement sur l'axe Z et pour le second lors d'un déplacement X. Il aurait donc fallu une coïncidence de deux drivers défaillants, ce qui est peu probable je pense.

L'impossibilité de fermer le logiciel autrement que par le gestionnaire de tâches me fait privilégier le bug logiciel.

Si ça devait inspirer quelqu'un je suis preneur des idées ...

Une anecdote :
lorsque j'avais enfin réussi à faire une pièce complète, la seconde (en cours sur la photo) a eu droit à un nouveau plantage
J'ai alors tenté de ne pas la perdre.
J'ai fait une capture d'écran pour mémoriser la position de la fraise et la ligne de G-code.
Je suis sorti du programme comme évoqué plus haut par le gestionnaire de tâches
Je n'ai pas bougé la fraise
J'ai relancé une nouvelle découpe à partir du fichier dxf
Au démarrage du programme, avant de cliquer sur le bouton de démarrage, j'ai entré manuellement la dernière position de la fraise et je me suis positionné sur la ligne du g-Code où cela s'était arrêté.
ça a bien redémarré PRESQUE au même endroit, mais avec un petit décalage linéaire vers les x positifs.
EXPLICATION
Une ligne g-code ne donne pas une position exacte de la fraise; mais un ordre de mouvement qui est le même pour décrire une ligne du début jusqu'à la fin de cette ligne; donc le positionnement sur la ligne s'est fait de façon aléatoire, du moins je le pense.
ça n'a pas eu de conséquence pour la pièce en question qui était utilisable (pas une pièce d'avion )

Pour Jipé : sur les capture d 'écran, en bas à gauche, le bouton avec la flèche rouge qui permet le démarrage de la broche lorsque celle-ci est pilotée par le g-code. Je ne l'utilise pas comme évoqué par ailleurs. La vitesse 15000 est celle que j'ai fixée dans les paramètres et qui correspond à la réalité, du moins si on fait confiance au tachymètre fourni avec la broche.

Ne serait ce pas ton économiseur d'écran ? une interruption due à Windows pour une tache quelconque ? est il connecté a internet?

Salut Armand,

Une ligne g-code ne donne pas une position exacte de la fraise; mais un ordre de mouvement qui est le même pour décrire une ligne du début jusqu'à la fin de cette ligne; donc le positionnement sur la ligne s'est fait de façon aléatoire, du moins je le pense.

Exact, il faut prendre les coordonnées du dernier point atteint (ligne précédent le mouvement que l'on souhaite initier)


Je remarque que le plantage se produit en passant d'une interpolation circulaire vers une interpolation linéaire (G03 --> G01) dans le premier cas et de G02 --> G01 dans le second cas.

Première hypothèse : le raccordement droite/courbe sur le .dxf est-elle correcte (décalage, mini rupture de continuité au point de jonction).

Seconde hypothèse : Les G02 et G03 utilisent les paramètres I et J qui nécessitent de savants calculs avec beaucoup de décimales à l'arrivée et un résultat arrondi à la précision définie dans GRBL ; dans le cas d'arcs de petites dimensions comme c'est le cas ici, l'arrondi pourrait éventuellement provoquer le plantage. Ceci étant dit, je n'ai qu'une vague idée du calcul matriciel qui est mis en oeuvre dans ton logiciel et de la façon dont sont gérés les résultats des calculs.

Troisième hypothèse : perte de communication entre le PC et l'Arduino/shield ; l'Arduino anticipe les opérations en lisant 4 à 5 blocs de code avant de les transmettre, sous forme d'ordres, aux moteurs pas à pas. Cette anticipation permet, entre autre, de vérifier que les trajectoires à venir ne sortent pas des limites logicielles défines (Hard limits ou Soft limits). Il faudrait que Windows soit occupé ailleurs pour que l'interruption soit suffisamment longue pour interrompre le fonctionnement. Mais avec Windows tout est possible, il y a en permanence une vingtaine, parfois plus, de tâches qui tournent sournoisement derrière l'application en cours. Certaines sont nécessaires au bon fonctionnement de Windows, d'autres sont plus discutables quand elles se connectent, à notre insu, pour aller vérifier la présence de mise à jour, ou balancer des informations de navigation pour alimenter les Google et Cie.
L'idéal pour piloter la CNC serait un PC dédié sur lequel serait uniquement installé les logiciels nécessaires au fonctionnement et vidé de toutes les tâches inutiles.

Autre possibilité : un échauffement anormal du Shield ou de l'Arduino qui provoquerait une mise en sécurité.

Question subsidiaire : est ce que le problème apparaît en simulation d'usinage ? Si le programme n'est pas trop volumineux, poste le, je le passerai en simulation avec mon logiciel.

JP

Merci Jacky, Jipé et aussi Alfred (qui m'a appelé pour ce problème).

Plusieurs pistes sont évoquées et je vais chercher à les réduire progressivement par élimination.

Tout d'abord un conflit logiciel sur le PC (mise en veille, mise à jour en tâche de fond par internet, trop de logiciels, ...
Je vais donc couper la liaison WiFi lors des prochaines découpes et fermer tout ce que je peux. Sur ce dernier point je n'avais en principe ouvert que Estlcam, mais je vérifierai ce qui se trame en tâche de fond avec Windows. Il ne s'est jamais mis en veille, mais je vérifierai aussi ce paramètre.
Sur ce PC portable déjà dédié je ne fais en principe pas grand chose d'autre que CNC et découpe Vinyl. Parfois aussi je surfe un peu sur internet.

Échauffement anormal.
Mes drivers de moteur sont ventilés et restent très froids au toucher, de même mes 3 moteurs pas à pas chauffent à peine depuis que yoyo m'a appris à régler les tensions limites sur les drivers. (Ce serait un comble si l'échauffement était en cause, les pièces usinées étant destinées à remplacer une charnière plastique cassée de porte intérieure de congélateur )
Mais compte tenu de l'effort peut-être supplémentaire provoqué par l'usinage du Dural les moteurs pourraient cependant peiner, je vais faire le test à vide (sans fraise) que m'a suggéré Alfred. Si plusieurs cycles faits de cette manière se passent normalement ça pourrait être une piste.

Quant au fichier source dxf, il a en principe été dessiné dans les règles de l'art avec des fonctions d'ajustement automatique de lignes et de courbes, qui ne laissent en principe aucune discontinuité.
Toutefois en fin de dessin je ne me suis plus donné la peine de recréer des polylignes pour chaque parcours de fraise car Estlcam, contrairement à Easel auparavant, sait très bien reconnaître un parcours en suivant des éléments individuels contigus du dessin. De plus les interruptions ont eu lieu à des endroits différents.
Mais Jipé je vais cependant t'envoyer mon fichier dxf, ainsi qu'un fichier g-code qu'il va falloir que je recrée car je ne conserve que des sauvegardes de la configuration Estlcam avant transformation en g-code, ce denier n'étant plus modifiable m'est moins utile que le fichier propriétaire estlcam qui est un intermédiaire entre le dxf et le g-code et sur lequel on peut à tout moment modifier des paramètres (vitesse, profondeur, diamètre fraise, ...)

merci encore pour vos retours rapides

Une ligne g-code ne donne pas une position exacte de la fraise; mais un ordre de mouvement qui est le même pour décrire une ligne du début jusqu'à la fin de cette ligne; donc le positionnement sur la ligne s'est fait de façon aléatoire, du moins je le pense.

Exact, il faut prendre les coordonnées du dernier point atteint (ligne précédent le mouvement que l'on souhaite initier)
[/quote]

Jipé, encore une question sur ce point important qui pourrait à terme permettre de contrer avec un moindre mal le genre de problème évoqué.

Si je me positionne sur la ligne précédente au démarrage je me retrouve peut-être dans une courbe, mais toujours pas au point précis où la fraise s'est arrêtée. Comment faire si une solution précise existe ?

Armand a écrit : ↑13 mars 2021, 13:18

Une ligne g-code ne donne pas une position exacte de la fraise; mais un ordre de mouvement qui est le même pour décrire une ligne du début jusqu'à la fin de cette ligne; donc le positionnement sur la ligne s'est fait de façon aléatoire, du moins je le pense.

Exact, il faut prendre les coordonnées du dernier point atteint (ligne précédent le mouvement que l'on souhaite initier)

Jipé, encore une question sur ce point important qui pourrait à terme permettre de contrer avec un moindre mal le genre de problème évoqué.

Si je me positionne sur la ligne précédente au démarrage je me retrouve peut-être dans une courbe, mais toujours pas au point précis où la fraise s'est arrêtée. Comment faire si une solution précise existe ?
[/quote]
Effectivement, l'usinage a pu être interrompu avant que le bloc n'ait été complètement traité. Pour éliminer cette éventualité, un retour 2 ou 3 blocs en arrière (sur une interpolation linéaire si possible) serait préférable ; dans ce cas la fraise reviendrait tangenter sur la surface déjà usinée avant de reprendre le cours du trajet programmé.

merci Jipé,
je note, ça semble simple, encore faut-il y penser.
Reste une petite incertitude cependant : au démarrage d'un nouveau programme à un endroit donné (le précédent ayant annulé) il n'y aura plus de repère point zéro, donc la fraise risque de repartir de sa position arrêtée qui correspond au point du bug, donc avec cependant un décalage de quelques lignes g-code

J'espère ne pas avoir à le tester à nouveau, mais je garde l'idée en mémoire.

Jipé, voici à toutes fins utiles mon fichier en 3 phases successives (ces formats de fichiers ne sont pas acceptés par le forum, mais sous forme zippée ça passe, bon à savoir) :

- dessin brut en dxf
- fichier propriétaire Estlcam
- fichier programme CNC (g-code). Ce dernier a cependant été généré sur mon ordinateur de bureau depuis le fichier précédent et non sur le portable utilisé avec la CNC. Si ça pouvait avoir une conséquence je peux toujours en recréer un depuis le portable.
Je n'ai pas encore eu le temps de faire les tests à vide, sans fraise. Mon maître d'ouvrage m'ayant confié d'autres missions

Encore une idée qui me vient à l'esprit : tu évoquais la précision dans ta réponse. Tous les plantage ont eu lieu dans la partie la plus étroite de la découpe intérieure de la pièce. Celle-ci fait volontairement 3.2 mm de large pour la fraise de 3.17 mm (3 mm auraient suffi pour la pièce. Peut-être un problème d'interprétation pour ce décalage de 3/100° entre l'aller et le retour ?

Je pourrais bien entendu envoyer un mail à Christian KNÜLL, le concepteur de ce logiciel, mais sur un forum anglophone une question du même genre lui avait été posée et est restée sans réponse selon celui qui a publié le sujet. De même, avant d'acheter la licence je l'avais questionné sur la compatibilité avec la CNC 3018 et les paramètres de configuration éventuels; il m'a répondu que je pouvais tester gratuitement, ce qu'on sait, mais surtout que selon les vendeurs les cartes de CNC 3018 ne sont pas les mêmes. Je comprends un peu, difficile de répondre de manière personnalisée à tout le monde lorsque selon ce qu'il me semble il s'agit d'un logiciel artisanal fait par une seule personne. Cela aussi pourrait être un critère de réflexion avant un choix qui se pose pour toi en ce moment. Mais je ne m'en plains pas par ailleurs et tous les Allemands rencontrés lors d'une bourse outre Rhin n'en parlent qu'en bien.

Je viens de faire passer, pour la même pièce, 3 fois le programme à vide (sans fraise et moteur de broche à l'arrêt, ce dernier étant indépendant de la carte Arduino, n'a logiquement aucune incidence sur un arrêt du déplacement)
Pour le moment sans déconnecter le PC d'internet ni en cherchant à faire le ménage dans les applications

Aucun problème rencontré après 3 fois 17 mn de fonctionnement.
J'ai donc refait une découpe dans le dural avec la même configuration.
Ma pièce a été découpée sans problème

J'en suis presque déçu car je reste sur ma faim quant à la cause du problème évoqué plus haut

S'il s'agit effectivement d'un problème d'effort retransmis par la fraise au moteur pas à pas, ce qui n'est pas encore totalement à exclure pour autant, comment un moteur à la peine peut-il se plaindre auprès de la carte Arduino ? Peut-être par une augmentation de l'intensité du courant ? Et pourquoi le programme se bloque alors sur l'ordinateur à tel point qu'on ne puisse même plus le fermer ?

Je suis davantage orienté vers un bug informatique provenant d'un conflit logiciel, ce qui peut effectivement être aléatoire en fonction de l'activité du moment du logiciel incriminé. Mais là aussi une interrogation : pourquoi cela n'est-il jamais arrivé avec les très nombreuses découpes de balsa que j'ai déjà faites avec cette machine ?

Je vais surveiller cela à l'avenir, peut-être que je tomberai sur un indice pour résoudre l'énigme ?

Ahh les plaisirs de la CNC, si tout était parfait du premier coup on n'aurait plus de quoi s'occuper