Réducteur programmable ?

[PUSSY]

Bonjour,

Vous l'aurez compris, je suis ignorant en électronique.
Pour remplacer la série de pignons que l'on doit installer entre la broche et la boîte d'avance sur un tour (fastidieux à monter / changer, bruyants, ...), je me demandais s'il y avait moyen de remplacer ce système pas un codeur sur la broche et un moteur pas à pas en entrée de boîte.
Il faudrait bien sûr qu'il n'y ait pas de glissement, que le coefficient de réduction ailles de 0,01 à 1, et soit facilement modifiable (choix du rapport par boutons poussoirs ?

Quelqu'un à-t'il une idée de la faisabilité d'une telle transmission ?

Cordialement,
PUSSY.

 

[mwm]

Bonjour,
Avec un moteur pas à pas et sa platine de commande, il y a 2 sens de rotation et une variation de vitesse par potentiomètre que tu peux remplacer par des résistances réglables et sélectionnables par les boutons poussoirs,
Il reste à voir la puissance nécessaire pour entraîner la boîte d'avance,
La liaison entre les 2 par une courroie crantée et 2 poulies ou par un autre moyen, 1 pignon qui s'engrene dans un pignon existant,,, A ++

 

[stanloc]

Bonjour,

Vous l'aurez compris, je suis ignorant en électronique.
Pour remplacer la série de pignons que l'on doit installer entre la broche et la boîte d'avance sur un tour (fastidieux à monter / changer, bruyants, ...), je me demandais s'il y avait moyen de remplacer ce système pas un codeur sur la broche et un moteur pas à pas en entrée de boîte.
Il faudrait bien sûr qu'il n'y ait pas de glissement, que le coefficient de réduction ailles de 0,01 à 1, et soit facilement modifiable (choix du rapport par boutons poussoirs ?

Quelqu'un à-t'il une idée de la faisabilité d'une telle transmission ?

Cordialement,
PUSSY.

Il y a 40 ans j'avais un collègue de travail électronicien qui m'avait fait ça (et que j'ai toujours) Le principe est simple. On multiplie les impulsions du codeur (à chaque impulsion du codeur un générateur d'impulsions "balance" 1000 impulsions par exemple) et ensuite on divise ce train d'impulsions au moyen d'un diviseur programmable par roues codeuses. Dans mon cas cela donne une boîte de vitesse avec 1000 rapports.
Il faut "brancher" des jeunes électroniciens sur une telle réalisation avec les moyens actuels.
Stan

 

[PUSSY]

Il y a 40 ans j'avais un collègue de travail électronicien qui m'avait fait ça (et que j'ai toujours) Le principe est simple. On multiplie les impulsions du codeur (à chaque impulsion du codeur un générateur d'impulsions "balance" 1000 impulsions par exemple) et ensuite on divise ce train d'impulsions au moyen d'un diviseur programmable par roues codeuses. Dans mon cas cela donne une boîte de vitesse avec 1000 rapports.
Il faut "brancher" des jeunes électroniciens sur une telle réalisation avec les moyens actuels.
Stan

Bonjour,

C'est bien ce que j'espérais !

Cordialement,
PUSSY.

 

[gaston48]

Bonjour,
l’idéal est de pouvoir rentrer des rapport de réduction non réductible, comme en pouce
ou en module. A partir de cela, il faut faire des calculs en temps réel de ratio avec des nombres flottants
en double précision, tu as tellement de nombres significatifs (15) qu'il faut faire
fonctionner le rapport plusieurs années avant d'avoir une erreur significative.
Sur le plan hard, il faut un codeur incrémental sur la broche avec une bonne résolution
pour prendre en compte en temps réel un ralentissement due à la charge de travail.
Des entrées d'acquisition rapides pour prendre en compte la fréquence max de comptage.
Ensuite une unité de calcul en temps réel et en flottant genre DSP ou un PC sous noyau
temps réel.
Une sortie de pilotage d'un drive pas à pas ou servomoteur
Peut être que BBB + machinekit serait assez rapide

 

[stanloc]

Bonjour,
l’idéal est de pouvoir rentrer des rapport de réduction non réductible, comme en pouce
ou en module. A partir de cela, il faut faire des calculs en temps réel de ratio avec des nombres flottants
en double précision, tu as tellement de nombres significatifs (15) qu'il faut faire
fonctionner le rapport plusieurs années avant d'avoir une erreur significative.
Sur le plan hard, il faut un codeur incrémental sur la broche avec une bonne résolution
pour prendre en compte en temps réel un ralentissement due à la charge de travail.
Des entrées d'acquisition rapides pour prendre en compte la fréquence max de comptage.
Ensuite une unité de calcul en temps réel et en flottant genre DSP ou un PC sous noyau
temps réel.
Une sortie de pilotage d'un drive pas à pas ou servomoteur
Peut être que BBB + machinekit serait assez rapide

J'espère que PUSSY aura compris car moi je n'ai rien compris (mais c'est sans importance)
Stan

 

[tronix]

Pas besoin de travailler en virgule flottante, on peut rester en virgule fixe (donc en entier, c'est juste une représentation), il faut juste ne pas faire les arrondis pour ne pas cumuler les erreurs. Pas non plus besoin de DSP, un processeur correct, bien programmé, sera largement suffisant par rapport à la vitesse très lente d'un tour. Un noyau temps réel apportera une complexité inutile, sans gain, au contraire.
J'utilise couramment des PIC32 (MX à 80MHz et MZ EF à 200MHz), donc en 32 bits, et pour faire du traitement de signal. Bien programmé (le DMA permet d'avoir des acquisitions et sorties parfaitement synchrones si besoin), sans OS, c'est très performant.
Mais il ne faut pas espérer faire ça avec un Arduino si on utilise des librairies telles que je les ai vues, avec des boucles d'attente (Delay) partout. Il faut proscrire toute boucle d'attente et rendre la main, une fonction ne pouvant se terminer immédiatement se terminera au tour suivant (ou même plus tard) quand le temps se sera suffisamment écoulé (en se basant par exemple sur un compteur global de ms), sans donc avoir besoin de ces foutues boucles d'attente. Sans OS, on appelle toutes les tâches les unes après les autres, qui vont exécuter ce qu'elles ont éventuellement à faire, et juste ce qu'elles peuvent faire sans attendre.
Les tâches critiques seront faites par interruption, mais uniquement la partie critique et si nécessaire, le reste se faisant dans les appels réguliers. Quand on commence à avoir des fréquences élevées (acquisitions à plusieurs centaines de kHz), les appels d'IT sont trop gourmands, et en utilisant des transfert DMA, on peut faire du traitement par bloc, avec des IT à fréquences plus faible, c'est donc plus efficace.
Pour en revenir au problème de base, c'est faisable et même assez facile, mais il faut un peu d'expérience. C'est ce qui permettra de transformer une 2CV en Ferrari, là où programmé avec les pieds on aura une 2CV en partant d'une Ferrari. !

 

[gaston48]

Si je prends des données de servomoteur standard rapporté à la broche, cela
donnerait avec un codeur 1000 imp/t x 4 x 3000 rpm = 200 Khz de f d'entrée max du codeur
même chose en sortie avec un rapport 1/1 si on imagine piloter un drive en step/dir
avec son servomoteur muni d'un codeur à 1000 imp/t ou d'un pas à pas en micropas.
Il faut ensuite inclure un petit interface pour rentrer le rapport en fraction si possible.

sachant que les calculs qui se font entre l'entrée et la sortie peuvent se faire à une
fréquence de rafraîchissement beaucoup plus faible, 1 khz par exemple comme une boucle PID
Entre 2 calculs, relever le compteur de position à l'entrée et corriger une générateur
d'impulsions en sortie.

 

[PUSSY]

Bonjour,

De toute cette littérature, j'en conclue que c'est faisable (assez facilement de ce que je comprend), et que la principale difficulté se résume (en gros) à l'entrée des données (entrée sous forme de fraction).

Quelqu'un se sens-t'il capable (ou a simplement envie) d'essayer, histoire de nous donner un schéma exploitable ?

Cordialement,
PUSSY.

 

[stanloc]

Bonjour,

De toute cette littérature, j'en conclue que c'est faisable (assez facilement de ce que je comprend), et que la principale difficulté se résume (en gros) à l'entrée des données (entrée sous forme de fraction).

Quelqu'un se sens-t'il capable (ou a simplement envie) d'essayer, histoire de nous donner un schéma exploitable ?

Cordialement,
PUSSY.

Toutefois mettre autant d'électronique pour remplacer une douzaine d'engrenages ne vaut pas le coup surtout que cela n'aura jamais la même perfection. En toute rigueur le moteur de la vis sera toujours à la traîne même si ce retard peut être négligeable.
Stan

 

[tronix]

Exact ! Sur un tour prévu à l'origine avec des pignons, pas la peine de se compliquer la vie.

Je ne comprends pas pourquoi il y a le x4 un peu plus haut. 1000 impulsions par tour à 3000t/min sont déjà pas mal. Il faut aussi le sens de rotation. Le principe est donc de toujours connaître la position exacte de l'entrée et de la sortie, et de ne faire avancer la seconde que quand la première a assez avancé, sinon, on mémorise. Et jamais d'arrondi, le reste est gardé et sera ajouté quand le cumul sera suffisant pour faire un nouveau pas. Le retard sera négligeable. Mais encore une fois, il faut que ce soit bien programmé, et ensuite bien câblé (gare aux parasites si les masses ne sont pas soignées et si c'est fait avec un assemblage de bric et de broc de cartes toutes faites).

 

[gaston48]

Sur n'importe quel tour moderne par apprentissage, sur la base mécanique de leur tour conventionnel,
c'est une vis à bille avec servomoteur, codeur sur la broche et boite electronique.
C'est bien par ce qu'on a jamais le pignon qu'il faut pour faire un pas bâtard (pas au module par exemple)
et qui sera approximé, qu'une boite électronique est intéressante. C'est la même problématique qu'un diviseur,
qui nous évite de sortie la cavalerie différentielle.
Sans compter les applications de taillage d'engrenage par génération...
Si tu prends un codeur 1000 impulsions marqué sur le boitier, après le décodage en quadrature
on prend en compte tous les fronts ce qui nous fait 4000 c'est exploité systématiquement
quand on utilise un codeur.

 

[stanloc]

Rien que l'installation du codeur sur la broche d'un tour conventionnel ce sera un sacré challenge et cela d'autant plus que ce codeur aura un grand nombre de pulses/tour.
Il faut être maso pour vouloir faire des pas de vis batârds.
Stan

 

[59JAG]

Bonjour,
je suis justement sur le meme projet .je vais utiliser un arduino car c est possible , la vitesse de la broche varie peux et lentement par rapport la vitesse de l arduino, donc avec un tachy sur broche et un pas a pas pour l avance
video en exemple
j

 

[gaston48]

Bonjour,
ça n'est pas une tachy, au sens analogique du terme mais bien un codeur incrémental de position
angulaire et avec une bonne résolution car avec une petit angle de rotation de la broche
avant / arrière, le moteur d'avance suit bien.

C'est un 1800 i/tr traité en x2
vitesse de broche max 2500 rpm avec les avances, 1800 rpm en filetage.
http://www.chipmaker.ru/topic/118083/
yapluka

 

[speedjf37]

Bonsoir,

Super projet , merci à celui qui l'a trouvé et bravo au concepteur !!!

Dans la version 6B_auto
Il fait même les cones

const cone_info_type Cone_Info[] =
{
{ 25, 6160, " KM0" }, // k = (Cone * X_Steps_mm / Z_Steps_mm) * 2
{ 26, 7293, " KM1" },
{ 26, 6933, " KM2" },
{ 26, 5627, " KM3" },
{ 25, 6720, " KM4" },
{ 25, 3360, " KM5" },
{ 25, 5733, " KM6" },
{ 5, 3333, " 1:4" },
{ 6, 6667, " 1:5" },
{ 9, 3333, " 1:7" },
{ 13, 3333, " 1:10" },
{ 21, 3333, " 1:16" },
{ 26, 6667, " 1:20" },
{ 32, 0, " 1:24" },
{ 40, 0, " 1:30" },
{ 66, 6667, " 1:50" },
{ 12, 1905, " 7:64" },
{ 4, 7436, " 8deg" },
{ 3, 7809, "10deg" },
{ 2, 4880, "15deg" },
{ 1, 1547, "30deg" }
};

Les paramètres de son code:
#define ENC_LINE_PER_REV 1800 // Кол-во линий энкодера
#define MOTOR_Z_STEP_PER_REV 200 // Кол-во шагов/об, ось Z, продольная
#define SCREW_Z 1.50 // Шаг продольного винта Z
#define McSTEP_Z 4 // Микрошаг, ось Z, продольная
#define MOTOR_X_STEP_PER_REV 200 // Кол-во шагов/об, ось X, поперечная
#define SCREW_X 1.00 // Шаг поперечного винта X
#define REBOUND_X 400 // Отскок резца в микрошагах, для авторезьбы, должен быть больше люфта поперечки
#define McSTEP_X 4 // Микрошаг, ось X, поперечная
#define ACCEL 15 // К.деления с которого будем ускоряться на Резьбах, Accel+Ks должен быть < 255

// Ускоренные перемещения
#define MAX_RAPID_MOTION 26 // Меньше - бОльшая конечная скорость //16000000/32/((26+1)*2)/800*60=694rpm
#define MIN_RAPID_MOTION (MAX_RAPID_MOTION + 125) // Больше - мЕньшая начальная скорость, max 255 //16000000/32/((125+26+1)*2)/800*60=123rpm
#define REPEAt (McSTEP_Z * 2) // Кол-во повторов для постоянной скорости в пределах полного шага

Cordialement JF

 

[midodiy]

de remplacer ce système pas un codeur sur la broche et un moteur pas à pas en entrée de boîte.

Plus besoin de boite avec un tel systeme, le moteur pas à pas est en bout de vis mère.

 

[netmetrique]

Je vais lire ce fil avec un grand intérêt.

Je m'étais attaqué à un problème assez similaire, celui du couplage entre la broche de ma fraiseuse et un diviseur en vue de faire le taillage de pignon par fraise mère. Sur un tour, vis mère et broche sont parallèles, et permettent facilement de mettre une lyre, dans mon cas la réalisation d'une solution mécanique était loin d'être simple et la solution d'attaquer le diviseur par un moteur pas à pas parait a priori beaucoup plus facile.

Je comptais mettre un codeur optique de 180 ou 360 secteurs sur la broche de la fraiseuse et pensait utiliser un arduino pour commander le PàP à partir des informations données par le codeur. Malheureusement, par manque de temps je n'ai pas encore réussi à trouver la solution pour l'électronique et le projet est toujours remis à plus tard en raison de choses toujours plus urgentes à faire. Alors si la solution apparaît ici....

 

[gaston48]

taillage de pignon par fraise mère

C'est ce que j'évoquais précédemment comme application possible, mais avec comme impératif
d'éviter une erreur cumulative. Une approximation dans le calcul d'un pas n’entraîne pas d'erreur cumulative,
juste une imprécision. Mais c'est plus grave quand il s'agit d'un engrènement permanent d'une fraise mère avec son engrenage.
Il y a une solution toute faite avec linuxcnc, mais les fréquences d'entrée / sortie oblige à investir
dans une carte à fpga Mesa beaucoup plus chère qu'Arduino, le port // n'est pas assez rapide pour acquérir le codeur.
Et si tu rajoutes un codeur sur l'axe X des avances, tu peux envisager le taillage hélicoïdal ou
même la roue creuse avec un outil unique fly cutter. Tu vas intégrer un différentiel numérique dans ton réducteur
2 entrées (ou plus) vers 1 sortie, ce qu'on retrouve dans une tailleuse d'engrenage universelle.

 

[stanloc]

Que l'on veuille "s'amuser" à adjoindre de l'électronique à son tour, pourquoi pas, mais de mon point de vue si on s'arrête à se doter d'une boîte de vitesses électroniques, on aura encore tous les problèmes déjà évoqués ailleurs des arrêts de broche et rétractation d'outil pour réussir ses filetages/taraudages. Moi je préférerais alors aller jusqu'au bout d'une solution mécano-électronique et numériser mon tour. Les jeux dans les coulisses et dans les noix d'un tour traditionnel sont un éternel problème.
Tout le travail que Pussy a fourni rien que pour la rétractation automatique de l'outil montre bien la justesse de ma remarque.
Stan

 

[speedjf37]

Bonjour,

un autre projet arduino:

code en visual micro
https://github.com/themuck/ZyklenAutomatik/tree/dev

JF

 

[JeanYves]

Bjr ,

Techniquement c'est interessant ,
pratiquement c'est plutot pourquoi faire simple quand on peut faire compliqué .

 

[59JAG]

Bonjour,

c est sûr ca paraît compliqué avec les solutions donné par certain comme travailler en virgule flottante et autre solution farfelues, l arduino est bien assez puissant pour traiter le problème.
J ai fait des test avec un codeur chinois de 600i/tr en mode 4x (2400 pas par tour) sur arduino nano , je traite cha et chb par interruption pour comptage /decomptage et envoi sur le driver de pas a pas le sens et les pulses.
pour le rapport de réduction, en parametre il faut 2 nombres entier qui donne une fraction ex:1 et 3 qui donne 1/3 qui n est pas reductible en un entier.
pour le calul je n utilse que des operations simple addition et soustraction de nombre entier 16bits, j ai vérifié a l oscilloscope le temps ou l encodeur change d etat et l envoi sur le driver de pas a pas cela prend moins de 4us.
bien sure je n utilise pas les library arduino et je travail directement sur les ports.

 

[fabrice c]

projets issu de l'ELS il me semble
http://www.autoartisans.com/ELS/

 

[59JAG]

Bonjour,
une petite video avec encodeur 600p/tr traité en 4x (2400i/tr) et moteur pas a pas configuré en 1600 pas/tr
j ai utilisé un uno avec shield lcd key , codeur et moteur pas a pas géré par interruptions , erreur maxi 1/2pas

 

[gaston48]

pour le calul j

C'est une très bonne solution , j'imagine que tu n’effectues jamais la division finalement
que du comptage décomptage, un peu comme cette solution:
https://www.usinages.com/threads/ta...fraiseuse-classique.67253/page-3#post-1128823
Cela résout la majorité des cas, les pas en pouce compris.
Restent les pas au module qui sont un multiple de Pi ou tu devras passer par une fraction réduite
approximée comme 355/113 ou 333/106. l'approximation est tolérable par rapport à la valeur du pas réel,
mais quand est-il d'une d'éventuelle erreur cumulative ?
Tu peux rentrer combien de voies de codeur ?

 

[MARECHE]

Bonjour,
En automatismes il faut s'astreindre à ne JAMAIS faire de division. L'expérience montre qu'il se produira toujours un cas où on aura zéro, et diviser par zéro provoque un plantage de bas niveau... et la perte du synchronisme.
Salutations

 

[stef1204]

@speedjf37
Pourquoi tu commente tes programmes en Russe?

Ou tu as copié le programme d’un Russe

 

[59JAG]

@gaston48
pas erreur cumulative car a chaque impulsion de l encodeur l erreur et recalculé avec la précédente , voici mon prog faut juste changer dx et dy pour le rapport de réduction
#include <avr/io.h>
#include <LiquidCrystal.h>
LiquidCrystal lcd(8, 9, 4, 5, 6, 7);
#define bit1(PORT,masque) (PORT|=(masque))
#define bit0(PORT,masque) (PORT&=~(masque))
#define encoder0PinA 2 //pin2 arduino
#define encoder0PinB 3 //PIN3
#define pulseMoteur A1 //pin A1
#define directionMoteur A2 //pin A2
#define encoderA 0b00000100 //masque pinA (portd)
#define encoderB 0b00001000 //masque pinB (portd)
#define sens 0b00000100 //masque direction (portc)
#define pas 0b00000010 //masque step (portc)
#define pas_encodeur 2400 //encodeur 600i/t en mode 4x =2400
#define moteur_res 1600 //1600 micropas pour 1 tour
signed long encoder0Pos = 0;
unsigned int dx=1; //ici rapport de reduction
encodeur(dx) et moteur pas a pas(dy)
unsigned int dy=1; // dx et dy entier positif
et dx=>dy dx
int dxx;
int dyy;
signed int erreur;

void setup() {
lcd.begin(16, 2); // start the library
lcd.setCursor(0,0);
lcd.print("Reducteur 59jag");
pinMode(encoder0PinA, INPUT);
pinMode(encoder0PinB, INPUT);
pinMode(pulseMoteur, OUTPUT);
pinMode(directionMoteur, OUTPUT);
attachInterrupt(0, doEncoderA, CHANGE);
attachInterrupt(1, doEncoderB, CHANGE);

dxx=dx*pas_encodeur; //calcul du rapport de
reduc final
dyy=dy*moteur_res;
erreur=-dxx/2;
delay(1000);
}

void loop(){
lcd.setCursor(0,0);
lcd.print(dy);
lcd.print("/");
lcd.print(dx);
lcd.print(" ");
lcd.setCursor(0,1);
lcd.print("enc_pos ");
lcd.print(encoder0Pos);
lcd.print(" ");
delay(100);
}

void doEncoderA(){
if ((PIND & encoderA) != 0) {
if ((PIND & encoderB) == 0) {encoder0Pos++; bit0(PORTC,sens);}
else {encoder0Pos--; bit1(PORTC,sens);}
}
else {
if ((PIND & encoderB) != 0) {encoder0Pos++; bit0(PORTC,sens);}
else {encoder0Pos--; bit1(PORTC,sens);}
}
erreur=erreur+dyy;
if(erreur>0){bit1(PORTC,pas);erreur=erreur-dxx; bit0(PORTC,pas);} //fait avancer le moteur d un pas

}

void doEncoderB(){
if ((PIND & encoderB) != 0) {
if ((PIND & encoderA) != 0) {encoder0Pos++; bit0(PORTC,sens);}
else {encoder0Pos--; bit1(PORTC,sens);}
}
else {
if ((PIND & encoderA) == 0) {encoder0Pos++; bit0(PORTC,sens);}
else {encoder0Pos--; bit1(PORTC,sens);}
}
erreur=erreur+dyy;
if(erreur>0){bit1(PORTC,pas);erreur=erreur-dxx; bit0(PORTC,pas);}
}

 

[speedjf37]

@speedjf37
Pourquoi tu commente tes programmes en Russe?

Ou tu as copié le programme d’un Russe

Bonsoir,

A priori le site est en allemand:

http://muck-solutions.com/?page_id=186

Le code est en Anglais

https://github.com/themuck/ZyklenAutomatik/tree/dev

JF