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

Pages: 1 ... 20 21 [22] 23 24 ... 44
316
Bus DCC / Re : Perte des fonctions
« le: octobre 31, 2018, 11:58:44 am »
Bonjour

Dans cette fonction, le 1 est effectivement le numéro de registre. Mais comme je le disais précédemment c'est plutôt le 0 qui devrait être utilisé ici, parce que le 1 est probablement utilisé par une machine pour sa vitesse, ce qui signifie qu'au lieu de répéter la vitesse comme c'est la norme, on répète l'état des fonctions ! Le 13 est l'adresse DCC de la loco, et gLocoFonction est une structure qui connait l'état de l'ensemble des fonctions d'une loco. En effet, le DCC ne permet pas d'activer les fonctions une par une. A la place il faut envoyer l'état voulu par groupes de quatre, ce qui fait que l'on doit se souvenir de l'état des autres fonctions du groupe à chaque envoi...
Accessoirement, il faudra que je change l'aide de la fonction qui dit de ne pas utiliser le registre 0...

317
Bus DCC / Re : Perte des fonctions
« le: octobre 29, 2018, 03:35:44 pm »
Pourquoi pas toutes les cinq secondes, mais il faut le faire pour toutes les machines qui sont pilotées en vitesse par ailleurs.
Le nombre de machines pilotables est limité par le nombre de registres de répétition de commande DCC utilisés par DCC++. La version de Greeg déclare 12 registres par défaut, un pour les ordres temporaires comme les fonctions, l'interrogation de CVs ou la commande d'accessoires, 11 pour les ordres répétitifs comme la vitesse d'une machine. C'est un moyen terme entre un Nano limité par sa mémoire et un Mega moins limité. Dans DcDccNanoController, j'ai limité à beaucoup moins puisque le but n'est que de piloter une machine. Et puis moins de canaux, c'est moins de mémoire utilisée !

318
Bus DCC / Re : Perte des fonctions
« le: octobre 29, 2018, 10:19:07 am »
La non répétition des fonctions fait partie de la norme DCC, la conservation de cette info est à la charge des décodeurs pour des micro-coupures. Malheureusement, si la machine n'est pas équipée avec des condensateurs, dès que l'on 'plante un choux' l'info est perdue.

La solution de renvoyer périodiquement les fonctions est possible, le problème est d'identifier le bon moment...

L'autre solution me parait pourtant acceptable. Utiliser deux registres par machine, avec un registre pour la vitesse et l'autre pour les fonctions, ça marche. Par contre il faut supporter de n'avoir que six machines à piloter.  C'est la stratégie que j'ai employée dans DcDccNanoController, sachant que c'est fait pour un Nano et donc pour une toute petite centrale.

319
Merci, c'est bien ce que je pensais. Mais tu sais tout le monde ne lit pas la schématique dans le texte aussi facilement que vous. Je m'améliore, mais j'ai encore des progrès à faire...

320
Bus DCC / Re : Nouvelle souris sans fil à mémoire
« le: octobre 24, 2018, 09:14:25 am »
Oui, ce type de tri va plus vite, mais il prend un peu plus de mémoire programme (on est déjà à 98%!) et la vitesse ne semble pas le critère déterminant.

321
Petite question sur le programmateur. Comment insérer un atTiny85 dans son support ? Le point vers le levier ? C'est le seul point de repère que j'ai...

322
Bus DCC / Re : Nouvelle souris sans fil à mémoire
« le: octobre 18, 2018, 09:21:54 am »
De rien.

Pour aller un peu plus loin et faire profiter tout le monde, voici un bout de code pour expliquer:

On commence par déclarer une liste, et la remplir avec un numéro croissant:

byte listeTriee[255];

for (int i = 0; i < 255; i++)
listeTriee[i] = i;

