Discussion:
microcontroleur pour piloter un driver de moteur pas à pas
(trop ancien pour répondre)
Julien Arlandis
2020-11-24 16:19:34 UTC
Permalink
Bonjour,

Les cartes industrielles de type servodrive utilisées pour piloter les
moteurs pas à pas permettent de piloter les moteurs en mode position avec
une rampe d'accélération et de décélération. Ce sont des
fonctionnalités indispensables en automatique industrielle. Néanmoins,
pour en avoir utilisé quelques unes sur différents projets, on retrouve
systématiquement les inconvénients suivants :
-un temps d'apprentissage conséquent, elles sont complexes à programmer
et quand on change de constructeur il faut repasser un temps équivalent
pour se les réapproprier,
-un protocole de communication bas niveau avec des couches propriétaires,
-leur prix est assez élevé (entre 100€ et 400€).

J'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
numériques basse tension :
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 ?
Olivier B.
2020-11-24 16:52:40 UTC
Permalink
On Tue, 24 Nov 20 16:19:34 +0000, Julien Arlandis
Post by Julien Arlandis
Bonjour,
Les cartes industrielles de type servodrive utilisées pour piloter les
moteurs pas à pas permettent de piloter les moteurs en mode position avec
une rampe d'accélération et de décélération. Ce sont des
fonctionnalités indispensables en automatique industrielle. Néanmoins,
pour en avoir utilisé quelques unes sur différents projets, on retrouve
-un temps d'apprentissage conséquent, elles sont complexes à programmer
et quand on change de constructeur il faut repasser un temps équivalent
pour se les réapproprier,
-un protocole de communication bas niveau avec des couches propriétaires,
-leur prix est assez élevé (entre 100€ et 400€).
J'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...

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.
--
Mail .invalid
Julien Arlandis
2020-11-24 17:50:40 UTC
Permalink
Post by Olivier B.
On Tue, 24 Nov 20 16:19:34 +0000, Julien Arlandis
Post by Julien Arlandis
Bonjour,
Les cartes industrielles de type servodrive utilisées pour piloter les
moteurs pas à pas permettent de piloter les moteurs en mode position avec
une rampe d'accélération et de décélération. Ce sont des
fonctionnalités indispensables en automatique industrielle. Néanmoins,
pour en avoir utilisé quelques unes sur différents projets, on retrouve
-un temps d'apprentissage conséquent, elles sont complexes à programmer
et quand on change de constructeur il faut repasser un temps équivalent
pour se les réapproprier,
-un protocole de communication bas niveau avec des couches propriétaires,
-leur prix est assez élevé (entre 100€ et 400€).
J'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. Votre 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.
Post 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, c'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é.
Olivier B.
2020-11-25 00:16:24 UTC
Permalink
On Tue, 24 Nov 20 17:50:40 +0000, Julien Arlandis
Post by Julien Arlandis
Post by Olivier B.
Post by Julien Arlandis
J'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 Arlandis
Votre 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,

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.
Post by Julien Arlandis
Post 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
Post by Julien Arlandis
c'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é.
A moment donné il faut faire un choix entre:
- 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

- 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.

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...

peut être que developper une gateway http<--->servodrive par moteur
serait la solution qui te permettrait d'obtenir l'architecture IP que
tu veux
--
Mail .invalid
Julien Arlandis
2020-11-25 08:57:17 UTC
Permalink
Post by Olivier B.
On Tue, 24 Nov 20 17:50:40 +0000, Julien Arlandis
Post by Julien Arlandis
Post by Olivier B.
Post by Julien Arlandis
J'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 Arlandis
Votre 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 Arlandis
Post 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 Arlandis
c'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.
Olivier B.
2020-11-25 18:12:39 UTC
Permalink
On Wed, 25 Nov 20 08:57:17 +0000, Julien Arlandis
Post by Julien Arlandis
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) ?
l'approche me semble correcte, cepandant pour rester temps réel il
faut faire gaffe à limiter le code appelé par interuption pour ne pas
empiler jusq'au crash.
Post by Julien Arlandis
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 ?
Je ne sais pas, mais tant qu'à avoir un raspberry, j'explorerais la
piste Qnx pour implémenter directement l'interruption temps réel sur
ce matériel.
Post by Julien Arlandis
Post by Olivier B.
Post by Julien Arlandis
À 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 ?
Virtuellement parce que la vitesse et position du rotor ne sont
qu'estimés, on est plus à l'aveugle mais on compte les barraux de
l'échelle à taton, si on a pas le bon doigté on se loupe et on est
perdus...
Post by Julien Arlandis
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 ?
C'est la carte qui sonde le courant résultant du changement d'état,
celui-ci évolue en fonction de l'impédance du stator ET et du
déplacement du rotor c'est la que le coté DSP entre en jeux parce que
c'est pas si évident que ça de distinguer les deux phénomènes.
Post by Julien Arlandis
Post by Olivier B.
Post by Julien Arlandis
c'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 ?
Pour le peux que je connais de toi, je dirais oui, mais pas sans un
certains nombres de tests pour trouver les limites et ne pas s'en
approcher en prod. Perso comme ça resterait du bricolage,
j'utiliserais un contact d'index pour lever une alerte si le
positionnement n'est plus cohérent, bourrage/manque de lubrification
etc...
Post by Julien Arlandis
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 ?
(le moteur pas à pas étant brushless j'interprête ton propos comme
l'utilisation d'un autre type de moteur)

