repman a écrit :Salut Myoda,
Pas de soucis pour le délai.
J'ai compris le principe et cela fonctionne
Concernant le problème de manque de fluidité des aiguilles.
si j'ai bien compris:
1- tu envois la valeur que le moteur doit atteindre
2- la librairie arduino fait monter le moteur jusqu'à cette valeur puis retour à l'étape 1
et donc tu ne contrôle pas la vitesse de déplacement de l'aiguille du moteur puisque c'est la librairie qui sent charge.
Une idée de néophyte:
1- tu compare la valeur actuel afficher par le moteur avec la valeur lu dans falcon (ex: RPM falcon70%-moteur affiche 5%)
2- si le résultat est positif, tu fais monter la valeur envoyé nom pas directement a 70%, mais tu incrémentes la valeur afficher par le moteur de X% (0.1%par exemple) suivi d'une petite pose de X millisecondes jusqu'à atteindre l'objectif qui est de 70%.
comme ca tu control la vitesse à laquelle monte ou descend l'aiguille
Je sais pas si je suis claire
Repman
Coucou,
merci pour ta réponse ! Alors en théorie oui, mais en pratique, c'est plus complexe que ça !
En faite la librairie SwitecX25.h travaille j'imagine en verrouillant la position du moteur pendant son déplacement !
J'ai déjà essayé en ajoutant des pourcentages de valeurs comme tu le préconises.
Le souci, c'est que si les valeurs envoyés à la carte Arduino augmentent ou chutent brutalement, le moteur en revanche devra toutes les traiter dans l'ordre d'arrivée, car SwitecX25.h créé une espèce de "queue" ou "tasklist" de travail en attente à effectuer par le moteur ! Donc du coup, le moteur n'est plus synchronisé avec BMS ! et le décalage s'accentue en fonction de l'activité !
A l'heure actuelle, je ne suis pas assez fort en math pour effectuer des calculs logarithmiques pour déplacer l'aiguille, mais grosso modo le principe est bien celui que tu décris sauf que le faire sans librairie est plus complexe que prévu !
La solution Accellstepper règle le problème, mais l'inconvénient, c'est que cette librairie n'est pas compatible avec plusieurs moteurs ! Et c'est bien logique, car comme je l'ai décris plus haut, en faisant cela, l'ensemble de la loop (boucle) Arduino qui est affecté ! Il faut donc créer un système de thread indépendant pour résoudre le problème ! Sauf que c'est pas le cas sur Arduino pour l'instant !
Je n'ai pas été chercher si il y avait des solutions ou des mises à jours de ce côté, car le programme est fonctionnel ! Je promet que je m'y remet bientôt et que je reviens avec une solution, mais pour l'instant, je suis concentré sur le HUD. J'ai commencé depuis quelques jours et les résultats sont prometteurs ! J'AI UN VRAIS HUD A LA MAISON !
Grome88 a écrit :Salut Myoda, je suis également super emballé par les projets arduino ! Ton programme est génial.
Pense tu qu'il est possible d'utiliser des arduino pour connecter les entrées interrupteurs ?
Envoyé de mon iPhone en utilisant Tapatalk
F4toArduino fonctionne comme F4ToPokeys ! L'interface vas pour l'instant dans un seul sens ! PC --> Arduino !
Pour faire l'inverse, il faut un système de "dialogue" entre le pc et la carte avec un truc du genre "baton de parole" pour éviter les collisions d'infos !
Pour l'instant, je ne me suis pas du tout intéressé à cet aspect pour une raison simple : la carte Pokeys le fait déjà très bien le job (En dehors des matrix qui m'ont fait pété un câble
! )
En revanche, j'ai reçu une carte Raspberry Pi 3 et je vais commencer à orienter mes recherches avec ! C'est un mini ordinateurs très puissant, qui permettra d'échanger avec le pc principal des infos ! il existe plein de chieds pour ca ! Le souci, c'est que c'est pour linux ! et Falcon 4 jusqu'à nouvel ordre n'est pas compatible, ou du moins on peux pas lancer d’exécutable !
Poker a écrit :Salut Myoda,
En effet après ta petite modif les moteurs reprennent vie ! Cool..
Merci
Super content que ça marche ! n'hésitez pas à me faire remonter d'autres infos !