Aller au contenu

Messages recommandés

Posté(e)

@Savate

Je ne m'en sors pas.
1/ Je pensais le problème d'affaissement de la gantry en Z2 réglé mais nada
et j'ai comme l'impression que mon problème en Z qui reste bloqué lors d'un <g28 z> y est lié :
j'ai resserré les courroies x, y en désserrant les fixations de la gantry afin de limiter sa déformation quand le poids est en y max
(puis resserré  les fixations évidemment) mis les run_current en z à 1.2 mais quand je fais un <g28 y> avec x max
la gantry s'affaisse de presque 10mm en z2 (avec le run_current à 1.0, elle s'affaissait de presque 15mm).
Je ne suis pas sur qu'une réduction des fils avec l'ebb36 soit suffisant pour résoudre le problème si c'est un problème de poids et de longueur des profilés.
Que faut-il en penser ?
La suppression du kit GE5C peut-il améliorer le problème ?
Est-ce lié à la taille de la bête ? Quand on regarde la conception des grands modèles non pro (tronxy etc)
on constate que souvent c'est le plateau qui se déplace et ce déplacement est assuré par des visses à billes


2/ Lors des <g28 x ou y>, lorsque les end_stops se déclenchent, il y a un léger retour en arrière (normal) mais insuffisant pour qu'ils soient remis en 'open'
du coup, le moteur semble forcer (ronronnement) jusqu'à ce que je fasse un x ou y -1 !
Comment résoudre ce problème ?

Posté(e)
Il y a 16 heures, jpeg a dit :

la gantry s'affaisse de presque 10mm en z2 (avec le run_current à 1.0, elle s'affaissait de presque 15mm).

tu es sûr que le moteur Z2 est dans le bon sens ?

en marche (moteurs sous tension) est-ce que tu arrives à faires descendre la gantry à la main ?

Il y a 16 heures, jpeg a dit :

La suppression du kit GE5C peut-il améliorer le problème ?

non aucun gain au contraire

Il y a 16 heures, jpeg a dit :

2/ Lors des <g28 x ou y>, lorsque les end_stops se déclenchent, il y a un léger retour en arrière (normal) mais insuffisant pour qu'ils soient remis en 'open'
du coup, le moteur semble forcer (ronronnement) jusqu'à ce que je fasse un x ou y -1 !

tu as vérifié que les rotation distance étaient ok (100 mm demandé = 100 mm de déplacement ?)

Est-ce que tu as des points durs sur xy ?

Est-ce que les courroies ne sont pas trop tendues ?

Est-ce que le passage des courroies est ok (surtout à l'arrière) ?

Il y a 16 heures, jpeg a dit :

Je ne suis pas sur qu'une réduction des fils avec l'ebb36 soit suffisant pour résoudre le problème si c'est un problème de poids et de longueur des profilés.

tu ne gagneras pas grand chose en poids et il y a des versions 500 qui existent donc je ne pense pas qu'il y aie un problème de ce côté là. 

Par contre la suppression des chaines devrait bien alléger la gantry sur le côté qui pose problème 

Il y a 16 heures, jpeg a dit :

Est-ce lié à la taille de la bête ? Quand on regarde la conception des grands modèles non pro (tronxy etc)
on constate que souvent c'est le plateau qui se déplace et ce déplacement est assuré par des visses à billes

le plateau est aussi lourd que la gantry, donc no pas de soucis de ce côté là non plus.

Posté(e) (modifié)

@Savate

 

Il y a 7 heures, Savate a dit :

tu es sûr que le moteur Z2 est dans le bon sens ?

Si tu entends par là la connection sur la manta, oui, j'ai tout controlé de ce coté (NVRB pour tous les moteurs)
si tu entends la possibilité qu'un moteur ait été inversé (NV/RB), ce serait bien le diable car j'ai changé le moteur
mais cela reste toujours possible que j'ai utilisé 2 moteurs mal cablés même si c'est fortement improbable.

Citation

en marche (moteurs sous tension) est-ce que tu arrives à faires descendre la gantry à la main ?

Oui, je peux, à la hausse comme à la baisse) mais c'est même pire puisqu'il n'est pas possible de maintenir une hauteur identique à l'avant et à l'arrière
quand la gantry est en y max :
le seul poids de la gantry provoque un affaissement
(ce qui m'échappe compte tenu du couple théorique des moteur 59N/cm -
en même temps, il y a une démultiplication avec le pignon sur les moteurs z qui réduit drastiquement le couple)

====

Il y a 7 heures, Savate a dit :

