Motivation
Le modèle de données ETS traditionnel n'est pas efficace pour les appareils contenant de nombreuses copies d'une structure essentiellement identique ni pour les structures configurables. Cela est souvent le cas pour les appareils possédant de nombreux canaux (p. ex. passerelles) ou des appareils hautement configurables (p. ex. capteurs avec affichage tactile).
Le problème ici est que toutes les données possibles doivent être explicitement incluses dans les données du projet, ce qui présente les désavantages suivants :
- Programmes d'application inutilement grands (avec de longs temps d'importation et de chargement et une consommation élevée en ressources – y compris des exceptions de dépassement de mémoire – dans ETS)
- Risque de bogues introduits lors de la copie manuelle des données dans MT.
- Gaspillage de ressources de l'appareil (p. ex. dans la table d'objets) parce que chaque canal (ou structure similaire) doit fournir la taille maximum des données contenues.
- Cet article présente des suggestions d'amélioration du modèle de données ETS pour tirer parti de programmes d'application régulièrement structurés grâce à une approche plus modulaire.
Cela offre l'avantage supplémentaire qu'il est plus facile de construire de nouveaux programmes d'application à partir de blocs de construction déjà disponibles, testés et éventuellement traduits.
La plupart de ces sujets ont un impact direct sur les coûts et la qualité des produits.
Exemples
Écran tactile universel avec mémoire - paramètres mapppés
Considérons un écran tactile capable d'afficher jusqu'à 100 commandes, dont chacune est soit une fonction marche/arrêt, une fonction de variation ou une fonction d'obturation.
La fonction marche/arrêt est une réalisation du FB 'Light Switching Sensor Basic' avec deux objets de groupe (SwitchOnOff et InfoOnOff) et quelques paramètres. Un des paramètres est l'étiquette label qui doit être affichée sur le bouton dans l'UI.
La fonction de variation est une réalisation du FB 'Dimming Sensor Basic' avec trois objets de groupe (SwitchOnOff, InfoOnOff, Relative Setvalue Control) et quelques paramètres. Un des paramètres est l'étiquette label qui doit être affichée sur le bouton dans l'UI.
La fonction d'obturation est une réalisation du FB Shutters and Blinds Sunblind Sensor Basic' avec deux objets de groupe (Move Up Down et StopStep Up Down) et quelques paramètres. Un des paramètres est l'étiquette qui doit être affichée sur le bouton dans l'UI.
Passerelle
Avec l'aide d'un DCA script de gestionnaire de bouton, le nombre et le type d'appareils connectés à une passerelle sont déterminés. Pour chaque appareil détecté, un module est mis en place : un module de type 1 pour les appareils du type 1 et ainsi de suite.
Outil de fabricant
Vous trouverez plus de détails dans l'aide (c'est-à-dire l'aide locale) de l'outil du fabricant (à partir de 5.7).
This download is a MAP specific demo, it includes a MT (v5.7.2) project and a dedicated KNX Virtual version.
The MT project contains 3 application programs with the exact same functionality, exact same memory layout and the exact same ETS parameter dialog for a dimmer with Application Number 0201h:
- Application Version 01h: this a 'regular' application program, i.e. it does not use any module
- Application Version 02h: this a modular application program, i.e. it contains 8 manually created instances of a module
- Application Version 03h: this modular application program uses the same module as in version 02h, but the 8 instances are created via 1 repeat and 3 allocator elements
The dimmer can be tested via an ETS Test Project in combination with the dedicated KNX Virtual version.