IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Arduino Discussion :

Commande PWM moteur CC, lecture encodeur


Sujet :

Arduino

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre averti
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2018
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2018
    Messages : 25
    Par défaut
    Salut,

    Citation Envoyé par Beginner. Voir le message
    Salut,


    90° +- 1/6T cela ne semble pas très précis, non ???
    Effectivement, 1/4 de T à + ou - 1/6 de T, c'est très très peu précis !
    Ah ben c'est pas cher aussi...

    Je me demandais si je ne pourrais pas faire un post-traitement des données brutes,
    pour calculer l'écart angulaire entre les pôles, en repérant le max, le min dans une fenêtre glissante de 12 intervalles successifs
    En faisant un calcul de vitesse moyenne sur une sec, on doit pouvoir le corriger automatiquement.
    Nous avons une demie-douzaine de ces moteurs. On va peut-être pas les jeter tout de suite.

    Il faut voir que je m'intéresse aussi (et surtout) au régime transitoire, qui dure environ 20millisec.
    Donc pour avoir des mesures pas trop "bruitées" de la montée en vitesse, il va falloir bosser dur !

    Merci pour les avis, je progresse grâce à vous !
    Cordialement
    Horus68

  2. #2
    Expert confirmé

    Homme Profil pro
    mad scientist :)
    Inscrit en
    Septembre 2019
    Messages
    2 907
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : mad scientist :)

    Informations forums :
    Inscription : Septembre 2019
    Messages : 2 907
    Par défaut
    la demande d'origine
    On en déduit le gain statique et la constante de temps, en assimilant le moteur à un premier ordre
    Si ma mémoire ne me joue pas des tours (on veut la valeur de la composante de sortie à l'infini pour une entrée constante - le PWM) vous trouverez ce Gain statique en assimilant votre système à un système linéaire continu invariant stable donc la précision à la micro-seconde en utilisant tous les pôles n'a pas vraiment d'importance, comptez le nombre de ticks (sur une seule broche ou les 2) pour x secondes et vous aurez la vitesse (6 ticks ou 12 par tour suivant ce que vous comptez)

  3. #3
    Membre averti
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2018
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2018
    Messages : 25
    Par défaut
    Bonjour Jay M,

    Citation Envoyé par Jay M Voir le message
    la demande d'origine
    Si ma mémoire ne me joue pas des tours (on veut la valeur de la composante de sortie à l'infini pour une entrée constante - le PWM) vous trouverez ce Gain statique en assimilant votre système à un système linéaire continu invariant stable donc la précision à la micro-seconde en utilisant tous les pôles n'a pas vraiment d'importance, comptez le nombre de ticks (sur une seule broche ou les 2) pour x secondes et vous aurez la vitesse (6 ticks ou 12 par tour suivant ce que vous comptez)
    Alors, oui, l'identification d'un moteur commandé en tension à un premier ordre est bien le but.
    C'est d'ailleurs le début de l'histoire, puisque l'on cherchera à calculer le comportement en boucle fermée avec une boucle d'asservissement
    et une correction soit proportionnelle, soit proportionnelle-Intégrale, mais c'est quand on sera sûr de pas faire de c... en boucle ouverte.
    Et évidemment de comparer la prévision (calcul) avec ce que l'on obtient (mesure).

    Bon, pour le gain, je n'ai besoin que de la vitesse en régime permanent, donc une moyenne sur 1 seconde est très bien...
    Mais ce n'est pas le cas pour la constante de temps, qui sera déterminée à l'aide du temps de réponse à 5%
    ou du temps de montée à 63%. Et là, j'ai besoin de rapidité et de précision de la part de mon moyen de mesure.

    Une petite précision, à l'heure actuelle, on exploite des données de vitesse en calculant la moyenne des écarts au carré entre le modèle et les mesures.
    ça permet de s'affranchir en partie des problèmes de précision du capteur,
    mais afficher des mesures aussi fluctuantes, ça ne fait pas très sérieux même (et surtout) aux yeux d'élèves novices
    De plus, ce sont des obstacles supplémentaires que l'on dresse entre la théorie bien lisse et la pratique...
    et faire le lien entre les 2 n'est jamais trivial... La preuve avec cette discussion.

    PS : j'ai utilisé le programme avec Encoder et Delay(1000). La fluctuation est effectivement bien réduite.
    Un petit récap dès que j'ai suffisamment de données. Merci encore.
    Cordialement
    Horus68

  4. #4
    Expert confirmé

    Homme Profil pro
    mad scientist :)
    Inscrit en
    Septembre 2019
    Messages
    2 907
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : mad scientist :)

    Informations forums :
    Inscription : Septembre 2019
    Messages : 2 907
    Par défaut
    Citation Envoyé par Horus68 Voir le message
    Mais ce n'est pas le cas pour la constante de temps, qui sera déterminée à l'aide du temps de réponse à 5%
    ou du temps de montée à 63%. Et là, j'ai besoin de rapidité et de précision de la part de mon moyen de mesure.
    Oui, j'ai bien en tête les 5% et 63%, mais c'est valable que si le système est vraiment linéaire invariant du premier ordre - ie si la réponse dans le temps est liée aux entrées par une équation différentielle linéaire à coefficients constants. ça marche pas trop mal avec un circuit RC, pour un moteur dont le enable est piloté en PWM c'est à mon avis moins vrai — ça va dépendre de la fréquence du PWM, de l'inertie et qualité du moteur, d'autant plus sans doute surtout en régime transitoire.

    Ce serait pas mal de voir ce qu'il se passe en enlevant le PWM (mettre l'alimentation du moteur sur une alimentation de labo) et en pilotant juste le enable en tout ou rien (et varier la puissance dispo pour trouver quand le moteur se comporte bien comme un système linéaire du premier ordre)

  5. #5
    Membre averti
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2018
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2018
    Messages : 25
    Par défaut
    Citation Envoyé par Jay M Voir le message
    Ce serait pas mal de voir ce qu'il se passe en enlevant le PWM (mettre l'alimentation du moteur sur une alimentation de labo) et en pilotant juste le enable en tout ou rien (et varier la puissance dispo pour trouver quand le moteur se comporte bien comme un système linéaire du premier ordre)
    Avec nos anciens programmes de mesure, avec un PWM à 255, en faisant varier directement la tension d'alimentation, on relevait :
    vitesse finale / tension : 8.6 °/s/V ; Tau : 17ms pour 7.5V
    8.8 ; Tau : 20ms pour 6
    8.8 ; Tau : 15ms pour 4.5
    9.0 ; Tau : 13ms pour 3
    Pas super linéaire, un ratio vitesse/V plus grand pour la tension la plus faible, là ou j'attendais le contraire !
    (importance relative plus forte des frottements)
    Une constante de temps pas super constante ... et même la tendance n'est pas monotone

    La linéarité, c'est pourtant le genre d'hypothèses que l'on prend, sans trop se poser de question, avec des moteurs CC
    (Cf. le site de 3sigma ou la carte Astrolab de chez SET)

    ça mériterait effectivement de mesurer tout ça plus précisément (alimentation : tension et intensité, vitesse),
    en alimentant directement le moteur.

    Cordialement
    Horus68

  6. #6
    Membre averti
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2018
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2018
    Messages : 25
    Par défaut Non linéarité vitesse/PWM
    Bonjour à tous,

    J'ai utilisé le programme de Jay M
    J'ai réglé le PWM à différentes valeurs >=64, pas de 16
    J'ai relevé la vitesse finale (Nb de fronts par sec) en faisant la moyenne sur 30 sec
    Voilà ce que ça donne :
    Nom : Encoder250-1_PWM.JPG
