Dcc++

[jpp38]

Bonjour,

Merci pour la réponse.
J'ai bien vu qu'il y une valeur prévue pour le Estop, à envoyer au niveau du cran vitesse de la loco, conformément à la spec du NMRA.
Donc, on peut toujours l'envoyer à une loco particulière (celle contrôlée à l'instant t par le throttle).
Mais l'intérêt de cette commande est d'arrêter tous les trains ensemble.
Donc, y a-t-il une commande (ou une convention) que je n'ai pas vu pour le faire?

je n'ai pas utilisé la déclaration des aiguillages de DCC++, et donc pas l'EEPROM. Je me suis contenté jusque là de commander les aiguillages en tant qu'accessoires. Leur position est indéfinie au départ et il faudrait les initialiser. Mais sur un (tout) petit réseau ...

Là, par contre, je n'ai pas compris. J'ai essayé de piloter les aiguillages sans stockage dans l'EEPROM (car ça m'embête plus qu'autre chose), et je n'y suis pas arrivé. Si je ne stocke pas en EEPROM, la commande passe tant que je ne définis pas d'autre aiguille, mais après, il les oublie.
Peux-tu me détailler la façon dont tu le fais, ça m'intéresse. J'ai l'impression que j'ai loupé quelque chose.


Enfin, la gestion des SENSORS (par les broches de l'ARDUINO), est vraiment trop limitée. Je ne suis pas certain que je vais perdre du temps là-dessus.
je pense que je vais vite m'orienter vers la solution de Xavier, si, comme j'ai cru le comprendre, il gère une chaîne S88.

JP

[Xavier]

Bonjour,

Effectivement, la solution S88 que j'ai mis en place remonte la chaîne des états d'occupation de chaque zone sous forme binaire: <y 0000100011000000>
Cette information remonte à chaque modification de l'un quelconque des états d'occupation.

Il suffit d'initialiser son fonctionnement en indiquant le nombre de modules S88 utilisé (1 module pour 16 zones de détection.) à l'aide de la commande <Y Nb>

A2 S88_Data_PIN
A3 S88_Clock_PIN
A4 S88_Reset_PIN
D6 S88_PS_PIN

Si besoin est, je pourrais bien évidement modifier cette fonction.

Amicalement,

Xavier

[msport]

Bonjour,
Merci pour la réponse.
J'ai bien vu qu'il y une valeur prévue pour le Estop, à envoyer au niveau du cran vitesse de la loco, conformément à la spec du NMRA.
Donc, on peut toujours l'envoyer à une loco particulière (celle contrôlée à l'instant t par le throttle).
Mais l'intérêt de cette commande est d'arrêter tous les trains ensemble.
Donc, y a-t-il une commande (ou une convention) que je n'ai pas vu pour le faire?

Bonjour,
coté Locoduino, j'ai eu plusieurs réponse sur le e-Stop individuel mais aucune sur le e-Stop général :
La séquence de bits est décrite dans la norme en 4.2 du MOROP, est-elle implémentée dans DCC++ ou est-ce à faire ?
http://www.morop.org/downloads/nem/fr/nem671_f.pdf
Paquet de données DCC de base pour la remise à zéro générale des décodeurs
Format des données DCC de base:
1111111111111111 0 00000000 0 00000000 0 00000000 1
Synchronisation Octet de données 1 Octet de données 2Octet dedonnées 3 (octet decontrôle)
Le paquet de données DCC pour la remise à zéro générale des décodeurs est constitué de trois
octets dont tous les bits sont à zéro. Lorsqu’un décodeur reçoit ce paquet de données, il doit
effacer toutes ses mémoires non permanentes (y compris les données de vitesse et de sens de
marche) et revenir à son état normal de mise sous-tension. Si la motrice est en mouvement, le
décodeur doit lui appliquer un arrêt d’urgence.
Dans les 20 millisecondes qui suivent un paquet de remise à zéro générale, une station de
commande ne doit pas envoyer un paquet de données avec une adresse comprise entre
01100100 (adresse 100) et 01111111 (adresse 127) bornes incluses, sauf si elle souhaite passer
en mode « Service ». 5)

