Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.


Messages - bobyAndCo

Pages: [1] 2 3 ... 11
1
Bravo j'applaudis des deux mains, très bonne idée d'utiliser des tableaux  :) :) :)

Par contre, il faut utiliser les balises de code pour que ton code dans les messages soit plus lisible. Le bouton avec # à l'intérieur.


const byte pin[] = {4, 5, 6, 7}; // création du tbl pour les 4 Pin des clignotants - Attention Index du 4 = 0
// à ajuster au total des 12 sorties / leds utilisées > TODO : sélectionner les 12 Pin
void setup () {
  for (int i = 0 ; i < 5 ; i++) {      // 5 car 4 leds utilisées dans cet ex
    pinMode (pin[i] , OUTPUT) ;        // les 4 leds sont déclarées en même temps en sortie
    digitalWrite (pin[i] , LOW) ;      // on éteint ttes les leds avant de commencer une sélection au clavier
  }                                    // fin de la boucle FOR
}

2
Discussions ouvertes / Re : Méga carte (pas carte Méga)
« le: juin 01, 2018, 08:08:50 am »
Bonjour Antoine,

C'est assez séduisant de prime abord. Nous sommes dans l'esprit de ce sur quoi nous travaillons comme en a déjà parlé Dominique (carte universelle tournée modélisme ferroviaire). Pas mal de choses intéressantes me semble t'il, dont les E/S opto isolées. Je ne suis pas spécialiste mais si effectivement comme tu le dis cela peut limiter ou supprimer les effets indésirables.

30 sorties 500mA. Je suppose que c'est 500mA sur chaque sortie. Auquel cas, c'est vraiment un plus car il est vrai que +-20mA, c'est tout de même un peu juste. Et les LEDs de contrôle, simple mais effectivement très utile.

Comment comptes-tu faire avec avec les si peu E/S du Nano pour gérer autant d'E/S sur ta carte ?

Bien amicalement.

Christophe

3
Vos projets / Re : Un mini module sonore
« le: mai 27, 2018, 08:42:04 pm »
Oui mais dans cas que je cite, il s'agit d'une situation particulière où plusieurs Arduino ont des programmes différents à executer et selon les étapes du programme, ils sont amenés à demander la lecture d'un morceau. Donc intérêt du CAN ici, tous les Arduino peuvent envoyer sur le même bus et grâce aux filtres, seul l'Arduino qui joue les sons peut intercepter les messages le concernant.

4
Eh bien mon cher Jean-Luc !!! Et tu n'oubliras pas de facturer ton temps aussi. Merci vraiment pour tout ce que tu fais.

Christophe

5
Vos projets / Re : Un mini module sonore
« le: mai 27, 2018, 06:58:17 pm »
C'est très bien tes musiciens   :) :) :)

Tu as totalement raison, il est très simple de faire jouer par différents Arduinos en CAN. Je viens moi même de le réaliser à partir de plusieurs cartes sur un UNO dédié avec son mini player MP3.

Et je compte bien aller plus loin car je viens d'acheter 6 modules mini player MP3 sur Ebay à 1,20€ pièce port gratuit ! Alors pourquoi se priver.

https://www.ebay.fr/itm/TF-Card-U-Disk-Mini-MP3-Player-Audio-Voice-Module-For-Arduino-DFPlay-Mini-Board/173243875082?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2648



6
Trouvé au hasard du net pour ceux qui s'intéressent au très bon JMRI. Une solution complète JMRI/DCC++ à base de Raspberry et Arduino Uno avec en prime le WiFi donc pilotage à partir d'un smartphone. Le tout probablement pour moins de 100 €.



Bon WE à tous, Christophe

7
Bus CAN / Re : Bus CAN avec DCC++
« le: mai 24, 2018, 08:12:53 am »
Faute de temps, je n'ai pas pu regarder tes différents codes, mais si tu as réussi à envoyer <0> ou <1> à DCCpp le plus dur est fait. Dans la version originale de DCCpp ligne 205 du fichier DCCpp_uno.ino, tu as l'appel de la fonction :   SerialCommand::process();  au tout début du loop.