c'est une approche très différente, le moteur pas à pas est plus
simple à mettre au point, au pire on va moins vite que prévu, alors
que boucler le positionnement avec un autre type de moteur fait appel
à des notions de régulation (PID etc...) pour être rapide sans "sucrer
les fraises" comme disait mon prof d'automatisme, il y a aussi des
risques de dépassement de consigne qui sont inacceptables dans
certains cas, bref laisse tomber...
--
Mail .invalid
Julien Arlandis
2020-11-26 20:40:29 UTC
Permalink
Post by Olivier B.
On Wed, 25 Nov 20 08:57:17 +0000, Julien Arlandis
Post by Julien Arlandis
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) ?
l'approche me semble correcte, cepandant pour rester temps réel il
faut faire gaffe à limiter le code appelé par interuption pour ne pas
empiler jusq'au crash.
Oui, tout à fait.
Post by Olivier B.
Post by Julien Arlandis
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 ?
Je ne sais pas, mais tant qu'à avoir un raspberry, j'explorerais la
piste Qnx pour implémenter directement l'interruption temps réel sur
ce matériel.
Tu penses qu'on pourrait générer des signaux stables de 100 Khz par
cette approche ?
Si c'est le cas, c'est le jackpot, plus besoin de microcontroleur, juste
un driver/séquenceur relié à un raspberry. Il existe même des cartes
qui viennent se fixer derrière le stepper :
https://www.omc-stepperonline.com/fr/pilote-pas-a-pas-numerique/pilote-de-moteur-pas-a-pas-integre-0-2a-10-28vdc-pour-nema-8111417-moteur-pas-a-pas
C'est encore plus satisfaisant, le driver étant collé au moteur je
limite le rayonnement électromagnétique, et je n'ai plus besoin que d'un
raspberry par moteur dans l'armoire électrique.
Enfin, reste à savoir si on peut générer des signaux stables...
Post by Olivier B.
Post by Julien Arlandis
Post by Olivier B.
Post by Julien Arlandis
À 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 ?
Virtuellement parce que la vitesse et position du rotor ne sont
qu'estimés, on est plus à l'aveugle mais on compte les barraux de
l'échelle à taton, si on a pas le bon doigté on se loupe et on est
perdus...
Post by Julien Arlandis
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 ?
C'est la carte qui sonde le courant résultant du changement d'état,
celui-ci évolue en fonction de l'impédance du stator ET et du
déplacement du rotor c'est la que le coté DSP entre en jeux parce que
c'est pas si évident que ça de distinguer les deux phénomènes.
Oui je vois. Peut être que ce produit mesure la phase du courant :
https://www.omc-stepperonline.com/fr/pilote-numerique-pas-a-pas-1-0-3-2a-18-30vdc-pour-nema-17-23-moteur-pas-a-pas.html
Dans les caractéristiques il est indiqué "Anti-résonance pour un couple
optimal", ça veut dire quoi?
Olivier B.
2020-11-27 10:17:19 UTC
Permalink
On Thu, 26 Nov 20 20:40:29 +0000, Julien Arlandis
Post by Julien Arlandis
Post by Olivier B.
Post by Julien Arlandis
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 ?
Je ne sais pas, mais tant qu'à avoir un raspberry, j'explorerais la
piste Qnx pour implémenter directement l'interruption temps réel sur
ce matériel.
Tu penses qu'on pourrait générer des signaux stables de 100 Khz par
cette approche ?
aucune idée raison pour laquelle je parle d'explorer, mais 100Khz
c'est chaud, j'avais cru comprendre que c'était de l'ordre du Khz. Ce
qui est sur pour moi c'est que Qnx est incontournable, obtenir une
stabilité de signal implique de maitriser l'archi matérielle et
logicielle, surtout la priorité des interruptions et potentiellement
désactivation de celles qui pourraient interférer.

En tout cas si t'avance la dessus, ça m'interresse :-)
Post by Julien Arlandis
Post by Olivier B.
C'est la carte qui sonde le courant résultant du changement d'état,
celui-ci évolue en fonction de l'impédance du stator ET et du
déplacement du rotor c'est la que le coté DSP entre en jeux parce que
c'est pas si évident que ça de distinguer les deux phénomènes.
https://www.omc-stepperonline.com/fr/pilote-numerique-pas-a-pas-1-0-3-2a-18-30vdc-pour-nema-17-23-moteur-pas-a-pas.html
Dans les caractéristiques il est indiqué "Anti-résonance pour un couple
optimal", ça veut dire quoi?
j'imagine que le pilotage ne se fait en générant une onde proche de
la fondamentale. Quant tu pilote en signaux carrés, il y a la
fondamentale qui va définir la vitesse de rotation, mais aussi un
ensemble d'harmoniques inutiles qui nuisent à la fluidité du mouvement
et donc au couple, provoquent des pertes fer (joules) et rendent le
système bruyant.
--
Mail .invalid
Julien Arlandis
2020-11-27 11:27:17 UTC
Permalink
Post by Olivier B.
On Thu, 26 Nov 20 20:40:29 +0000, Julien Arlandis
Post by Julien Arlandis
Post by Olivier B.
Post by Julien Arlandis
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 ?
Je ne sais pas, mais tant qu'à avoir un raspberry, j'explorerais la
piste Qnx pour implémenter directement l'interruption temps réel sur
ce matériel.
Tu penses qu'on pourrait générer des signaux stables de 100 Khz par
cette approche ?
aucune idée raison pour laquelle je parle d'explorer, mais 100Khz
c'est chaud, j'avais cru comprendre que c'était de l'ordre du Khz. Ce
qui est sur pour moi c'est que Qnx est incontournable, obtenir une
stabilité de signal implique de maitriser l'archi matérielle et
logicielle, surtout la priorité des interruptions et potentiellement
désactivation de celles qui pourraient interférer.
En tout cas si t'avance la dessus, ça m'interresse :-)
J'ai du mal à comprendre d'où vient la limitation, si Arduino y parvient
avec un processeur à 16Mhz pourquoi Raspberry avec ses 4 coeurs n'y
parviendrait pas? Ce serait si compliqué de faire tourner du code arduino
sur l'un des coeurs en le dissociant complètement de l'OS?
Post by Olivier B.
Post by Julien Arlandis
Post by Olivier B.
C'est la carte qui sonde le courant résultant du changement d'état,
celui-ci évolue en fonction de l'impédance du stator ET et du
déplacement du rotor c'est la que le coté DSP entre en jeux parce que
c'est pas si évident que ça de distinguer les deux phénomènes.
https://www.omc-stepperonline.com/fr/pilote-numerique-pas-a-pas-1-0-3-2a-18-30vdc-pour-nema-17-23-moteur-pas-a-pas.html
Dans les caractéristiques il est indiqué "Anti-résonance pour un couple
optimal", ça veut dire quoi?
j'imagine que le pilotage ne se fait en générant une onde proche de
la fondamentale. Quant tu pilote en signaux carrés, il y a la
fondamentale qui va définir la vitesse de rotation, mais aussi un
ensemble d'harmoniques inutiles qui nuisent à la fluidité du mouvement
et donc au couple, provoquent des pertes fer (joules) et rendent le
système bruyant.
De ce que j'ai compris, de manière tout à fait générale le courant
harmonique généré par le driver est dégradé par l'inductance du
moteur, la valeur du courant est alors prélevée par la carte afin de
réajuster la tension pour forcer le courant à se maintenir sur sa
sinusoïde. Ce mécanisme me parait fondamental pour maintenir un bon
rendement du moteur, il ne me parait pas illusoire de penser que cette
carte malgré son coût bas (17$) régule le courant.
Olivier B.
2020-11-27 13:06:56 UTC
Permalink
On Fri, 27 Nov 20 11:27:17 +0000, Julien Arlandis
Post by Julien Arlandis
Post by Olivier B.
Post by Julien Arlandis
Tu penses qu'on pourrait générer des signaux stables de 100 Khz par
cette approche ?
aucune idée raison pour laquelle je parle d'explorer, mais 100Khz
c'est chaud, j'avais cru comprendre que c'était de l'ordre du Khz. Ce
qui est sur pour moi c'est que Qnx est incontournable, obtenir une
stabilité de signal implique de maitriser l'archi matérielle et
logicielle, surtout la priorité des interruptions et potentiellement
désactivation de celles qui pourraient interférer.
En tout cas si t'avance la dessus, ça m'interresse :-)
J'ai du mal à comprendre d'où vient la limitation, si Arduino y parvient
avec un processeur à 16Mhz pourquoi Raspberry avec ses 4 coeurs n'y
parviendrait pas? Ce serait si compliqué de faire tourner du code arduino
sur l'un des coeurs en le dissociant complètement de l'OS?
C'est pas une question de puissance ou d'affinité mais de ce que
l'architecture t'autorise comme niveau d'interruption. Sur Atmega tu
peux exploiter directement le matériel tu as potentiellement un
control total sur le coté priorité et temps d'execution, mais quand tu
as un OS il peut disposer d'interruption prioritaires sur la tienne.