je n'ai pas utilisé la déclaration des aiguillages de DCC++, et donc pas l'EEPROM. Je me suis contenté jusque là de commander les aiguillages en tant qu'accessoires. Leur position est indéfinie au départ et il faudrait les initialiser. Mais sur un (tout) petit réseau ...

Là, par contre, je n'ai pas compris. J'ai essayé de piloter les aiguillages sans stockage dans l'EEPROM (car ça m'embête plus qu'autre chose), et je n'y suis pas arrivé. Si je ne stocke pas en EEPROM, la commande passe tant que je ne définis pas d'autre aiguille, mais après, il les oublie.
Peux-tu me détailler la façon dont tu le fais, ça m'intéresse. J'ai l'impression que j'ai loupé quelque chose.

pour les aiguillages j'utilise des décodeurs d'accessoires (Rudy Boer sur arduino, bien sur) qui répondent aux commandes DCC ci-dessous. J'utilise une manette dédiée aux dits accessoires (dérivée de celle de Dave Bodnar avec des modules radio HC-12C)
####STATIONARY ACCESSORY DECODERS & TURNOUTS####
DCC++ BASE STATION can keep track of the direction of any turnout that is controlled by a DCC stationary accessory decoder once its Defined (Set Up).
All decoders that are not in a engine are accessory decoders including turnouts.
Besides being defined all turnouts, as well as any other DCC accessories connected in this fashion, can always be operated using the DCC BASE STATION Accessory command:
#####You Controlling a Accessory Decoder** with **< a ADDRESS SUBADDRESS ACTIVATE >#####
• <: Begin DCC++ command
• a (lower case a) this command is for a Acessory Decoder
• ADDRESS: the primary address of the decoder controlling this turnout (0-511)
• SUBADDRESS: the subaddress of the decoder controlling this turnout (0-3)
• ACTIVATE: (0) (Deactivate, Off, Unthrown) or (1) (Activate, On, Thrown)
• >: End DCC++ command
• However, this general command simply sends the appropriate DCC instruction packet to the main tracks to operate connected accessories. It does not store or retain any information regarding the current status of that accessory.

