Affichage des articles dont le libellé est I-Controllino. Afficher tous les articles
Affichage des articles dont le libellé est I-Controllino. Afficher tous les articles

samedi 21 octobre 2017

Ecran tactile pour PLC. Episode 2

Après la réalisation matérielle de ce type de projet, et les inévitables séances de débogage, vient le temps de la programmation. A noter que ce montage simple n'a présenté aucun défaut de conception, si ce n'est un petit souci que j'évoquerai plus bas.

Je n'ai pas souhaité rendre ce montage compatible Arduino, c'est donc avec l'outil d'Atmel, Studio 7, et le programmateur AVR Dragon que j'ai effectué la totalité la programmation. Rien de bien compliqué ici sachant que son rôle consiste 'juste' à transmettre des données reçues en RS485 avec une vitesse de 2400 à 115200 Bauds, à un écran 'intelligent' réglé à une vitesse de communication de 115200 Bauds. Le gros principe de l'application étant juste la gestion de buffers circulaires de mise en tampon des donnés.

Les premiers test ce sont effectué en situation presque réelle :


Un écran intelligent est connecté sur le module de conversion de vitesse et de type d'interface, ce module étant relié en RS485 à un automate Controllino. L'automate est alimenté par son port USB directement sur le PC de développement. Le module de conversion et l'écran sont reliés à une alimentation de 12V.


Le bouton de droite 115200 permet de configurer la vitesse de communication de l'écran à 115200 Bauds. Le bouton Display... permet d'afficher la valeur en cours du Baud rate. Plusieurs informations en provenance de l'automate en 19200 Bauds sont retransmises à l'afficheur en 115200 Bauds. Il s'agit de l'heure et de la date qui sont transmises au début de l'application, puis de la valeur de comptage qui est simplement incrémentée dans la boucle principale du programme de l'automate :

#include <Controllino.h>

  int ledPin = 13;
  unsigned char Buffer[32];
  unsigned char EndBuffer[] = {0xFF, 0xFF, 0xFF, 0x00};
  unsigned char NumberBuffer[8];
  unsigned int  NumberTest = 0;

void setup() {
 
  DDRJ = DDRJ | B01100000;
  PORTJ = PORTJ & B10011111;
  PORTJ = PORTJ | B01000000;
  pinMode(ledPin, OUTPUT);
  Serial.begin(19200);
  Serial3.begin(19200);
  strcpy(Buffer, "rtc3=17");
  strcat(Buffer, EndBuffer);
  Serial3.print((char *)Buffer);
  strcpy(Buffer, "rtc4=36");
  strcat(Buffer, EndBuffer);
  Serial3.print((char *)Buffer);
  strcpy(Buffer, "rtc5=00");
  strcat(Buffer, EndBuffer);
  Serial3.print((char *)Buffer);
  strcpy(Buffer, "rtc2=21");
  strcat(Buffer, EndBuffer);
  Serial3.print((char *)Buffer);
  strcpy(Buffer, "rtc1=10");
  strcat(Buffer, EndBuffer);
  Serial3.print((char *)Buffer);
}

void loop() {

  delay(1000);
  digitalWrite(ledPin, HIGH);
  strcpy(Buffer, "n6.val=");
  itoa(NumberTest++, NumberBuffer, 10);
  strcat(Buffer, NumberBuffer);
  strcat(Buffer, EndBuffer);
  Serial3.print((char *)Buffer);
  Serial.print((char *)Buffer);
  delay(1000);
  digitalWrite(ledPin, LOW);
}

Programme de test réalisé sans aucune volonté de perfection...

Les instructions
DDRJ = DDRJ | B01100000;
PORTJ = PORTJ & B10011111;
PORTJ = PORTJ | B01000000;
servent 'juste' à configurer les pattes /RE et DE du tranceiver interne du Controllino afin que les données émises sur le port série n°3 partent bien en RS485.
La variable EndBuffer initialisée à {0xFF, 0xFF, 0xFF, 0x00} est obligatoire car toute instruction transmise à l'écran doit se terminer de la sorte. Les différentes variables rtcx correspondent à l'initialisation des différentes variables de l'heure et de la date qui sont mises à jour automatiquement par l'afficheur lui-même. Enfin n6, correspond à la variable affichée au milieu de l'écran, mise à jour toutes les secondes par l'automate.