Je ne connais pas l'archi R.PI aussi je vais potentiellement dire une
connerie, mais par exemple la régularité va être vérifiée durant le
prototypage, et puis en prod ça va merder à cause d'un trafic ethernet
un peu plus soutenu que prévu titillant une interruption prioritaire
sur la tienne.

Qnx apporte normalmeent ce coté temps réel par rapport à un noyau
Linux mais je n'en sais pas plus sur le sujet je ne fais donc
qu'alerter sur cet aspect, parfois on architecture mal mais le système
"tombe en marche" grace au surcroit de puissance...

Comme t'as évoqué le multicoeur, fais gaffe à bien gérer un lock pour
l'accès concurentiel aux données entre le code appelé par
l'interruption et celui de gestion "haut niveau" s'ils ne sont pas
executé par le même thread.
Post by Julien Arlandis
Post by Olivier B.
Post by Julien Arlandis
https://www.omc-stepperonline.com/fr/pilote-numerique-pas-a-pas-1-0-3-2a-18-30vdc-pour-nema-17-23-moteur-pas-a-pas.html
Dans les caractéristiques il est indiqué "Anti-résonance pour un couple
optimal", ça veut dire quoi?
j'imagine que le pilotage ne se fait en générant une onde proche de
la fondamentale. Quant tu pilote en signaux carrés, il y a la
fondamentale qui va définir la vitesse de rotation, mais aussi un
ensemble d'harmoniques inutiles qui nuisent à la fluidité du mouvement
et donc au couple, provoquent des pertes fer (joules) et rendent le
système bruyant.
De ce que j'ai compris, de manière tout à fait générale le courant
harmonique généré par le driver est dégradé par l'inductance du
moteur, la valeur du courant est alors prélevée par la carte afin de
réajuster la tension pour forcer le courant à se maintenir sur sa
sinusoïde. Ce mécanisme me parait fondamental pour maintenir un bon
rendement du moteur, il ne me parait pas illusoire de penser que cette
carte malgré son coût bas (17$) régule le courant.
Possible, la vente à grande echelle a tellement fait baisser les couts
de certains chips pourtant complexes



PS. La priorité "Temps réel" assignable à un processus sous Windows,
quelle bonne blague :'-)
--
Mail .invalid
Julien Arlandis
2020-12-04 19:20:58 UTC
Permalink
Post by Olivier B.
Post by Julien Arlandis
Post by Olivier B.
j'imagine que le pilotage ne se fait en générant une onde proche de
la fondamentale. Quant tu pilote en signaux carrés, il y a la
fondamentale qui va définir la vitesse de rotation, mais aussi un
ensemble d'harmoniques inutiles qui nuisent à la fluidité du mouvement
et donc au couple, provoquent des pertes fer (joules) et rendent le
système bruyant.
De ce que j'ai compris, de manière tout à fait générale le courant
harmonique généré par le driver est dégradé par l'inductance du
moteur, la valeur du courant est alors prélevée par la carte afin de
réajuster la tension pour forcer le courant à se maintenir sur sa
sinusoïde. Ce mécanisme me parait fondamental pour maintenir un bon
rendement du moteur, il ne me parait pas illusoire de penser que cette
carte malgré son coût bas (17$) régule le courant.
Possible, la vente à grande echelle a tellement fait baisser les couts
de certains chips pourtant complexes
J'ai commencé les essais avec le driver DM542T, y a rien à dire sur la
régulation.
Par contre, quand je mesure le signal qui alimente une des bobines je
retrouve bien une tension en créneau comme le montre l'image ci-dessous,
mais j'obtiens aussi un signal sinusoïdal basse tension autour de 0. De
quoi s'agit il ?
<http://news2.nemoweb.net/jntp?***@jntp/Data.Media:1>
--
Ce message a été posté avec Nemo : <http://news2.nemoweb.net/?DataID=***@jntp>
Olivier B.
2020-12-05 00:33:41 UTC
Permalink
On Fri, 04 Dec 20 19:20:58 +0000, Julien Arlandis
Post by Julien Arlandis
Post by Olivier B.
Post by Julien Arlandis
Post by Olivier B.
j'imagine que le pilotage ne se fait en générant une onde proche de
la fondamentale. Quant tu pilote en signaux carrés, il y a la
fondamentale qui va définir la vitesse de rotation, mais aussi un
ensemble d'harmoniques inutiles qui nuisent à la fluidité du mouvement
et donc au couple, provoquent des pertes fer (joules) et rendent le
système bruyant.
De ce que j'ai compris, de manière tout à fait générale le courant
harmonique généré par le driver est dégradé par l'inductance du
moteur, la valeur du courant est alors prélevée par la carte afin de
réajuster la tension pour forcer le courant à se maintenir sur sa
sinusoïde. Ce mécanisme me parait fondamental pour maintenir un bon
rendement du moteur, il ne me parait pas illusoire de penser que cette
carte malgré son coût bas (17$) régule le courant.
Possible, la vente à grande echelle a tellement fait baisser les couts
de certains chips pourtant complexes
J'ai commencé les essais avec le driver DM542T, y a rien à dire sur la
régulation.
Par contre, quand je mesure le signal qui alimente une des bobines je
retrouve bien une tension en créneau comme le montre l'image ci-dessous,
mais j'obtiens aussi un signal sinusoïdal basse tension autour de 0. De
quoi s'agit il ?
honnetement, je distingue pô bien, et dans savoir comment brancher le
sondes pfouuuuu compliqué d'en déduire de quelle mesure ce signal est
l'image....
--
Mail .invalid
Julien Arlandis
2020-12-05 14:00:49 UTC
Permalink
Post by Olivier B.
Post by Julien Arlandis
Post by Olivier B.
Possible, la vente à grande echelle a tellement fait baisser les couts
de certains chips pourtant complexes
J'ai commencé les essais avec le driver DM542T, y a rien à dire sur la
régulation.
Par contre, quand je mesure le signal qui alimente une des bobines je
retrouve bien une tension en créneau comme le montre l'image ci-dessous,
mais j'obtiens aussi un signal sinusoïdal basse tension autour de 0. De
quoi s'agit il ?
honnetement, je distingue pô bien, et dans savoir comment brancher le
sondes pfouuuuu compliqué d'en déduire de quelle mesure ce signal est
l'image....
La sonde est branchée sur B+/B- :