Enfin, la gestion des SENSORS (par les broches de l'ARDUINO), est vraiment trop limitée. Je ne suis pas certain que je vais perdre du temps là-dessus.
je pense que je vais vite m'orienter vers la solution de Xavier, si, comme j'ai cru le comprendre, il gère une chaîne S88.

Je n'utilise pas encore de rétrosignalisation, ce que je compte faire dès que CDM-Rail pilotera ma Base Station, mais alors je préfèrerais qu'elle n'utilise pas les broches de la Base Station, je pense que des fonctions indépendantes faciliteraient la mise au point et le dépannage. Mais la Base Station pourrait servir d'interface à des concentrateurs S88 - merci Xavier - (genre montage Paco, je n'ai pas encore vu d'arduino pour ça) Coté Locoduino, le S88 est bien vu, relayé par un bus CAN apparemment plus robuste.

Merci pour vos réponses et à bientot.

[jpp38]

@msport.

Merci pour ta réponse détaillée. En effet, j'avais lu trop vite, et la commande 'a' n'avais pas retenu mon attention.
En fait, c'est exactement celle-là qu'il me faudrait, vu que je gère mes listes d'aiguilles, signaux et détecteurs dans la DLL. Pas besoin d'EEPROM.
Par contre, il n'y a pas de retour (pas de réponse / accusé de prise en compte)? Ca pour moi, c'est prohibitif, surtout pour des aiguillages.

Pour l'Emergency stop, je le ferai en envoyant la commande individuelle à chacune de toutes les locos enregistrées.

@Xavier:

Très bien ce que tu as fait. Juste une suggestion: ce serait de rapporter l'état de la chaine en hexa, pas en binaire, ce qui limiterait la chaine de caractères d'état à 32 caractères, au lieu de 128, si on monte à 128 zones.

Ce qui serait bien aussi, ce serait d'avoir une commande de requête d'état, pour envoyer la même chaîne. En fait, dans CDM-Rail, j'utilise les deux mécanismes, car j'ai déjà vu (sur centrale Lenz), des "feedbacks" de rétrosignalisation manquants. Donc, je fais du polling en plus, quand la loco est en attente de synchro.

JP

[Xavier]

Bonsoir Jean-Pierre,

Actuellement au ski, je n'ai pas les outils, mais je regarde dès que possible pour passer en Hexa.
Je vais aussi voir pour ajouter la demande d'état dans un deuxième temps.

Amicalement,

Xavier

[jpp38]

Salut Xavier,

Bon ski! Au moins, tu as de la bonne neige!

Amicalement.

JP

[msport]

Par contre, il n'y a pas de retour (pas de réponse / accusé de prise en compte)? Ca pour moi, c'est prohibitif, surtout pour des aiguillages.

Bonsoir à tous,
un petit test avec mon sketch de manette "accessoires" donne une réponse à chaque commande <a ...> <p1>, aussi bien à l'activation qu'à la désactivation car je la fais précéder de <1> (cf .ino).
Solution de contournement, tout shuss ...
Si on veut être sur du résultat, il faudrait récupérer l'info aux bornes du décodeur et la remonter par le S88, ou si ils existent par les fins de courses des aiguillages.
Peut-être vaudrait-il mieux ne pas trop compliquer ?

[jpp38]

Bonjour

Merci pour la réponse.

Si on veut être sur du résultat, il faudrait récupérer l'info aux bornes du décodeur et la remonter par le S88, ou si ils existent par les fins de courses des aiguillages.
Peut-être vaudrait-il mieux ne pas trop compliquer ?

Ca, c'est une usine à gaz. Non. je reste sur l'approche EEPROM.

Bonne journée.

JP

[msport]

- chez moi, la commande <e> (effacement de l'EEPROM) ne fonctionne pas.

Bonjour,
Effectivement, pour moi non plus. Mais la modification dans l'EEPROM reste possible.
Si vraiment besoin, Il faudrait utiliser le sketch :
https://www.arduino.cc/en/Tutorial/EEPROMClear, en le modifiant pour écrire des 255 et non des 0.

- si on envoie un état autre que 0 ou 1 sur une aiguille (déjà en EEPROM), il la prend en compte en mettant l'état 1. Mais après, les commandes envoyées à cet aiguille ne passent plus. Il faut refaire la déclaration d'identité.
Et pourquoi avoir mis cette identité, alors que l'adresse de l'accessoire (aiguillage, signal) est faite pour ça?.... ce qui oblige à gérer en interne à la DLL les listes correspondantes.

Par contre, là je ne comprends pas la question. Pourquoi envoyer autre chose que 0 ou 1 à une aiguille ? Si il s'agit d'une autre sortie de décodeur, il faut changer la sous adresse. Je n'ai pas de problème : si avec <T 10 1 0> on a enregistré un aiguillage n°10 à l'adresse 0:1 , <T 10 1> (réponse <H10 1>) envoie bien un ordre unique à l'accessoire 1 1:0, sortie 1, comme vérifié avec un sniffer, ordre qui peut être répété, et <T 10 0> (réponse <H10 0>) envoie bien un ordre unique à l'accessoire 1 1:0, sortie 0.
Effectivement, utiliser les commandes et réponses prévues pour serait quand même mieux.
Encore merci pour ce travail.

PS : la norme n'a pas fait dans la simplicité : partant d'une numérotation linéaire, elle s'est ingéniée à inventer des adresses : sub-adresses pour sauter de 4 en 4.
1 = 1:0
2 = 1:1
3 = 1:2
4 = 1:3
5 = 2:0
6 = 2:1
etc

[jpp38]

Par contre, là je ne comprends pas la question. Pourquoi envoyer autre chose que 0 ou 1 à une aiguille ? S

Ca peut arriver sur erreur de transmission. Et comme il n'y a pas de code de parité ou autre, on est en boucle ouverte là-dessus.
Bon! on va faire avec. Mais ce protocole est vraiment très très basique, et pas vraiment pensé pour une sécurité de fonctionnement.