Les premiers tests s'avèrent concluants. Même avec une communication RS485 en 2400 Bauds, l'écran répond correctement en 115200 Bauds. Ne connaissant pas la façon dont est effectué la gestion de la communication série au sein de l'écran, il était en effet possible qu'un time-out un peu trop 'serré' à la réception de caractères empêche ce dernier de considérer une trame correcte,  valide. Mais il n'en est rien, à ma grande satisfaction.

Que reste-t-il à faire? D'un point de vue programmation, il reste à gérer la manipulation en temps réel du bloc de switchs afin de configurer le ports série du processeur qui gère le port série RS485 en temps réel.

D'un point de vue matériel, la partie alimentation à découpage implémentée sur cette carte d'interface est un peu trop juste pour l'écran de 7". La puissance demandée par les écrans de taille inférieur ne pose pas de problème au régulateur à découpage, mais le 7", avec ses 500mA de consommation, arrive en limite de ce qu'est capable de débiter l'alimentation. Dans ce cas, le régulateur ainsi que la self montent déjà un peu trop en température. Il faudra donc envisager une solution d'alimentation un peu plus cossue.

26 octobre 2017 : Après avoir implémenté la gestion des erreurs de communication, l'heure du bilan à sonné. Un peu de la même façon que ce qui est arrivé avec le switch MIDI (qu'il faut que je continue de développer d'ailleurs) et le processeur PIC utilisé au départ, puis remplacé par la suite par un processeur ARM de chez ST, je vais étudier une nouvelle version équipée elle aussi d'un processeur ARM de ST.

La raison principale de ce choix est, la aussi, un manque de flexibilité des processeurs de type ATmega. Sur ces derniers, il est difficile d'effectuer un débogage en temps réel. Or, avec le peu de temps dont je dispose pour mes développements, il m'arrive souvent de tester des petits bouts de code sur un montage laissé de côté depuis un certain temps. Ne me souvenant plus de tous les détails, il devient alors compliqué de comprendre la raison du non fonctionnement du code en test.
Pouvoir jeter un œil sur un registre devient alors primordial. Et puis l'IDE Atmel est lourd, vraiment trop lourd. Installer des centaines de méga pour du processeur 8 bits... Allez donc voir ce que propose Zilog depuis des décennies avec le ZDSII. Si seulement Zilog avait eu la bonne idée de rajouter un peu de RAM dans ses micro-contrôleurs. Mais ceci est une autre histoire.....

Je vais aussi en profiter pour améliorer un peu le concept de cette carte en y ajoutant quelques fonctionnalités qui me semblent intéressantes afin de la rendre un peu plus versatile que ce qu'elle est aujourd'hui. Un port RS232 me semble une option valable. Il y a en effet quantité de matériels 'anciens' qui fonctionnent avec ce type d'interface. Pouvoir les passer en 485 opto-isolé me semble être une bonne idée.

A suivre... 

01 décembre 2017 : après avoir cherché des solutions d'alimentations à découpage qui ne soient pas trop complexes à implémenter sur une petite carte, d'un prix 'acceptable' et d'une capacité en courant suffisante, j'ai décidé de tester une solution à base de LM2596. Pour effectuer des tests sans avoir à développer quoi que ce soit, j'ai acquis sur eBay quelques modules de ce type pour quelques Euros :


Ce qui est intéressant avec ce type de module, c'est qu'en plus de la plage de tension d'entrée qui peut monter à 40V, la sortie réglable de quelques volts à plus de 30V sous 3A max permet de s'en servir en petite alimentation d'appoint pour effectuer quelques tests. A noter que ce type d'alimentation ne peut guère servir en alimentation définitive sur du long terme vu le type et la qualité des condensateurs chimiques.

Et à propose de test, j'ai pu vérifier le fonctionnement correct de l'écran tactile en version grand format de 7 pouces :



Après une petite heure de fonctionnement, les éléments du module d'alimentation sont à peine tiède pour un débit d'environ 500mA, ce qui me semble plus pertinent comme solution que celle adoptée en premier lieu sur ma carte de développement. Je vais quand même sortir l'oscilloscope pour vérifier à minima l'allure de l'alimentation ainsi que son bruit.


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

vendredi 21 octobre 2016

C'est la reprise!

Mis à part quelques sujet sur des réparations/modifications d'instruments électronique de musique, je n'ai rien publié à la suite du MakerFaire de Nantes qui s'est déroulé début juillet.

Parce-que finalement, je n'avais rien de spécial à publier. Pratiquement quatre mois après ce MakerFaire, et malgré l'enthousiasme affiché par les 'passants' sur mes présentations, force est de constater que la multitude de contacts échangés à cette occasion n'a rien donné de particulier. Reste malgé tout cet incroyable moment passé à la rencontre de personalités très variées et intéressantes.

