# SW-Beschreibung URL: https://irs.systems/docs/messy/sw-description Im folgenden Kapitel wird das Softwarekonzept vorgestellt: zunächst ein allgemeiner Überblick, dann Blockschaltbilder der SW-Subsysteme, eine Beschreibung der Kommunikation zwischen den SW-Subsystemen und schließlich eine kurze Funktionsbeschreibung der Funktionsblöcke. Für Lebensdauertests wird Software zur Testkonfiguration, Datenaufzeichnung und Testausführung benötigt. Diese Softwareteile werden in diesem Dokument nicht beschrieben. IRS bietet eine vollständige SW-Lösung für Lebensdauertests an, die zusätzlich zu der im folgenden Kapitel beschriebenen Software Folgendes enthält: - PC-Host-Software - Benutzeroberfläche (GUI) - TestStand Controller (TSC) - TestStand einschließlich Prüfablauf, der auf die API-Funktionen des Messsystems zugreift Für eine Beschreibung dieser Softwareteile wenden Sie sich an IRS. Für das Messsystem werden im folgenden Kapitel diese Subsysteme vorgestellt: - PC-Host-Software - Basiskommunikation zum Messsystem (Kommunikation PC zu RT) - SW zum Steuern und Abfragen der einzelnen Funktionsblöcke - Signalzuordnung für den Zugriff auf Analog-, Digital- und Kommunikationskanäle über den DUT-spezifischen Signalnamen - Messsystem-Software: - LabVIEW-RT-Software, die auf dem RT-Controller des sbRIO läuft - LabVIEW-FPGA-Software, die auf dem FPGA des sbRIO läuft - Mikrocontroller-Software, die auf dem Mikrocontroller der Kommunikationsplatine läuft ## SW-Schichten im Lebensdauertest Das folgende Blockschaltbild zeigt die verschiedenen Softwareschichten eines typischen Lebensdauerprüfstands mit Schwerpunkt auf der Messsystem-Software (gelb). Die blau markierten SW-Teile sind die generische IRS-Benutzeroberfläche und TestStand von National Instruments. ![Softwareschichten eines Lebensdauerprüfstands: LDSA-GUI, TestStand Controller und Sequenz, Hardware-Abstraktionsschichten (Messsystem-API mit benannten Kanälen, Messsystem-API), Kommunikation PC zu MesSy, LabVIEW RT, Kommunikation RT zu FPGA, LabVIEW FPGA, Messsystem-Hardware und Hardware externer Systeme](/docs/assets/messy/images/messy-sw-layers.png) ## Embedded Software des Messsystems ![Embedded Software des Messsystems: Messsystem-API und Hardware-Abstraktionsschicht auf dem PC, generische Kommunikation über die NI-STM-Bibliothek, RT-Datenverarbeitung mit CAN-Command-Response-Handling und Sub-Sequencer, generische Kommunikation über DMA-FIFOs, FPGA-Datenverarbeitung (PWM-Generator, kontinuierliche Analogüberwachung), Hardwaresteuerung und Hardware](/docs/assets/messy/images/messy-embedded-sw.png) ### Übersicht FPGA-SW Das nächste Blockschaltbild zeigt das gesamte FPGA-Design mit seinen Funktionsblöcken, das auf dem FPGA des sbRIO läuft: ![LabVIEW-FPGA-Blockschaltbild mit Analogabtastung, allgemeiner Systemsteuerung (HW-Version, SW-Version, Temperatur, LED), Systemtimer, Command-Handler RT zu FPGA, statischen Digitalausgängen, PWM-Erzeugung, Analog Signal SuperVision (SSV), Mikrocontroller-Kommunikation (CAN, seriell) und Abfrage des Strommessmoduls](/docs/assets/messy/images/messy-fpga-overview.png) Das Blockschaltbild enthält mehrere Sub-VIs, die die gesamte FPGA-Datenverarbeitung gemäß der folgenden VI-Hierarchie übernehmen: ![FPGA-VI-Hierarchie mit FPGA-Top-Level-Design, Systemtimer, Command-Handler RT zu FPGA, Analog Signal SuperVision (SSV), Mikrocontroller-Kommunikation, PWM-Erzeugung, Analogabtastung, Abfrage des Strommessmoduls, EEPROM lesen/schreiben und statischen Digitalausgängen](/docs/assets/messy/images/messy-fpga-vi-hierarchy.png) Die Sub-VIs werden nicht im Detail beschrieben, da dies den Rahmen dieses Dokuments sprengen würde. Um die Funktionsweise der Blöcke zu verstehen, sollte der Quellcode untersucht werden. ### Übersicht RT-SW Das folgende Blockschaltbild zeigt das Top-Level-RT-Design, das auf dem RT-Controller des sbRIO läuft: Nach dem Einschalten initialisiert die RT-SW die FPGA-Referenz und nimmt alle DMA-Kanaleinstellungen für die Kommunikation mit dem FPGA vor. Anschließend wartet die RT-SW auf eine Verbindungsanfrage vom Host-PC. Nachdem die Verbindung aufgebaut ist, wartet die RT-SW stets auf einen auszuführenden Befehl vom Host-PC. Bei jedem Befehl (z. B. Digitalausgänge setzen, Analogwerte anfordern, CAN-Befehl senden, …) werden die folgenden Schritte ausgeführt: - Command-Handler aufrufen - Parameter lesen - Befehl ausführen - Antwort zurückgeben Nachdem der Host-PC die Verbindung geschlossen hat, wird die Schleife, die auf einen Befehl wartet, abgebrochen, die Ethernet-Verbindung geschlossen, und die RT-SW wartet erneut auf eine neue Verbindung zum PC-Host. Derzeit sind für die RT-SW keine weiteren Tasks erforderlich. Es gibt mehrere Möglichkeiten, diese Software zu erweitern, unter anderem durch parallele Tasks für Berechnungen, die Ausführung von Modellen, … ![Top-Level-RT-Design: Initialisierung und Lesen der internen SW-Versionen, Hintergrundschleife zur Prüfung der PC-Host-Verbindung im Sekundentakt, neue PC-Host-Verbindung öffnen, gültige PC-Host-Verbindung prüfen, auf Befehl warten, Befehl ausführen, Antwort zurückgeben, Deinitialisierung nach dem Schließen der Verbindung, Hintergrundtask zur Steuerung der RunState-LED, Aufräumcode](/docs/assets/messy/images/messy-rt-overview.png) Das Blockschaltbild enthält mehrere Sub-VIs, die die gesamte RT-Datenverarbeitung gemäß der folgenden VI-Hierarchie übernehmen: ![RT-VI-Hierarchie](/docs/assets/messy/images/messy-rt-vi-hierarchy.png) Die Sub-VIs werden nicht im Detail beschrieben, da dies den Rahmen dieses Dokuments sprengen würde. Um die Funktionsweise der Blöcke zu verstehen, sollte der Quellcode untersucht werden. ### Kommunikation RT zu FPGA #### Kommunikation über Read/Write-Controls Befehle, die keine größeren Datenblöcke von RT an das FPGA oder umgekehrt übergeben müssen, verwenden einfache Read/Write-Controls, um Daten an das FPGA zu senden oder vom FPGA zu lesen. Als Beispiel sehen Sie hier den Case des Command-Handlers zum Setzen der Digitalausgänge aus RT-Sicht: ![Command-Handler-Case DIG_REL_SetAll: Befehlsparameter entpacken und das RW-Control DIG_REL_1to64 in das FPGA schreiben](/docs/assets/messy/images/messy-rt-rw-controls.png) Alle verfügbaren Read/Write-Controls (Temperatur, Digitalausgänge, Zeitstempel, Reset, CMM, …) zeigt auch das FPGA-Blockschaltbild in [Kapitel 5.2.1](/docs/messy/sw-description#uebersicht-fpga-sw). #### Kommunikation über DMA aus FPGA-Sicht Zur Übergabe größerer Datenblöcke von RT an das FPGA oder umgekehrt können DMA-Kanäle verwendet werden. Die folgende Struktur, die sich in der Abbildung in [Kapitel 5.2.1](/docs/messy/sw-description#uebersicht-fpga-sw) findet, übernimmt die DMA-Kommunikation: ![Struktur FPGA_COMM: DMA-FIFO RT zu FPGA in den Puffer RT zu FPGA lesen, FPGA_command_handler mit Pufferinhalt RT zu FPGA und FPGA zu RT (Befehl, Datenlänge N, reserviert oder Fehlercode, Datenbytes), befehlsspezifische Ausführung, DMA-FIFO FPGA zu RT schreiben; Signale Communication_Request und Communication_Ready](/docs/assets/messy/images/messy-dma-fpga.png) #### Kommunikation über DMA aus RT-Sicht Für die Kommunikation von RT zum FPGA werden die folgenden Schritte ausgeführt: ![RT-Seite der DMA-Kommunikation: Befehlsanforderung zurücksetzen, DMA-FIFO RT zu FPGA leeren, warten, bis das FPGA zur Kommunikation bereit ist, Befehl senden, DMA-FIFO FPGA zu RT lesen, bis die gesamte Antwort gesendet wurde, Befehlsanforderung zurücksetzen, im Fehlerfall Fehlercode hinzufügen](/docs/assets/messy/images/messy-dma-rt.png) ## Kommunikation PC zu RT ### STM-Bibliothek Die Kommunikation zwischen der PC-Host-Schnittstelle und dem RT-Controller des Messsystems erfolgt über eine Ethernet-Verbindung. Implementiert ist ein Protokoll auf Basis der STM-Bibliothek von National Instruments, das das TCP/IP-Protokoll verwendet. Jedes von der STM-Bibliothek verarbeitete Befehls- oder Antwortpaket enthält den folgenden Datenstring: ![STM-Datenstring: Data Size (32 Bit), Meta Data ID (16 Bit), Data](/docs/assets/messy/images/messy-stm-data-string.png) Das Befehlsfeld „Metadata“ ist eine ID, die ein Element des Arrays gültiger Befehle darstellt. Die folgende Abbildung zeigt ein Beispiel der verwendeten Befehle des Messsystems. Die Metadaten werden einmalig vom PC-Host an das RT-Target übertragen, nachdem der Host-PC die Verbindung aufgebaut hat. So ist sichergestellt, dass PC und RT dieselben gültigen Befehle mit denselben IDs kennen. ![Array gültiger Befehle (MetaData): Befehle ACK, SUBSEQUENCE, SYS_, ANA_, DIG_, PWM_, SSV_, CMM_, EEPROM_, SPI_ und CAN_](/docs/assets/messy/images/messy-stm-metadata.png) ### Normale Befehlsausführung aus PC-Sicht Normale Befehlsausführung bedeutet, dass der PC einen Befehl sendet. RT führt den Befehl aus und sendet sofort eine Antwort. Aus Sicht des PC werden die folgenden Schritte ausgeführt: 1. Parameter in den Befehlsstring packen: - Dieser Schritt ist befehlsspezifisch und bedeutet, alle Befehlsparameter in einen String zu packen 2. Befehlsstring an RT senden: - Dieser Schritt ist in der generischen Kommunikationsroutine enthalten, die den Befehlsstring an das RT-Target sendet 3. Antwortstring von RT empfangen: - Dieser Schritt ist in der generischen Kommunikationsroutine enthalten, die auf den Antwortstring vom RT-Target wartet 4. Parameter aus dem Antwortstring entpacken: - Dieser Schritt ist befehlsspezifisch und bedeutet, alle Antwortparameter aus dem String zu extrahieren ![LabVIEW-Blockschaltbild eines Befehls aus PC-Sicht: 1. Parameter in den Befehlsstring packen, 2. Befehlsstring an RT senden, 3. Antwortstring von RT empfangen (generische Kommunikationsroutine, siehe Kapitel 5.3.3), 4. Antwortstring in Rückgabeparameter entpacken](/docs/assets/messy/images/messy-pc-command-execution.png) ### Slot-Adressierung Beachten Sie, dass bei jedem Befehl ein Slot-Parameter übergeben wird. Dieser Parameter dient dazu, mehrere Prüflinge an einem Messsystem zu unterscheiden. Bei Prüflingen mit nur wenigen Pins und Funktionen kann ein Messsystem bis zu 6 Prüflinge parallel bedienen. Wenn in diesem Fall mehr als eine Testausführung mit dem Messsystem verbunden ist, muss die Kommunikationsroutine die Verbindungen für die Testausführung jedes Prüflings prüfen. Sie darf die Verbindung erst schließen, wenn alle Testausführungen aller Prüflinge die Verbindung geschlossen haben. Der Slot repräsentiert also den Prüfling am Messsystem. ### Generische Kommunikationsroutine Die generische Kommunikationsroutine wird für jeden vom PC gesendeten Befehl verwendet. Die folgende Abbildung zeigt die Schritte dieser Routine. ![Generische Kommunikationsroutine: Befehlszähler hinzufügen, um sicherzustellen, dass die Antwort zum Befehl passt, Befehl senden (STM_Library), Antwort empfangen (STM_Library), auf Fehler prüfen und Befehlszähler prüfen](/docs/assets/messy/images/messy-generic-comm-routine.png) ### Normale Befehlsausführung aus RT-Sicht Die folgende Abbildung zeigt die Schleife für den Befehlsempfang, die kontinuierlich auf RT läuft: ![RT-Schleife für den Befehlsempfang: Verbindung prüfen, Befehlsstring lesen, auf normale Ausführung oder Sub-Sequencer-Ausführung prüfen, Command-Handler für die normale Ausführung, Antwortstring senden](/docs/assets/messy/images/messy-rt-command-loop.png) Der Command-Handler wählt den Befehl aus und führt ihn aus: ![RT-Command-Handler: Eingangsparameter aus dem Befehl, Parameter aus dem String extrahieren, abhängig vom Befehlstyp ausführen, verschiedene verfügbare Befehle, Antwortstring erstellen, im Fehlerfall Fehlercode hinzufügen](/docs/assets/messy/images/messy-rt-command-handler.png) ## Befehlsablauf ### Normale Befehlsausführung Die folgende Abbildung zeigt einen typischen Befehlsablauf aus PC-Sicht. In diesem Fall werden die Funktionen des Messsystems in einer LabVIEW-Anwendung verwendet: ![Typischer Befehlsablauf in LabVIEW: 1. Verbindung öffnen (Standardport ist 55555), 2. Safe-State-Timeout auf eine geeignete Größe setzen (PC_SYS_SetSbRioCmdWaitTimeout.vi), 3. je nach Anwendung mehrere Befehle aufrufen, 4. Verbindung beim Beenden der Anwendung schließen](/docs/assets/messy/images/messy-command-flow-labview.png) Dieselben Schritte sind erforderlich, wenn aus TestStand oder anderen Anwendungen auf das Messsystem zugegriffen wird. Die folgende Abbildung zeigt einen typischen Ausführungsablauf in TestStand ![NI TestStand Sequence Editor mit einem typischen Ausführungsablauf: Schritte Open PC_COMM, sbRIO_CMD_Wait_Timeout, Zeitstempel zurücksetzen, CMM, Version, Temperatur und CAN-Einstellungen, Schritteinstellungen von PC_SYS_ResetUc.vi](/docs/assets/messy/images/messy-command-flow-teststand.png) Schritt 1: Öffnen Sie die Verbindung, um die TCP-IP-Verbindung aufzubauen und die Metadaten zwischen PC und RT auszutauschen. Schritt 2: Rufen Sie „PC_SYS_SetSbRioCmdWaitTimeout.vi“ auf, um den „Safe-State“-Timeout auf eine geeignete Größe zu setzen. Dieser Timeout bedeutet Folgendes: Wenn das Messsystem (RT-SW) innerhalb dieser Timeout-Zeit keinen gültigen Befehl empfangen hat, schaltet die RT-SW alle Ausgänge ab, setzt die CAN-Controller zurück, trennt die TCP-IP-Verbindung und wartet auf eine neue Öffnungsanfrage. Dieser Timeout soll sicherstellen, dass das Messsystem in einen Ruhezustand zurückkehrt und den Prüfling abschaltet, wenn der PC abgestürzt ist. Der Standardwert dieses Timeouts beträgt 2 Sekunden. Der PC muss also alle 2 Sekunden einen Befehl senden. Das lässt sich nicht in allen Anwendungen erreichen. Insbesondere wenn der Benutzer Befehle durch Betätigen von Schaltflächen senden möchte, muss der Timeout auf höhere Werte gesetzt werden. Ein typischer Wert für ein unempfindliches Gerät wären 60 Sekunden. Geräte wie Fensterheber, die in einem unkontrollierten, aktiven Zustand beschädigt werden könnten, erfordern kürzere Timeouts, deutlich unter 5 Sekunden. Der Benutzer legt den geeigneten Timeout für seine Anwendung selbst fest. Schritt 3: (beliebig oft wiederholbar) Befehle gemäß der API-Beschreibung in [Messsystem-API (CORE_API)](/docs/messy/sw-description#messsystem-api-core-api) oder in [Lebensdauertest-API mit benannten Kanälen (TS_API)](/docs/messy/sw-description#lebensdauertest-api-mit-benannten-kanaelen-ts-api) können anwendungsspezifisch in beliebiger Weise gesendet werden. Schritt 4: Vor dem Beenden der Anwendung sollte die Verbindung geschlossen werden. Andernfalls würde das Messsystem weiterhin auf einen Befehl warten und nach der eingestellten Zeit in den „Safe-State“-Timeout laufen. Versucht der Benutzer, die Verbindung zum Messsystem erneut zu öffnen, während es noch läuft, würde ein Fehler gemeldet. Schließen Sie daher die Verbindung, bevor Sie die Anwendung beenden. ### Sub-Sequencer-Ausführung Der Sub-Sequencer ist dafür ausgelegt, Befehle schnell mit einem genau definierten Timing im Bereich weniger Millisekunden auszuführen. Beim Senden von Befehlen über die normale Befehlsausführung hängt das Timing zwischen den Befehlen vom Timing des Windows-Betriebssystems auf dem PC ab. Bei einem solchen Nicht-Echtzeit-Betriebssystem kann das Timing zwischen wenigen Millisekunden und mehreren Sekunden schwanken. Sub-Sequencer-Ausführung bedeutet, mehrere Befehle auf RT zu laden, sie ohne vom PC verursachte Verzögerungen auszuführen und mehrere Antworten an den PC zurückzugeben. Die Antworten können in der PC-SW mit unkritischem, schwankendem Timing ausgewertet werden. #### Befehlsablauf des Sub-Sequencers Um eine Subsequenz zu verwenden, muss der folgende Befehlsablauf implementiert werden ![Befehlsablauf des Sub-Sequencers: Ausführungsthread auf dem Host-PC mit optionalem Remove Subsequence, Create Subsequence, COMMAND_XXXX Add to Subsequence (für beliebig viele Befehle wiederholt), PC_SUBSEQUENCER_ExecuteSubsequence (auf RT herunterladen, ausführen und alle Antworten zurücklesen), COMMAND_XXXX GetResult; die RT-SW führt die Befehle von Sequence 1 aus und sammelt die Antworten in einem String-Array](/docs/assets/messy/images/messy-subsequencer-flow.png) #### Befehlsausführung des Sub-Sequencers aus RT-Sicht Aus RT-Sicht bedeutet Sub-Sequencer-Ausführung einfach, ein Array von Befehlsstrings vom PC zu empfangen. Das Array mit den einzelnen auszuführenden Befehlsstrings wird Element für Element abgearbeitet. Die Antworten der einzelnen Befehle werden in einem String-Array gesammelt und an den PC zurückgegeben. ![RT-Case des Sub-Sequencers: ein Array auszuführender Befehle erwarten, Schleife über alle Befehle im Befehls-Array, normale Befehlsausführung für jeden Schleifendurchlauf](/docs/assets/messy/images/messy-subsequencer-rt.png) #### Befehlsausführung des Sub-Sequencers aus PC-Sicht Aus PC-Sicht bedeutet Sub-Sequencer-Ausführung, die Einheit für die Befehls-/Antwortverarbeitung in drei Teile aufzuteilen: - Befehl zur Subsequenz hinzufügen (für mehrere Befehle wiederholt) - Gesamte Subsequenz ausführen - Antwort der Subsequenz abrufen (für mehrere Befehle wiederholt) Die Trennung zwischen normaler Befehlsausführung, Sub-Sequencer-„Load“ und Sub-Sequencer-„Get Result“ ist mit polymorphen VIs implementiert. Die Sub-Sequencer-Ausführung wird im Folgenden am Beispiel-VI „CAN_EOL_SendReceive.vi“ erläutert: Zunächst wird die normale Befehlsausführung von CAN_EOL_SendReceive.vi dargestellt, um den Unterschied zur Sub-Sequencer-Ausführung zu zeigen CAN_EOL_SendReceive, normale Ausführung: ![CAN_EOL_SendReceive, normale Ausführung: EOL-spezifische Datenverarbeitung für den Befehl, mehrere CAN-Nachrichten senden, Fehlerbehandlung der Antwort](/docs/assets/messy/images/messy-can-eol-normal.png) Can_SendMultipleMsgs: ![Can_SendMultipleMsgs: Nachricht in Befehlsstring umwandeln, generische Kommunikationsroutine (siehe Kapitel 5.3.3), Antwortstring in EOL-Nachricht umwandeln](/docs/assets/messy/images/messy-can-sendmultiplemsgs.png) Für die Sub-Sequencer-Ausführung müssen die drei farbig markierten Teile auf mehrere VIs aufgeteilt werden. Der Teil „Execute Subsequence“ ist generisch und kann von jedem Befehl verwendet werden. Für jeden Befehl müssen jedoch die folgenden Teile separat mit polymorphen VIs implementiert werden: - COMMAND_XXX_AddToSubsequence - enthält die Formatierung des Befehlsstrings und speichert den Befehlsstring im angegebenen Befehlscontainer der Subsequenz - COMMAND_XXX_GetResult - enthält das Lesen des Antwortstrings der angegebenen Sequenz und des angegebenen Schritts. Der formatierte Antwortstring wird entpackt und in die entsprechenden Antwortparameter umgewandelt. ***Add to Subsequence (befehlsspezifisch)*** ![Add to Subsequence: EOL-spezifische Datenverarbeitung für den Befehl und Umwandlung der Nachricht in einen Befehlsstring, Befehlsstring in die benannte Subsequenz mit benanntem Schritt laden](/docs/assets/messy/images/messy-subseq-add.png) ***Execute Subsequence (ein generisches VI für alle Befehle)*** ![Execute Subsequence: alle in die benannte Subsequenz geladenen Befehlsstrings zu einem String bündeln, alle Befehle der Subsequenz ausführen, alle von der Subsequenz als ein String zurückgegebenen Befehlsstrings wieder aufteilen](/docs/assets/messy/images/messy-subseq-execute.png) ***GetResult (befehlsspezifisch)*** ![GetResult: Befehlsstring aus der benannten Subsequenz mit benanntem Schritt laden, Antwortstring in EOL-Nachricht umwandeln und Fehlerbehandlung der Antwort](/docs/assets/messy/images/messy-subseq-getresult.png) ## Fehlerbehandlung ### Allgemeine Fehlerbehandlung Jedes implementierte VI hat einen Fehlereingang und einen Fehlerausgang. ![Frontpanel eines VI mit Eingängen (IP Address, Slot, Channel_Type, Channel_Nr, Nr_Samples), Ausgängen (Waveform) und den Fehlerclustern error in und error out mit status, code und source](/docs/assets/messy/images/messy-error-cluster.png) Alle VIs geben Fehlercodes im Cluster „error out“ zurück. Wird dem VI an „error in“ ein Fehler mit einem Fehlercode ungleich null übergeben, - wird der Code des VI nicht ausgeführt - wird der Fehlercode an „error out“ durchgereicht Es wird empfohlen, Fehlereingang und Fehlerausgang mit einem benutzerdefinierten Fehlerhandler in der Anwendung zu verbinden. So ist sichergestellt, dass die Kommunikation mit dem MesSy und alle Parameter geprüft werden und der Benutzer der Anwendung Informationen über den Status von MesSy und Software erhält. ### Fehlercodes Im Feld „code“ von „error out“ wird ein Fehlercode zurückgegeben, der entweder von einem VI der Standard-LabVIEW-Bibliothek oder von der MesSy-Software erzeugt wird. Werte unter 5000 einschließlich negativer Werte sind Standard-LabVIEW-Fehlercodes. Werte darüber sind MesSy-Fehlercodes. Die MesSy-Fehlercodes sind wie folgt gegliedert: | Bit 30..24 | Bit 23..16 | Bit 15…0 | | --- | --- | --- | | Klassifizierung | Quelle | Typ | Die **Klassifizierung** legt die Kritikalität des Fehlers fest, wobei ein Systemfehler als schwerer Fehler gilt. Ein DUT-Fehler bedeutet, dass das MesSy-System noch arbeitet, aber beispielsweise eine CAN-Nachricht vom Prüfling nicht beantwortet wurde. Eine Warnung dient lediglich zur Information. | Nummer | Klassifizierung | | --- | --- | | `0x10` | Systemfehler | | `0x20` | DUT-Fehler | | `0x30` | Warnung | Die **Quelle** ist der Softwareblock, der einen Fehler erkannt hat. | Nummer | Quelle | Beschreibung | | --- | --- | --- | | `0x00` | SYS | Allgemeine Systemsteuerung, z. B. Zeitstempel, IP-Verbindung, … | | `0x10` | CAN | CAN-Kommunikation | | `0x20` | PWM | Dynamische Erzeugung digitaler Ausgangssignale | | `0x30` | ANALOG | Analogeingang | | `0x04` | SSV | Signalüberwachung | | `0x05` | DIGOUT | Statischer Digitalausgang | | `0x06` | SERIAL | Serielle Kommunikationsleitungen | | `0x07` | MICROCONTROLLER | Allgemeine Mikrocontroller-Kommunikation für seriell oder CAN. | Der **Typ** klassifiziert einige typische Fehlerarten. | Nummer | Fehlertyp | | --- | --- | | `0x###A` | | | `0x###B` | Parameter | | `0x###C` | Kommunikation | | `0x###D` | Timeout | | `0x###E` | | | `0x###F` | Unbekannt | Die folgenden Tabellen zeigen die implementierten Fehlercodes und den zugehörigen Fehlertext, der im Cluster „error out“ unter „source“ ausgegeben wird: - DUT-Fehler: ![DUT-Fehlercodes: 0x2001000C DUT_COMMUNICATION_ERROR, 0x2001000D CAN_COMMUNICATION_TIMEOUT, 0x20010000 CAN_INVALID_SEED_KEY_SEQUENCE, 0x20010001 CAN_WRONG_SEED_KEY, 0x20010002 CAN_INVALID_SET_EOL_SEQUENCE, 0x20010003 CAN_TOOLBOX_DOWNLOAD_FAILED, 0x20010004 CAN_INVALID_RESPONSE_LENGTH, 0x20010101 ISO_TP_FRAME_ERROR, 0x20010102 ISO_TP_UNEXPECTED_RESPONSE_LENGTH, 0x20010103 ISO-TP_RESPONSE_PENDING](/docs/assets/messy/images/messy-dut-errors.png) - Systemfehler: ![Systemfehlercodes von 0x1000FFFF UNKNOWN_ERROR_CODE bis 0x1007001F UC_OUT_OF_MEMORY](/docs/assets/messy/images/messy-system-errors.png) ## Messsystem-API (CORE_API) Für den Zugriff einer Benutzeranwendung, typischerweise in LabVIEW erstellt, auf das MesSy steht eine VI-Bibliothek (API) zur Verfügung. Der Funktionsumfang der Bibliothek wird künftig erweitert. Die Dokumentation der Bibliothek ist deshalb elektronisch verfügbar. Der normale Befehlsablauf der CORE API ist identisch mit dem in [Kapitel 5.4.1](/docs/messy/sw-description#normale-befehlsausfuehrung) beschriebenen Ablauf. ### Adressierungsarten der CORE_API Zur Adressierung eines bestimmten MesSy wird dessen IP-Adresse verwendet. Jedes VI der Bibliothek hat dazu einen String-Eingangsparameter namens „IP Address“, der die IP-Adresse als String enthält (z. B. `192.168.101.2` – ohne Anführungszeichen eingeben) Beachten Sie, dass bei jedem Befehl ein Slot-Parameter übergeben wird. Dieser Parameter dient dazu, mehrere Prüflinge an einem Messsystem zu unterscheiden. Bei Prüflingen mit nur wenigen Pins und Funktionen kann ein Messsystem bis zu 6 Prüflinge parallel bedienen. Wenn in diesem Fall mehr als eine Testausführung mit dem Messsystem verbunden ist, muss die Kommunikationsroutine die Verbindungen für die Testausführung jedes Prüflings prüfen. Sie darf die Verbindung erst schließen, wenn alle Testausführungen aller Prüflinge die Verbindung geschlossen haben. Der Slot repräsentiert also den Prüfling am Messsystem. ### Funktionsblöcke In der API stehen verschiedene Funktionsblöcke zur Verfügung. Jedes VI hat ein Präfix PC_xxx, wobei xxx der Block gemäß der folgenden Tabelle ist: | Funktionsblock | Beschreibung | Beispiele | | --- | --- | --- | | **SYS** | Systembefehle | Zeitstempel abrufen, Verbindung aufbauen, EEPROM lesen und schreiben, … | | **DIGOUT** | Steuerung statischer Digitalausgänge | Einzelnes Relais, FET setzen / rücksetzen, alle Relais setzen / rücksetzen, … | | **PATTERN** | Steuerung dynamischer Digitalausgänge (PWM, Pattern) | Set_PWM, digitales Pattern herunterladen, Pattern starten, … | | **ANALOG** | Allgemeine Steuerung der Analogeingänge | Multiplexer einstellen, Wert eines einzelnen Kanals abrufen, Signalverlauf eines Kanals abrufen, … | | **SSV** | Signalüberwachung der Analogeingänge (SSV) | Überwachungskonfiguration einstellen, Ergebnis seit dem letzten Auslesen lesen. | | **CAN / uC_CAN** | CAN-Kommunikation | Conti-EOL-Protokoll, ISO-TP (ISO 15765-2), zyklisches Senden von Nachrichten. | | **uC_UART** | Serielle Kommunikation | Serielle Konfiguration, Byte senden, seriellen Repeater konfigurieren. | | **CMM** | Strommessmodul | Stromwert eines CMM lesen, Anzahl der CMMs in der Kette einstellen. | | **SUBSEQUENCER** | Subsequencer | Subsequenz erstellen, Schritt hinzufügen, Subsequenz ausführen, Schrittergebnis abrufen | ## Lebensdauertest-API mit benannten Kanälen (TS_API) Für den Zugriff aus TestStand auf das MesSy steht eine VI-Bibliothek (API) zur Verfügung, die komfortabler ist als die CORE_API. Diese Bibliothek heißt TS_API. Diese zusätzliche Softwareschicht über der CORE_API erleichtert dem Benutzer die Gestaltung des Prüfablaufs, insbesondere wenn mehrere Prüflinge entweder mit einem MesSy oder mit mehreren MesSys geprüft werden müssen. Der normale Befehlsablauf der TS_API entspricht im Wesentlichen dem in [Kapitel 5.4.1](/docs/messy/sw-description#normale-befehlsausfuehrung). Unterschiede sind die Adressierung des MesSy über die Nummern „Bus“ und „Slot“ sowie die Signalzuordnung zur Adressierung des physischen Analog-, Digital- oder Kommunikationskanals. Der Funktionsumfang der Bibliothek wird künftig ebenso wie die CORE_API erweitert. Die Dokumentation der Bibliothek ist deshalb elektronisch verfügbar. ### Adressierung über Bus, Slot und Signalname Die TS_API unterscheidet sich von der CORE_API in der Adressierung der physischen Kanäle des MesSy. Während in der CORE_API jeder physische Kanal über die IP-Adresse des MesSy und die physische Kanalnummer adressiert wird (z. B. 1…96 für die Single-Ended-Analogeingänge SE_1to96, Serial_01 … SERIAL_10, 1…24 für FET, ...), erfolgt die Adressierung in der TS_API über „Bus“, „Slot“ und „Signalname“: - Bus: - Bereich = [0…255] - Ist die letzte Zahl der IP-Adresse. - Der Rest der IP-Adresse – der IP-Adressbereich – wird in der Signalzuordnungsdatei festgelegt (siehe [Signalzuordnung](/docs/messy/sw-description#signalzuordnung)). - Z. B.: Bei **Bus = 12** und dem IP-Adressbereich „192.168.100.“ lautet die IP-Adresse des adressierten MesSy „192.168.100.**012**“, - Slot: - Bereich = [1…6] - Die MesSy-Software ist so ausgelegt, dass ein MesSy bis zu 6 Prüflinge bedienen kann. - Die Slot-Nummer steht für die Nummer des Prüflings. - Der Slot wählt gemäß der Signalzuordnungsdatei den passenden physischen Kanal eines MesSy aus (siehe [Signalzuordnung](/docs/messy/sw-description#signalzuordnung)). - Signalname - Der Signalname ist ein frei wählbarer Name, der einem Signal entspricht (typischerweise dem Signalnamen des Prüflings), das entweder an einen Analogeingang, einen Digitalausgang oder eine Kommunikationsleitung angeschlossen ist. - Die Zuordnung der physischen Kanäle zu Signalnamen erfolgt in der Signalzuordnungsdatei (siehe [Signalzuordnung](/docs/messy/sw-description#signalzuordnung)). Bedient ein MesSy beispielsweise drei Prüflinge, ist derselbe Signalname an einem MesSy dreimal vorhanden. Der richtige physische MesSy-Kanal wird über die jeweilige Slot-Nummer ausgewählt. ### Signalzuordnung Die Signalzuordnungsdatei enthält zunächst den IP-Adressbereich aller angeschlossenen MesSys. Der IP-Adressbereich umfasst die ersten drei Zahlen der IP-Adressen (z. B. `192.168.101.`). Außerdem enthält diese Datei die Anzahl der Slots, d. h. die Anzahl der angeschlossenen Prüflinge und der zugehörigen Ausführungen. Und schließlich ist in dieser Datei für jeden Slot die Zuordnung der Signalnamen zu Analogeingängen, Digitalausgängen, Relais und Kommunikationsleitungen festgelegt. Die Signalzuordnungsdatei wird als XML-Datei gespeichert. Das folgende XML-Beispiel zeigt den IP-Adressbereich (`common_ip=192.168.101.`), die Anzahl der Slots = 2 (`count=2`) und alle möglichen Signalgruppen. Wird ein „name“ mehrfach verwendet, entweder für denselben Typ (Relais, Single-Ended-Eingang, …) oder für verschiedene Typen, fügen Sie die folgende Eigenschaft hinzu (wie im Beispiel für den Analogeingang gezeigt) `resourcesharing = "1"` Andernfalls wird beim Laden der Signalzuordnungsdatei ein Fehler gemeldet. Diese Funktion hilft, unerwünschte Mehrdeutigkeiten zu vermeiden. ```xml ```