<http://news2.nemoweb.net/jntp?***@jntp/Data.Media:1>
Olivier B.
2020-12-05 15:38:52 UTC
Permalink
On Sat, 05 Dec 20 14:00:49 +0000, Julien Arlandis
Post by Olivier B.
Post by Julien Arlandis
Post by Olivier B.
Possible, la vente à grande echelle a tellement fait baisser les couts
de certains chips pourtant complexes
J'ai commencé les essais avec le driver DM542T, y a rien à dire sur la
régulation.
Par contre, quand je mesure le signal qui alimente une des bobines je
retrouve bien une tension en créneau comme le montre l'image ci-dessous,
mais j'obtiens aussi un signal sinusoïdal basse tension autour de 0. De
quoi s'agit il ?
honnetement, je distingue pô bien, et dans savoir comment brancher le
sondes pfouuuuu compliqué d'en déduire de quelle mesure ce signal est
l'image....
hum... si je comprend bien, la sonde est sur le B+ et sa masse au B-

Le B- est très probablement une sortie de pont en H et ne doit pas
être connecté à la masse sous peine de risquer le CC si la masse de
l'oscillo et de l'alims sont connectées (a ce sujet attension la masse
de l'oscillo est souvent connectée à la terre il faut donc avoir
conscience de ce que l'on fait quand on référence un partie d'un
montage).

Si tu veux mesurer la tension B+ - B- il faut connecter un canal sur
l'un, l'autre canal sur l'autre, et utiliser la fonction ADD et
inverser l'un des deux.

Sinon, désolé mais je n'arrive pas à voir le "signal sinusoïdal basse
tension autour de 0"
--
Mail .invalid
Loïc G.
2020-11-27 11:39:03 UTC
Permalink
Post by Olivier B.
On Thu, 26 Nov 20 20:40:29 +0000, Julien Arlandis
Post by Julien Arlandis
Post by Olivier B.
Post by Julien Arlandis
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 ?
Je ne sais pas, mais tant qu'à avoir un raspberry, j'explorerais la
piste Qnx pour implémenter directement l'interruption temps réel sur
ce matériel.
Tu penses qu'on pourrait générer des signaux stables de 100 Khz par
cette approche ?
aucune idée raison pour laquelle je parle d'explorer, mais 100Khz
c'est chaud, j'avais cru comprendre que c'était de l'ordre du Khz. Ce
qui est sur pour moi c'est que Qnx est incontournable, obtenir une
stabilité de signal implique de maitriser l'archi matérielle et
logicielle, surtout la priorité des interruptions et potentiellement
désactivation de celles qui pourraient interférer.
Une idée comme ça : Au lieu d'utiliser un Rpi + Arduino, un BeagleBone
Black pourrait suffire en utilisant une des deux PRU pour générer le
signal de 100kHz ?
Julien Arlandis
2020-11-27 12:51:52 UTC
Permalink
Post by Loïc G.
Post by Olivier B.
On Thu, 26 Nov 20 20:40:29 +0000, Julien Arlandis
Post by Julien Arlandis
Post by Olivier B.
Post by Julien Arlandis
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 ?
Je ne sais pas, mais tant qu'à avoir un raspberry, j'explorerais la
piste Qnx pour implémenter directement l'interruption temps réel sur
ce matériel.
Tu penses qu'on pourrait générer des signaux stables de 100 Khz par
cette approche ?
aucune idée raison pour laquelle je parle d'explorer, mais 100Khz
c'est chaud, j'avais cru comprendre que c'était de l'ordre du Khz. Ce
qui est sur pour moi c'est que Qnx est incontournable, obtenir une
stabilité de signal implique de maitriser l'archi matérielle et
logicielle, surtout la priorité des interruptions et potentiellement
désactivation de celles qui pourraient interférer.
Une idée comme ça : Au lieu d'utiliser un Rpi + Arduino, un BeagleBone
Black pourrait suffire en utilisant une des deux PRU pour générer le
signal de 100kHz ?
"The BeagleBone Black is an open hardware single-board computer. While
it's similar to the Raspberry Pi, the BeagleBone Black targets a bit of a
different market. Rather than focusing on hobbyists, the BeagleBone Black
is more an engineering-focused board. For instance, the BeagleBone Black
boasts dual 46-pin headers, 4GB of 8-bit eMMC, and a NEON floating-point
accelerator. Plus, there are two PRU 32-bit microcontrollers."