C'est cette fonction (dans le fichier SerialCommand) qui va faire le travail :

void SerialCommand::process(){
  char c;
   
  #if COMM_TYPE == 0

    while(INTERFACE.available()>0){    // while there is data on the serial line
     c=INTERFACE.read();
     if(c=='<')                    // start of new command
       sprintf(commandString,"");
     else if(c=='>')               // end of new command
       parse(commandString);                   
     else if(strlen(commandString)<MAX_COMMAND_LENGTH)    // if comandString still has space, append character just read from serial line
       sprintf(commandString,"%s%c",commandString,c);     // otherwise, character is ignored (but continue to look for '<' or '>')
    } // while
 
  #elif COMM_TYPE == 1

    EthernetClient client=INTERFACE.available();

    if(client){
      while(client.connected() && client.available()){        // while there is data on the network
      c=client.read();
      if(c=='<')                    // start of new command
        sprintf(commandString,"");
      else if(c=='>')               // end of new command
        parse(commandString);                   
      else if(strlen(commandString)<MAX_COMMAND_LENGTH)    // if comandString still has space, append character just read from network
        sprintf(commandString,"%s%c",commandString,c);     // otherwise, character is ignored (but continue to look for '<' or '>')
      } // while
    }

  #endif

} // SerialCommand:process

Ici, tu as les cas pour le port serie et pour une liaison en ethernet TCP. Il faut ajouter le cas de la réception en CAN et la fonction parse(commandString); va faire tout le reste du travail.

Comme tu fais la réception des messages CAN dans ton loop, tu peux essayer d'envoyer l'ensemble du message reçu comme paramètre à SerialCommand::process(tonMessageCan) du loop. Et modifier en consèquence SeriaCommand.cpp et SerialCommand.h

Bien sûr, dans le loop, tu n'auras plus à appeler SerialCommand::process() à chaque tour mais simplement quand tu as un nouveau message CAN

8
Ok adjugé, 2 PTC à Dominique et 1 à msport. En fait j'en ai besoin que d'une dans l'immédiat !

9
Discussions ouvertes / Re : Humour et vérité
« le: avril 01, 2018, 04:37:09 pm »
Je suis entièrement d'accord avec tout ce qui est dit précédemment. Néanmoins, je pense que rien ne saurait s'expliquer sans l'éclairage de la norme pifométrique dont je vous joint un extrait en PJ !

10
Discussions ouvertes / Re : Automatisme pour passage à niveau
« le: avril 01, 2018, 04:26:08 pm »
Alors là Jean-Luc, la flemme pour une interruption alors qu'il n'y a rien de plus facile, c'est pas bien !

11
Bus CAN / Re : Réduire câblage
« le: mars 29, 2018, 10:50:12 am »
Bonjour à tous,

Je défend le concept présenté par Dominique que je n'hésite pas à appeler "un Arduino par canton". En réalité, il s'agit bien plus qu'un Arduino puisque cela comprend les servos (dans mon cas) pour les aiguillages, les détecteurs de consommation, la signalisation etc... etc... Donc tout ce qui fait un canton.

Je suis assez avancé sur un prototype où l'ensemble du code est identique sur tous les Arduinos. Seul l'ID de l'Arduino est différent et se paramètre en début de programme. Un certain nombre d'options sont "imposées par défaut" comme par exemple le fait que la classe aiguillage instancie 4 aiguillages ou que par défaut encore, le nombre de capteurs ON/OFF (consommation, effet Hall...) est fixé à 12. Je suis sur des MEGA et cela suffit dans mon cas à couvrir tous mes besoins et les dépasse même.

