...Avec Windows c'est la carte motion qui inclue un processeur temps réel, tu n'as pas à t'en occupé...
Avec Linuxcnc, le processeur temps réel, c'est le PC qui héberge Linux. Tu te préoccupes à la foi du paramétrage de l'interface mais également des fonctions temps réel que tu choisis et "câbles" véritablement toi même...
la (non)disponibilité ou le coût de processeurs dédiés,
Mais qui semble bien allé là ou il décidé.Laurent, pas rapide mais obstiné...
En fait, cela va être plus simple pour moi : j'ai une liaison boulonnée sur un plan entre les chariots X et la poutre Y, qui admet un peu de jeu en rotation. Je peux donc régler l'équerrage simplement, puis bloquer cette liaison. J'ai aussi prévu de passer des goupilles coniques pour être sûr que cela ne bouge plus par la suite.Sinon, si ce n' est pas le cas, il faudra revoir l' attachement des patins du X pour réorienter correctement le Y
Pour l'instant, les tubes support des guidages X sont encore flottant sur les châssis, i.e ils peuvent bouger pour s'aligner et/ou s'écarter/resserrer un peu. Pour une longueur de poutre Y donnée, le réglage de l'équerrage influe sur l'écart entre les guidages du X. Je préfère donc commencer par le réglage de l'équerrage pour bénéficier de cette flexibilité. Pour régler l'horizontal, je serai amené à bloquer les tubes X sur les châssis -> plus de possibilités de variation d'écartement des guidages X.Je ne suis pas spécialiste en réglage de machine, aussi je ne comprend pas pourquoi régler l'équerrage X/Y avant la mise à l'horizontal de l'axe X ? Intuitivement, j'aurais fait le contraire.
Pas de soucis, je n'ai trouvé ton message que ce matin. En fait, je vais commencer à me pencher sur la partie commande demain, et je suis un peu fébrile !Désolé pour ton insomnie, j'espère que j'y suis pour rien
Tu as raison bien sûr, je vais faire comme cela, j'ai l'impression que cela sera la méthode la plus simple, au moins pour commencer, et à moins que qq'un ne vienne avec une meilleure idée.La croix me semble une bonne idée. Mais pourquoi un axe au milieu ? ... On mesure ainsi une fois une valeur double de celles avec un axe au milieu, cela me semble plus précis.
OK, j'étais sur la même idéeun contact à galet (car souvent sollicité) positionné ou l'on veut dans l'amplitude pour faire la POM de l'axe.
Il va initialiser en absolu la course logiciel absolue de l'axe, ses limites et donc des butées logicielles parfaitement identifiées, dont on sort au jog sans tralala ...
Je pense que la libération se fera obligatoirement par JOG et/ou MDI, vu le poids et l'inertie des moteurs/réducteurs, j'aimerais donc trouver une solution qui empêche toute tentative de continuer à avancer 'dans le mauvais sens' (par ex. sous le coup de la panique !).un contact de fins de course actionné par 2 butées, positionnées un peu en avant des limites mécaniques
qui entraînera une alarme majeure en cas de franchissement, avec obligation d'intervenir dans l'armoire
si libération par jog, ou libération obligatoire manuellement alimentation coupée.
Est-ce que tu préfères cela pour simplifier le câblage, ou bien pour une autre raison pratique ? J'avais imaginé plutôt identifier chaque FdC séparément.Tous les contacts de chaque axe en série donc origine de l'alarme à identifier visuellement.
Pas sûr de bien comprendre, il faut que j'étudie la doc Homing de LinuxCNC, cela à l'air assez détaillé.les contacts de POM de chaque axe peuvent être en série aussi je crois, si on paramètre les prises de POMs successivement si je me souviens bien
Je crois que j'ai compris le principe, mais je ne pourrai pas l'appliquer pour l'instant, étant en boucle ouverte entre LinuxCNC et les servos (bob simple sur port parallèle). Ce sera pour la suite.Pour une grande précision de POM, qui permet une reprise d'usinage après coupure de l'alimentation par exemple,
On choisit la routine de linuxcnc en 2 temps qui exploite le contact à galet pour autoriser la réinitialisation après acquisition
d'un top index de règle optique ou de codeur de servo-moteur, donc une impulsion beaucoup plus précise
car en amont de la chaîne de réduction moteur vis, mais qui a elle seule ne suffit pas, le contact à galet discrimine
en absolu un tour moteur, puis l'index: un angle de ce tour maintenant identifié.
Le franchissement d'un butée switch doit être considérer comme une panne majeure et rare, comme l’arrêt d'urgence, donc solution AJe pense que la libération se fera obligatoirement par JOG et/ou MDI, vu le poids et l'inertie des moteurs/réducteurs, j'aimerais donc trouver une solution qui empêche toute tentative de continuer à avancer 'dans le mauvais sens' (par ex. sous le coup de la panique !).
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?