Mais c'est génial, si je comprends bien : 1 BeagleBone Black = 1
raspberry + 2 arduinos ?
Quelqu'un sait comment envoyer téléverser du code sur le microcontroleur
du BeagleBone ?
Olivier B.
2020-11-27 13:09:17 UTC
Permalink
On Fri, 27 Nov 20 12:51:52 +0000, Julien Arlandis
Post by Julien Arlandis
Post by Loïc G.
Une idée comme ça : Au lieu d'utiliser un Rpi + Arduino, un BeagleBone
Black pourrait suffire en utilisant une des deux PRU pour générer le
signal de 100kHz ?
"The BeagleBone Black is an open hardware single-board computer. While
it's similar to the Raspberry Pi, the BeagleBone Black targets a bit of a
different market. Rather than focusing on hobbyists, the BeagleBone Black
is more an engineering-focused board. For instance, the BeagleBone Black
boasts dual 46-pin headers, 4GB of 8-bit eMMC, and a NEON floating-point
accelerator. Plus, there are two PRU 32-bit microcontrollers."
Mais c'est génial, si je comprends bien : 1 BeagleBone Black = 1
raspberry + 2 arduinos ?
ça a l'air séduisant en effet :-)
Post by Julien Arlandis
Quelqu'un sait comment envoyer téléverser du code sur le microcontroleur
du BeagleBone ?
non, mais ça m'interresse, n'hésite pas à partager tes avancées.

A+
--
Mail .invalid
Julien Arlandis
2020-11-27 13:18:06 UTC
Permalink
Post by Olivier B.
On Fri, 27 Nov 20 12:51:52 +0000, Julien Arlandis
Post by Julien Arlandis
Post by Loïc G.
Une idée comme ça : Au lieu d'utiliser un Rpi + Arduino, un BeagleBone
Black pourrait suffire en utilisant une des deux PRU pour générer le
signal de 100kHz ?
"The BeagleBone Black is an open hardware single-board computer. While
it's similar to the Raspberry Pi, the BeagleBone Black targets a bit of a
different market. Rather than focusing on hobbyists, the BeagleBone Black
is more an engineering-focused board. For instance, the BeagleBone Black
boasts dual 46-pin headers, 4GB of 8-bit eMMC, and a NEON floating-point
accelerator. Plus, there are two PRU 32-bit microcontrollers."
Mais c'est génial, si je comprends bien : 1 BeagleBone Black = 1
raspberry + 2 arduinos ?
ça a l'air séduisant en effet :-)
Post by Julien Arlandis
Quelqu'un sait comment envoyer téléverser du code sur le microcontroleur
du BeagleBone ?
non, mais ça m'interresse, n'hésite pas à partager tes avancées.
Je viens de commander un Beaglebone Black chez RS, j'ai hâte de commencer
les premiers tests. J'ai également proposé le projet aux étudiants de
master du parcours télécom et réseaux dans le cadre de mes vacations.
Je vous tiendrai informé des avancées.
Julien Arlandis
2020-12-05 17:38:21 UTC
Permalink
Post by Olivier B.
On Fri, 27 Nov 20 12:51:52 +0000, Julien Arlandis
Post by Julien Arlandis
Post by Loïc G.
Une idée comme ça : Au lieu d'utiliser un Rpi + Arduino, un BeagleBone
Black pourrait suffire en utilisant une des deux PRU pour générer le
signal de 100kHz ?
"The BeagleBone Black is an open hardware single-board computer. While
it's similar to the Raspberry Pi, the BeagleBone Black targets a bit of a
different market. Rather than focusing on hobbyists, the BeagleBone Black
is more an engineering-focused board. For instance, the BeagleBone Black
boasts dual 46-pin headers, 4GB of 8-bit eMMC, and a NEON floating-point
accelerator. Plus, there are two PRU 32-bit microcontrollers."
Mais c'est génial, si je comprends bien : 1 BeagleBone Black = 1
raspberry + 2 arduinos ?
ça a l'air séduisant en effet :-)
Post by Julien Arlandis
Quelqu'un sait comment envoyer téléverser du code sur le microcontroleur
du BeagleBone ?
non, mais ça m'interresse, n'hésite pas à partager tes avancées.
A+
Pour info, j'ai essayé avec un espruino pico (il s'agit d'un
microcontroleur qui interprète du javascript :
https://www.espruino.com/Pico) et je confirme qu'on peut assez simplement
générer un signal carré de 2 Khz simplement avec le code suivant :

setInterval(() => {
digitalWrite(D0, s = !s)
}, 1/4000)

voir https://www.espruino.com/FAQ

Pour piloter un moteur pas à pas, le espruino serait suffisant pour une
vitesse qui n'excède pas 600 tours minutes à condition de rester sur des
pas entiers. Je ne désespère pas qu'un jour, on pourra générer des
signaux haute fréquence en javascript, ce serait une révolution dans
l'industrie et l'électronique.

En attendant, il faut se plonger dans la programmation PRU et ce ne sera
pas aussi simple...
Julien Arlandis
2020-12-05 17:42:32 UTC
Permalink
Post by Olivier B.
On Fri, 27 Nov 20 12:51:52 +0000, Julien Arlandis
Post by Julien Arlandis
Post by Loïc G.
Une idée comme ça : Au lieu d'utiliser un Rpi + Arduino, un BeagleBone
Black pourrait suffire en utilisant une des deux PRU pour générer le
signal de 100kHz ?
"The BeagleBone Black is an open hardware single-board computer. While
it's similar to the Raspberry Pi, the BeagleBone Black targets a bit of a
different market. Rather than focusing on hobbyists, the BeagleBone Black
is more an engineering-focused board. For instance, the BeagleBone Black
boasts dual 46-pin headers, 4GB of 8-bit eMMC, and a NEON floating-point
accelerator. Plus, there are two PRU 32-bit microcontrollers."
Mais c'est génial, si je comprends bien : 1 BeagleBone Black = 1
raspberry + 2 arduinos ?
ça a l'air séduisant en effet :-)
Post by Julien Arlandis
Quelqu'un sait comment envoyer téléverser du code sur le microcontroleur
du BeagleBone ?
non, mais ça m'interresse, n'hésite pas à partager tes avancées.
A+
Pour info, j'ai essayé avec un espruino pico (il s'agit d'un
microcontroleur qui interprète du javascript :
https://www.espruino.com/Pico) et je confirme qu'on peut assez simplement
générer un signal carré de 2 Khz avec le code suivant :

setInterval(() => {
digitalWrite(D0, s = !s)
}, 1/4)

voir https://www.espruino.com/FAQ

Pour piloter un moteur pas à pas, le espruino serait suffisant pour une
vitesse qui n'excède pas 600 tours minutes à condition de rester sur des
pas entiers. Je ne désespère pas qu'un jour, on pourra générer des
signaux haute fréquence en javascript, ce serait une révolution dans
l'industrie et l'électronique.

En attendant, il faut se plonger dans la programmation PRU et ce ne sera
pas aussi simple...
Olivier B.
2020-12-05 19:40:22 UTC
Permalink
On Sat, 05 Dec 20 17:42:32 +0000, Julien Arlandis
<***@gmail.com> wrote:
salut,
Post by Julien Arlandis
Pour info, j'ai essayé avec un espruino pico (il s'agit d'un
https://www.espruino.com/Pico) et je confirme qu'on peut assez simplement
setInterval(() => {
digitalWrite(D0, s = !s)
}, 1/4)
voir https://www.espruino.com/FAQ
Pour piloter un moteur pas à pas, le espruino serait suffisant pour une
vitesse qui n'excède pas 600 tours minutes à condition de rester sur des
pas entiers. Je ne désespère pas qu'un jour, on pourra générer des
signaux haute fréquence en javascript, ce serait une révolution dans
l'industrie et l'électronique.
En attendant, il faut se plonger dans la programmation PRU et ce ne sera
pas aussi simple...
Est-ce que tu es initié au rouages de la programmation temps réel, cad
ce qui se passe coté processeur lors de l'execution du code, les
changements de contexte sur interruption, priorité de ces dernières,
mises en pile etc ... ?
--
Mail .invalid
Julien Arlandis
2020-12-05 20:35:22 UTC
Permalink
Post by Olivier B.
On Sat, 05 Dec 20 17:42:32 +0000, Julien Arlandis
salut,
Post by Julien Arlandis
Pour info, j'ai essayé avec un espruino pico (il s'agit d'un
https://www.espruino.com/Pico) et je confirme qu'on peut assez simplement
setInterval(() => {
digitalWrite(D0, s = !s)
}, 1/4)
voir https://www.espruino.com/FAQ
Pour piloter un moteur pas à pas, le espruino serait suffisant pour une
vitesse qui n'excède pas 600 tours minutes à condition de rester sur des
pas entiers. Je ne désespère pas qu'un jour, on pourra générer des
signaux haute fréquence en javascript, ce serait une révolution dans
l'industrie et l'électronique.
En attendant, il faut se plonger dans la programmation PRU et ce ne sera
pas aussi simple...
Est-ce que tu es initié au rouages de la programmation temps réel, cad
ce qui se passe coté processeur lors de l'execution du code, les
changements de contexte sur interruption, priorité de ces dernières,
mises en pile etc ... ?
Non pas vraiment, j'ai programmé en assembleur il y a longtemps, mais ça
ne m'a jamais passionné. J'y préfère les langages déclaratifs à très
haut niveau d'abstraction. Si j'arrive à créer ce générateur de
signaux je ferai de toute façon remonter la couche au niveau JavaScript
via un transpileur qui regénerera le code C à la volée.
Olivier B.
2020-12-06 00:37:48 UTC
Permalink
On Sat, 05 Dec 20 20:35:22 +0000, Julien Arlandis
Post by Julien Arlandis
Post by Olivier B.
Est-ce que tu es initié au rouages de la programmation temps réel, cad
ce qui se passe coté processeur lors de l'execution du code, les
changements de contexte sur interruption, priorité de ces dernières,
mises en pile etc ... ?
Non pas vraiment, j'ai programmé en assembleur il y a longtemps, mais ça
ne m'a jamais passionné. J'y préfère les langages déclaratifs à très
haut niveau d'abstraction. Si j'arrive à créer ce générateur de
signaux je ferai de toute façon remonter la couche au niveau JavaScript
via un transpileur qui regénerera le code C à la volée.
je vais pas pouvoir t'aider beaucoup plus, si en éttofant le code tes
essais encourageant sont entachés d'irrégularités, je t'invite à
monter un peu en compétance sur la prog temps réel afin de
réarchitecturer dans le bon sens.

peut-être commence tu à comprendre que le prix des servomoteurs à
apprentissage est lié à l'empilement de pas mal de briques/domaine de
compétance scpécifique.
--
Mail .invalid
Loïc G.
2020-11-27 14:14:45 UTC
Permalink
Post by Julien Arlandis
Mais c'est génial, si je comprends bien : 1 BeagleBone Black = 1
raspberry + 2 arduinos ?
Quelqu'un sait comment envoyer téléverser du code sur le microcontroleur
du BeagleBone ?
(ça recommence avec le message "Too much text quoted" ...)

J'avais envisagé l'utiliser pour un projet mais au final, je me suis
rendu compte qu'un Arduino Due suffisait.

Quelques liens qui peuvent être utiles :

https://beagleboard.org/static/prucookbook/

https://www.element14.com/community/community/designcenter/single-board-computers/next-genbeaglebone/blog/2019/05/14/coding-for-the-beaglebone-pru-with-c-in-2019

Un peu de recherche sur le net avec le mot clé PRU devrait te donner pas
mal de résultats.
Julien Arlandis
2020-12-01 17:49:19 UTC
Permalink
Post by Olivier B.
j'étais parti sur cette hypothèse :-)
Post by Julien Arlandis
Votre 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,
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.
J'ai ou tester aujourd'hui le pilote de stepper avec un générateur de
signaux, le résultat me parait plutôt bon. Avec les micro-pas le
mouvement est très fluide et fait disparaitre les vibrations que l'on
obtient à faibles vitesses avec les pas entiers. Pour ceux que ça
intéresse, voici le modèle acheté :
https://www.omc-stepperonline.com/fr/pilote-pas-a-pas-numerique/digital-stepper-driver-1-0-4-2a-20-50vdc-for-nema-17-23-24-stepper-motor.html