Affichages : 182
Taille : 25,9 Ko

    Pas linéaire du tout !!
    Je m'y attendais pour les basses valeurs de PWM, puisqu'en deçà de 64, la rotation n'a plus lieu
    A noter, la singularité du PWM à 255 (à cause de l'absence de commutation ?)

    Du coup, pour un éventuel asservissement en vitesse, il faudra calculer un gain en linéarisant autour du point de fonctionnement,
    en travaillant sur des échelons de vitesse d'amplitude modeste, si on veut avoir une chance de faire matcher calculs et mesures.
    Idem pour obtenir la constante de temps.

    Comme le disait jpbbricole, il y a de nombreux phénomènes qui rendent cette linéarité caduque, sur de grandes amplitudes.
    Cordialement
    Horus68

  7. #7
    Expert confirmé

    Homme Profil pro
    mad scientist :)
    Inscrit en
    Septembre 2019
    Messages
    2 907
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : mad scientist :)

    Informations forums :
    Inscription : Septembre 2019
    Messages : 2 907
    Par défaut
    ah oui c'est assez parlant !

    peut-être il faudra vous limiter à un intervalle de valeur PWM où le changement de vitesse à l'air assez linéaire?
    Nom : courbe.png
Affichages : 176
Taille : 156,7 Ko

    à noter que sur un Arduino UNO les pin PWM sont les suivantes : 3, 5, 6, 9, 10, 11. La fréquence de PWM est de 490 Hz mais pour les pins 5 et 6 elle est double 980 Hz. Peut-être que cette fréquence double est génératrice aussi de souci. ça vaudrait le coup de voir si la courbe est identique sur la pin 3 par exemple.

    j'ai lu aussi votre commentaire:
    Avec nos anciens programmes de mesure, avec un PWM à 255, en faisant varier directement la tension d'alimentation
    est-ce qu'il y avait une limite en courant? Le moteur ne démarre qu'au-delà d'une tension de seuil dépendante des frottements mais le courant consommé croît avec les frottements et autres pertes qui vont dépendre non linéairement de la vitesse. De plus avec une alimentation pulsée (notre PWM) l'induit du moteur présente une self-inductance dont il faudrait tenir compte

  8. #8
    Membre averti
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2018
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2018
    Messages : 25
    Par défaut
    Bonjour,
    de retour après un gros break ...

    Citation Envoyé par Jay M Voir le message
    ah oui c'est assez parlant !
    peut-être il faudra vous limiter à un intervalle de valeur PWM où le changement de vitesse à l'air assez linéaire?
    Oui, j'y ai pensé, pour une identification sur la base d'un échelon de vitesse entre 2 valeurs assez élevées de PWM, c'est jouable.
    Mais le but est d'aboutir à un asservissement de position, et là, on utilisera toute la plage de vitesse, enfin, notamment la partie inférieure si on ne sature pas,
    et donc on subira la non linéarité, ce qui rend le comportement non calculable... Beurk !

    Citation Envoyé par Jay M Voir le message
    à noter que sur un Arduino UNO les pin PWM sont les suivantes : 3, 5, 6, 9, 10, 11. La fréquence de PWM est de 490 Hz mais pour les pins 5 et 6 elle est double 980 Hz. Peut-être que cette fréquence double est génératrice aussi de souci. ça vaudrait le coup de voir si la courbe est identique sur la pin 3 par exemple.
    Alors, cette fréquence n'est pas supposée poser de problème. C'est lorsqu'elle est beaucoup plus basse que le comportement change : conduction discontinue et variation d'intensité de 0 à Imax puis redescente à 0...
    Ici, doubler la PWM ne devrait pas changer le comportement (conduction dite continue) Cf. le site "Modelleisenbahn" Tension hachée et pertes Joules.
    Cela dit, je tenterai de voir si il y a une différence en changeant de broche.

    Citation Envoyé par Jay M Voir le message
    j'ai lu aussi votre commentaire:
    est-ce qu'il y avait une limite en courant? Le moteur ne démarre qu'au-delà d'une tension de seuil dépendante des frottements mais le courant consommé croît avec les frottements et autres pertes qui vont dépendre non linéairement de la vitesse. De plus avec une alimentation pulsée (notre PWM) l'induit du moteur présente une self-inductance dont il faudrait tenir compte
    Pour ce qui est du courant moteur, je me suis méfié de la petite alim que j'utilisais, et en utilisant une autre affichant le courant, on note une légère augmentation avec la vitesse, mais l'ordre de grandeur est de 0.13 ampères à 0,18A, pour une alim capable d'en délivrer 2...
    Il y a de la marge. Mon moteur tourne presque à vide, mais effectivement, les frottements secs dans le réducteur justifient la tension minimale induisant le courant mini pour que le moteur démarre.
    A noter que les modèles de calcul avec frottement sec + frottement fluide sont linéaires quand le moteur tourne.

    Mon collègue a obtenu un comportement linéaire en utilisant un pont différent et en faisant de la PWM sur la broche DIR et non sur EN (Enable)
    Il faut que je creuse la question... et je ne pense pas pouvoir faire la même chose avec mon PModHB5.

    Merci pour ces suggestions
    Cordialement
    Horus

  9. #9
    Membre averti
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2018
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2018
    Messages : 25
    Par défaut Comparaison de différents ponts
    Bonjour,

    Après avoir suspecté mon alim, une HQPower 2A, 0 à 12V
    et testé le comportement moteur avec une Elix 3A, 0-30V sans constater d'amélioration...

    J'ai testé différents hacheurs pour comparaison. Même programme, branchements analogues et même principe de commande :
    PWM sur la broche En (Enable) ou sur la "gate" du MosFet

    Pont en H L293D du starter kit, avec branchements du livret ;
    MosFet IRF520, diode de roue libre, résistance, conforme au schéma ci-dessous :
    Nom : MosFetL-IRF520.jpg