Je continue donc, seul, mes développements et diverses expérimentations électroniques.

Lors de ce MakerFaire nantais, j'ai présenté deux thématiques principales :

- l'automatisme dédié à l'habitation, basé sur l'environnement Arduino. Le matériel exposé se composait d'un automate commercial de type Controllino, d'une carte Arduino de type UNO de ma composition, mais possédant DEUX vrais ports série, et d'un écran graphique tactile permettant de commander le tout :


Les évolutions de ce système consistent en une carte d'interface que je développe actuellement pour la carte automate Arduino. Cette interface comportera un circuit industriel capable de gérer la commande de signaux numériques en 24V, ainsi qu'un certain nombre d'entrées analogiques acceptant du 10V et du 5V. tout ceci devant permettre de sécuriser la carte Arduino vis à vis du monde extérieur et permettra de se passer de l'automate commercial Controllino.
Quelques passages en FabLab à titre de conseil en développement de solutions électroniques m'ont permis de constater à quel point il est facile de détruire les entrées/sorties du processeur quand les 'expérimentateurs/trices" ne possèdent qu'une vague notion des grandeurs physiques utilisées.

D'autre part, le type d'écran tactile utilisé à subi une évolution. Ces écrans sont maintenant plus réactifs en affichage du fait d'un système à processeur intégré plus rapide. Ils possèdent aussi une plus grande capacité mémoire, ce qui permet une montée en 'raffinements' d'affichage. Ils possèdent aussi directement l'heure temps réel. Ce qui permet de libérer le port d'extension dédié de ma carte Arduino.

Le schéma théorique de l'interface industrielle est terminé. Il reste encore à créer le circuit imprimé, ce qui sera fait dans les semaines à venir.

- L'électronique dédié aux instruments numériques était la deuxième thématique présentée au MakerFaire. Avec deux présentations matérielles. D'une part un système permettant de prendre le contrôle d'une machine pour y effectuer des diagnostiques et réparations éventuelles. En l’occurrence ce système prend la forme d'un 'émulateur' de processeur Z80, utilisé en lieu et place du processeur d'origine d'une Drumulator :



Cet émulateur de Z80 n'émule pas réellement un Z80, évidemment, mais est en mesure de prendre le contrôle des différents bus du système, et ce, dans le but de commander les différents organes de la machines afin d'en évaluer le comportement. Le gros avantage de cette solution est qu'elle ne nécessite aucun composant externe pour fonctionner. Par le fait, il devient alors possible d'effectuer un DUMP de la ROM d'origine de la machine, et même de tester le bon fonctionnement des mémoires RAM.
Mon étude initiale comportait quelques 'bugs'. Afin de la finaliser, j'ai donc corrigé les erreurs et en ai aussi profité pour changer le connecteur mini-usb en optant pour un modèle vertical. De cette façon, l'émulateur n'occupe que la place d'origine du Z80 et ne déborde plus. Je pourrai remettre en place le potentiomètre que j'avais du retirer.

La nouvelle version est à gauche!
 
Côté pile.

Côté face.
La nouvelle version est bien plus 'propre' que l'ancienne et va me permettre de continuer à développer sereinement les algorithmes de test de la Drumulator.

Autre sujet développé dans cette thématique instruments numérique de musique, une 'nouvelle' liaison M.I.D.I. :


Ces deux modules relient mon clavier maitre K250 et un expandeur sur lequel j'utilise différents sons de piano depuis quatre mois maintenant. Je n'ai constaté aucune erreur de communication malgré une certaine 'rapidité' des notes jouées (je prends par ailleurs des cours de clavier, histoire de me servir aussi de ce que je fabrique!). La topologie de ma liaison M.I.D.I. n'étant plus la même que celle d'origine, je développe en ce moment un switch qui me permettra de non plus faire un simple point à point, mais de créer un vrai réseau de machines. Le PCB de ce switch est créé et ne requiert 'plus' que sa fabrication puis la programmation du système.

Le principe de mise en place de ce nouveau réseau devrait être assez 'ludique', agréable, et pratique, tout en conservant l'existant. Non? si si....

Cerise sur le réseau, avec tous ces développements et matériels disponibles, j'en profite pour développer un petit système de commande pour le Juno 2 que j'ai dépanné récemment. Ce système se comportera comme un PG300 mais à partir d'un des écrans tactiles évoqués plus haut. Il permettra aussi de faire l'interface entre le nouveau réseau M.I.D.I. et les 'anciennes' prises M.I.D.I. de la machine. L'interface graphique ressemblera à ceci :


