mardi 3 octobre 2017

Ecran tactile pour PLC.

Depuis presque deux ans maintenant, j'utilise des écrans tactiles fabriqués en Chine, qui ont l'avantage par rapport à d'autres solutions, d'être très facilement programmable. Cependant ce type d'écran présentait plusieurs problèmes. Les premières versions ne disposaient pas de l'heure sauvegardée. Le tactile était de type résistif, donc assez peu pratique à manipuler, ou en tout cas interdisant les objets affichés de petite taille. Récemment, le fabricant à amélioré le sujet en proposant plus spécialement un écran de 7 pouces, de type capacitif, avec heure temps réel sauvegardée, présenté dans un boitier qui n'est pas inélégant :


Reste quand même quelques caractéristiques techniques qui contraignent un peu l'utilisation de ce type d'écran. La première contrainte concerne l'interface de communication qui se trouve être exclusivement de type TTL 5V. Il est donc impossible de raccorder ce type d'écran directement à un PLC, notamment par l'intermédiaire d'une interface standard RS485.

Le deuxième problème vient de la façon dont réagit cet écran, et notamment du format des informations bidirectionnelles. Elles ne répondent à aucun format standard comme le protocole Modbus par exemple, et est totalement propriétaire.

Dans quel cas utiliser ce type d'écran alors? Dans un premier temps il est tout à fait possible d'envisager une connexion à un automate de type Controllino :


Ce type d'automate se laisse facilement programmer en langage 'C', et est donc tout à fait capable de gérer directement des chaines de caractères, dialecte utilisé par l'écran. Ce type de configuration est particulièrement adaptée à l'automatisation et/ou le contrôle d'habitations ou de petits bâtiments. Que manque-t-il alors pour connecter ces deux appareils? Tout simplement une interface de communication de type TTL/RS485.

Le problème étant posé, il est dès lors assez simple d'établir les besoins minimum pour l'interface à réaliser :

- Le premier sera de convertir la nature des signaux série TTL/RS485.
- Le deuxième consiste à en profiter pour permettre l'adaptation de la vitesse de communication.
- Le troisième : fournir une alimentation régulée et relativement généraliste pour permettre une alimentation sans véritable contrainte.

Les solutions adoptées :

- Utilisation d'un convertisseur dédié permettant l'isolation du bus RS485.
- Utilisation d'un processeur offrant une adaptation simple de la vitesse de communication par rapport aux contraintes du terrain, sans avoir à reprogrammer l'écran.
- Utilisation d'une alimentation à découpage interne (7 à 26V en entrée), en mesure de fournir l'alimentation à l'écran ainsi qu'à la carte d'adaptation.

Et cela se présente comment?
Comme ceci :
Carte prototype
Il s'agit d'une carte prototype ou les composants sont soudés à la main, raison pour laquelle le design est très aéré. Un produit industrialisé devrait pouvoir occuper à peine la moitié de la surface actuelle.

Il y a un peu plus d'un an, j'avais réalisé le même type de carte, de plus compatible Arduino, dont l'avantage était d'être programmable, mais l'inconvénient, donc, de devoir être programmée par l'utilisateur :


Dans cette nouvelle version, le programme sera développé directement avec l'outil Atmel (Microchip maintenant), et gravé une fois pour toute dans la puce.

Il ne reste plus qu'à effectuer le travail de programmation de la nouvelle carte, et à tester le tout avec l'écran et l'automate Controllino.

A suivre...

jeudi 21 septembre 2017

AMIGA32

Le cas Amiga : je me souviens qu'au début des années 1990 il m'arrivait d'acheter une revue dont les sujets principaux étaient les systèmes informatiques dits 'alternatifs', qui avaient fait le bonheur de ma génération jusqu'à ce que le terrible PC écrase tout. Dans cette revue on y parlait de machines comme la série Next, de systèmes comme le BeOS, et évidemment des errements de la marque Amiga.



J'ai du cesser de rêver à ces machines accessibles vers 1993 lorsque que la saga Commodore fût définitivement morte. De toute ces belles (et parfois de vraiment moins belles) machines de la décennie 80, il ne reste plus aujourd'hui beaucoup de sujets actifs. Il existe bien quelques recréations de ZX80-ZX81, de Spectrum, de MSX le plus souvent en FPGA, mais pas grand chose de plus.