Affichages : 166
Taille : 45,9 Ko

    Et ça donne ça :
    Nom : Encoder250-1_ComparPonts.JPG
Affichages : 158
Taille : 34,8 Ko

    On peut observer une certaine constance des résultats (non linéarité), et des différences importantes...
    Aucune idée des causes probables...

    Cordialement
    Horus68

  10. #10
    Expert confirmé

    Homme Profil pro
    mad scientist :)
    Inscrit en
    Septembre 2019
    Messages
    2 907
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Etats-Unis

    Informations professionnelles :
    Activité : mad scientist :)

    Informations forums :
    Inscription : Septembre 2019
    Messages : 2 907
    Par défaut
    c'est frustrant.... peut-être une déficience du PModHB5?

  11. #11
    Membre averti
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2018
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2018
    Messages : 25
    Par défaut Correction des imprécisions du codeur par post-traitement
    Re,

    J'avais dit que je ferai un petit programme python pour voir si on pouvait améliorer les mesures, le voilà
    (les puristes y trouveront sans doute beaucoup à redire)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    ## Repérage des différents poles et calcul des angles entre chaque
    # En régime permanent, la vitesse est constante, la durée entre deux poles n'est pas exactement la même
    # On importe le fichier texte contenant les intervalles de temps en microsecondes entre 2 ticks
    # On prend la moyenne des intervalles sur n tours consécutifs en partant de la fin
    # On en déduit une succession d'intervalles angulaires pour faire un tour
    # On calcule la vitesse en prenant angle calculé/durée mesurée
     
    import numpy as np
    import matplotlib.pyplot as plt
     
    poles = 6                   # fronts par voie (paires de poles)
    voies = 2                   # voies codeur
    nbtours = 1                 # nb de tours sur lesquels est calculée la moyenne
    cycle = poles*voies         # nb de fronts sur un tour
     
    fichier = open("essai.csv","r",encoding="utf8")
     
    # temps en millisecondes entre deux fronts
    temps = [float(x) for x in fichier.read().split()]
    # vitesse en tours par seconde, sachant qu'un tour est fait en "cycle"s fronts
    # en supposant que l'écart angulaire entre 2 fronts est absolument régulier
    vitesse = np.array([1000/(t*cycle) for t in temps])
    # Echelle des temps
    T=np.array([sum(temps[:i]) for i in range(len(temps))])/1000
     
    # Ici, on a exclu le dernier tour (ralentissement) du fichier csv
    def moyenne(temps) :
        """ Moyenne des périodes de chaque "pole", à vitesse supposée constante, appliquée à un fichier 'propre', sans valeur exceptionnelle en fin de colonne"""
        temps_sum = temps[-cycle:]      # somme des valeurs en vue d'une moyenne, initialisation
        for i in range(nbtours-1) :
            for j in range(cycle) :
                temps_sum[j] += temps[-(2*(i+1)*cycle)+j]
        return np.array(temps_sum)/nbtours            # Calcul et renvoi de la moyenne
     
    DeltaT_moy = moyenne(temps)             # Période moyenne de chaque "pole" en ms
    Theta_moy = DeltaT_moy/sum(DeltaT_moy)  # angle moyen entre chaque pole (en fraction de tour)
     
    def vitesse_corr(temps) :
        """ Vitesse corrigée des variations angulaires des poles"""
        i0 = cycle - len(temps)%cycle
        return np.array([Theta_moy[(i0+j)%cycle]*1000/temps[j] for j in range(len(temps))])
     
    vitesse2 = vitesse_corr(temps)
     
    plt.plot(T,vitesse,label = "vitesse brute (tr/s)")
    plt.plot(T,vitesse2,label = "vitesse corrigee (tr/s)")
    plt.legend()
    plt.show()
    Mais bon, ça tourne.
    On obtient ça sur un fichier test, extrait de mesures en millisecondes, la durée étant un peu courte pour assurer être en régime permanent sur plus d'un tour (le dernier), mais la comparaison est sans équivoque (sauf le premier point qui est une singularité due à une mauvaise maitrise de la communication série, sans doute)
    Nom : VitesseCorrigee.png