Et d'ailleurs voici ce à quoi ressemble le circuit imprimé tout fraîchement arrivé de fabrication :


Pour ce montage j'ai choisi de passer sur un processeur de type ARM de chez ST. D'une part ces processeurs sont rapides, mais surtout l'ensemble des logiciels disponibles pour ces circuits est vraiment 'facile' à utiliser. CubeMX permet en effet de configurer de façon graphique les processeurs ST puis de générer le projet contenant toutes les initialisations nécessaires. Projet qu'il suffit d'ouvrir avec System Workbench for STM32 d'AC6 par exemple pour commencer à développer le code dans un environnement Eclipse. Cela fonctionne très bien, une très grande partie du travail fastidieux d' initialisation du processeur devenant automatique.

Carte montée : 28/10/2016

Pas du grand art, mais pour du prototype, ça ira bien!
Carte partiellement testée : 05/11/2016


Pour tester mon montage, j'ai réutilisé une petite carte d'affichage réalisée en 1992 il me semble. Cet affichage faisait parti d'un système de filtrage des canaux M.I.D.I. à destination d'un JX3P.
Insérée directement sur un port d'extension de la carte ARM, elle me servira à afficher des indications sommaires lors du développement logiciel de cette carte.

Et pendant que j'y suis : publicité gratuite pour ST. Je m'empresse de suite de préciser que mon intention n'est pas de dénigrer d'autres fondeurs proposant des processeurs compatibles ARM certainement très intéressants mais je n'ai jamais poussé les essais, la plupart du temps non pas à cause des circuits heux même, mais du fait du manque de logiciels de développement 'faciles d'installation/d'utilisation'. Ce qui m'a fait pencher pour les micro-contrôleurs ST est en tout premier lieux l'application CubeMX ou plus exactement STM32cubeMX. Ce logiciel permet tout simplement de configurer tous les aspects matériels du micro-contrôleur utilisé. Pour qui souhaite développer rapidement une petite application, cet outil est indispensable. Ensuite, vient évidemment la chaîne de développement Système Workbench for STM32 d'AC6. Il s'agit d'un IDE basé sur l'incontournable Eclipse. A ceci près, que l'installation complète de la chaîne de développement se fait de façon extrêmement simple. Ce qui n'était pas encore le cas mi-2015! Je rajouterai à cela que les processeur ST sont complets, rapides et d'un prix très faible. Inutile de plus d'acquérir un programmateur au prix exhorbitant. Pour ma part, j'utilise le STlink2 présent sur une carte Nucleo, qui me permet aussi d'effectuer du deboggage en temps réel : carrément le luxe!

Système quasi fonctionnel : 14/12/2016

Il m'aura fallu un peu plus d'un mois pour arriver à mes fins mais ça y est, l'afficheur graphique me permet de modifier en temps réel les paramètres du Juno 2. Pour l'instant je n'ai pas encore testé la connection au 'vrai' standard M.I.D.I. puisque j'en ai équipé ma carte processeur, mais 'me suis contenté' de faire transiter les informations par mon réseau compatible M.I.D.I. avec la mise en place d'un convertisseur vers l'ancien système M.I.D.I., directement connecté au synthétiseur. Pour imager la chose, je suis maintenant en mesure de modifier les paramètres du son du Juno en live avec l'écran tactile, tout en étant distant de presque 10m, longeur du câble qui relie l'écran au synthé. Et cela fonctionne superbement bien :-)
La fonctionnalité du système étant validée, il 'ne me reste plus' qu'à programmer l'ensemble de l'application et à trouver un boitier adéquate pour loger le tout! 

Je n'ai pas précisé, mais l'émulateur de Z80 est basé sur un processeur Atmel ATmega328pb, ainsi que les modules M.I.D.I. personnels, et évidemment la carte automate compatible Arduino. Pour le switch M.I.D.I. je vais utiliser un microcontrôleur de chez Microchip de la famille PIC32MX.

S'il est possible de débuter la programmation en 'jouant' de l'IDE Arduino sur les cartes du même nom, l'étape suivante qui consiste à programmer tel ou tel type de microprocesseur avec l'IDE du 'constructeur' et un programmateur dédié n'est finalement pas beaucoup difficile, à partir du moment ou les bons outils et le bon environnement informatique est utilisé.
  
Voilà, c'est tout pour l'instant. Encore que... D'autres sujets sont plus ou moins en cours d'étude, qui aboutiront peut-être... ou pas!