Des deux ordinateurs 13/32 bits de l'époque l'Atari ST eût sa petite heure de gloire à la fin des années 2000 avec la machine Suska, dont le firmware est toujours mis à jour :

https://www.experiment-s.de/en/boards/suska-iii-t/

Et plus actuellement le M.I.S.T. que je possède et qui fonctionne très bien, édité par LOTHAREK :

http://lotharek.pl/product.php?pid=186
Ces deux machines fonctionnent avec des émulation du processeur d'origine, à savoir un 680x0 quelconque et la majorité des périphériques, à l'intérieur d'un FPGA. La compatibilité avec le matériel d'origine est alors très élevée.

Une autre voie a été prise par le projet FireBee, débuté en 2008, qui a consisté à créer une machine 'compatible' avec l'Atari d'origine, en partant d'un processeur ColdFire MCF5474 capable d'émuler les instructions du 68000 d'origine, mais en impliquant quand même de grosses modifications logicielles :

http://firebee.org/fb-bin/index?lng=FR

J'ai pu assister à une démonstration de cette machine grâce à Vincent Rivière, développeur logiciel de la machine, qui en possédait un exemplaire. J'avais été très impressionné par le travail effectué. La machine est relativement chère et la partie soft est toujours activement en cours de développement. Il s'agit donc plus d'une machine pour gros passionnés de la programmation que d'un matériel apte à rendre de suite quelques services.

Ce sont les trois machines que je considère comme actuelles, naviguant dans la sphère de l'ancien ATARI ST.

Et à propos de l'Amiga? J'ai bien entendu parler des machines crées dans les années 90 et début 2000, mais n'ai jamais vraiment porté attention à ces réalisations. Hormis le Minimig dont j'ai entendu parler il y a quelques années de cela, pas grand chose.

Hors il semblerait que les choses changent actuellement de façon très dynamique, particulièrement grâce à l'entreprise Applo Accelerators, fabriquant des cartes accélératrices Vampires :

http://www.apollo-accelerators.com
Ces cartes accélératrices sont disponibles pour A600 et A500, avec une version A1200 prévue, et aussi et surtout, une version autonome qui rassemblerait tout le hard d'un Amiga sur une même carte, il s'agirait de la Vampire V4 :


Je n'ai pas tout suivi l'affaire Amiga mais il me semble que l'aspect logiciel n'est pas en reste non plus. Et vues les démos que sont capables d'effectuer ces cartes, il est légitime de penser que l'on se trouve en présence d'un vrai eco-système sur base Amiga.

Alors si vous souhaitez en savoir plus, il pourrait être intéressant de participer à l'évènement Amiga 32 qui se tiendra à Neuss en Allemagne le 28 octobre 2017 (j'ai déjà eu l'occasion dévoquer cet évènement ici ) :


Pour se procurer un billet, c'est ici : http://www.amiga32.de

Physiquement ca se trouve ici :


Cette fois, je me laisserais bien tenter ;-)

mercredi 20 septembre 2017

Recreating the Sequential Circuits Prophet VS.

Comme le titre le laisse à penser, j'ouvre ici un billet dont le sujet est la recréation totale du synthétiseur de Sequential Circuits, le Prophet VS.

Pourquoi? Parce que le Prophet VS est une machine assez intéressante. Parce que j'ai toujours estimé qu'elle n'avait pas été très bien conçue et que le concept pouvait 'sonner' un peu mieux. Parce que j'ai étudié il y a quelques années la faisabilité de la mise en FPGA de l'ensemble de la carte mère du Prophet VS, et que le résultat obtenu était pertinent. Que finalement, cela peut aussi être bien de mener à terme un projet qui m'a déjà occupé un bon paquet d'heures. Quant à faire mieux que les développeurs de l'époque chez Sequential Circuits : a voir...

'THE' Prophet VS

Le travail déjà effectué à consisté à implémenter dans une carte à base de FPGA, l'ensemble de la carte mère du VS :

La carte mère du Prophet VS.
Absolument tous les composants de cette carte sont émulés, sauf la gestion du clavier. Je n'ai d'ailleurs pas l'intention de m'attaquer à la gestion du clavier du VS sachant que je projette d'élaborer une version 'desktop' de ce synthétiseur.