A partir d'un code standard et pour individualiser le travail de chaque MEGA à son canton, j'ai une méthode dans le setup qui va charger sur un serveur les paramètres spécifiques à ce canton reconnu par l'ID écrite en "dur" au début du programme. Pour cela, j'utilise une liaison Ethernet et un serveur en Node.js (mais cela pourrait aussi être fait en CAN). Le transfert des données est au format Json et j'utilise la bibliothèque "ArduinoJson" qui simplifie grandement l'affectation des valeurs à chaque paramètre.

L'avantage est bien sûr comme souligné déjà la réduction du câblage, mais aussi un code unique pour toutes les cartes donc plus facile à maintenir et à faire évoluer. Par ailleurs, le fait que tous les paramètres spécifiques d'un canon soient stockés dans de simples fichiers textes sur un serveur facilite aussi la maintenance et la mise à jour.

Je cherche à introduire en plus un bus CAN pour profiter d'une spécificité que bizarrement il ne me semble pas encore avoir vu développée sur Locoduino. La possibilité que chaque nœud  a d'intercepter l'ensemble des messages et donc de pouvoir agir dans certains cas sans avoir besoin (ou d'attendre) l'information d'un gestionnaire central. Un certain nombre d'objets locaux pourraient alors interagir sans passer (ou tout passer par le gestionnaire). Le cas le plus évident me semble par exemple l'interaction d'un détecteur de consommation sur le la modification de la signalisation lumineuse.

Cela me semble intéressant là où les questions de sécurité sont critiques (rapidité d'intervention, panne éventuelle du gestionnaire...) ou au contraire très secondaire. La gestion d'un PN n'a en effet probablement pas besoin de passer par un gestionnaire central mais met en œuvre pas mal d'actions qui peuvent être auto-gérées localement. Détection d'un train, feux rouges clignotants, signal sonore, fermeture des barrières...

Le CAN avec son système de filtres et de masques permet cela à merveille. C'est comme cela que je comprends "solution intelligente répartie"  dont parle Rob1.

Par contre, je déconseille vivement, et je ne suis pas le seul, d'envisager la conception d'un réseau aujourd'hui (hors traction bien sûr) sur le bus DCC et décodeurs comme en parle Tony04.

Bien amicalement

Christophe.

12
Bonjour Jean-Luc,

Maintenant qu'il y a des détecteurs simples "en magasin" (DETECT_SINGLE), j'en veux bien 24 si possible.

Bien amicalement.

Christophe

13
Le logiciel DCC++ / Re : e-stop emergency stop avec DCC++
« le: mars 19, 2018, 09:05:34 pm »
Merci d'avoir cherché... et trouvé. C'est effectivement intéressant et important pour la sécurité sur nos réseaux... enfin, ceux qui sont en DCC, les autres, euuuh !!!

14
Le logiciel DCC++ / Re : e-stop emergency stop avec DCC++
« le: mars 16, 2018, 07:26:43 am »
Il y a au moins une raison, le locos équipées de PowerPacks ne vont pas s'arrêter immédiatement ce qui est pourtant le but recherché.

15
Le logiciel DCC++ / Re : e-stop emergency stop avec DCC++
« le: mars 15, 2018, 10:38:06 pm »
Dans mon cas, mais je ne sais pas s'il est reproductible pour toi, toutes mes locos (13) sont enregistrées dans un objet tableau dans mon gestionnaire. Je fais tout simplement une boucle de la taille du tableau et j'envoie autant de commandes que de locos <t ID @ -1 1>.

$scope.setUpLocos = function () {
// On met toutes les locos à l'arrêt
for(var i = 0; i < $scope.locomotives.length; i++) {
$scope.locomotives[i].vitesse = -1;
$scope.locomotives[i].sens = 1;
var data = "t ";
data += $scope.locomotives[i].id;
data += " ";
data += $scope.locomotives[i].address;
data += " ";
data += $scope.locomotives[i].vitesse;
data += " ";
data += $scope.locomotives[i].sens;
data = "<" + data + ">";
$scope.sendReq(data);
$scope.locomotives[i].vitesse = 0;
}
}

Bien amicalement

Christophe

Pages: [1] 2 3 ... 11