Affichages : 157
Taille : 39,0 Ko

    C'est pour le moment le travail le plus satisfaisant que j'ai pu effectuer sur ce thème.
    Il parait que la démarche d'investigation c'est pédagogiquement super, mais c'est un peu chronophage quand on est pas doué !!

    Cordialement
    Horus68

  12. #12
    Membre Expert

    Homme Profil pro
    Directeur de projet
    Inscrit en
    Mai 2013
    Messages
    1 632
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Service public

    Informations forums :
    Inscription : Mai 2013
    Messages : 1 632
    Par défaut Encodeur & PWM
    Bonjour,

    Est-ce que vous savez comment fonctionne l'encodeur (électrique, magnétique, optique...) ? Je fais l'hypothèse non optique car la précision serait a priori bien meilleure.

    Si la détection est très économique, elle peut se baser sur la détection directe (ie sans roue) de la rotation du moteur (retour électrique ou détection des pôles tournant). Si c'est le cas bien que le moteur soit un passe bas, cela ne se manifeste qu'au travers de l'inertie mécanique. Mais si nous sommes en amont (avec la détection directe sur les champs tournant) nous risquons d'avoir un joyeux mélange entre le retour moteur vers les détecteurs et le PWM.

    Un test de cette hypothèse serait de changer la période de base du PWM et de regarder comment évolue la situation. Si rien ne se passe : rejet d'hypothèse. Sinon…

    Hors sujet : je me demande à quoi sert ici une détection en quadrature puisque nous commandons le sens de rotation du moteur.

    Salutations

  13. #13
    Membre averti
    Homme Profil pro
    Enseignant
    Inscrit en
    Avril 2018
    Messages
    25
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Enseignant
    Secteur : Enseignement

    Informations forums :
    Inscription : Avril 2018
    Messages : 25
    Par défaut Encodeur
    Bonjour Guesset,

    Capteur à effet hall à 3 paires de pôles. La précision annoncée dans la doc est très mauvaise. C'est confirmé par l'expérience.
    Le post-traitement est satisfaisant, d'autant que mon fichier exemple est plutôt mal choisi : on n'est pas vraiment arrivé en régime permanent sur le dernier tour.
    D'où la petite discontinuité (mini rampe) en début de tour.

    Le changement de fréquence PWM ne semble pas influente : en passant de la broche 5 (490Hz) à la 9 (980Hz), pas de changement.

    L'utilisation des 2 voies et de tous les fronts a pour but d'augmenter la précision.

    Pour la quadrature, ne peut-on pas envisager un cas de figure avec un système mécanique très inerte, qui continue à tourner dans le sens + longtemps après que l'on l'ait commandé pour le sens - ? Du coup, il est nécessaire de faire le test a ET b, après front sur a ou sur b pour savoir si il faut effectivement incrémenter ou décrémenter.
    Je me place là dans le cadre d'un asservissement en position, par exemple.

    Cordialement

  14. #14
    Membre Expert

    Homme Profil pro
    Directeur de projet
    Inscrit en
    Mai 2013
    Messages
    1 632
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Directeur de projet
    Secteur : Service public

    Informations forums :
    Inscription : Mai 2013
    Messages : 1 632
    Par défaut Vitesse et précipitation
    Bonjour Horus,

    Citation Envoyé par Horus68 Voir le message
    ...Le changement de fréquence PWM ne semble pas influente : en passant de la broche 5 (490Hz) à la 9 (980Hz), pas de changement.
    L'utilisation des 2 voies et de tous les fronts a pour but d'augmenter la précision.
    Pour la quadrature, ne peut-on pas envisager un cas de figure avec un système mécanique très inerte, qui continue à tourner dans le sens + longtemps après que l'on l'ait commandé pour le sens - ? ...
    Ok, Hypothèse out.

    L'argument selon lequel on peut passer en marche arrière alors que le moteur est lancé à pleine vitesse en marche avant me laisse très dubitatif. On peut essayer. Une fois

    Salut

Discussions similaires

  1. Programme Arduino de commande de moteur+encodeur.
    Par loquet38 dans le forum Arduino
    Réponses: 7
    Dernier message: 15/03/2018, 20h20
  2. Commander un moteur (virtuellement)
    Par soft001 dans le forum LabVIEW
    Réponses: 0
    Dernier message: 12/04/2012, 10h06
  3. Commander un Moteur Electrique via une Interface Web
    Par felops dans le forum Entrée/Sortie
    Réponses: 4
    Dernier message: 05/03/2008, 14h00
  4. Installation d'un module en ligne de commande sur moteur 9i
    Par Arakil dans le forum Installation
    Réponses: 0
    Dernier message: 10/09/2007, 12h47
  5. Commander plusieurs moteurs par un seul port USB
    Par wolfjeremy dans le forum Windows
    Réponses: 6
    Dernier message: 11/06/2006, 14h52

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo