Post by Olivier B.On Tue, 24 Nov 20 17:50:40 +0000, Julien Arlandis
Post by Julien ArlandisPost by Olivier B.Post by Julien ArlandisJ'ai donc cherché des solutions pour m'affranchir de ces contraintes pour
mes futures machines industrielles. En partant d'une carte toute simple
qui ne fait que piloter le moteur en puissance via des impulsions
https://www.omc-stepperonline.com/digital-stepper-driver/y-series-digital-stepper-driver-0-3-2-2a-dc18v-36v-for-nema-14-17-23-stepper-motor.html
Je me suis dit qu'il suffirait que j'interface ce type de cartes avec un
microcontroleur qui gère toute la partie logique et génération de
signaux pour m'affranchir de tous les problèmes mentionnés plus haut.
Qu'en pensez vous ?
Le pilotage en mode position est un processus à part entière dont
l'optimisation nécéssite obligatoirement la mesure de phase
tension/courant pour ne pas sauter des pas lors de l'accélération et
décélération, ceci "nourrissant" un algo d'apprentissage, c'est entre
autre pour ça que ces cartes ont un cout...
J'ai oublié de préciser que les moteurs n'ont pas de codeurs intégrés,
ils sont pilotés en boucle ouverte.
j'étais parti sur cette hypothèse :-)
Post by Julien ArlandisVotre remarque mme suggère une autre
question, comment faire pour accélérer un moteur pas à pas avec un
servodrive tel que celui-ci
<https://www.omc-stepperonline.com/digital-stepper-driver/y-series-digital-stepper-driver-0-3-2-2a-dc18v-36v-for-nema-14-17-23-stepper-motor.html>
puisque dans tous cas de figure je n'aurais aucun contrôle sur la phase
ou la tension e,n dehors de celle que je suis capable de générer par le
microcontrôleur.
ce n'est pas du tout un servodrive mais un simple sequenceur/driver,
Oui.
Post by Olivier B.un front descendant de PU incrémente la séquence dans le sens
déterminé par DR, on obtient un déplacement élémentaire angulaire du
rotor.
une fréquence appliquée sur PU correspond à une vitesse angulaire fixe
du rotor
l'accélération correspond à la dérivée de la fréquence
le déplacement est proportionnel à l'intégrale des fronts PU, on le
connait généralement à l'avance, pour démarrer un choisi
arbitrairement une valeur basse de fréquence à laquelle on ajoute
l'intégrale de la valeur accélération (ch'uis un peu fatigué mais on
doit pas être loin du compte).
MF permet de couper l'alimentation stator pour passer en "roue libre",
si le moteur a levé une charge elle peut redescendre moyennant les
frictions, l'action de l'arrêt d'urgence sur cette valeur est donc à
réfléchir selon le risque encouru.
C'est bien comme ça que j'avais compris le fonctionnement du bidule. Pour
piloter mes steppers avec cette carte il me faut générer des signaux de
l'ordre du khz, en jouant sur les interruptions et les timers du arduino
ça doit être faisable de prototyper l'étage logique (calcul des rampes
d'accélération et génération des signaux en conséquence) ?
Une fois le prototypage terminé, il faudra trouver le moyen de compacter
tout ça dans un boitier, et pour ça je ne sais encore pas trop par quoi
je vais remplacer le couple raspberry + arduino, n'existe-t-il pas des
cartes qui combinent les deux ?
Post by Olivier B.Post by Julien ArlandisPost by Olivier B.sans mesure de courant tu risque de sauter des pas si un problème
survient au dela de la marge que tu auras pris, il faut donc qu'elle
soit conséquente, voir complétée par un capteur index pour que le soft
recalibre si nécéssaire, tu seras forcément moins performant sauf à
réécrire le même code ou surdimensionner les moteurs.
À quelle mesure de courant faites vous référence,
le courant de stator, il permet de d'estimer le déplacement du rotor
sur du pilotage vectoriel
https://www.researchgate.net/figure/Adopted-sensorless-vector-control-scheme-for-stepper-motors_fig1_269309363
Si on mesure le courant, ça devient de la boucle fermée non ?
En pratique comment opère t-on ? Faut il des moteurs spéciaux, rajouter
un codeur sur le moteur ou bien c'est la carte qui se débrouille en mode
ampèremètre ?
Post by Olivier B.Post by Julien Arlandisc'est toute la
problématique du pilotage d'un stepper en boucle ouverte, on envoie des
impulsions à l'aveugle sans certitude que le moteur n'a pas décroché.
- piloter à l'aveugle/surdimensionner pour éviter le décrochage, ce
qui n'empeche pas de gérer acc/décélérations, exemple imprimantes 3D
Je suis partie sur cette option plus facile à atteindre. Avec un
séquenceur/driver couplé à ma solution je devrais y arriver ?
Post by Olivier B.- coller au plus près des perfs moteur parce qu'on commnce à taper
dans des games ou surdimensionner le moteur coute plus cher que le
controleur qui évite d'avoir à le faire.
Si on doit faire de la boucle fermée sur du stepper, n'est il pas plus
avantageux de partir sur des brushless ?
Post by Olivier B.j'ai peur que tu ais sous-estimé le cout de cette partie dans le
projet de pilotage http de tes moteurs, j'attire toutefois ton
attention sur l'impact qu'un tel niveau de protocole peut avoir coté
(variation de) latence et donc erreur de coordinations aboutissant à
une cinématique erronée sur des mouvements combinés, à considérer ou
pas selon ce qu'on pilote...
Avec ma solution je ne pourrais pas faire de mouvements combinés comme
par exemple suivre une trajectoire avec une imprimante 3D ou une CNC. Ce
n'est pour l'heure pas mon besoin, mais si un microcontrôleur arrive à
générer les signaux pour un moteur, on pourrait effectivement étendre
ses capacités pour faire du multi-axe. Aujourd'hui je dois juste gérer
des mouvements séquentiels, attendre qu'un moteur ait atteint sa position
pour envoyer l'ordre en HTTP. J'ai estimé qu'il y aurait une latence (ou
plutôt devrais je dire une pause) de l'ordre de 1-2ms entre deux cycles
qui correspond grossomodo au cumul des latences de la liaison I2C et du
transfert de données en HTTP.
Post by Olivier B.peut être que developper une gateway http<--->servodrive par moteur
serait la solution qui te permettrait d'obtenir l'architecture IP que
tu veux
J'ai essayé, c'est trop compliqué, entre la gateway et les servodrive je
suis obligé de gérer les collisions, les acquittements etc etc... En
bref je suis obligé de bricoler toutes les couches du modèle OSI, alors
que le HTTP gère tout ça de façon transparente. J'envoies un ordre,
j'obtiens automatiquement une réponse, sans me soucier de la manière de
transporter les requêtes et les réponses. Le temps que je vais perdre en
investissant dans cette direction je vais largement le récupérer sur le
temps gagné lors du prototypage de mes futures machines.