Lors de mon étude précédente, je me suis arrêté à celle du circuit 'custom' responsable de la génération des formes d'ondes des oscillateurs. Je viens donc de m'attaquer à ce sujet important, car une fois ces quatre circuits 'décodés', il deviendra possible d'intégrer absolument toute la partie numérique de ce synthétiseur dans un gros circuit de type FPGA. Cela va encore demander un certain travail...

28/08/2017 : après avoir ressorti l'analyseur logique et effectué une série de tests afin de se faire une première idée de la façon dont fonctionnent les circuit custom de ce Prophet VS, il est temps de se préparer un circuit d'interface pour permettre le raccordement d'une carte FPGA sur la carte de synthèse du VS.
Parce que le gros problème de ce type de machine Vintage, c'est que tous les circuits numériques fonctionnent en 5V. Alors que les entrées/sorties des FPGA actuels sont, au mieux, en 3,3V. Cela peut poser des problèmes lorsqu'il s'agit de faire 'rentrer' un signal de 5V sur une entrée qui ne supporte QUE 3,3V max.
Le circuit étudié se contente de tamponner tous les signaux d'un circuit CUSTOM en 3,3V avec une connectivité facilitée pour le raccordement à une carte FPGA :


Ce circuit se positionnera directement à la place d'un des circuits CUSTOM sans avoir quoi que ce soit à modifier de la carte de synthèse, tout en conservant une bonne intégrité des signaux.

Et en attendant de recevoir ce circuit imprimé, il est temps de s'occuper du traitement audio qui suit directement ces circuits CUSTOM, à savoir la conversion numérique/analogique, les VCAs d'onde et le démultiplexage analogique final des signaux audio. J'ai quelques idées pour améliorer et simplifier toute cette partie avec des composants modernes. Il me faut tester la viabilité de ces idées...

lundi 11 septembre 2017

A la découverte de l'automate UniPi Neuron S103-G (en live, c'est plus dynamique...)

Depuis quelques mois maintenant, des automates programmables développés sur une base Arduino sont disponibles sous diverses formes. Le phénomène se propage actuellement sur la technologie Raspberry Pi 3, à la faveur du portage par CODESYS de la norme 61131-3.
 
Le sujet de ce billet porte donc sur la mise en œuvre d'un PLC à base de PI 3 comportant de plus un module GSM. Le but en étant l'application à un cas concret.

La première chose à faire consiste donc à commander et à recevoir un PLC de type S103-G de chez UniPi :

Fraichement arrivé!
Fraichement déballé...
Sera-t-il aussi performant que le n°007?
Le n°4 de la ligne de production. N'est-ce pas un peu risqué? Pour le savoir, il ne reste plus qu'à rendre cet automate opérationnel. Pour cela, il est nécessaire tout d'abord de copier l'image du système Neuron sur une carte SD, puis de placer cette carte SD dans le S103G. L'opération est simple, elle consiste à récupérer l'image sur le site D'UniPi à cette adresse (version UniPian-Neuron-OS-2017-08-30), puis à la copier après l'avoir préalablement dézippée, sur une carte SD à l'aide du logiciel Win32 Disk Imager.

Carte SD avec OS validé.

Jusqu'ici, les opérations effectuées sont totalement triviales. A titre d'information, une version plus 'amateur' de ce concept peut être trouvé à cette adresse :

http://alltwincat.com/codesys/raspberry-pi-plc/
Une fois le S103G démarré sur sa carte SD, il reste encore à s'y connecter en réseau parce que la sortie HDMI n'est évidemment pas accessible. SSH est actif par défaut sur les distributions Raspbian dont semble être issu l'OS UniPian d'UniPi. Par contre, le protocole de boot par défaut utilise le DHCP via l'interface Ethernet. Quand tout l'environnement réseau fonctionne en WiFi, comme c'est le cas chez moi, la seule solution consiste à connecter ce S103G directement sur un des ports Ethernet du routeur réseau. Une fois cette connexion réalisée, l'accès au système est de suite possible en SSH avec le login root:unipi.

Avec en prime l'adresse MAC de la bête, afin de la configurer en statique dans le DHCP.
Passons aux choses sérieuses...

Pour programmer ce type d'automates il existe plusieurs possibilités. A la limite, des scripts en Python pourraient 'suffire'. Je pense néanmoins qu'il est plus judicieux d'utiliser l'environnement de programmation Mervis fourni par le constructeur, et compatible avec la norme 61131-3.  Il y a deux années de cela, j'ai eu l'occasion de programmer des automates à base de processeurs ARM qui utilisent cette norme de programmation et d'en constater la facilité de mise en oeuvre :