On a ainsi la liste des locos non triée, désignée par leur position dans l'EEPROM.
Puis on réalise le tri proprement dit par la méthode dite du tri à bulle: (https://fr.wikipedia.org/wiki/Tri_%C3%A0_bulles)

for (int i = 255 - 2; i >= 0; i--)
{
for (int j = 0; j <= i; j++)
{
if (loco[listeTriee[j+1]].adresse < loco[listeTriee[j]].adresse)
{
byte t = listeTriee[j + 1];
listeTriee[j + 1] = listeTriee[j];
listeTriee[j] = t;
}
}
}

Si l'ordre entre deux locos n'est pas le bon, on échange simplement les octets de la liste triée.
Pour tester sur le nom ou autre chose, il suffit de remplacer le '.adresse' par autre chose. Pour trier dans l'ordre inverse, changer le '<' par un '>' !
Je n'ai ni compilé ni testé ce code...

323
Bus DCC / Re : Nouvelle souris sans fil à mémoire
« le: octobre 17, 2018, 05:02:43 pm »
Un autre moyen est de créer une liste d'entiers ou d'octets (si on se limite à 255 machines maxi) qui représente la liste triée des locos présentes en EEPROM. Il "suffit" de créer cette liste au démarrage une fois pour toutes. L'autre solution si l'on veut éviter d'utiliser de la mémoire centrale ou de la mémoire programme est de créer cette liste directement en mémoire EEPROM grâce à un autre programme sur Arduino ou sur ordinateur, et de mettre ces 255 octets dès le début de l'EEPROM, avant les locos. Pour atteindre une loco, une simple indirection suffit : je veux la loco 3 dans l'ordre, je lis l'octet 3 de la liste qui me dit c'est l'enregistrement EEPROM 17, je lis la loco à l'emplacement 17 !

324
Bus DCC / Re : Re : Fonctions DCC de 21 à 28
« le: octobre 11, 2018, 03:03:20 pm »
1 ou -1 that is the question. Je passerai par des essais, merci pour ta réponse claire sur les pas.

Sans vouloir fâcher qui que ce soit, c'est tout vu ! N'oublions pas que l'on parle d'arguments passés en DCC sous forme de bits. Or lorsqu'on parle de -1 sur un champs de bit qui n'a pas de signe comme ici, dire -1 revient à mettre tous les bits à 1 ! En clair si tu mets -1 tu iras à fond !

325
Bus DCC / Re : Fonctions DCC de 21 à 28
« le: octobre 11, 2018, 03:00:34 pm »
La réponse est visible à deux endroits : le fichier include concernant le type utilisé, ici un RegisterList puisque tu utilises DCCpp::progRegs, c'est à dire en clair PacketRegister.h . Si tu cherches readCV() tu verras que le type de retour est fixé à 'int'. writeCVByte() et assimilés n'ont pas de valeur de retour : 'void' pour vide en Français. Donc tu ne peux pas récupérer d'information suite à l'écriture. C'est conforme à l'implémentation originale de DCC++ par Gregg .
L'autre endroit, c'est la documentation livrée avec la bibliothèque, visible depuis son répertoire 'extras' en cliquant sur le fichier index.html , toujours en cherchant RegisterList et writeCVByte().
Enfin, il n'y a que très peu de besoins justifiants de passer par autre chose que les fonctions de DCCpp, et ton utilisation n'en fait pas partie. Ce n'est pas faux, mais DCCpp est justement là pour masquer la complexité de ce qu'il y a derrière. Tu devrais utiliser DCCpp::readCVProg() et DCCpp::writeCVProg() ...

326
Bus DCC / Re : Fonctions DCC de 21 à 28
« le: octobre 11, 2018, 10:50:34 am »
Pour être plus précis, il faut se référer à la norme NMRA https://www.nmra.org/sites/default/files/s-9.2.1_2012_07.pdf qui définit les valeurs possibles pour la vitesse. Extraits :

Mode 14 pas de vitesse:
Citer
In this mode, Speed U0000 is stop, speed U0001 is emergency stop, speed U0010 is the
first speed step and speed U1111 is full speed
. This provides 14 discrete speed steps in each direction.
250 If a decoder receives a new speed step that is within one step of current speed step, the Digital Decoder may select a
step half way between these two speed steps. This provides the potential to control 56 speed steps should the
command station alternate speed packets.

Mode 128 pas
Citer
CCCCC = 11111: 128 Speed Step Control - Instruction "11111" is used to send one of 126 Digital Decoder speed
steps. The subsequent single byte shall define speed and direction with bit 7 being direction ("1" is forward and "0"
is reverse) and the remaining bits used to indicate speed. The most significant speed bit is bit 6. A data-byte value
of U0000000 is used for stop, and a data-byte value of U0000001 is used for emergency stop
. This allows up to 126
210 speed steps.

Il me semble que dans tous les cas, 0 signifie vitesse 0 donc arrêt normal, 1 impose un arrêt immédiat à l'engin moteur concerné, et le reste donne les différents crans de vitesse.

327
Magnifique ! Mais la création d'un dessin vectoriel n'est pas forcément à la portée du premier béotien venu... Il faudra prévoir un frontal de création de réseau.

328
Beau boulot de recherche et de mise au point. En informatique on appelle ça un jeu d'essai qui sert à vérifier tous les cas de figure. Enfin tous ceux auxquels on pense. Le dernier et le plus laborieux cas de figure à tester reste toujours le 'gros' jeu d'essai. Celui qui sature tous les compteurs par sa taille plus que par sa complexité...

329
Bibliothèques / Re : Bibliothèque Accessories
« le: septembre 07, 2018, 09:35:15 am »
La réponse la plus simple tient dans les identifiants 'inutiles' ! Au lieu de 456, mets DCCINT(125,0)...

Tel que tu l'as codé, le bouton poussoir envoie un seul événement que tu gères manuellement dans le loop. Tu peux aussi laisser Commanders et Accessories discuter entre eux : tu fixes deux événements au lieu d'un pour le poussoir, et tu donnes le même identifiant au servo. Bien entendu, il ne faut pas oublier le Commanders::loop(); !
Voici ma version avec l'option DCC en remarque:

#include <Accessories.h>
#include <Commanders.h>
 

// Le poussoir...
ButtonsCommanderPush boutonPoussoir;
 
// Le moteur
AccessoryServo AIGL;

 
// Les ports pour connecter le moteur et les DELs.
PortServo portAIGL;

#define SERVOMIN  201
#define SERVOMAX  202
 
// code pour un accessoire à l'adresse DCC 125 piloté par un bouton On et un bouton Off (cas de ma MS2 Marklin...)
//#define SERVOMIN  DCCINT(125,0)
//#define SERVOMAX  DCCINT(125,1)
 
void setup()
{
  Commanders::begin(LED_BUILTIN);

  DccCommander.begin(0x00, 0x00, digitalPinToInterrupt(3), true);
  // Memoriser les positions des moteurs dans l'EEPROM.
  Accessories::begin(0, 500);
 
  // Evènement du bouton 100 branché sur la borne 6...
  boutonPoussoir.AddEvent(SERVOMIN, COMMANDERS_EVENT_MOVEPOSITIONID, 0); // Le dernier argument ne sert pas pour ce type d'evenement
  boutonPoussoir.AddEvent(SERVOMAX, COMMANDERS_EVENT_MOVEPOSITIONID, 0);
  boutonPoussoir.begin(200, 6); // premier événement pour le déclanchement
 
  // Les ports avec leurs broches en digital (pas PWM)
  portAIGL.begin(12);
 
    // Le servo : pas de durée de mouvement, un débattement entre 95 et 135 degres
  // et deux positions stables annoncées avec des identifiants inutiles (mais obligatoires)
  AIGL.begin(&portAIGL, 50, 95, 135, 1);
  // Les deux positions sont au mini et au maxi :
  AIGL.AddMinMaxMovingPositions(SERVOMIN, SERVOMAX);
}

void loop()
{
  Commanders::loop();
  Accessories::loop();
}

Dans cette version, le DCC et le poussoir restent tous les deux actifs sur le même servo puisqu'ils génèrent les mêmes événements !

PS: je ne suis pas sur mon PC perso, alors ce n'est ni compilé ni testé...

330
Salut à tous, et désolé d'avoir loupé le chapitre sur DCCpp....
Je rappelle (ou je signale à ceux qui ne le savaient pas) que pour toutes mes bibliothèques une documentation HTML est disponible (en anglais uniquement...) en cliquant sur extras/Doc/index.html, ou sous Windows en lançant StartDoc.bat présent dans le répertoire de la biblio. On trouve la bonne info en cherchant l'aide sur beginMain():

Pages: 1 ... 20 21 [22] 23 24 ... 44