Vous trouverez ci-dessous les différences de la version 3.00 par rapport à la version 0.0.2.3
Un nouveau manuel est également disponible pour la version 3.00
Les versions OC32 0.0.3.x sont des versions temporaires/bêta qui sont devenues caduques à partir de la version 3.00 et ne sont plus prises en charge. La version 3.00 est donc plus récente que la version 0.0.3.x
Attention : Le micrologiciel OC32 ainsi que l’OC32Config ont été considérablement modifiés :
La configuration du dispositif OC32 a été considérablement remaniée. Auparavant, une définition de dispositif pouvait être chargée, mais cette définition devenait ensuite un ensemble de broches individuelles dans l’OC32Config et l’OC32.
À partir de la version 3.00, l’OC32Config et l’OC32 reconnaissent la cohérence des broches en tant que « dispositif ». Cela permet à l’OC32Config d’écrire toutes les définitions appartenant à ce dispositif vers l’OC32 et de les relire depuis l’OC32 en un seul clic. Le nombre de boutons dans l’OC32Config sous « Configuration du dispositif » pour écrire et lire les définitions vers/depuis l’OC32 a donc été fortement réduit, ce qui, nous l’espérons, rendra l’utilisation beaucoup plus claire pour les « utilisateurs normaux ». Les anciens boutons existent toujours, mais ils sont cachés derrière un « mode expert ».
Dans l’OC32Config, la possibilité a été ajoutée d’enregistrer un dispositif créé ou modifié en tant que DeviceDefinition sur le système de fichiers de votre PC
Vous pouvez attribuer à un OC32 une « adresse étendue » (eXtended Address) de 0 à 95. L’adresse de module normale devient alors une adresse de canal (Channel Address). L’adresse étendue forme, avec l’adresse de canal, une adresse unique. De cette manière, 16 * 96 = 1 536 adresses de modules sont disponibles.
En pratique, vous n’utiliserez jamais toutes ces adresses. L’idée est d’utiliser soit l’adressage normal, soit l’adressage étendu sur un seul canal. Sinon, cela devient très confus. Vous pouvez toutefois utiliser judicieusement les numéros de canaux : utilisez par exemple le canal 1 pour la commande normale (opérationnelle). Si vous avez déjà un certain nombre de modules OC32 actifs (sur le canal 1) et que vous souhaitez ajouter un module supplémentaire, vous réglez ce module sur le canal 0. Vous pouvez alors configurer ce module, lui attribuer l’adresse étendue souhaitée, etc. Une fois terminé, vous réglez le module sur le canal 1 et il peut rejoindre les autres.
L’attribution d’une adresse étendue à un module se fait avec l’OC32Config dans l’onglet « Général ». Il est préférable de le faire alors que vous n’utilisez pas l’adressage étendu pour ce module spécifique. En effet, si vous voulez attribuer une adresse à un module qui n’a pas encore d’adresse étendue connue, ce module ne saura pas à quelle adresse étendue il doit répondre. C’est pourquoi il est également pratique de réserver un canal séparé à cet effet.
Le choix de l’adresse étendue du module avec lequel vous souhaitez réellement communiquer s’effectue en haut de la fenêtre de l’OC32Config.
En plus d’une adresse étendue, il existe également un masque de groupe étendu (eXtended Group Mask). Il sera bientôt possible de commander certaines fonctions de l’OC32 par groupe de modules. Vous enverrez alors une telle commande à un groupe au sein d’un canal. Chaque OC32 peut être membre d’aucun, d’un ou de plusieurs groupes. 16 groupes sont définis.
De nombreux systèmes numériques ne seront pas encore capables de commander l’OC32 au moyen de l’adressage étendu. Au moment d’écrire ces lignes, aucun système n’en est capable, pas même Dinamo. Certains systèmes ne le pourront probablement jamais, car ils ne sont plus développés, comme par exemple Koploper.
Vous pouvez communiquer avec l’OC32 via 2 protocoles. Bien que ces protocoles puissent être utilisés simultanément, ils sont fondamentalement différents. Pour la configuration et les tests de l’OC32, l’OC32Config utilise le protocole OC32. Les logiciels de commande opérationnelle peuvent également utiliser ce protocole OC32. Le protocole OC32 est bidirectionnel et permet désormais (voir ci-dessus) l’adressage étendu, afin que vous disposiez de suffisamment d’adresses pour tout commander.
De plus, l’OC32 comprend l’« ancien » protocole OM32. Le protocole OM32 ne connaît pas l’adressage étendu et est limité à 16 modules * 32 broches, soit 512 « sorties ».
Avec l’adressage flexible OM32, nous utilisons l’espace d’adressage des 512 adresses comme un espace d’adressage linéaire. Les adresses ne sont donc plus réparties sur 16 modules, mais vous pouvez répartir ces adresses arbitrairement sur autant de modules que vous utilisez, à condition que le nombre total d’adresses nécessaires ne dépasse pas 512. En pratique, cela permet souvent une utilisation nettement plus efficace des adresses. En effet, un signal néerlandais à 3 feux occupe 3 broches, mais peut être commandé via 1 adresse. Un signal de sortie allemand avec signal avancé occupe 9 broches, mais peut être commandé avec 1 adresse. En d’autres termes : presque chaque « dispositif » occupe plusieurs broches et donc, dans l’« ancienne » situation, plusieurs adresses, mais peut être commandé via 1 seule adresse.
Vous pouvez désormais attribuer de 0 à 6 adresses OM32 à chaque broche. Vous donnez 1 adresse à la première broche du dispositif, et 0 adresse aux broches suivantes. Vous indiquez au module OC32 la première adresse OM32 à laquelle il doit répondre. L’OC32 calcule ensuite lui-même l’adresse OM32 avec laquelle le dispositif concerné peut être commandé.
Vous pouvez calculer cette adresse, mais elle est également affichée dans l’onglet de configuration de l’OC32Config à côté du numéro de broche. La condition est toutefois que vous ayez rempli ET activé l’adresse de départ flexible OM32 (OM32 Flex Start-Address) dans l’onglet « Général ». Si l’adresse de départ flexible OM32 n’est pas activée, l’OC32 fonctionne à l’ancienne avec les adresses OM32, quel que soit le nombre d’adresses que vous avez attribuées à chaque broche !
L’adressage flexible OM32 fonctionne également dans l’autre sens. Parfois, un dispositif n’utilise qu’une seule broche, mais vous avez besoin de plusieurs adresses pour commander les fonctions. Par exemple, un Wissel MCC à 3 voies, commandé par un servo. Si vous voulez le commander depuis Koploper, vous avez besoin d’au moins 2 adresses. Vous pouvez résoudre cela dans l’OC32 en effectuant une redirection depuis une autre broche inutilisée, mais c’est parfois peu pratique ou même impossible, par exemple si vous avez beaucoup de dispositifs de ce type sur un seul OC32. Vous avez alors en fait besoin de plus que les 32 adresses disponibles par OC32. Avec l’adressage flexible OM32, cela est possible en attribuant plusieurs adresses à une broche.
Il existe une restriction importante avec l’adressage flexible OM32. Si cette fonction est activée, une seule commande OM32 fonctionne encore : « Set Aspect ».
Pour la première adresse attribuée à une broche, les Aspects sont liés un à un, donc l’Aspect 0 commande la position 0, l’Aspect 1 commande la position 1, etc. Pour l’adresse suivante, l’Aspect 0 commande la position 2, l’Aspect 1 commande la position 3, etc. Pour une éventuelle adresse suivante, l’Aspect 0 commande la position 4, l’Aspect 1 la position 5, etc.
L’adressage DCC flexible fonctionne de la même manière que l’adressage flexible OM32 décrit ci-dessus. Vous pouviez/deviez déjà régler l’adresse de départ DCC, donc rien n’a changé à ce niveau. Ce qui a été ajouté est la possibilité d’attribuer de 0 à 6 adresses DCC à chaque broche. Ainsi, vous pouvez économiser des adresses DCC ou, inversement, attribuer plusieurs adresses DCC à un dispositif sans avoir à utiliser de redirections. En DCC, c’est encore plus important qu’avec l’adressage série, car malheureusement presque aucun système DCC ne peut générer des paquets « Extended Accessory Decoder Packets », qui permettent de mettre 1 adresse DCC dans 32 positions. Vous êtes donc contraint, dans presque tous les cas, de vous rabattre sur les positions « voie directe » et « déviée », soit seulement 2 par adresse DCC.
Étant donné qu’iTrain prend désormais en charge les paquets DCC Accessory étendus en combinaison avec certaines centrales, les possibilités de l’OC32 ont été optimisées à cet effet.
Vous avez maintenant la possibilité d’attribuer séparément des adresses DCC de base (Basic) et des adresses DCC étendues (Extended). L’OC32 dispose donc désormais non seulement d’une adresse de départ DCC, mais aussi d’une adresse de départ XDCC. Basic et Extended sont donc 2 espaces d’adressage différents que vous pouvez utiliser tous les deux, si vous le souhaitez, de manière mixte.
À chaque broche OC32, vous pouvez désormais attribuer, en plus d’un maximum de 6 adresses DCC, au maximum 1 adresse XDCC.
En ce qui concerne le comptage, la spécification DCC est extrêmement peu claire, surtout concernant le démarrage à l’adresse 0 ou 1. Cela devient encore plus complexe car un décodeur d’accessoires DCC de base possède en fait 4 adresses avec chacune 2 sorties ayant chacune 2 états. Il n’est donc pas clair si le décodeur 1 commence à l’adresse 0, 1, 4 ou 5. Après consultation avec, entre autres, iTrain, l’implémentation suivante a été choisie pour l’OC32 :
Si vous utilisez vos OC32 aussi bien pour des accessoires ferroviaires que pour des accessoires routiers ou pour l’éclairage jour/nuit, cette combinaison permet une économie encore plus importante. Supposons que vous commandiez vos accessoires de train avec le DCC, vos accessoires de voiture avec le RS485 et la simulation jour/nuit de manière autonome ou via les entrées ETI. Dans ce cas, il vous suffit désormais d’attribuer des adresses DCC aux dispositifs qui doivent pouvoir être commandés via le DCC et des adresses OM32 Flex aux dispositifs commandés via le RS485.
Il était déjà possible d’activer les événements (Events) définis pour les entrées de déclenchement (Trigger Inputs) par logiciel (depuis une définition d’Aspect) au moyen d’une instruction « soft-event ». Les possibilités d’utilisation des entrées de déclenchement d’événements (Event Trigger Inputs) ont été considérablement élargies :
En raison de l’extension des possibilités, l’onglet « Configuration d’événement » de l’OC32Config a été considérablement simplifié. Cela semble contradictoire, mais avec toutes les nouvelles options, cela ne tenait tout simplement plus dans la fenêtre. Vous devez maintenant configurer les paramètres broche par broche. Cela présente des avantages et des inconvénients.
Il est désormais possible de configurer une broche (donc une ou plusieurs des 32) comme entrée. Cela permet notamment d’utiliser l’OC32 comme unité de commande autonome pour les réseaux miniatures analogiques sans commande par PC. Bien entendu, vous avez besoin d’un PC pour configurer l’OC32, mais une fois cela fait, vous pouvez commander les fonctions de l’OC32 via des boutons-poussoirs, des contacts reed, des interrupteurs ou d’autres signaux externes connectés à un certain nombre de broches de l’OC32. C’est en quelque sorte une extension des entrées d’événements que les OC32/FULL et OC32/ETI possédaient déjà, seule la fonction est légèrement différente.
Pour pouvoir utiliser une broche comme entrée, un réseau de résistances doit être placé dans le groupe de broches concerné et cela doit également être configuré ainsi dans la configuration matérielle (onglet Général).
ATTENTION : La tension d’entrée sur une broche ne doit jamais dépasser +5 V ou être inférieure à 0 V, sinon cela peut endommager le processeur de manière irréparable ! Pour minimiser le risque de dommage, il est préférable de choisir un réseau de résistances avec une valeur de résistance un peu plus élevée, par exemple 470 ohms ou 1 k, à condition bien sûr que cela soit possible pour l’utilisation des autres broches du groupe.
Une entrée est Active (1) ou Inactive (0). La broche peut être active à l’état haut (normale) ou active à l’état bas (inversée). Active à l’état haut signifie que la broche est considérée comme Active si le signal d’entrée est supérieur à 4 V. La broche est considérée comme Inactive si le signal d’entrée est inférieur à 1 V. Active à l’état bas est l’inverse. Avec le réglage actif à l’état bas (inversé), l’OC32 génère un « Pull-Up ». Cela signifie que la broche est « haute » (donc Inactive) si rien n’est connecté. Dans ce cas, vous pouvez simplement connecter un interrupteur ou un bouton-poussoir entre la broche et la masse (GND). Interrupteur/bouton fermé est alors Actif, interrupteur/bouton ouvert est Inactif. Avec le réglage non inversé, l’état est indéfini si rien n’est connecté à la broche.
Un interrupteur mécanique « rebondit » (presque) toujours lors de la commutation. C’est pourquoi l’OC32 intègre une fonction anti-rebond (« debounce »). L’OC32 vérifie alors plusieurs fois de suite si l’entrée est réellement Active ou Inactive avant de tirer cette conclusion. Ce délai est appelé ON-delay et OFF-delay et peut être réglé par broche via l’OC32Config. Par défaut, le délai est de 4, soit environ 100 ms. Si vous avez des problèmes d’entrées qui rebondissent, vous pouvez augmenter ces valeurs. Généralement, si cela est nécessaire, seule l’augmentation du OFF-delay suffit. Si vous voulez que l’OC32 réagisse à des impulsions très courtes, vous devrez diminuer (l’une de) ces valeurs.
L’activation d’une broche déclenche l’Aspect 1 de la broche concernée. La désactivation déclenche l’Aspect 0 de la broche concernée. Via la configuration d’Aspect, vous pouvez donc définir vous-même entièrement ce qui doit se passer lorsque l’entrée devient Active ou Inactive.
Auparavant, l’OC32 ne pouvait que recevoir des commandes d’un système numérique ou d’un PC. Désormais, l’OC32 peut également signaler des événements au PC. La condition est que la connexion avec l’OC32 soit en RS485.
Le signalement d’un événement n’est rien de plus ou de moins qu’une instruction dans une définition d’Aspect. Ainsi, un signalement peut être activé par exemple par un changement d’état d’une broche configurée en entrée, mais aussi à certains moments lors du déroulement d’une séquence.
Avec le PM32, vous pouvez commander 64 Wissels (128 bobines) avec 24 fils.
La même technique est désormais intégrée à l’OC32. L’OC32 dispose maintenant d’une instruction permettant de commander les Wissels de manière séquentielle par multiplexage. Pour pouvoir l’utiliser, un certain nombre de broches doivent être équipées de pilotes de source (source drivers) et d’autres de pilotes de dissipation (sink drivers). Dans la plupart des cas, vous devrez amplifier les sorties avec des transistors sur un DS32. Le nombre de broches que vous utilisez est flexible, par exemple :
Les deux premières options sont évidemment sans intérêt, mais une définition de dispositif sera créée pour les 3 dernières options.
Les broches qui ne sont pas utilisées pour le multiplexage peuvent bien entendu être utilisées pour d’autres fonctions.
L’OC32 possède 2 ports série : RS485 et RS232/TTL. Ce dernier ne pouvait que recevoir. Bien entendu, ce port possède une capacité d’émission, mais elle n’était pas exploitée par l’OC32. Avec « SendSerial », ce port peut envoyer des données à des appareils externes, tels que des lecteurs MP3 et toutes sortes d’autres choses que vous pouvez commander avec des commandes série simples.
Si vous utilisez la fonction SendSerial, vous ne pouvez plus utiliser le port RS232 de l’OC32 pour commander votre OC32 lui-même. Cela signifie que la commande doit alors se faire via RS485 ou DCC (ou les deux). Le port RS232 continue de fonctionner, mais il commencera à perdre des paquets pendant l’émission avec « SendSerial »
Les instructions suivantes avaient déjà été déclarées « obsolètes » et sont un héritage de l’époque de l’OM32. Ces instructions sont désormais définitivement supprimées :
Ce que ces fonctions faisaient peut aujourd’hui être réalisé de manière plus efficace et plus flexible avec des instructions de séquence.
