[TUTO] Pilotage de Ledstrip adressable style "Teensy" via WEMOS D1 PRO

Bonjour,

Est-ce que vous sauriez où trouver le code source modifié du dof?

J'aimerais comprendre ce qui a été modifié pour qu'il fonctionne avec la wemos pour éventuellement reporter la modif sur les dernières versions du dof, voire faire une pull request pour que cette modif soit dans la branche main du dof.

Aussi, quelle est la version du dof qui correspond à la dll modifiée ?

Merci

Le dog version mjr est a jour...

Super merci !!! Ce serait bien de mettre à jour le tuto

Salut à tous,

Ma wemos est correctement flashée, affiche bien les 3 couleurs au démarrage, le dof affiche cette erreur :

Code:

2024.10.06 09:31:48.706 Initializing ComPort COM14 with these settings :
2024.10.06 09:31:48.706 BaudRate 9600, Parity None, DataBits 8, StopBits One, R/W Timeouts 200ms
2024.10.06 09:31:48.706 Handshake Timings : Open 50ms, Loop Start/End 20/50ms, DTR enable False
2024.10.06 09:31:49.424 EXCEPTION: Could not put the controller on com-port 'COM14' into the commandmode. Will not send data to the controller.
2024.10.06 09:31:49.424 EXCEPTION: Thread: TeensyStripController LedStripController updater thread
2024.10.06 09:31:49.479 TeensyStripController LedStripController updater thread  has reconnected to TeensyStripController LedStripController.
2024.10.06 09:31:49.580 EXCEPTION: TeensyStripController LedStripController updater thread  could still not send update for TeensyStripController LedStripController: Comport is not initialized. Thread will quit.
2024.10.06 09:31:49.580 EXCEPTION: Thread: TeensyStripController LedStripController updater thread
2024.10.06 09:31:49.580 EXCEPTION: Message: Exception --> Comport is not initialized
2024.10.06 09:31:49.580 EXCEPTION: Stacktrace:    à DirectOutput.Cab.Out.AdressableLedStrip.TeensyStripController.UpdateOutputs(Byte[] OutputValues)
2024.10.06 09:31:49.580 EXCEPTION: Stacktrace:    à DirectOutput.Cab.Out.OutputControllerCompleteBase.UpdaterThreadDoIt()
2024.10.06 09:31:49.580 EXCEPTION: Targetsite: Void UpdateOutputs(Byte[])

Je me demande s'il ne me manque pas l'étape décrite par Arnoz ici : Puis allez dans le gestionnaire de périphérique pour cocher cette case (Port settings, Advanced), je ne comprends pas comment accéder à ce panneau de configuration.


Merci pour votre aide !


Edit voici on dof log complet :
doflog

installe les drivers dispos sur la page produit, puis dans le device manager tu trouveras tout

Je pense avoir trouvé après un coup de chatgpt pour lui demander la vitesse par défaut d'un port serie en c# : 9600. 
Du coup j'ai reuploadé le code avec Serial.begin(9600);  sur la Wemos et paf le dof communique bien avec elle.
J'ai compris ceci avec le code par défaut et le moniteur série Arduino : la wemos répondait bien N sur l'envoie du 0 avec la bonne vitesse de sélectionnée.

Mais alors je me demande comment vous arrivez à la faire fonctionner de votre côté sachant que le code wemos de ce thread à la vitesse 921600  et le code de aetios50 à 2000000 de bauds de setup

Salut,

Un conseil, fais ce que préconise Arnoz.

J'ai eu exactement le même soucis la semaine dernière, même erreur dans le log du dof. J'avais fais un post [Vous devez être inscrit et connecté pour voir ce lien] d'ailleurs.

Après avoir installé les drivers de la weemos fourni par le lien d'arnoz, la coche "disable modem hand shake" apparaitra dans les settings de ton périphérique. Dans mon cas, avec les drivers que j'avais avant, cette coche n'etait tout simplement pas la.

Après tu n'auras plus de soucis, j'en suis quasi certain !

Au passage, étant donné qu'il y a des milliers d'infos sur quoi installer / dll différentes ou pas, etc : dans mon cas, j'ai pas eu de dll a modifier. J'ai bien l'impression qu'avec la dernière version du dof il n'y a plus de problème du genre "il faut une dll de remplacement". Ca me parait être de l'histoire ancienne ca !

Bonne fin de week end !

A priori la wemos communique désormais, je me demande quand même comment les vôtres communiquent alors que le baud rate du code de la wemos n'est pas le même que celui attendu par dof

Salut,

Ca fonctionne !!! 
Je n'ai pas eu besoin d'installer les driver cp3xx, ceux que j'avais installés fonctionnent : les cp2XX car mon gestionnaire de périphérique a bien un CP210x, je n'ai pas eu non plus besoin de désactiver le handshake modem et je me demande si augmenter les timeout sur l'outil d'arnoz évite de désactiver le handshake modem 

J'ai juste eu besoin de regénérer le cabinet.xml à partir de l'utilitaire Arnoz Tiny Tools, je n'ai pas fait de diff pour voir mon erreur d'origine. J'ai il me semble à l'époque changé quelques valeurs dans la partie communication (TimeOutMs 300, OpenWaitMs 300, HandshakeStartMs 100 et HandshakeEndMs 100).
Merci Arnoz pour ton utilitaire

