[ RESOLU ] Problème étrange qui me résiste

[JL3D46]

Bon OK, à ce que je vois, les deux vis sont liées mécaniquement via une courroie synchrone ET électriquement par deux moteurs alimentés par un même stepper.

Donc à priori aucune raison que l'un tourne plus vite que l'autre ou se désynchronise à l’arrêt, c'est l'option "ceinture ET bretelles". En machine outil on ne joue pas à ça, mais vu la "souplesse" des imprimantes 3D si ça peut passer, au moins une chose de sure : les deux vis tournent de la même valeur et à la même vitesse.

Sauf un grand bruit de courroie qui saute, c'est verrouillé à ce niveau. Donc, lorsque la traverse est de travers par rapport à la table, tu fais quoi ? réglage de la traverse ou réglage de la table? parce qu'à force de se décaler toujours du même coté, tu devrais avoir une table (et/ou une traverse) qui penche horriblement.

[Kachidoki]

Il y a 2 heures, Guizboy a dit :

Si je me souviens bien de mes cours. Pour mettre deux moteurs 12V en série, il faut les alimenter en 24V.

Si ils sont en parallèle ils partageront l intensité. Si ils sont en série, ils partageront la tension.

Tout à fait juste, cependant les moteurs ne sont pas alimenté en tension (12V), mais bien en courant.

En prenant une spec de NEMA 17 48mm sur reprap-france par exemple, tu peux voir 1.68A par phase et seulement 2.8V en tension (et non pas 12V). C'est le job du stepper driver de réguler en courant, et de ce fait si tu en mets deux en série, tu te retrouves avec 1.68A par phase et 5.6V. Le driver pourra toujours les alimenter car ça reste bien inférieur à la tension d'entrée (12V) moins le rendement.

[Guizboy]

il y a une heure, JL3D46 a dit :

Donc, lorsque la traverse est de travers par rapport à la table, tu fais quoi ? réglage de la traverse ou réglage de la table?

Je n'ai plus de soucis de décalage depuis que j'ai synchronisé les deux Z.
Au pire, j'ai mesuré 0.1mm d'écart entre l’extrémité gauche et droite du portique de l'axe X.
Du coup, je me posais la question de savoir si, profitant du changement de carte pour une 32bits, je n'aurais pas intérêt à en prendre une qui me permette d'installer un contacteur de fin de courses pour chacun des deux moteurs de l'axe Z et un pilote par moteur.
De cette façon, une fois que les deux fin de courses seront alignés, à moins qu'un des steppers ne saute des pas, les deux Z seront immanquablement à la même hauteur sans avoir à les synchroniser mécaniquement. 

il y a 28 minutes, Kachidoki a dit :

Tout à fait juste, cependant les moteurs ne sont pas alimenté en tension (12V), mais bien en courant.

En prenant une spec de NEMA 17 48mm sur reprap-france par exemple, tu peux voir 1.68A par phase et seulement 2.8V en tension (et non pas 12V). C'est le job du stepper driver de réguler en courant, et de ce fait si tu en mets deux en série, tu te retrouves avec 1.68A par phase et 5.6V. Le driver pourra toujours les alimenter car ça reste bien inférieur à la tension d'entrée (12V) moins le rendement.

Merci pour cette explication claire, je ne savais pas que ça fonctionnait ainsi

Modifié (le) Juillet 14, 2018 par Guizboy

[JL3D46]

il y a 30 minutes, Guizboy a dit :

Au pire, j'ai mesuré 0.1mm d'écart entre l’extrémité gauche et droite du portique de l'axe X

Ne te pose aucune question, à moins de 0.1 mm d'incertitude d'un coté à l'autre, soit une incertitude "moyenne" de chacun à +/- 0.05 mm tu ne feras pas mieux, sauf à mettre des vis à billes et un codeur additionnel ce qui serait parfaitement inutile vu le besoin de l'impression sur ce type de machine.

[Guizboy]

Le 12/07/2018 at 21:51, Guizboy a dit :

Et le coupable qui me pourrit presque toutes mes impressions depuis des jours est :
.
Roulements de tambours SVP !
.
Repetier Host

 

Le 12/07/2018 at 21:51, Guizboy a dit :

Hypothèses :

1. Le trop grand nombre de lignes de code à transmettre sature le buffer de transmission USB en plus de dépasser la capacité max. de transmission de l'USB.
2. La carte mère de l'imprimante n'est pas capable d'encaisser le surplus de lignes de codes et essai tant bien que mal de les traiter ce qui dévie la priorité du processeur sur l'acquisition de donné plutôt que sur son traitement.
3. Le processus de hachage de Repetier n'a pas la capacité de déduire une ligne droite à partir d'une succession de polyèdres et génère des tas de lignes de code pour une ligne droite alors qu'une seule ligne suffirait. Du coup le logiciel creuserait sa propre tombe en générant des gcodes trop long qui ne peuvent pas être transmis et/ou reçus assez vite.

Je me permets de m'autoquoter parce que ça date et pour faire un peu d'auto dérision

Vous voyez le pignouf du premier quote qui dit que le coupable c'est Repetier Host. Hé ben y s'est planté !

Explications :
Mon tonton est venu me voir pour me souhaiter bon anniversaire. Il est directeur R&D dans une boite d'électronique.
Je lui sers des binches pour l'amadouer et ensuite je l'amène délicatement sur le problème.
En vrai je lui ai posé la carte mère sur les genoux en lui demandant "c'est quoi t'y qui mâche pû ?!" (pour ma défense je l'ai franchement accompagné pour la binouse )
Ensuite je lui explique le problème en détail ainsi que mes hypothèses et celles que vous m'avez apporté.

Du coup il part (titube serait plus approprié) dans mon atelier/bureau/bar (pièce multi-tâche quoi).
Il a exécuté une série de lignes de commande puis lancé la calculette (ça lui a pris quoi, 50 ou 70s ! Jamais pu saquer les frimeurs !)

Confirmation de l'hypothèse 1 comme étant la bonne.
D'après ce que j'ai compris de son explication :

Le problème vient du port USB qui est utilisé comme un port série (beaucoup plus lent que l'USB), il marche donc en baud de 8bits selon une fréquence de 115200.
Vient ensuite la quantité de données à transmettre avec la taille des polyèdres que j'ai réduite pour plus de précision sur les formes. Soit dans le cas de la pièce qui nous occupe : 44Mo.
Plus la rallonge de câble USB que j'utilise et qui génère des erreurs de temps en temps dans la transmission PC/CR-10S (je ne le savais pas, c'est tonton qui l'a vu).

Ces trois facteurs ajoutés ont généré le défaut d'impression qui est le sujet de ce topic.

Conclusion :

• Le port série émulé en USB n'a pas une bande passante suffisante pour imprimer des stl avec la définition élevée dont j'ai besoin pour mes pièces.
• La rallonge USB est trop longue ou de trop mauvaise qualité pour maintenir un baudrate de 115200, ce qui génère des erreurs de transmission.

On a imprimé la pièce à nouveau en diminuant la définition du stl et avec la rallonge USB en moins. résultat nickel

Je suis bien content de connaître avec certitude le fin mot de l'histoire, je peux entamer ma 35ème année avec sérénité maintenant.

Je vais me renseigner sur les cartes afin de passer sur un modèle 32bits (tant qu'à changer autant que ce soit pour le mieux), mais surtout pour passer sur un mode de liaison plus rapide. De plus je pourrais mettre deux pilotes sur le Z et arriver à mon objectif.
Je ne peux pas me passer de la gestion via PC des impressions, du coup c'est mort pour l'impression via SD.

Merci encore à tous ceux qui m'ont aidé

 

 

Modifié (le) Juillet 18, 2018 par Guizboy

[Guizboy]

@pascal_lb : Est ce que tu peux mettre une balise résolu sur le sujet s'il te plaît ?

Je n'ai plus l'option éditer sur le sujet.

D'avance merci

[Kachidoki]

Content d'avoir eu le fin mot !

Pour info, tu dois pouvoir passer en 250KBps en restant sur la carte 8bits (je le fais avec repetier firmware et un tft32).

Après pour aller plus vite, il faut changer de type de liaison, l'UART n'est plus approprié, mais là ça demande de recoder la partie communication dans le firmware.

Sinon la carte SD. 

[Guizboy]

Il y a 2 heures, Kachidoki a dit :

Après pour aller plus vite, il faut changer de type de liaison, l'UART n'est plus approprié,

Oui c'est exactement ce qu'il m'a dit, l'UART est trop lent ^^
Il a également parlé de virer le Tx Rx pour passer en D (apparemment ce serait en rapport avec la connectique d'un contrôleur USB ?). Mais j'étais déjà largué depuis un moment
J'aimerais m'y connaitre en électronique mais bon, c'est bien pour ça que le forum existe, on ne peut pas être spécialiste en tout !

Il y a 2 heures, Kachidoki a dit :

Sinon la carte SD. 

Je pense que je vais couper la poire en deux pour le moment.
Je vais déporter un serveur et l'attacher à l'imprimante avec un câble plus court.
Si je fais rentrer d'autres imprimantes comme prévu, le recours à la carte SD va être problématique.

Modifié (le) Juillet 19, 2018 par Guizboy