freeze GEN7

j'ai entendu (lu) que quelques uns avaient des problèmes de freeze de carte GEN7 . L'impression s’arrête au bout d'un "certain" temps, nécessitant un reboot de la carte et de l'host..... impression foutue.

j'avais récemment sur une carte GEN7 avec firmware Teacup ce même souci de freeze assez répétables, que je viens de résoudre en passant à 19200 bauds et surtout en cochant la case "use ping-pong communication (send only after ok)" de l'host repetier ( menu printer settings)
depuis plus aucun problème. d'ou ce post si cela peut servir à d'autres.

par contre vous dire pourquoi ça ne marchais pas sans cela ?
peut être un problème de gestion du xonxoff sous seven avec le driver ftdi, ou un problème d'émulation des lignes CTS RTS via l'USB, ou autre chose ?!!!

la case pingpong fait finalement du xonxoff "programmé".... avec un buffer très réduit.

j'avais essayé avant, différentes valeur de débit de communication (de 9600 bauds à 115200) mais ça ne faisait que retarder ou accélérer le moment ou cela bloquait..

reste à voir si ce séquencement a réellement un impact sur les trajectoires.
si vous avez qqs infos a ce sujet ?
Pierre-Marie

Edited 1 time(s). Last edit at 05/15/2012 08:16AM by paoparts.

---

-----------------------------------------------------------------------------------------------------------
blog Paoparts

Ben, on a ce problème avec la reprap du log, Teacup sur une Gen7. Pas encore réussi à régler le problème.

Ce qu'on a essayé :

Changer de PC.
Changer d'alimentation.
Changer le câble USB.
Changer la vitesse de communication (il me semble qu'on a essayé 19200, sans résultat).
Changer le logiciel de contrôle (printrun, repsnapper et replicatorg - pas essayé repetier car sous linux il parait qu'il ne marche pas très bien, des problèmes de communication entre autres...).

Prochaines étapes :
Essayer Marlin, il parait qu'il compile bien sur la Gen7.
Essayer un autre FTDI, ou au moins de faire un câble dédié pour le désolidariser de la Gen7.

Ça m’embêterait quand même de devoir changer d’électronique après le temps que j'ai passé à souder celle là...

---

Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.

J'ai eu aussi ce problème avec le Firmware Teacup. Que ce soit sous OsX, Windows ou linux, le problème étais le même.
Je ne pense pas que le FTDI soit en cause, car il fonctionne très bien pour d'autres projets. De plus avec un système sans fil X-Bee le soucis persistait !
Je n'ai pas trop fait de tests complémentaires vu que je suis passé sous Repetier.

@deuxvis: repetierhost sous GNU-linux (ubuntu11.10 et 12.04) pour moi fonctionne très bien, pas d'interruptions de quelque ordre que ce soit, le seul inconvénient est pour moi de devoir installer mono.
Bon, je sais le "chez moi ça marche" n'est pas très constructif mais je devais le dire.

Ok merci du rapport pomalin. Quel firmware et électronique tu utilises et à quelle vitesse tu communiques avec la machine ?

Je vais peut-être essayer quand même, si ça se trouve avec les trucs de paoparts ça marcherait.

---

Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.

je suis avec repetier sur gen7 de paoparts et je communique en 115200.

pomalin,
c'est quoi ta config dans Printer Settings?
tu as coché ping pong ?
moi j'ai :
COM2
baudrate:19200
stopbits: 1
Parity: None
Transfert protocol: ASCII ( je sais plus si j'ai testé protocole Repetier)
receive cache size: 100
et coché use Ping-Pong communication

repetierhost 0.50
GEN7 1.3.1 - TEACUP firmware
SEVEN + Cable USB-FTDI

Edited 3 time(s). Last edit at 05/17/2012 04:53PM by paoparts.

---

-----------------------------------------------------------------------------------------------------------
blog Paoparts

Bon, là je réponds de chez moi, donc de mémoire, mais je regarderais si je me suis trompé tout à l'heure quand je serais à l'école.

Je n'ai pas coché ping pong, le port c'est /dev/tty/ACM0, baudrate 115200,stopbits 1, parity None, transfert autodetect, cache 120.


repetierhost 0.50
repetier firmware 0.62b
GNU/linux ubuntu 12.04

c'est bien ça sauf pour le port /dev/ttyUSB0

@UtilisateurDeRepetierHost:
Juste pour info,

Attention à Repetier-host sous linux
Cela peut engendrer des mini-freeze ou des sauts d'instructions qui generent des décalages dès que vous imprimez un peu trop rapidement.

C'est due a la librairie mono, a voir avec une nouvelle version la mienne date un peu, par contre Repetier host sous windows, c'est genial j'ai pas eu de probleme.
A bon entendeurs salut.

@ghunt : c'est justement le propos de mon post, pour moi sous GNU/linux, avec repetierhost0.50+repetier firmware 0.62b, et impression à 60 pour les perimetres, 60 pour les petits perimetres, 100 pour le infill, 100 pour solid infill, 120 pour les bridges, je n'ai pas de soucis de mini-freezes, pas de sauts d'instructions, alors peut-être que j'ai de la chance, ou peut-être que ça vient du host, même si je n'avais pas de problèmes non plus avec repetierhost0.40, je dois juste être chanceux.

pour infos,
les freezes identifiés chez moi, étaient rédhibitoires -->>> obligation de rebooter l'ensemble.
c'est l'association GEN7 + Teacup à priori.
Je confirme le host Repetier sous windows c'est Top...
de plus il gère en manu le fan supplémentaire. Je viens de finir de souder le sevenswitch de markkus.
il est monté sur mon support, faut juste que je comprenne comment l'activer avec le firmware Teacup et le slicer slic3r.

en avant première je vous montre mon dernier design pour embarquer sous la prusa, l'alim, la carte GEN7, les fils.....

---

-----------------------------------------------------------------------------------------------------------
blog Paoparts

Bonjour à tous,
Je viens de voir le dernier design de Paoparts pour ranger tous les "à-côtés" : c'est vraiment très astucieux . Je pense que je vais m'en inspirer . Belle idée Paoparts !
Cordialement,

Thierry

---

Prusa V2 + Ramps 1.4 (Marlin Firmware) avec autolevelling bed, écran LCD et alimentation à 24V + Raspberry Pi Model B (pour impression autonome) / Pronterface + Slic3r sous Ubuntu 14.04 / Niveau : Pratiquant / Localisation : Lézignan-Corbières (Aude, France)

Merci Thierry,

je met les fichiers STL demain sur le blog.
après avoir usiné tout cela et testé en réel ....

---

-----------------------------------------------------------------------------------------------------------
blog Paoparts

Bonjour,

j'ai eu moi aussi un problème d'arrêt d'impression, systématique et toujours au même endroit du Gcode, avec Teacup et Gen7, qui n'était pas dû à un défaut de communication entre ordinateur et reprap mais à un bug dans Teacup (dépassement d'un entier), non encore réglé aujourd'hui (commit 85e29e8c91, GitHub Gen7 branch ).

Ce problème fait l'objet d'un thread, et est réglé par l'application d'un patch de andrey2345 sur les fichiers dda.c et dda.h du firmware. Je mets en pièces jointes ces 2 fichiers patchés, ainsi que le patch pour ceux qui veulent l'appliquer eux-mêmes.

Impressions parfaites depuis !… (et une journée entière de recherches pour trouver cette solution…!). Je précise que mes axes X Y et E sont en 16e de pas, sauf le Z qui est en 8e : beaucoup de calculs et risque plus grand que ce bug se produise.

Bien sûr, le logiciel envoyant le Gcode à la RepRap n'est pas concerné.

Edited 1 time(s). Last edit at 06/15/2012 05:29AM by François Delègue.

---

François

Super , merci francois pour cette information.
j'avais zappé ce thread , pourtant je suis attentif ...
je vais pouvoir augmenter la vitesse de transmission et passer en mode stratosphérique ...

---

-----------------------------------------------------------------------------------------------------------
blog Paoparts

paoparts Wrote:
-------------------------------------------------------

> j'avais zappé ce thread , pourtant je suis attentif ...

L'actualité est tellement dense qu'il est impossible de tout suivre, bdnnd (soyons polis) !…

> je vais pouvoir augmenter la vitesse de
> transmission et passer en mode stratosphérique ...

Peux-tu me dire si finalement ta question à l'origine de ce thread était un pb de com ordinateur/reprap ou bien de bug du firmware ? mmmhhh les 2 ? si bug, se produit-il peu souvent pour toi car vitesse plutôt lente d'impression ou microstepping pas trop élevé ?

Pour ma part, il se produisait quasi systématiquement sur mes 1res pièces de test, avec gros microstepping X, Y et E et impression plutôt lente (10 mm/s). Si peu de gens ont ce bug peut-être est-ce à cause d'un micostepping plus bas…

Sinon, il y a un autre bug du firmware entraînant un défaut de géométrie bizarre, qu'on peut contourner, voir ce thread…

---

François

j'ai voulu reproduire les pbs de communications avec une de mes cartes GEN7
1/16 de pas, sauf sur Z 1/8 de pas - windows 7 - repetier host V5.0 - slicrinterne 0.7.2b
firmware Teacup - dernière version

je suis repassé en 115200 bauds (recompilation du firmware et upload)
puis sclicing de carre de calibration ( fichier stl et gcode ci joint). vitesse de déplacement faible

j'ai décoché dans l'host Use Ping-Pong communication du menu Printer settings.
bilan : au bout de qqs lignes : FREEZE., c'est rassurant c'est reproduisible
message :

11:50:14.431 : N2079 G1 X89.43 Y77.82 E3.26095 *121
11:50:14.445 : ok
11:50:14.446 : N2080 G1 X89.98 Y77.79 E3.29882 *124
11:50:20.020 : ok
11:50:22.433 : rs N2080 Expected checksum 90
11:50:22.433 : ok
11:50:22.435 : N2084 G1 X110.41 Y77.88 E4.7034 *125
11:50:22.449 : ok
11:50:25.485 : ok
11:50:28.538 : ok
11:50:31.590 : ok
11:50:31.591 : N2088 G1 X110.71 Y77.9 E4.72407 *125

y a bien un pb de checksum qui nécessite reboot de la carte et du Host .

Si je recoche "Use Ping-Pong communication" du menu "Printer settings." pas de problème ça refonctionne. ( pas testé à l'instant sur un gros fichier).

Francois, J'ai essayé tes 2 fichiers dda.c et .h, mais ma version du code teacup est surement plus récente, car il y a qqs changement en particulier sur la variable steptimeout qui n'est pas déclarée dans ton code et qui conduit donc a une erreur de compilation sur le fichier clock.c.
Peut être qu'une modif des 2 fichiers par le fichier patch peut résoudre ce problème, mais pour cela il faut que je passe par une distrib linux. je ne sais pas faire en windows !

voila ou j'en suis.
du coup je ne saurais dire, si c'est un pb de transmission ou de dépassement, voire les 2 ?!

---

-----------------------------------------------------------------------------------------------------------
blog Paoparts

aaahhh nous n'avons sûrement pas la même version du firmware, les 2 dda patchés n’entraînent pas d'erreur de compilation chez moi. Différence de version confirmée aussi par E_STARTSTOP_STEPS à 289 dans ton config.h, une telle valeur entraîne un énorme défaut de géométrie des pièces imprimées avec mon firmware (E_STARTSTOP_STEPS est donc à 0 ici-même à Clermont-Ferrand (City)).

ma version est l'actuelle, commit 85e29e8c91, le fichier zip téléchargé étant triffid-Teacup_Firmware-85e29e8.zip.

je peux te patcher les 2 dda si tu veux…

côté plateforme : sous OS X pour la compilation, j'envoie le gcode Skeinforgé en ligne de commande avec l'utilitaire inclus dans la distribution de Skeinforge, sous OS X aussi ou avec une autre machine sous Debian.

---

François

a priori c'est le fichier triffid-Teacup_Firmware-886bacd.zip que j'utilise (pas sur a 100% car je l'ai renommé depuis)
je te joins mes 2 fichiers dda si tu peux me faire cela c'est sympa , et je teste.
j'ai regardé le patch,y a du monde, c'est du travail en profondeur ....

je comprend pas bien le lien entre les problèmes de débordement de variables et le choix d'une conf/vitesse de transmission.
pour l'autre problème, fais moi passer ton stl que je teste voir si j'obtiens le même souci avec ma version installée.

---

-----------------------------------------------------------------------------------------------------------
blog Paoparts

l'application du patch a échoué…

patching file Teacup_Firmware/dda.c
Hunk #8 FAILED at 753.
1 out of 8 hunks FAILED -- saving rejects to file Teacup_Firmware/dda.c.rej

ce qui confirme que ça ne pouvait pas compiler pour toi, nos dda.c étant différents… tu peux essayer la version du FW citée plus haut… qui entraîne ce défaut de géométrie si E_STARTSTOP_STEPS est supérieur à 0… pour tout fichier stl, inutile que je t'en envoie un car ta version du FW ne pose pas ce pb.

> je comprend pas bien le lien entre les problèmes de débordement de variables et le choix d'une conf/vitesse de transmission.

il n'y a pas de lien avec la vitesse de transmission mais avec le microsteppage, s'il est bas le bug du dépassement de capacité d'une variable dans dda.c (un entier pouvant aller jusqu'à 65535) a moins de chances de se produire car moins de calculs de l'atmega…

c'est un pb de com pour toi, plus sûrement qu'un bug du FW…

Le patch a été ajouté à la dernière version de Teacup, branche Gen7 (commit f2383d542d) par Markus Hitter : plus besoin de l'appliquer soi-même !

---

François

Ah ben c'est cool, je vais lui redonner une chance alors à Teacup, une question si tu sais est-ce qu'il gère les arcs ? parce que un rond rond, sans crénelage c'est tellement beau.

pas de gestion des arcs et cercles avec la commande G2 ou G3 pour TEACUP

voir le fichier gcode_process.c

//	G2 - Arc Clockwise
// unimplemented

//	G3 - Arc Counter-clockwise
// unimplemented

après pour utiliser cette commande il faut aussi un slicer qui génère ce type de commande.

Edited 3 time(s). Last edit at 07/07/2012 06:29PM by paoparts.

---

-----------------------------------------------------------------------------------------------------------
blog Paoparts

arf, ok, merci.