Par contre je me pose toujours la question de savoir comment vos wemos communiquent avec un baudrate différent de 9600 sachant que le code c# du DOF ne change pas la valeur par défaut de l'attribut baudRate de l'objet SerialPort et qui s'attend donc à un baudrate de 9600 bauds 


Pour la blague j'ai cramé 73 LEDs hier car je les aies alimentés en 12v

[Vous devez être inscrit et connecté pour voir ce lien] :
Tant mieux si tu t'en es sorti avec ta wemos ...
... et mince pour tes leds ... dommage, au moment où tu allais pouvoir en profiter !
Mais bon, c'est vite venu des erreurs ! Moi aussi j'avais cramé une bande en soudant les câbles dans le mauvais sens !!!

C'est pas grave pour les led j'avais 5m qui traînaient depuis peut-être 10 ans

Salut [Vous devez être inscrit et connecté pour voir ce lien]

Sais-tu quelle est la raison de désactiver le modem handshake de la wemos ? Il est peut-être possible de fixer ceci directement dans le code de la wemos, ou dans un .ini, ça simplifierait le process

Salut

faut demander à Vroonsh, c'est pas moi qui bricole le driver, juste en faisant  ça ça marche, donc voila

Salut [Vous devez être inscrit et connecté pour voir ce lien] aurais-tu la réponse à la question que j'ai posée ci-dessus ?

Je suis passé recemment sur le DOF combiné 32/64 bits 
DOF R3 & LEDWIZ.DLL Updates (mjrnet.org)

ET suite à celà, j'ai moi-aussi eu le même message d'erreur :

Code:

[size=16]EXCEPTION: Could not put the controller on com-port COM3 into the commandmode. Will not send data to the controller.[/size]
[size=16]<...> [/size]
[size=16]2020.08.01 00:16:01.838 EXCEPTION: Message: Exception --> Comport is not initialized[/size]

J'ai bien galéré et j'ai finalement édité mon cabinet.xml et changé les deux lignes suivantes (passage de 100 à 200)

Code:

      <ComPortHandshakeStartWaitMs>200</ComPortHandshakeStartWaitMs>
      <ComPortHandshakeEndWaitMs>200</ComPortHandshakeEndWaitMs>

Et bien ça marche tout de suite mieux
Je pense que la wemos met "un peu trop de temps" à répondre et que le DOF la désactive

---

Sinon la mise à jour du DOF s'était bien passé, et tordons le cou une fois pour toute à cette légende, il n'y a plus besoin de DLL modifiée avec les versions récentes du DOF !

---

Et pour ceux qui ont encore des problèmes avec leur DOF dans popper ou VPX, je vous conseille d'abord de le tester en standalone. Donc à faire en version x86 puis x64 :
Cliquez sur DirectOutputConfigTester.exe, selectionnez votre globalConfig.xml, une table et sa rom et activez les effets, vos lumières doivent s'allumer. 
Si vos lumières ne réagissent pas, pas la peine de continuer, vérifiez vos fichiers de configuration et votre cabinet.xml

Si vos lumière réagissent, c'est le lien entre Popper/VPX et le DOF qui ne se fais pas. Et là ca dépend, ça dépasse :

- Pour VPX, le lien passe par le plugin du backglass. 
      Si vous n'avez pas de backglass server, ou un server en 32 et VPX en 64, on met à jour le backglass server
      Puis on vérifie bien les liens symboliques entre les repertoires plugin et plugin64 du b2s server

- Pour popper, le lien passe par la base de registre, et idem, il faut un DOF en 32bit si popper est en 32bit
Alors si vous avez enregistré plusieurs fois les DLL ou ne savez plus, toutes les chances pour que popper s'emmele les pédales et ne prenne pas la bonne version.
Pour vérifier, ouvrez regedit et accédez à :
Ordinateur\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{A23BFDBC-9A8A-46C0-8672-60F23D54FFB6}
Ouvrez InprocServer32, vous ne devez avoir qu'une clé comme ci-desous

[Vous devez être inscrit et connecté pour voir cette image]

Si ce n'est pas le cas, on supprime toute la clé {A23BFDBC-9A8A-46C0-8672-60F23D54FFB6}
Puis dans dof, on relance RegisterDirectOutputComObject.exe (une seule fois !) en prenant la version x86 à priori ou x64 selon sa version de popper

Voilà.. j'espère que ca aidera quelqu'un !

Content que ça ai marché également pour toi et effectivement on dirait que ça ne sert à rien de désactiver le modem handshake, augmenter le timeout suffit afin justement de laisser échouer le modem handshake

Salut [Vous devez être inscrit et connecté pour voir ce lien],

Est-ce que tu reproduis le fait de ne pas avoir besoin de tweaker le modem handshake en augmentant les timeout ?

perso je le desactive, si ça marche pour toi en modifiant les timeout, c'est tant mieux

Ok, c'était par curiosité et pour éviter une étape aux utilisateurs lors du setup

Bon tout fonctionne enfin ainsi que les 300 leds qui composent le flip.
C'était une connerie d'avoir mis tous les baudrates à 9600, le wemos se deconnectait aléatoire et ça ramait, je suis repassé à 200000 dans le firmwate ainsi que dans cabinet.xml.
Les temps de réponses sont parfaits et la wemos ne reboot plus aléatoirement.

Merci [Vous devez être inscrit et connecté pour voir ce lien] pour ton configurateur qui évite pas mal de maux de têtes pour générer ce satané cabinet.xml