Demain, je vais essayer de remplacer le générateur de signaux par le
BeagleBone, mais j'anticipe un petit soucis étant donné que le seuil de
détection du niveau haut sur les entrées numériques du pilote sont dans
la gamme des 4-5V, les sorties digitales du BeagleBone sont à 3.6V.
Il risque de manquer un chouilla de tension, comment la réhausser ?
Loïc G.
2020-12-01 21:26:15 UTC
Permalink
Post by Julien Arlandis
Demain, je vais essayer de remplacer le générateur de signaux par le
BeagleBone, mais j'anticipe un petit soucis étant donné que le seuil de
détection du niveau haut sur les entrées numériques du pilote sont dans
la gamme des 4-5V, les sorties digitales du BeagleBone sont à 3.6V.
Il risque de manquer un chouilla de tension, comment la réhausser ?
En utilisant un level shifter 3.3V->5V
Julien Arlandis
2020-12-01 21:55:20 UTC
Permalink
Post by Loïc G.
Post by Julien Arlandis
Demain, je vais essayer de remplacer le générateur de signaux par le
BeagleBone, mais j'anticipe un petit soucis étant donné que le seuil de
détection du niveau haut sur les entrées numériques du pilote sont dans
la gamme des 4-5V, les sorties digitales du BeagleBone sont à 3.6V.
Il risque de manquer un chouilla de tension, comment la réhausser ?
En utilisant un level shifter 3.3V->5V
Pas besoin de l'alimenter en 5V ?
Volkin
2020-12-02 17:32:01 UTC
Permalink
Post by Julien Arlandis
Post by Loïc G.
Post by Julien Arlandis
Demain, je vais essayer de remplacer le générateur de signaux par le
BeagleBone, mais j'anticipe un petit soucis étant donné que le seuil de
détection du niveau haut sur les entrées numériques du pilote sont dans
la gamme des 4-5V, les sorties digitales du BeagleBone sont à 3.6V.
Il risque de manquer un chouilla de tension, comment la réhausser ?
En utilisant un level shifter 3.3V->5V
Pas besoin de l'alimenter en 5V ?
Si, bien sur.
Volkin
2020-12-01 21:58:52 UTC
Permalink
Post by Julien Arlandis
Post by Olivier B.
j'étais parti sur cette hypothèse :-)
Votre 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,
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.
J'ai ou tester aujourd'hui le pilote de stepper avec un générateur de
signaux, le résultat me parait plutôt bon. Avec les micro-pas le
mouvement est très fluide et fait disparaitre les vibrations que l'on
obtient à faibles vitesses avec les pas entiers. Pour ceux que ça
https://www.omc-stepperonline.com/fr/pilote-pas-a-pas-numerique/digital-stepper-driver-1-0-4-2a-20-50vdc-for-nema-17-23-24-stepper-motor.html
Demain, je vais essayer de remplacer le générateur de signaux par le
BeagleBone, mais j'anticipe un petit soucis étant donné que le seuil de
détection du niveau haut sur les entrées numériques du pilote sont dans
la gamme des 4-5V, les sorties digitales du BeagleBone sont à 3.6V.
Il risque de manquer un chouilla de tension, comment la réhausser ?
Si les GPIO ne peuvent pas être configurés en OC tolérant 5V - utiliser
des transistors externes comme dans Figure 2 page 4 du manuel
me semble le plus simple.
Julien Arlandis
2020-12-01 22:16:38 UTC
Permalink
Post by Volkin
Post by Julien Arlandis
Post by Olivier B.
j'étais parti sur cette hypothèse :-)
Votre 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,
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.
J'ai ou tester aujourd'hui le pilote de stepper avec un générateur de
signaux, le résultat me parait plutôt bon. Avec les micro-pas le
mouvement est très fluide et fait disparaitre les vibrations que l'on
obtient à faibles vitesses avec les pas entiers. Pour ceux que ça
https://www.omc-stepperonline.com/fr/pilote-pas-a-pas-numerique/digital-stepper-driver-1-0-4-2a-20-50vdc-for-nema-17-23-24-stepper-motor.html
Demain, je vais essayer de remplacer le générateur de signaux par le
BeagleBone, mais j'anticipe un petit soucis étant donné que le seuil de
détection du niveau haut sur les entrées numériques du pilote sont dans
la gamme des 4-5V, les sorties digitales du BeagleBone sont à 3.6V.
Il risque de manquer un chouilla de tension, comment la réhausser ?
Si les GPIO ne peuvent pas être configurés en OC tolérant 5V - utiliser
des transistors externes comme dans Figure 2 page 4 du manuel
me semble le plus simple.
À ce propos, quelqu'un peut m'expliquer les implications de ces deux
schémas :
<http://news2.nemoweb.net/jntp?***@jntp/Data.Media:1>
Dans quel cas je dois utiliser celui de gauche, et dans quel cas celui de
droite ?
Sur arduino/BeagleBone la modulation se fait par la borne positive, de
fait c'est bien le schéma de droite qui m'est imposé ?
Volkin
2020-12-02 17:31:26 UTC
Permalink
Post by Julien Arlandis
Post by Volkin
Post by Julien Arlandis
Post by Olivier B.
j'étais parti sur cette hypothèse :-)
Votre 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,
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.
J'ai ou tester aujourd'hui le pilote de stepper avec un générateur de
signaux, le résultat me parait plutôt bon. Avec les micro-pas le
mouvement est très fluide et fait disparaitre les vibrations que l'on
obtient à faibles vitesses avec les pas entiers. Pour ceux que ça
https://www.omc-stepperonline.com/fr/pilote-pas-a-pas-numerique/digital-stepper-driver-1-0-4-2a-20-50vdc-for-nema-17-23-24-stepper-motor.html
Demain, je vais essayer de remplacer le générateur de signaux par le
BeagleBone, mais j'anticipe un petit soucis étant donné que le seuil
de détection du niveau haut sur les entrées numériques du pilote sont
dans la gamme des 4-5V, les sorties digitales du BeagleBone sont à 3.6V.
Il risque de manquer un chouilla de tension, comment la réhausser ?
Si les GPIO ne peuvent pas être configurés en OC tolérant 5V - utiliser
des transistors externes comme dans Figure 2 page 4 du manuel
me semble le plus simple.
À ce propos, quelqu'un peut m'expliquer les implications de ces deux
Dans quel cas je dois utiliser celui de gauche, et dans quel cas celui
de droite ?
Sur arduino/BeagleBone la modulation se fait par la borne positive, de
fait c'est bien le schéma de droite qui m'est imposé ?
Celui à droite utilise des transistors PNP avec des émitteurs au VCC.
Pour les fermer il faut un niveau logique proche de VCC. Si le VCC = 5V
il vous faut le niveau logique 5V et ce n'est pas votre cas.
En fait c'est un montage très rarement utilisé.

Sur le schéma à gauche c'est des transistors NPN, avec l'émetteur sur
la masse, vous pouvez les piloter avec un niveau logique faible, pas
seulement 3,3V. Même 1,2V suffit.
C'est un montage classique pour piloter une tension élevée avec
de la logique basse tension.
Loïc G.
2020-11-24 21:00:27 UTC
Permalink
Post by Julien Arlandis
Bonjour,
[ CUT, j'obtiens un message d'erreur si je laisse la citation, aucune
idée de si ça vient du lecteur de news ou du serveur mais c'est relou ...]


Bonjour,

Les problématiques de temps d'apprentissage et de réappropriation au
changement de constructeur sont valables pour à peu près n'importe quel
produit, à mon avis.

Sur le plan pro, quand j'ai besoin de moteurs pas à pas, j'ai une
préférence pour les produits Oriental Motor.
Je trouve le soft assez intuitif avec des possibilités intéressantes.

Sinon, pour avoir un meilleur contrôle là-dessus, je regarderais du côté
de Trinamic.
Leurs circuits (TMC2209, TMC5160, etc ..) sont très utilisés dans le
domaine de l'impression 3D, avec des fonctionnalités qui peuvent être
intéressantes selon l'application (réduction de bruit, fin de course
sans capteur, etc ...)
Julien Arlandis
2020-11-24 21:35:28 UTC
Permalink
Post by Loïc G.
Post by Julien Arlandis
Bonjour,
[ CUT, j'obtiens un message d'erreur si je laisse la citation, aucune
idée de si ça vient du lecteur de news ou du serveur mais c'est relou ...]
Étrange, c'est quoi le message d'erreur ?
Post by Loïc G.
Bonjour,
Les problématiques de temps d'apprentissage et de réappropriation au
changement de constructeur sont valables pour à peu près n'importe quel
produit, à mon avis.
Sur le plan pro, quand j'ai besoin de moteurs pas à pas, j'ai une
préférence pour les produits Oriental Motor.
Je trouve le soft assez intuitif avec des possibilités intéressantes.
Sinon, pour avoir un meilleur contrôle là-dessus, je regarderais du côté
de Trinamic.
Leurs circuits (TMC2209, TMC5160, etc ..) sont très utilisés dans le
domaine de l'impression 3D, avec des fonctionnalités qui peuvent être
intéressantes selon l'application (réduction de bruit, fin de course
sans capteur, etc ...)
Merci pour le retour d'expérience. Ce que j'aimerais construire, parce
qu'à mon avis ça n'existe pas dans l'industrie, c'est un driver avec un
port ethernet, une adresse IP et un serveur HTTP. Ensuite, je branche tous
mes drivers sur un switch et je pilote l'ensemble avec des requêtes HTTP
de la même façon que je piloterais une API web. Si je veux par exemple
faire tourner mon 47ème moteur de x tours avec une accélération a et
une décélération d, je voudrais pouvoir envoyer ma commande par une
requête du genre :
http://motor47/gotoPosition/?{pos:x,acc:a,dec:d}
Pour parvenir à cet objectif, j'ai pensé coupler un driver à commande
numérique pour la partie puissance comme celui que j'ai indiqué, un
raspberry pour la partie serveur et une carte dédiée pour la partie
pilotage, elle communique avec le raspberry en I2C et se contente de
générer les impulsions en basse tension pour le driver. Je soude
l'ensemble dans un boîtier et voilà ma propre carte maison directement
accessible via un protocole de haut niveau avec des entrées et des
sorties évoluées sans la moindre limitation. Si quelqu'un sait
réaliser cette carte pour la produire en série on peut en discuter.
cLx
2020-11-25 18:38:41 UTC
Permalink
Post by Julien Arlandis
Bonjour,
Les cartes industrielles de type servodrive utilisées pour piloter les
moteurs pas à pas permettent de piloter les moteurs en mode position avec une
rampe d'accélération et de décélération. Ce sont des fonctionnalités
indispensables en automatique industrielle. Néanmoins, pour en avoir utilisé
quelques unes sur différents projets, on retrouve systématiquement les
-un temps d'apprentissage conséquent, elles sont complexes à programmer et
quand on change de constructeur il faut repasser un temps équivalent pour se
les réapproprier,
-un protocole de communication bas niveau avec des couches propriétaires,
-leur prix est assez élevé (entre 100€ et 400€).
J'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 numériques basse
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 ?
Bonsoir,

Il y a GRBL sur Atmega :
https://github.com/grbl/grbl

instructions G-Code en entrée via port série, step/dir en sortie sur trois
axes. Ça gère les rampes, et tout plein de trucs.

https://github.com/gnea/grbl/wiki/Connecting-Grbl
Julien Arlandis
2020-11-26 22:05:53 UTC
Permalink
Post by cLx
Post by Julien Arlandis
Bonjour,
Les cartes industrielles de type servodrive utilisées pour piloter les
moteurs pas à pas permettent de piloter les moteurs en mode position avec une
rampe d'accélération et de décélération. Ce sont des fonctionnalités
indispensables en automatique industrielle. Néanmoins, pour en avoir utilisé
quelques unes sur différents projets, on retrouve systématiquement les
-un temps d'apprentissage conséquent, elles sont complexes à programmer et
quand on change de constructeur il faut repasser un temps équivalent pour se
les réapproprier,
-un protocole de communication bas niveau avec des couches propriétaires,
-leur prix est assez élevé (entre 100€ et 400€).
J'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 numériques basse
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 ?
Bonsoir,
https://github.com/grbl/grbl
instructions G-Code en entrée via port série, step/dir en sortie sur trois
axes. Ça gère les rampes, et tout plein de trucs.
https://github.com/gnea/grbl/wiki/Connecting-Grbl
Merci pour le tuyau !
ptilou
2020-12-05 06:31:05 UTC
Permalink
Post by Julien Arlandis
Bonjour,
Les cartes industrielles de type servodrive utilisées pour piloter les
moteurs pas à pas permettent de piloter les moteurs en mode position avec
une rampe d'accélération et de décélération. Ce sont des
fonctionnalités indispensables en automatique industrielle. Néanmoins,
pour en avoir utilisé quelques unes sur différents projets, on retrouve
-un temps d'apprentissage conséquent, elles sont complexes à programmer
et quand on change de constructeur il faut repasser un temps équivalent
pour se les réapproprier,
-un protocole de communication bas niveau avec des couches propriétaires,
-leur prix est assez élevé (entre 100€ et 400€).
J'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 ?
Y a pas besoin d’un micro-contrôleur pour de l’automatisme, mais de centraliser via des interface ttl-se_que_tu_aime par raison de coût ?

Apprendre quoi ça du XVI les carte perforée avec automatisme, y a que des portes logiques en automatisme ?

Enfin une fois je rencontre il me semble à Nanterre, un me dit on peut pas mettre un cage d’écureuil en automatisme, bon même l’es fraiseuse française y arrive au lycée Émile Paytavain de Mende, qu’est ce que le crie de guerre ingegegegenieur ?



Ptilou
Loading...