Question:
L'imprimante se déplace de manière aléatoire vers la maison pendant l'impression, puis reprend normalement
Tom van der Zanden
2016-04-10 15:31:23 UTC
view on stackexchange narkive permalink

Pendant l'impression, mon imprimante effectue parfois des mouvements mystérieux: elle déplacera très lentement l'axe X ou Y complètement vers la gauche / l'avant, avant de revenir très lentement à sa position d'origine et de reprendre l'impression normalement. J'ai vérifié mes fichiers G-code et les mouvements ne font certainement pas partie du G-code. Quelle pourrait en être la cause?

J'imprime à partir d'une carte SD sur une imprimante cartésienne.

Quel firmware (Marlin, ..)? Quelle imprimante (cartésienne, delta, ..)? Extensions (capteur hors filament, ..)? Source des codes G (impression à partir d'une carte SD ou d'une interface série)? On dirait que l'imprimante suspend l'impression. Les causes peuvent être l'absence de codes G (connexion série lente) ou un autre signal (déclenchement du capteur de filament)
La question est étiquetée marlin. J'ai modifié la question pour inclure l'endroit à partir duquel j'imprime. Je n'ai pas de capteur à filament.
J'ai juste eu le même problème. Je pourrais bien imprimer à partir de l'ordinateur mais charger le même fichier sur le disque et obtenir le déplacement aléatoire vers les points 0 sur x et y de manière complètement aléatoire.
Deux réponses:
Tom van der Zanden
2016-04-11 01:50:22 UTC
view on stackexchange narkive permalink

Le problème était dû à une carte SD corrompue, sur laquelle des déchets étaient parfois lus. Il s'avère que Marlin essaiera d'interpréter une commande de déplacement corrompue comme G0 X1q3.54 et lira toujours autant de nombres que possible. Dans cet exemple, il serait interprété comme G0 X1 plutôt que (comme cela aurait pu être prévu) G0 X103.54 .

Ceci explique mes symptômes parfaitement:

  • X et Y se sont toujours déplacés vers (approximativement) leurs positions d'origine, mais ce n'était toujours qu'une seule d'entre elles (il est peu probable que les deux mouvements soient corrompus).

  • Z n'a pas été affecté car les déplacements Z sont beaucoup plus rares dans le code G (uniquement lors d'un changement de couche) et il était donc très peu probable qu'un déplacement Z soit affecté.

  • E n'a pas été affecté car une demande de déplacement de E vers 0 serait empêchée par la prévention de longue extrusion de Marlin.

Eurgh! Je n'aime pas que Marlin fasse ça. Une trouvaille intéressante, cependant. J'adorerais savoir comment vous avez compris cela.
Qu'est-ce qui est corrompu dans `` G0 X1y3.54 ''?
@Wirewrap Mon intention était que le code G "non corrompu" aurait été quelque chose comme "G0 X103.54" et j'ai remplacé le 0 par un caractère aléatoire. Malheureusement, j'ai choisi un personnage aléatoire vraiment déroutant. Merci d'avoir fait remarquer cela.
Trish
2018-08-19 13:41:29 UTC
view on stackexchange narkive permalink

En plus d'une carte SD corrompue qui stocke des bits usés, conduisant à des commandes absurdes, il est également possible que les autres parties de la Creatin du fichier soient compromises:

Cela peut par exemple se produire si la carte est retirée pendant l'écriture - mais dans ce cas, il devrait s'agir principalement d'un fichier incomplet lors de l'importation dans un interpréteur.

Plus une distribution aléatoire de mauvaises commandes apparaîtrait si le processus d'écriture en lui-même est défectueux, par exemple si le SD Le port est défectueux ou l'adaptateur a une erreur. L'écriture peut également échouer si les pilotes de l'adaptateur / port de carte SD sont corrompus.

Détecter un mauvais fichier ou une carte corrompue est possible en réimportant le G-Code dans un slicer (par exemple CURA le permet) et en regardant les chemins des outils. Si un port fait cela avec n'importe quelle carte, le logiciel est à blâmer: voyez s'il persiste après une mise à jour du pilote (rare!) Et une réinstallation du slicer. S'il échoue dans un port mais fonctionne dans un autre, le port ou l'adaptateur peut être en faute et nécessiter un remplacement. Si elle est endémique à une carte, celle-ci est corrompue et à jeter. S'il est endémique à un seul fichier, écrasez-le par un nouveau - parfois l'écriture échoue pour des raisons presque impossibles à comprendre.

Si le fichier&card est correct mais mal lu sur l'imprimante, alors la carte les lecteurs de l’imprimante ou du tableau sont à blâmer.



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...