Configuration quelque peu artisanale, mais efficace!

Mervis fonctionne de la même façon que la solution Codesys. A savoir un runtime temps réel implémenté sur l'automate qui exécute le programme édité et 'compilé' sur un IDE fonctionnant dans mon cas sous Windows. Pour implémenter une solution Mervis, il convient donc de télécharger et d'installer sur la SDcard de l'automate, l'image du système contenant le runtime Mervis. Une fois fait, un ssh à l'adresse IP du PLC permet de se connecter au système Linux embarqué de la même façon que cela fût le cas avec le système Linux 'standard'.

La ou cela devient intéressant, c'est qu'une fois le logiciel de développement installé sur le PC, il devient possible de se connecter, via ce logiciel, directement au Neuron S103-G. Il 'suffit pour cela de demander l'ajout d'un contrôleur :


Et d'attendre que la recherche automatique ait eu lieu pour que l'automate soit reconnu depuis le réseau, wifi dans mon cas :


Une fois l'automate sélectionné et cette fenêtre validée, l'IDE Mervis est en mesure de montrer les détails du PLC nouvellement détecté :

Et voilà!
Allez, je renomme ce PLC en S103-G. Passons à l'étape suivante qui va consister à écrire le premier 'Hello World', à savoir faire clignotter une des sorties de ce PLC.

Pour l'instant le logiciel, bien qu'ayant reconnu le type d'automate en ligne, ne connait absolument rien des périphériques disponibles dans ce S103-G. Or, tous les périphériques sont accessibles VIA le protocole ModBus. Il est donc nécessaire de déclarer ce type de bus au sein de l'environnement de développement afin qu'il puisse converser normalement avec l'automate. Cela se faire de la façon suivante :


Puis dans le panneau propriété, de sélectionner le protocol ModBus. J'en ai aussi profité pour modifier le nom du 'channel' en l'appelant TcpModbus. A remarquer que cette liaison ModBus se fera sur le réseau Ethernet de la Pi3.


Ça n'est pas fini. Alors que le type d'automate a été déclaré précédemment, cette déclaration ne concerne pas la définition de ses périphériques qui demeurent encore inconnus par le logiciel de développement. Une procédure 'purement administrative' doit donc avoir lieu, qui consiste à déclarer tous les périphériques sous forme de variables utilisables dans les futurs programmes. Pour cela, il faut déclarer le type de 'device' attaché au bus ModBus, ce qui aura pour effet de générer les variables d'entrées/sorties associées :

Dans mon cas, il s'agit d'un modèle S10x.
Un fois ce 'device' de type S10x reconnu, il suffit de demander l'auto-génération des variables pour obtenir la liste de toutes les entrées/sorties disponibles dans l'automate :


Dans l'onglet 'View' du logiciel, il est possible de demander le panneau 'Variables Browser', pour obtenir comme on peut s'en douter, le panneau avec toutes les variables déclarées :


On est presque au bout. Je vais faire clignoter la LED 01 de l'automate, matérialisée par la variable $Neuron S10x_ULED_1.01$ dans le fichier des variables globales générées lors des opérations précédentes dans la rubrique 'generated' du type de variables 'Globals' du programme que j'ai nommé 'Mervis-Test' dans la partie 'Executable projects' de mon premier projet 'Mervis-Test'. L'esprit humain adore la hiérarchie ;-) ...

Dans ce projet, j'ai donc créé un source principal nommé 'Main'. Pour un début, je n'ai pas cherché l'originalité. Cela se fait facilement de la façon suivante :


Dès lors, il est possible de commencer à rentrer du code dans la partie d'édition dédiée. Le code est extrêmement 'complexe' puisqu'il s'agit de faire clignoter une seule LED à une fréquence d'à peu près le Hertz :

PROGRAM Main

VAR
   Delay : TON;
END_VAR

    Delay(IN:=TRUE, PT:=T#1S);
    IF NOT(Delay.Q) THEN
           RETURN;
    END_IF;

    Delay(IN:=FALSE);
    IF(hw.$Neuron S10x_ULED_1.01$ = FALSE) THEN
        hw.$Neuron S10x_ULED_1.01$ := TRUE;
    ELSE
        hw.$Neuron S10x_ULED_1.01$ := FALSE;
    END_IF;

END_PROGRAM

Je ne rentre pas dans les détails, notamment de la variable de type TON. Tout ce qui est écrit ici se trouve sur le Net. C'est l'avantage du langage à la norme 61131-3. Et pour plus de référence, il 'suffit' de rechercher les informations disponibles sur la toile avec le mot-clé Codesys puisque c'est l'entreprise de 'référence' en ce qui concerne ce langage. La compilation de ce source se passe sans problème.

Est-ce suffisant pour que cela fonctionne? Et bien NON!

Il est encore nécessaire de déclarer cette tâche au sein de l'automate en lui affectant un temps de fonctionnement. Il serait possible de discuter sur les raisons de cela, Il faut juste prendre conscience que sur un bus de type ModBus c'est toujours le Maître qui demande des 'choses'. Un périphériques ne peut JAMAIS interrompre un programme maître. Du coup, pour savoir ce qui se passe sur des entrées, par exemple, la seule solution consiste à faire du pooling sur l'entrée surveillée. C'est tout simplement cette notion de pooling, ou de fausse interruptions, qui est implémentée de la sorte de façon généralisée dans les automates. Cela reste évidemment extrêmement moins efficace que de la vraie gestion d'interruption processeur, mais c'est ainsi...

Un double 'click' sur l'automate permet de changer les icônes du bandeau supérieur du logiciel pour voir apparaître celui des Tâches. Il convient dès lors d'en ajouter une, en renseignant le programme concerné et le temps machine alloué, même si ce programme ne gère absolument aucune entrée :


Un 'clik droit sur l'automate pour demander un 'Full run' dans la rubrique 'PLC Operation' permet, après avoir déployé la solution, de démarrer 'réellement' la tâche et de constater le clignotement de la LED X1 sur le joli boitier bleu: magique!

A noter que lors de la mise sous tension du PLC, le programme démarre automatiquement après seulement quelques secondes de boot de la carte Pi3. On s'en serait douté, mais autant le confirmer.

13/10/2017 Bon, une LED qui clignote sur la face avant de l'automate c'est bien, et quoi d'autre?

Un des intérêt de cet automate de chez UniPi, c'est qu'il possède en interne un module GSM. J'ai choisi cet automate aussi pour cette raison parce que l'application que je développe doit prévenir en cas de problème. Un moyen 'simple' de le faire est donc de profiter de l'infrastructure réseau du téléphone mobile.

Le problème (le monde technique n'est QUE problèmes. Mais les résoudre est un vrai challenge, n'est-ce pas, surtout quand la réflexion profite à soi même, et non pas à Micro-Logiciel!), c'est qu'il n'y a absolument aucune connexion entre ce moduler GSM et l'automate.
Impossible donc de disposer d'une sortie type relais de l'automate, propre à déclencher quelque chose sur le module téléphone. En fait, il existe une solution, simple dans l'idée, mais un peu compliquée à mettre en œuvre.

Comme l'automate est connecté avec la carte Pi3 par le biais d'un liaison de type TCPModBus, et bien il 'suffit' de la même façon, d'implémenter sur le système de la Pi3 un client ModBus en TCP qui déclenchera le contrôle du module téléphone, qui lui, est connecté par port série sur la carte Pi3.

L'idée est simple, reste à la mettre en pratique. Pour ce faire, je vais d'abord effectuer des tests à l'aide d'un client démarré sur le PC de développement, raccordé en WiFi au réseau sur lequel est connecté l'automate.

La première étape consiste donc à déclarer un client ModBus par liaison TCP dans l'environnement de l'automate en ajoutant en Device dans la liaison TCPModBus comme ceci :



Contrairement à ce qui a été fait précédemment, il ne faut pas installer quoi que ce soit à partir de la 'Library Device' parce que, forcément, mon client ModBus n'a jamais été déclaré ou que ce soit étant donné que je le crée quasiment en live.

Voici les propriété que j'ai configuré pour ce client ModBus :


Pas grand chose de vital mis à part l'adresse IP du client, ainsi que le port réseau d'écoute. Le reste des paramètres se comprend aisément, tellement, que je n'ai touché à rien d'autre, hormis le nom.
Ah oui, pourquoi installer un client ModBus et non pas un Serveur? Parce que c'est l'automate le patron, c'est lui qui VA lire ou écrire à l'extérieur.

Une fois le client déclaré, il faut maintenant déclarer les registres de ce client auxquels il va falloir accéder, parce qu'il n'existe aucun fichier de déclaration pré-établi.

Première chose à faire, il faut déclarer en fait le type de variables auxquelles l'automate devra accéder. J'ai choisi de déclarer un groupe de variables de type 'Single Coil', autrement dit, un pool de relais dont j'en déclencherai un pour indiquer une action à effectuer vers le module téléphone.

Un 'clic' droit sur le Client ModBus permet d'ouvrir l'éditeur et d'accéder à l'ensemble de ce qu'est 'censé' contenir le client en terme de registres, d'entrées/sorties etc etc...


Et la page des ressource matérielle du client :


Je triche un peu, normalement le contenu de cette page est vide à la création. Mais ici, on voit le Group de ressources qui a été créé, et quelle est la ressource utilisée dans ce groupe.

'Clic' droit sur cette fenêtre permet d'accéder à la création du groupe de ressources :


Puis la sélection du Groupe permet d'en configurer les paramètres :


Donc, je déclare un 'tas' de variables, en fait il y en aura une, mais de type Byte, qui commencera à l'index n°1 et qui sera considérée comme un 'paquet' de relais qui accepteront simplement d'être 'écrits', toutes les 100ms. Le choix de la fréquence est important parce que pour mon test, je vais évidemment insérer la mise en ON puis OFF de la variable à l'endroit du code ou je mets la LED du panneau avant de l'automate en ON puis en OFF. Et comme je le fais toutes les secondes, une écriture toutes les 100ms me donnera donc au maximum un retard d'un dixième de secondes à l'actualisation de la variable du client ModBus par rapport à l'actualisation de la LED de l'automate. Vous suivez toujours?...

Ceci fait, la même manipulation permet de déclarer... la variable finale, cette fois ci en déclarant un 'Data Point' :



Il reste encore à positionner les propriétés de cette variable pour pouvoir l'utiliser :


Les paramètres les plus importants sont le groupe auquel appartient cette variable, ici le groupe 'Group' (comme c'est original!), le type de variable, j'ai choisi une sortie de type bit, donc 'bool'. Il est important de renseigner l'endroit ou se trouve la variable dans le paquet de huit 'bool' déclarés, à savoir la première position, avec le paramètre Write Offset Gap, puis d'indiquer la taille totale de la variable à écrire lors du changement d'état de la variable booléenne, ici un octet. Parce-que ModBus ne sait pas traiter des données de 1 bit, mais à minima des octets. Il suffira donc d'envoyer l'octet ou se trouve la variable à modifier vers le client.

Et ça n'est pas fini. Il faut maintenant générer la variable globale associée à cette variable pseudo physique. Simple, il suffit de demander l'auto-génération de la variable :


pour se retrouver avec la nouvelle variable globale de l'application :


C'est fait, nous voici avec une bien jolie variable. Qu'il suffit maintenant d'utiliser dans le programme initial :


J'utilise toujours le même programme qui consiste à faire clignoter une LED de la face avant de l'automate. Cette fois, je fais aussi clignoter la sortie virtuelle associée à la nouvelle variable. Bien évidemment, au redémarrage il ne se passe pas grand chose sur l'automate. Et pour cause, je suis censé faire clignoter une sortie sur un automate quelque part sur le réseau.

Or donc, il reste encore à démarrer un client sur le PC portable relié en WiFi au réseau. J'utilise l'esclave pyModSlave :


Après avoir configuré cet esclave ModBus pour fonctionner en TCP à l'adresse IP et au PORT adéquat, je peux constater qu'effectivement la première variable de type 'Coil' c'est à dire de type  relais, ou tout simplement de type 'tout ou rien', clignote en rythme avec la LED de l'automate, à quelques dixièmes de secondes près :


Bien que l'image soit statique par essence, le seul bit à '1' correspond bien à la variable positionnée toutes les secondes par l'automate qui se situe... à l'autre bout de l'habitation : cool, voir carrément fun! (chacun ses plaisirs). A remarquer que l'adresse IP et le PORT correspondent à ce qui a été positionné sur le logiciel de l'automate pour créer le client virtuel. Les 'packets' indiquent en fait les trames ModBus valides qui ont été reçues. Par contre le client n'affiche pas un octet de variables, mais 10 bits. Je n'ai pas creusé la question parce que cela n'a aucun importance (pour le moment).

Et maintenant? Il ne s'agit la que d'un test de faisabilité. Il me faut maintenant implémenter un client ModBus directement sur l'automate, puis m'en servir pour déclencher un script de gestion du module GSM afin qu'il y ait bien émission d'un SMS lors d'un évènement surveillé. Je ne suis pas au bout de mes peines...


lundi 21 août 2017

Drumulator : l'heure du remontage!


Cela fait un peu plus d'un an que je possède cette Drumulator. Je l'ai achetée en région parisienne pur un prix modique car elle présentait quelques défauts, notamment la présence du message 'bad' au démarrage. Ce message n'est pas bien grave puisqu'il indique juste que la batterie interne de sauvegarde des RAM statiques est arrivée en fin de vie. La réparation ne devait donc pas poser trop de problème.

J'ai déjà eu l'occasion de présenter cette boit à rythme. Il y a à peine plus d'un an, j'ai effectué quelques dépannages et expérimentations ici, et créé un outil de débogage basé sur l'émulation des bus d'un Z80 sous la forme d'un 'composant' compatible Arduino, avec la version définitive ici, en milieu d'article.

Version définitive à gauche, version de test à droite.
Je n'avais pas remonté cette machine parce qu'une personne rencontrée lors du MakerFaire de Nantes en juillet 2016 m'avait proposé de participer à une manifestation sur le thème du rétro et du hack. Bien évidemment, cette personne ne m'a jamais recontacté. J'ai donc décidé de terminer mon travail sur cette boîte.

Digression : Je n'ai pas participé au MakerFaire de Nantes 2017. Cela représente beaucoup de travail de préparation et des bénéfices quasiment nuls malgré un nombre incroyable de personnes passées me voir l'année dernière. En fait le principe est simple, il s'agit de travail offert aux organisateurs, seuls à tirer les bénéfices de votre présence. Et pour être plus clair, travail fourni pour la très grande cause du rayonnement de Nantes, dans le cas présent. Une fois ça va, pas deux! Fin de digression.

Le changement de pile a effectivement réglé le problème du message d'erreur au démarrage de cette Drumulator, après avoir toutefois effectué la procédure de RESET des mémoires. Tout s'est bien passé au remontage, sauf que le réel problème de cette machine est apparu lors des premières tentatives d'utilisation. Tout fonctionnait SAUF le potentiomètre de data. Les valeurs qu'il permettait d'obtenir allaient de 45 à 64 pour ce qui était du réglage du tempo, et ne permettaient pas de modifier les valeurs des volumes des différents sons!

Une petite étude du schéma de principe de la machine permet de cerner rapidement le problème :

Une façon possible de faire de la conversion analogique/numérique.
 Surtout quand on constates ce qui a été installé en guise de réparation :


Et oui, la réponse au problème est tout simplement écrite : 10K. Le potentiomètre utilisé certainement pour remplacer celui d'origine défaillant est un 10KOhms en lieu et place de ce qui devrait être un 100KOhms, comme indiqué sur le schéma de la machine. Et de suite il est possible de comprendre la façon dont la personne qui a (tenté d'effectuer) effectué la réparation s'y est prise.

Et pour commencer, tentons de trouver le même type de potentiomètre rectiligne en version 100KOhms. Si vous y arrivez, faites-moi signe. J'ai passé un temps suffisamment long sur Internet pour arriver à la conclusion que ce type de potentiomètre est introuvable aujourd'hui. Le temps passé à cette recherche, à lui seul, rend la réparation de cette Drumulator absolument pas rentable! En version 100KOhms, cela devait déjà être compliqué à trouver à l'époque, même si je ne sais pas quand à eu lieu cette réparation!

L'auteur de cette 'tentative' de réparation a du se dire que cela ne faisait rien et que ce 10KOhm fonctionnerait quand même. Après tout, ça n'est pas pour le courant consommé qui passe de 50µA à 500µA sous 5V. Certes, sauf que la méthode de mesure de la valeur de ce potentiomètre n'est pas effectuée par un convertisseur CAN 'habituel' qui relèverait la tension présente à son entrée, mais par le calcul du temps que met un condensateur à se charger. Et qui dit charge de condensateur dit quantité d'énergie, et donc courant de charge!

Pour faire simple, voici comme cela fonctionne : le circuit intégré 74ls221 est un monostable. C'est à dire qu'une impulsion sur une patte permet de changer l'état de sortie d'une autre patte pendant... un certain temps, puisque c'est un monostable et non pas un bistable. Le 'certain temps' est généré par
le condensateur chargé à travers une résistance. Il est possible de déterminer la durée de ce temps de basculement à partir du datasheet d'un des fabricants de ce type de circuit.

Le fonctionnement final se déduit donc très facilement : une impulsion négative sur la patte '1' du 74ls221 fait instantanément passer sa sortie Q (patte 13) à '1'. Cette sortie Q reste à '1' le temps de la prise en compte de la charge du condensateur, et revient toute seule à '0'.

Comme l'entrée de déclenchement /A du 74ls221 est générée par le programme de la Drumulator, le programme sait exactement le moment du début du déclenchement (remise à zéro du registre de comptage du CTC, voir plus bas). Pour trouver la fin du déclenchement, il suffit de surveiller le passage à '0' de la sortie Q du 74ls221. C'est le rôle dévolu au Z80 CTC qui est un timer/compteur. Ce composant est capable de compter des impulsions arrivant sur sa patte 21 et de tenir à jour un registre interne dont la valeur sera le reflet du nombre d'impulsions d'horloge comptées pendant tout le temps que le condensateur aura mis à se charger, et donc sera le reflet de la position du potentiomètre, qui conditionne le temps de chargement du condensateur. A noter que la sortie Q du 74ls221 ne fournit pas les signaux d'horloge à mème de faire compter le CTC, mais valide le passage de l'horloge système vers le CTC via la porte NON-ET 74ls00.

Voilà, ça n'est pas compliqué. Encore faut-il se donner la peine de comprendre un peu le fonctionnement avant de se lancer dans une modification hasardeuse!

Que m'a-t-il fallu faire pour 'rattraper' le coup? C'est assez simple en fait. Puisque je ne pouvais pas augmenter la résistance de potentiomètre de 10KOhms à 100KOhms, il suffisait de multiplier la valeur de condensateur C77 par 10. J'ai donc placé deux condensateurs de 3200pF en parallèle entre les pattes 14 et 15 du 74ls221, pour une valeur finale de 6400pF + les 680pF d'origine.


Je triche un peu, ça n'est pas si simple que cela parce qu'il faut vérifier que les valeurs des composants restent dans les possibilités du 74ls221. Chance, c'était le cas!

Pour compléter, j'ai aussi du changer la résistance en parallèle sur le potentiomètre. Elle est censée diviser la valeur finale du potentiomètre de façon non linéaire. De 500KOhms à l'origine, je l'ai fait passer à 50KOhms (valeur divisée par 10 par rapport à l'origine, comme celle du potentiomètre). Dans les faits, j'ai placé deux résistances en série pour un total de 55KOhms. Les 10% supplémentaires me permettent d'atteindre la pleine échelle à coup sûr. A noter que la progression résultante du potentiomètre avec cette résistance en parallèle n'est donc pas linéaire. L'idée étant de linéariser la progression "apparente" de la charge du condensateur, sachant que la courbe de charge d'un condensateur, justement, est exponentielle et non pas linéaire. J'ai aussi du rajouter une résistance ajustable en parallèle de celle de 2KOhms d'origine pour régler plus facilement le zéro du potentiomètre. Une fois ces opérations réalisés, j'obtiens des créneaux de charge de 2,5% à 18,5% par période me permettant d'atteindre la valeur 0 pour le réglage du volume, et la valeur maximale de 240 pour le tempo par exemple.

Potentiomètre en butée à gauche.

Potentiomètre en butée à droite.
Les modifications effectuées, j'ai remonté la machine et ai procédé aux tests finaux en écoutant pour la première fois cette boite à rythmes :



J'ai passé l'OS de cette Drumulator à la version 3, avec la prise en charge de la liaison M.I.D.I. entrante. Il ne me reste plus qu'à mettre en place la petite interface M.I.D.I. standard d'entrée. A moins que j'en profite pour y implémenter un module de conversion de ma nouvelle interface M.I.D.I.

Mais pour l'heure, je remonte l'Emulator I que j'ai acquis il y a aussi un an. Fonctionnel, mais qui m'a généré une superbe fumée âcre de condensateurs quelques minutes après sa mise en marche. Je me dis que cet Emu 1 sera le parfait compagnon de cette Drumulator!