tu as vérifié que les rotation distance étaient ok (100 mm demandé = 100 mm de déplacement ?)

Oui

Citation

Est-ce que tu as des points durs sur xy ?

Aucune résistance

Citation

Est-ce que les courroies ne sont pas trop tendues ?

Possible car j'ai tenté de jouer sur ce paramètre pour maintenir la gantry parallèle au cadre 'sans affaissement, mais cela ne fait rien

Citation

Est-ce que le passage des courroies est ok (surtout à l'arrière) ?

OK d'autant que je n'ai encore mis aucune paroi

Il me semblait ( mais je ne retrouve plus) qu'il existait un paramètre permettant d'ajouter une valeur de déplacement lors du 'retour' après déclenchement du end_stop
Dans mon cas, 1mm(peut-être moins) et uniquement sur le y end_stop

En fait ma question est :
est-il normal qu'un end_stop reste '
TRIGGERED' après avoir été déclenché ?
Il me semblait qu'après avoir été déclenché, un léger retour arrière était effectué afin que que le end_stop repasse à open.
Vrai ou faux ?

 

Il y a 7 heures, Savate a dit :

Par contre la suppression des chaines devrait bien alléger la gantry sur le côté qui pose problème 

Sur le coté, ok, je verrais si je ne parviens à rien. Pour l'arrière verticale, aide à ce que la gantry ne supporte pas le poids du cablage

Il y a 7 heures, Savate a dit :

le plateau est aussi lourd que la gantry, donc no pas de soucis de ce côté là non plus.

La, je ne suis pas d'accord dans le sens où une visse sans fin offre une toute autre résistance
qu'un jeu de courroie qui lui supporte l'ensemble du poids notamment si l'angle formé par le filet est faible.
De plus, je pensais plutôt à un plateau fixe avec les visses actionnant la gantry
mais ce n'est pas moi qui vais m'atteler à modifier ce projet - ce n'est pas dans mes compétences
ni mes délais lol

Modifié (le) par jpeg
Posté(e)

@Savate

PS: Je précise car j'ai l'impression de manquer de précision et ne pas me faire comprendre 😉 
Quand je parle d'affaissement, c'est en position static moteur allumé :
je cale la gantry, je mets sous tension, j'ote le calage : l'affaissement se produit sans demande de mouvement -
il est impossible de maintenir la position initiale.

 

Posté(e)
Le 19/11/2023 at 18:17, jpeg a dit :

Si tu entends par là la connection sur la manta, oui, j'ai tout controlé de ce coté (NVRB pour tous les moteurs)

ça ou le dir_pin du moteur concerné : ajout d'un ! ou suppression du ! si il est déjà là.

Si tu envoies un M84 (désactivation des moteurs), est-ce que tout est libre ou pas ?

Le 19/11/2023 at 18:17, jpeg a dit :

est-il normal qu'un end_stop reste 'TRIGGERED' après avoir été déclenché ?
Il me semblait qu'après avoir été déclenché, un léger retour arrière était effectué afin que que le end_stop repasse à open.
Vrai ou faux ?

non et vrai 🙂

les paramètres de recul

#homing_retract_dist: 5.0 # Distance de recul (en mm) avant le retour au point d'origine une seconde fois. # Réglez cette valeur à zéro pour désactiver le second retour à l'origine. La valeur par défaut # est de 5 mm.

#homing_retract_speed: # Vitesse à utiliser pour le mouvement de recul après le retour à l'origine au cas où elle soit # différente de la vitesse de mise à l'origine qui est la valeur par défaut de ce paramètre.

#second_homing_speed: # Vitesse (en mm/s) du moteur pas à pas lors du second retour à l'origine. # La valeur par défaut est homing_speed/2.

Le 19/11/2023 at 18:17, jpeg a dit :

La, je ne suis pas d'accord dans le sens où une visse sans fin offre une toute autre résistance

pour la vis sans fin oui, pour le poids du plateau / gantry non, le plateau est nettement plus lourd 🙂

Le 19/11/2023 at 18:17, jpeg a dit :

De plus, je pensais plutôt à un plateau fixe avec les visses actionnant la gantry

il y a un constructeur (elegoo ?) qui a une version 1m3 (kickstarter) qui utilise une gantry mobile sur vis sans fin

Il y a 19 heures, jpeg a dit :

Quand je parle d'affaissement, c'est en position static moteur allumé :
je cale la gantry, je mets sous tension, j'ote le calage : l'affaissement se produit sans demande de mouvement -
il est impossible de maintenir la position initiale.

vérifie avec le M84, si tout n'est pas libre après le M84 : un ou plusieurs enable_pin des steppers est/sont inversé(s)

 

Posté(e)

@Savate

Concernant les tests de résistances, j'ai utilisé un peson électronique (les valeurs restent approximatives à 100g près)
avec le stealthburner placé au centre (250, 250) afin d'évaluer la valeur de ces résistances
(les tests ont été effectués moteurs éteints puis allumés, à la hausse et à la baisse, respectivement Z, Z1, Z2, Z3)

Moteurs éteints ou allumé avec M84 (résultats identiques) :
- UP : 2.2, 3.5, 3.5, 2.7
- DOWN : 0.65, 0.3, 0.2, 0.65

Moteurs allumés (run_current 1.2)
- UP : 2.4, 3.9, 4.0, 3.0
- DOWN : 1.0, 0.5, 0.35, 0.9

Après dir_pin inversé, moteurs allumés :
- DOWN : 0.65, 0.35, 0.2, 0.3

Posté(e)

@Savate

Il semble que le problème d'affaissement soit enfin résolu en inversant le enabled_pin 
(j'arrive à une traction supérieure à 6kg !!! dans les 2 sens quand les moteurs sont allumés).
C'est déjà une grosse épine du pied qui est enlevée ;
je commençais à imaginer le remplacement des courroies par des tiges filetées de 8 😅
coté logiciel il n'y aurait rien eu à changer en respectant un déplacement identique à celui avec des courroies
mais coté adaptation mécanique, il y avait de quoi faire
.

J'ai rétabli le dir_pin que j'avais dernièrement modifié puisque semblant valide auparavant vu le sens du g28 z.
J'ai également redescendu le run_current car le bruit des moteurs me semblait excessif au repos.

Jusque là tout baigne, sauf que, ... un G28 z n'est toujours pas fonctionnel - de plus les moteurs se mettent à faire un boucan du diable
que même un restart firmware/restart ne supprime pas !
Est-ce le fait que  klipper refuse toute instruction tant que le endstop z n'est pas déclenché ?

 

Concernant le second problème : les endstops x, y
les homing_retract_dist mis à 0 ne changent rien :
après un g28, ils restent à déclenchés (
TRIGGERED) et ne reviennent pas à OPEN !



PS: Existe-t-il une instruction GCode qui permette un déplacement paramétré de chaque axe z sans avoir fait au préalable un G28 ?
(L'idée étant de tester un à un la direction de chaque moteur z avec un petit déplacement)

Posté(e)
Le 21/11/2023 at 16:06, jpeg a dit :

les homing_retract_dist mis à 0 ne changent rien :

il faut plutôt mettre 5 ou 10 pour lui dire de reculer (et donc de libérer le endstop)

 

Le 21/11/2023 at 16:06, jpeg a dit :

PS: Existe-t-il une instruction GCode qui permette un déplacement paramétré de chaque axe z sans avoir fait au préalable un G28 ?

le seul test possible sans avoir fait de G28

STEPPER_BUZZ

Par contre tu peux tricher et appuyer toi même sur les endstop au début du G28Z par exemple pour lui faire croire que tout est ok 🙂

Le 21/11/2023 at 16:06, jpeg a dit :

Il semble que le problème d'affaissement soit enfin résolu en inversant le enabled_pin 

ça c'est une excellent nouvelle !

Le 21/11/2023 at 16:06, jpeg a dit :

Jusque là tout baigne, sauf que, ... un G28 z n'est toujours pas fonctionnel - de plus les moteurs se mettent à faire un boucan du diable
que même un restart firmware/restart ne supprime pas !

Attention pour faire un g28 z il faut faire un G28 X Y avant 

Pour le G28 z il faut que la gantry soit à peu prés droite (pas au mm, mais au cm)

Qu'est ce qu'elle fait lors du G28 z ?

(si tu as les logs de klipper ça doit indiquer le/les problèmes rencontrés)

un M84 devrait arrêter les moteurs (et stopper le bruit)

Posté(e)

@Savate

il y a 19 minutes, Savate a dit :

il faut plutôt mettre 5 ou 10 pour lui dire de reculer (et donc de libérer le endstop)

homing_retract_dist: 0, 10 ou 20 ne change rien - il faut impérativement un <G1 X499.50> consécutif au <G28 x> pour qu'il revienne 'open' ;
dans tous les cas précédents, le stealthburner finit immanquablement à la même position.

il y a 32 minutes, Savate a dit :

le seul test possible sans avoir fait de G28

STEPPER_BUZZ

Par contre tu peux tricher et appuyer toi même sur les endstop au début du G28Z par exemple pour lui faire croire que tout est ok 🙂

et un

SET_KINEMATIC_POSITION 
FORCE_MOVE STEPPER=Stepper_z DISTANCE=5 VELOCITE=5

 

FORCE_MOVE STEPPER=Stepper_z DISTANCE=5 VELOCITE=5

etc. ? Je n'ai pas encore testé - j'attendais ton avis ?
 

il y a 37 minutes, Savate a dit :

ça c'est une excellent nouvelle !

Tout à fait la stabilité de la gantry est une bonne nouvelle - restera à gérer un parkage en x:0, y:0 avant extinction ou quelque chose du genre 🤪

il y a 41 minutes, Savate a dit :

Attention pour faire un g28 z il faut faire un G28 X Y avant 

Pour le G28 z il faut que la gantry soit à peu prés droite (pas au mm, mais au cm)

Qu'est ce qu'elle fait lors du G28 z ?

(si tu as les logs de klipper ça doit indiquer le/les problèmes rencontrés)

un M84 devrait arrêter les moteurs (et stopper le bruit)

Rien, à part des moteurs qui ronflent sans aucun déplacement (apparent)
d'où ma question sur les tests à opérer sur chaque z des fois qu'un (ou plusieurs) soit incorrectement connecté en interne
et s'assurer de la direction du dir_pin.

Je dois m'absenter une heure - je referais un test au retour

Posté(e)
à l’instant, jpeg a dit :

etc. ? Je n'ai pas encore testé - j'attendais ton avis ?

jamais essayé, mais effectivement ça devrait bien marcher

Pour les endstop 

* au repos est-ce qu'il sont bien tous 'OPEN' (et enfoncés ils doivent passer en triggered) ?

* Si ils sont tous branchés entre gnd et pin xx est-ce qu'il y a bien un accent circonflexe devant les pins ? 

* au repos il faut tous les essayer et vérifier qu'ils sont tous ok et correspondent au bon axe

il y a 1 minute, jpeg a dit :

Rien, à part des moteurs qui ronflent sans aucun déplacement (apparent)

un M84 (ou un "motors off" dans mainsall) arrête le bruit ou pas ?

Posté(e) (modifié)
QUERY_ENDSTOPS

< 17:54 x:open y:open z:open>

G28 x
QUERY_ENDSTOPS
<17:55 x:TRIGGERED y:open z:open >

G1 X499.50 F6000
QUERY_ENDSTOPS

<17:57 x:open y:open z:open>

G28 y
QUERY_ENDSTOPS
<18:00 x:open y:TRIGGERED z:open>
  
G1 Y-1 F6000
QUERY_ENDSTOPS
<18:02 x:open y:open z:open>
  
G1 Y498.00 F6000
G1 X405.00 F6000
  
g28 z
<18:05 No trigger on z after full movement>
Après le G28 z : aucun mouvement moteur - l'affaissement se reproduit toutefois en z2 (environ 1 cm) sans aucun mouvement comme si le enabled_pin n'était plus fonctionnel
jusqu'au moment où l'instruction est stoppée - on entend alors le rétablissement du enabled_pin : la ~rigidité~ en z2 est rétablie.
Cette fois-ci, pas de ronflement (peut-être parce que le départ de l'opération s'effectue avec une gantry en position correcte ???)
 
ps/ Le positionnement su STH en 405 498 correspond à l'alignement avec le z endstop
[stepper_x]
dir_pin: PB4
step_pin: PE2
enable_pin: !PC11
rotation_distance: 40
microsteps: 16

endstop_pin: ^PF3
homing_retract_dist: 20
 
Citation

un M84 (ou un "motors off" dans mainsall) arrête le bruit ou pas ?

@Savate

PS: Unknown command:"FORCE_MOVE" (Ce n'est pas une instruction gérée par Klipper)

Modifié (le) par jpeg
Posté(e)
il y a 21 minutes, jpeg a dit :

Après le G28 z : aucun mouvement moteur - l'affaissement se reproduit toutefois en z2 (environ 1 cm) sans aucun mouvement comme si le enabled_pin n'était plus fonctionnel
jusqu'au moment où l'instruction est stoppée - on entend alors le rétablissement du enabled_pin : la ~rigidité~ en z2 est rétablie.
Cette fois-ci, pas de ronflement (peut-être parce que le départ de l'opération s'effectue avec une gantry en position correcte ???)

un petit check de la config tel qu'indiqué par klipper

Contrôles de la configuration - Documentation Klipper (klipper3d.org)

surtout la partie 'Vérifier les moteurs pas à pas' devrait résoudre tous les problèmes.

 

Posté(e) (modifié)

@Savate

J'ai effectué les tests de ce chapitre à maintes reprises :
- après démarrage, avec enabled_pin=!xxx, les moteurs se bloquent tous
(d'où comme déjà décrit, il n'y a plus d'affaissement de la gantry)
et un M84 ne change rien.
De plus les STEPPER_BUZZ STEPPER=stepper_z etc ne sont plus fonctionnels !

Si je supprime le <!> de enabled_pin, la gantry s'affaisse en z2.
Si je fais un G28 z dans ce contexte, la gantry se bloque comme quand enabled_pin est mis à <!>
(impossible de la déplacer manuellement durant l'instruction)
Dès que je presse manuellement le z endstop, la gantry se débloque et est déplaçable manuellement !!!
Bref, retour à la case départ.

Je passe à coté de quoi ?

Quelle est l'alternative ?

J'imagine que je dois supprimer le <!> des enabled_pin
et résoudre le problème d'affaissement de la gantry autrement ?

Modifié (le) par jpeg
Posté(e)

@Savate etc

Je récapitule :
[stepper_z]etc
enable_pin: !xxx

la gantry est déplacable manuellement
STEPPER_BUZZ STEPPER : tous moteurs valides

g28 x ou y OK
G28 z la gantry se bloque (ronflement et déplacement infime) même si une instruction M18 ou M84 précède le G28
(comme au repos quand enabled_pin est mis sans ! )
Après un arrêt d'urgence la gantry se déplace brutalement vers le bas de 2cms comme projetée par un ressort.

Suis suffisamment précis cette fois ? 😉

Posté(e)
Il y a 21 heures, jpeg a dit :

J'imagine que je dois supprimer le <!> des enabled_pin
et résoudre le problème d'affaissement de la gantry autrement ?

oui manifestement le enabled_pin n'est pas dans le bon sens.

Mais après l'appui sur le enstop, la gantry ne devrait pas être "libre" et rester en l'état

Tu peux essayer de rajouter la directive hold_current (au même niveau que le run_current) avec une valeur différente du run_current

 

 

Posté(e) (modifié)

J'ai testé avec

enabled_pin: !xx

run_current: 1.200     # max 1.350
hold_current: 0.800

AVANT

image1.png.beab1f531ba38f9134519311af4ec61b.png
Chaque axe z bouge peu mais pas tous dans le bon sens
et ça craque dur si je n'interviens pas avec un arrêt d'urgence :

image2.png.d000aa5d508b55d3628c6f7f0f033031.png
au final, j'ai un z et z2 qui vont vers le bas
et un z1 et z3 vers le haut.

 Au final 
image3.png.882d64df6ff16f53661654e6754ff313.png
mais ce qui importe c'est la photo 2 qui parle d'elle-même.

Modifié (le) par jpeg
Posté(e)
il y a 49 minutes, jpeg a dit :

hold_current < run_current ou hold_current > run_current ?

non c'est une entrée à part entière

par exemple :

run_current: 0.8

hold_current: 1.0

Posté(e) (modifié)

Si je supprime le ! du enabled_pin, avec ou sans M18/54, la gantry est bloquée dès le départ

J'avais compris pour le hold_current : je demandais si la valeur devait etre > ou < à run_current

Modifié (le) par jpeg
Posté(e)
à l’instant, jpeg a dit :

je demandais si la valeur devait etre > ou < à run_current

je n'avais pas vu le post d'avant qui ne s'était pas affiché.

Par défaut hold = run 

en général c'est moins pour le hold, mais ce n'est pas une obligation.

il y a 59 minutes, jpeg a dit :

au final, j'ai un z et z2 qui vont vers le bas
et un z1 et z3 vers le haut.

donc 2 dir_pin à inverser avec un !

elle est gigantesque 🙂 

Posté(e) (modifié)
Citation

donc 2 dir_pin à inverser avec un !

Je testerais demain mais ce n'est pas sur - cela peut-être une distorsion mécanique
car le déplacement se fait très doucement avec un fort ronflement.

Citation

elle est gigantesque 🙂

Voui (*) 🙂 et c'est peut-être bien le problème

(*) en plus l'ERCF (que j'envisage à terme avec un boitier intégré pour protéger les bobines) n'est pas installé - c'est une réhausse de 40 cms environ lol

Modifié (le) par jpeg
Posté(e) (modifié)

Bon, c'est réglé. Tout venait effectivement des dir_pin. Le déplacement z est opérant
Les fichiers config fournis par BIGTREETECH pour la Manta (generic-bigtreetech-manta-m8p-v1.1.cfg) et ceux du kit-voron2 sont invalides
concernant le sens des dir_pin
😞
Pour info, il faut Z_dir =xx, z1_dir=!xx, z2_dir=xx, z3_dir=!xx

 

D'autre part les enable_pin ne peuvent être mis en valeur haute sans bloquer totalement les déplacements
Mis en valeur haute, <M84 G28 z> ou <M18 G28 z> restent inopérants.
Je me retrouve donc avec le problème de l'affaissement de la gantry en z2 (environ 1.5cm).
La solution serait de pouvoir modifier enable_pin en valeur basse dynamiquement via g_code sans restart
sinon en dehors d'une modification matérielle, je ne vois pas comment m'en sortir.

Si quelqu'un de passage ( @Savate ?)  à une idée, je suis preneur
au cas contraire, j'en suis encore pour un billet de 2 à 300€ pour une transformation du kit avec 4 visses sans fin à la place des courroies.

Modifié (le) par jpeg
Posté(e)
il y a 5 minutes, jpeg a dit :

Les fichiers config fournis par BIGTREETECH pour la Manta (generic-bigtreetech-manta-m8p-v1.1.cfg) et ceux du kit-voron2 sont invalides
concernant le sens des dir_pin

C'est souvent le cas avec les fichier de config fournis par les fabricants (ou alors il faut attendre la revision 12 pour que presque toutes les erreurs soient corrigées)🙂

Pour l'affaissement, essaye de mettre ta gantry en position basse et de faire les tests, quand elle est tout en haut la chaîne force un peu plus dessus.

Parce que dans l'ensemble ce ne sont pas les 15cm x 3 de profilé alu en plus par rapport à une 350 qui provoquent un tel affaissement.

Tu peux aussi essayer sans les chaines X, Y : en mettant les câbles 'volants' par dessus la gantry, ça devrait enlever un bon poids dans le coin qui pose problème. 

Posté(e) (modifié)

@Savate

J'ai tendance à penser que c'est autant la section des cables (AWG18/20) que le nombre de cables (22 du STB + 8 moteurs XY +4 endstop=34)
qui posent problème.

J'ai fait les tests (dumoins une partie) avec la gantry basse mais cela ne change rien car la chaine verticale soulage énormément
et donc «l'altimétrie» n'a pas d'effet.
Les 2 chaines horizontales c'est effectivement 2x150g mais je ne suis pas sur que cela soit suffisant car j'avais déjà le problème avant leurs poses.
Je vais à nouveau tester mais vu la galère que j'ai eu pour les mettre 😞 

Les 15 cms de plus sur la gantry, c'est moins le poids des profilés que l'effet de levier en bout
doublé de l'effet lié au repli du cablage :
en x min et y min : aucun problème
en x min et y max (1 seule chaine repliée) léger affaissement en z1 et moindre en z2
en x max et y max : affaissement léger en z1 et maximum en z2.

 

Citation

Tu peux aussi essayer sans les chaines X, Y : en mettant les câbles 'volants' par dessus la gantry, ça devrait enlever un bon poids dans le coin qui pose problème. 

Pour une machine qui me revient déjà à presque 3000€, c'est pas glop pas glop 😂

 

PS: J'ai vu le g_code M42 mais j'ai peur de tout cramer lol

Modifié (le) par jpeg
Posté(e)
à l’instant, jpeg a dit :

Pour une machine qui me revient déjà à presque 3000€, c'est pas glop pas glop

je n'ai plus de chaînes X Y sur mes 2.4, tu peux passer tous les câbles dans une belle gaine qui passe par en haut et qui redescend par derrière (pas par la chaîne Z qui doit rester, mais avec 10 fils - endstops X sur la tête, Y au fond de la gantry), ça marche aussi bien (et avec le canbus c'est encre plus simple, puisqu'il n'y a que 4 fils au lieu des 22)

Posté(e)

D'où l'idée d'installer le canbus
mais ça m'a l'air galère.

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant
  • Sur cette page :   0 membre est en ligne

    • Aucun utilisateur enregistré regarde cette page.
  • YouTube / Les Imprimantes 3D .fr

×
×
  • Créer...