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
Cette vidéo est une démo pour MT en général.
Ce téléchargement est une démo spécifique au MAP, il inclut un projet MT (v5.7.2) et une version KNX virtuel dédiée.
Le projet MT contient 3 programmes d'application avec exactement la même fonctionnalité, la même mise en page de mémoire et la même boîte de dialogue de paramètre ETS pour un variateur avec le numéro d'application 0201h:
- Version 01h de l'application : il s'agit d'un programme d'application 'standard', c'est-à-dire qu'il n'utilise aucun module
- Version 02h de l'application : ceci est un programme d'application modulaire, c'est-à-dire qu'il contient 8 instances d'un module créées manuellement
- Version de l'application 03h : ce programme d'application modulaire utilise le même module que dans la version 02h, mais les 8 instances sont créées via 1 répétition et 3 éléments d'allocation
Le variateur peut être testé via un projet de test ETS en combinaison avec la version KNX virtuel dédiée .