MFU NiosII Software Change Log

• The current Nios software can be downloaded here.

• [vnc2_move_parameters_to_ram] brach das Laden von Parametern ab, wurde die restliche Funktion nicht ausgefuehrt. D.h. es wurde keine Verifikation durchgefuehrt, es erfolgte keine Meldung (26.04.23)
• Der Timer fuer die Aufzeichung von Spannungen und Temperaturen stand auf 2 Sekunden. Sind jetzt wieder 60 Sekunden. Damit stimmt auch die grafische Darstellung wieder. (08.02.24)

• Erweiterung der Versionsnummer: 3xMajor.3xMinor+2xSubMinor
• MFU LWL wird im FSP225 nun unterstützt. (29.03.23 - DS)
• MFU Selbsttest -> DAC Ausgabe des FG funktionierte nicht mehr. Anpassung an MFU FW 7.5.0 (und neuer) vorgenommen. (30.03.23 - DS)
• [serial_flash_page_program] Hin und wieder sind Einträge des Logbuchs nicht ganz korrekt (warum auch immer?).
  Verdacht: eine ISR unterbricht den Speichervorgang. Daher werden nun ALLE ISR während des Speicherns abgeschaltet. (05.04.23 - DS)
• Einige neue Logbucheintraege hinzugefügt (ab 34), andere etwas angepasst. (05.04.23 - DS)
• Wird ein Gerät mit Spannung versorgt, wird dies im Logbuch vermerkt. Zusätzlich wird nun auch eine Info darüber ins Logbuch geschrieben, ob das Gerät dabei Remote oder Local betrieben wurde. (05.04.23)
• [internal_fsp_233] Vermerk im Logbuch über den Empf. von Daten (05.04.23 - DS)
• [serial_flash_save_config_file] Vermerk im Logbuch über den Empf. von Daten (05.04.23 - DS)
• [log_send] Der Logbucheintrag, dass das Logbuch gelesen wird/wurde, erfolgt nun VOR dem Auslesen und ist damit auch gleich Teil des aktuellen Auslesevorgangs und nicht erst des nächsten. (05.04.23 - DS)

• "USI-Gap" wird unterstützt (04.07.22 - DS)
• Moduleintragungen in der 'update.txt' für Module die physikalisch nicht verfuegbar sind, führen nicht mehr zu einem Abbruch des Update-Vorgangs.
  Vielmehr werden diese übersprunegen und es erfolgt ein entsprecheder Eintrag in der 'update.log'. (21.07.22 - DS)
• 'internal_fsp_244()': ist 'received_usi_number = 0", wurde fälschlich local_usi_com_block.module_number = received_module_number-1;
  Dadurch konnte .module_number = 0xFF (-1) werden, was in der folgenden 'usi_config_bit_rate_usi_mode()' zu einem Fehler fuehrte.
  Workaround: den Parameter für ModuleNummer (Mod) bei USINumber (USI) == 0 auf mind. 1 setzen. (DS)
• 'internal_fsp_225()' FSP225_INT_READ_RECORDED_MODULE_DATA fuer DataStorage eingeführt.
• 'internal_fsp_229()' FSP229_INT_READ_RECORDED_MODULE_DATA entfernt. Statdessen FSP225 nutzen.
• 'internal_fsp_226()' FSP225_INT_FSP_FILL_FGSTIMULI_RAM aktiviert. (16.03.23 - DS)

• FSP229 reaktiviert (07.05.21 - DS)
• 'menu_1451_status_flow_rate_details': ab ICM 7.5.0 und verwandte Module (ICM_SR...) ist die Bittiefe zur Festlegung der Durchflussraten-Grenzen und der eigentlichen Durchflussrate von 24 Bit auf 16 reduziert.
  Ausserdem ist die max. Durchflussrate entfallen. Es werden nun beide Möglichkeiten in diesem Menü unterstützt. (15.02.22 - DS)
• 'internal_fsp_226()' FSP225_INT_FSP_FILL_FGSTIMULI_RAM fuer FG Stimuli hinzugefügt.
  Noch nicht erreichbar/verfügbar. (23.03.22 - DS)

• Wurde die Funktion 'usi_config_bit_rate_usi_mode()' mit dem Parameter 'change_bit_rate_usi_mode_for_all_modules == TRUE' aufgerufen, kam es fuer den Fall, dass HighSpeed engeschaltete werden sollte, zu folgendem Effekt:
  Da bei HighSpeed nur max. 1 Modul am USI sein darf, aber der State UCBRUM_CONFIG_BIT_RATE_USI_MODE_FOR_ALL_MODULES aufgerufen wird, wurde darin der HighSpeed -Wunsch in der Anfrage an das Modul ignoriert, aber die USI auf MFU-Seite trotzdem auf HighSpeed geschaltet.
  Das Resultat war der Sprung in eine Endlosschleife.
• Mit dem FSP244 koennen nun auf einmal alle USIs mit allen Module oder alle Module an einem USI oder nur ein bestimmtes Modul an einem bestimmten USI umgeschaltet werden.
• Das leidige Thema "zyklische Interlockabfrage" hat immer noch nicht funktioniert. Sofern KEINE Interlocks anlagen, wurde diese nicht ausgeführt, da die Bedingungen zur Abfrage auch an die Flags INTERLOCK_AT_LEAST_ONE_EXT_TRIPLINE_PULLED und CPU_STATUS_SYSTEM_HAS_INTERLOCKS gebunden waren.
  Dadurch wurde die Abfrage verhindert, wenn KEINE Interlocks anlagen, bzw keine Reisleine gezogen war. Dadurch wurden auch die SCU exklusiven Interlockregister NICHT aktualisiert. Wurde etwas unpassend der RESET durchgeführt, konnte es passieren, dass anstehende Interlocks in den SCU exklusiven Interlockregistern NICHT gelöscht wurden. Ebenso wurden verlorene Module die NICHT in HighSpeed angebunden sind NICHT erkannt.

• Durch Änderungen in 007.00003 in der Funktion 'serial_flash_get_system_parameters()' konnte es passierte, dass am Ende einer Page nicht die nächste geladen wurde obwohl der USI-String ueber die Page-Grenze hinaus ging.
  Vielmehr wurde das Laden der Parameter abgebrochen, weil 'ascii_value <> ETX' war und page_index = 256.
• Senden von Interlocktexten war nicht moeglich und wurde immer mit 'ERR_CHECKSUM_ERROR' beantwortet. Der Pruefsummentest war wegen einer Modifikation im FSP233 Funktionstext versehentlich geloescht.
• War SVE eingeschaltet und wurde ICM gezogen (Status nicht mehr lesbar), wurde CPU_STATUS_PSU_IS_ON nicht geloescht. D.h. fuer z.B. PCA war der Geraetetstatus weiterhin: Eingschaltet.
• Die Abschaltung der zyklischen Interlockabfrage ueber CPU-Status hat nicht richtig funktioniert.
• Mit dem Kommandos '*initpar' wird nun zusaetzlich auch der Konfigurationsdateien-Sektor geleoscht.
• Das FSP66 entfaellt zukuenftig. Daher ist das Uebertragen von Interlockinfos an die SCU/die IFK nun mittels RAM organisiert. Die Funktion 'menu_0111_interlocks_dyn()' entsprechend angepasst.
• Geht ein Modul/eine gesamt USI verloren, sind bisher alle nachfolgenden Interlockbits in der Ausgabe ans Kontrollsystem nach vorne gerutsch. Das ist natuerlich nicht so schoen, da deren Bedeutung dann nicht mehr stimmt.
  Kuenftig werden Interlockbits verlorener Module mit '0' aufgefuellt. Fuer das Kontrollsystem stehendan dann ALLE Interlocks des Moduls an.
• ISR Probleme in Massen:
  • Beim Empfang von Parametern (STATUS_CURRENTLY_RECEIVING_MFU_PARAMETERS_n = '0') darf in der zugehoerigen ISR das Setzen von WARNING_MODULE_VERFICATION_FAILED nicht ins Logbuch eingetragen werden. Andernfalls wuerde bei jedem Parametersenden faelschlich ein Fehler der Modulverfikation auftauchen.
  • Die Interruptquelle (weil ueberflüssig) STATUS_CHECKSUM_OK ist auf STATUS_CURRENTLY_RECEIVING_MFU_PARAMETERS_n reduziert.
  • Die Auswertung des 'EdgeCapture-Register' u.a. in der 'status_pio_isr()' war nicht richtig.
    Dieses Register erkennt fuer den STATUS_PIO prinzipiell eine fallende Flanke bei jedem Bit. Ist zusaetzlich fuer das betreffende BIT der IRQ zugelassen, wird bei fallender Flanke an diesem Bit die ISR aufgerufen. Da aber auch Flanken an anderen BITs, die KEINE IRQ Freigabe haben erkannt worden sein koennen, sind im 'EdgeCapture-Register' mitunter Bits gesetzt, die keinen Interrupt ausloesen.
    Beispiel:
    

    EdgeCapture	0011 0010	drei Flanken erkannt
    Interrupt	1100 0010	drei Interruptquellen aktiv
    EC & I	0000 0010	Bit[1] hat ausgeloest

    Wird nur das 'EdgeCapture-Register' in der ISR betrachtet, sind drei Bits gesetzt, dabei hat Bit[1] den Interrupt ausgeloest.
    Das notwendige UND hat bisher gefehlt. Dadurch wurden ggf. auch falsche 'if'-Zweige abgearbeitet.
  • Das int. Scope war immer aktiv (unabhängig von den Parametern), weil am Ende der ‚scope_init()‘ Funktion der Trigger aktiviert wurde. Das ist dahingehend fatal, als dass dadurch im Falle eines Triggerereignisses die 'status_pio_isr()' aufgerufen wurde. Das selbst ist noch nicht das Problem, in der ISR aber, wurden (durch das fehlerhaftes Bitmanagement) mitunter Bits "geserviced", die gar nicht als ISR-Quelle zugelassen waren. U.A. STATUS_CURRENTLY_RECEIVING_MFU_PARAMETERS_n*, was dafür sorgte, dass CPU_STATUS_MODULES_VERIFIED geloescht und WARNING_MODULE_VERFICATION_FAILED gesetzt wurde. Der Trigger ist daher nun per Standard deaktiviert, auch wenn das Problem in der ISR behoben ist.
• Alle mUSIc_COM_BLOCK mit 'usi_number' und 'module_number' vorinitialisiert im Hinblick auf 'error_record_error()'. Dort wird nun, sofern 'usi_number >= USI_NMBR_UNDEFINED' und/oder 'module_number >=MOD_NMBR_UNDEFINED' sind der entsprechende Wert mit 0xF abgelegt. dadurch ist ersichtlich, dass die Variable ggf. (noch) nicht in Verwendung war. Dies soll Eintraege falscher USI/Modul Nummern aufgrund nicht initialisierter Variablen verhindern.
• Logbuch zeigt undefinierte USI/Modul-Nummern nun als '-1'.
• 'usi_auto_reconnect()' komplett ueberarbeitet. Das Wiederverbinden einzelner Module an USIs, die NICHT in HighSpeed sind, funktionierte nicht richtig.
• Laden von Parametern von USB-Speichern ins MFU RAM hat nur 1x funktioniert, danach kam es zu einem Mem-Buf-Error. Ursache war: Der Pointer auf den reservierten RAM Speicher wurde veraendert, daher schlug 'free(pointer)' fehl.
• CPU_STATUS_PERFORMING_USI_SCAN ist nun CPU_STATUS_MFU_CAN_NOT_TRANSFER_ANY_DATA_RIGHT_NOW und wird nicht mehr nur fuer den USI-Scan verwendet. Vielmehr wird der CPU-Status mit gesetztem CPU_STATUS_MFU_CAN_NOT_TRANSFER_ANY_DATA_RIGHT_NOW nun immer dann verschickt, wenn PCA gerade mal nicht irgendwelche Daten an die MFU schicken oder von dieser holen soll, weil diese zu beschaeftigt ist.
• Das Umschalten von Bitraten einzelner Module/USI mittels FSP244 funktionierte nicht, wenn an einem USI mehr als ein Modul angeschlossen ist. Es muessen die Bitraten fuer ALLE Module geandert werden, nicht nur fuer das im 'p_usi_com_block'. Abhaengig vom neuen Parameter 'change_bit_rate_usi_mode_for_all_modules' in 'usi_config_bit_rate_usi_mode()' werden nun ggf. alle Module auf einmal umgeschaltet. Dabei wird darauf geachtet, dass die Bitrate des langsamsten Moduls nicht ueberschritten wird.
• Neues internes FSP227 'internal_fsp_227()' fuer Bitmanipulationen in beliebigen FSPs. Verbesserte Version von int. FSP241.
• Differenziertere Statusanzeige im Hinblick auf "Controller disabled".
• Neues FSP067 in der MFU wird unterstuetzt im 'menu_0021_quick_oview_usi_modules()'. Dieses zeigt nun im Falle 'TFT_SHOW_USI_1ST_MODULE' ein rotes Sternchen (*) beim zugehoerigen Modul an, wenn dieses sich im HS-Modus befindet aber das zugehoerige Bit im FSP067 nicht gesetzt ist.
• Int. FSP231 und FSP245 unterstuetzen nun auch das neue, auf vier Kanaele reduzierte Scope in der MFU.
• Altera Remote Update fuer Cyclone V erfordert einen groesseren Adressbereich in FSP045. Daher nimmt 'update_update_module_firmware()' nun Ruecksicht auf die neue FSP-Tiefe von 7 anstelle 6 Byte.
• Der Menuepunkt 145 zeigt nun den Mediendurchfluss bei vorhandenen Durchflusswaechtern.
• Besitzt ein Modul KEINEN FSP004 und ist im Standard USI Modus konnte ohne FSP004 der Verlusst dieses Moduls am USI nicht erkannt werden. Daher wird nun in diesem Fall FSP012 gelesen. Dessen Inhalt aber verworfen. Ein FSP004 ist also zukuenftig fuer Module OHNE Interlockerfassung nicht mehr noetig.
• 'menu_0062_..()' und 'mux_get_front_dac_..()' Funktionen an das neue 4 Kanal Scope und die Tatsache, dass es keinen seperaten FSP115 zur Scope-Quellenwahl mehr gibt angepasst. Die Scopequellen werden künftig ueber FSP110 fuer den DAC bestimmt. (02.04.20 - DS)
• int. Scope auf dem TFT wurde nicht immer korrekt getriggert, da das Ein- bzw. Ausschalten der zugehoerigen ISR nicht richtig funktionierte (09.04.20 - DS)
• Sind mehr als 2 ADCs angebunden, wird KEIN "ERR_MDS_3RD_ADC_FOUND" mehr erzeugt. Es sind beliebig viele ADCs möglich, aber der erste gefundene wird als ADC1 (Istwert-Strom) der naechste als ADC2 (Istwert-Feld) gewertet und auch entprechend auf dem TFT angezeigt. Für alle weiteren ADCs werden deren Messwerte NICHT auf dem TFT gezeigt. (27.05.20 - DS)
• Neuer Menuepunkt "menu_0044_copy_compresse_configuration()" zum kopieren der gepackten Gerätekonfigurationdatei auf einen USB Speicher. (24.06.20 - DS)

• Bisher wurde auf 'USI_RxBufCounter < (USI_RXBUF_SIZE-1)' geprüft. Da 'USI_RxBufCounter' aber in der ISR inkrementiert und in 'usi_get_value()' dekrementiert wird, konnte es passieren, dass beide Zählungen "zeitgleich" erfolgen. Die ISR ist zwar verriegelt und kann nicht unterbrochen werden, 'usi_get_value()' hingegen von der ISR sehr wohl. Wie auch immer 'USI_RxBufCounter' ging manchmal falsch. Daher wird nun direkt auf die Pufferzeiger 'USI_RxBufIn' und 'USI_RxBufOut' getestet. 'USI_RxBufCounter' wird rein zu Debugzwecken noch mitgeführt.
• Bei einem Module FW Update war es möglich Module zu adressieren, die in Wirklichkeit überhaupt nicht angeschlossen sind.
• Das Gleiche galt für das Starten von "Reconf". Auch hier muss ein Modul nun physisch vorhanden sein.
• Bei der Interlockanzeige und zusätzlich bei deren Kommunikation ans Kontrollsystem wurde '.mem_interlocks' verwendet. Dies ist insofern nicht ganz OK, als dass ein Benutzer 'Memorized Interlocks' deaktivieren, resp. diese maskieren kann. Im Interlockfall wird dieses Bit dann nicht gesetzt, wurde also weder auf dem TFT angezeigt (sofern auch dessen HW-Anbindung an die Reißleine deaktiviert war), noch an das Kontrollsystem gemeldet. Nun werden '.mem_interlocks' und '.act_interlocks' miteinander UND Verknüpft und im neuen Speicherbereich '.mem_or_act_interlocks' abgelegt. Dieser neue Speicherbereich wird nun für die Anzeige und Meldung an das Kontrollsystem verwendet. Daraus folgt, solange das Interlockbit (ENTWEDER) in '.mem_interlocks' UND/ODER '.act_interlocks' gesetzt ist, wird es erkannt und gemeldet.
  Für die Anzeige auf dem MFU TFT gilt:

Masken		Interlock			Rahmen/TFT Anzeige
"Pending Interlocks"	"Memorized Interlocks"	inaktiv	aktiv	wieder inaktiv	bisher mit RL-Anbind.	bisher OHNE RL-Anbind.	jetzt MIT RL-Anbindung	jetzt OHNE RL-Anbindung
zulässig	zulässig	X	-	-	grün/No interlocks	grün/No interlocks	grün/No interlocks	grün/No interlocks
zulässig	zulässig	-	X	-	rot /*Interlock (RL)	rot /*Interlock (RL)	rot /*Interlock (RL)	rot /*Interlock (RL)
zulässig	zulässig	-	-	X	rot / Interlock (RL)	rot / Interlock (RL	rot / Interlock (RL)	rot / Interlock (RL)
zulässig	ausmaskiert	X	-	-	grün/No interlocks	grün/No interlocks	grün/No interlocks	grün/No interlocks
zulässig	ausmaskiert	-	X	-	gelb/No interlocks (RL)	grün/No interlocks	rot /*Interlock (RL)	rot /*Interlock
zulässig	ausmaskiert	-	-	X	gelb/No interlocks (RL)	grün/No interlocks	gelb/No interlocks (RL)	grün/No interlocks
ausmaskiert	zulässig	X	-	-	grün/No interlocks	grün/No interlocks	grün/No interlocks	grün/No interlocks
ausmaskiert	zulässig	-	X	-	rot / Interlock (RL)	rot / Interlock (RL)	rot / Interlock (RL)	rot / Interlock (RL)
ausmaskiert	zulässig	-	-	X	rot / Interlock (RL)	rot / Interlock (RL)	rot / Interlock (RL)	rot / Interlock (RL)
ausmaskiert	ausmaskiert	X	-	-	grün/No interlocks	grün/No interlocks	grün/No interlocks	grün/No interlocks
ausmaskiert	ausmaskiert	-	X	-	gelb/No interlocks (RL)	grün/No interlocks	gelb/No interlocks (RL)	grün/No interlocks
ausmaskiert	ausmaskiert	-	-	X	gelb/No interlocks (RL)	grün/No interlocks	gelb/No interlocks (RL)	grün/No interlocks

(RL) sofern das Interlock modulseitig an die HW-RL angebunden ist, wird diese gezogen
Das Verhalten ändert sich also nur wenn "Memorized Interlocks" ausmaskiert ist.

• Leider wird die RESET-Taste nicht per ISR erfasst, sondern nur gepolled. Daher kann das Löschen von Interlocks und ändern der Rahmenfarbe zurück auf Grün nicht direkt an die RESET-Taste geknüpft werden.
• Zeigte das TFT NICHT das 'menu_interlocks_dyn()' und es standen Interlocks an, wurde der Rahmen neuerdings nicht mehr grün, sofern sich diese erfolgreich löschen ließen. Der Rahmen wurde immer erst dann grün, wenn das Menu 'menu_interlocks_dyn()' aufgerufen wurde. Das 'menu_interlocks_dyn()' wurde bisher immer durchlaufen, beim
  - ersten Aufruf des Standardbildschirms
  - zyklischen Interlocktesten durch Aufruf in 'menu_idel_jobs' und dann durch -> testen von 'isr_timer_interlock_circular_check()' in 'menu_interlocks_dyn()'
  - wenn das Interlockmenü "111" angezeigt wird
  durch -> manuellen Aufruf durch den Benutzer
  -> automatischen Aufruf im Interlockfall
  Wurde der zyklische Test ausgesetzt, konnte der Rahmen nicht mehr grün werden, es sei denn, der Benutzer befand sich in 'menu_interlocks_dyn()'.
  Daher sind die Kriterien im 'menu_idle_jobs()' nun dahingehend geändert, dass 'menu_interlocks_dyn()' bei mindestens einer gezogener Reißleine und/oder bei mindestens einem anstehenden Interlock auch dann aufgerufen wird, wenn der zyklische Test eigentlich deaktiviert ist.
• Bei einigen Funktionen im Menü
  - menu_0411_reload_flash_parameters(),
  - menu_4132_load_parameters_FROM_usb_flash_drive_TO_RAM()
  - menu_0422_0432_4131_load_data_FROM_usb_flash_drive()
  - menu_0412_0421_0431_save_data_TO_usb_flash_drive()
  wird der angezeigte Text und die Zulässigkeit zum Ausführen der Funktion durch den Benutzer nun abhängig vom Betriebszustand der SVE (Ein/Aus) oder USB Speicher verfügbar ist oder nicht umgeschaltet. Dadurch entfällt die Notwendigkeit zur Aktualisierung der Anzeige den Menüpunkt erneut aufzurufen. Problem war dabei, dass die Anzeige auf dem TFT mitunter nicht zur Zulässigkeit passte, sofern sich der Betriebszustand der SVE oder die Präsenz des USB Speichers änderte solange dieser Menüpunkt angezeigt wurde.
• Die Anzeige der physikalischen Einheiten hat nicht wirklich funktioniert. Zum einen waren die FSP29 und FSP39 der physikalischen Eimheiten vertauscht, zum anderen wurden in der Funktion zur Ermittlung der Einheit immer das FSP29 anstelle des uebergeben benutzt.
• Software FSP229 hinzugefuegt für das HighSpeed auslesen von Aufzeichungsdaten.
• Software FSP237 ist nun synchronisierbar. Erfordert aber eine passende FW MFU_SE >= 7.4.0.
• Werden die programmierten Interlocktexte über dem MFU FSP233 gelesen, wurde am Ende der Übertragung KEINE Prüfsumme geschickt. Lediglich das ETX.
• Beim Programmieren von Interlocktexten mittels USB Speicher ist es möglich, dass eine Datei die nicht vollständig ist ins Flash programmiert wird.
  Z.B. weil die Datei selbst nicht vollständig ist. Es findet beim Programmieren keine Verifizierung statt, da es sich um eine Textdatei handelt deren Inhalt nicht überprüft wird.
  Beim Lesen von Interlocktexten zur Darstellung auf dem TFT kann es also passieren, dass in einem leeren Speicherbereich des seriellen Flashs versucht wird
  den eigentlichen Interlocktext auszulesen. In diesem Fall wurde bisher KEIN Fehler zurükgegeben. Dies sorgte dafuer, dass keine oder fehlerhafte Interlocktexte auf dem TFT zu sehen waren.
• Leere Parameterdatei von USB Device ins RAM schreiben schlug fehl. Programm hing in 'vnc2_move_parameters_to_ram()'. Manche MFUs starteten sogar neu (wie RESET).
  Wird versucht eine leere Datei zu laden (Größe 0 Byte) wird dies nun verweigert und auf dem TFT gemeldet.
• War ein USI Parameter String unvollständig, brach also mit (0xFF) ab, wurde dies nicht erkannt.
  Wird ein unvollständiger Parametersatz mit einem unvollstaendigen Parameter String (welcher z.B. nicht bis zum ETX reicht) geladen, wird dies nun sowohl in ‚serial_flash_get_system_parameters()‘ als auch ‚vnc2_move_parameters_to_ram()‘ bemerkt und als inkorrekter Parameterstring dokumentiert.
• USB Device einstecken, Spannung MFU einschalten -> update.txt wird ausgeführt. Anschließend war USB Device nicht verfügbar, bzw. angeblich nicht angesteckt.
  Beim Starten der MFU wird ‚update_manage_update_from_usb_flash_drive()‘ aufgerufen. Darin wurde zwar getestet ob der VNC2 einen USB Speicher angesteckt hat, aber das zugehörige Flag ‚CPU_STATUS_USB_DEVICE_DETECTED‘ wurde nicht gesetzt, sofern dies der Fall ist. Lediglich ‚CPU_STATUS_USB_DEVICE_PERMITTED‘ wurde gesetzt oder nicht. Die Routinen des Menüs fragen aber zuerst ‚CPU_STATUS_USB_DEVICE_DETECTED‘ ab und erst wenn dieses gesetzt ist: ‚CPU_STATUS_USB_DEVICE_PERMITTED‘. Daher wurde immer angenommen, es ist kein USB Speicher angesteckt.
• Auslesen der Scopedaten über FSP245 korrigiert im Hinblick darauf, dass die Indizierung der Messwerte von 1..500, der Trigger aber von 0..499 lief. Dies ist nun sowohl in PCA, in der FW (ab 7.4.1) der MFU, als auch in der Nios SW konsistent.

• Die Anzeige "alter" FW-Versionen mit lediglich Major.Minor muss auf die neue FW-Version MinorLSB korrigiert angezeigt werden. Dies ist lediglich eine "Schönheitsreparatur" für den Benutzer.
• Das MFU interne FSP 251 zum Speichern der Konfigurationsdatei funktioniert wieder nach dem alten Prinzip.
  1. senden der Dateilänge als vollständiger USI Stream
  2. senden der Konfigdatei als RBF ohne irgendwelche USI Zeichen
  Dies deshalb, weil das neue Verfahren, die Konfigdatei als vollständigen USI Stream zu schicken in PCA nicht richtig funktioniert.
  Die Datei ist komprimiert, d.h. deren Daten sind Symbole und werden vor dem senden mit PCA in einen String konvertiert.
  Dabei passiert etwas (was genau ist die Frage), dass dazu führt, dass sich die Datei nach dem lesen nicht wieder entpacken lässt.
• Kurze Textanzeige vor der USI Schnellansicht mit der Bitte um etwas Geduld.
• Die USI Schnellansicht zeigt nun das Image, die Bitrate und den USI Modus an.
• Sind Modulbeschreibungen in der USI Schnellansicht zu lang, werden diese nun gekürzt und dies per ".." mitgeteilt

• Anzeige von Modul-FSP-Inhalten neu strukturiert.
• MDS der MFU wird nun auch angezeigt.
• Anzeigefehler bei mehrseitigen Interlocks behoben.
• Lokaler Sollwert ist nun (richtig) 1/50 vom Nennstrom und nicht mehr 1/50 vom Nennstrom + 10%.
• Einschaltzeit der SVE wurde falsch erfasst. Da der Status NICHT bitcodiert ist war hier die Verknüpfung nicht korrekt. Folglich wurde die Einschaltzeit auch irrtümlich beim Ausführen eines Kommandos erfasst.
• Neuer Menüpunkt "Interlock Early Bird".
• Speichern einer Datei im ext. seriellen Flash ist nun möglich. I.d.R. wird dies die Gerätekonfiguration sein.
• Beim Erstellen des zugehörigen Software-FSP251 ist aufgefallen, dass im ext. seriellen Flash keine Sektoren > 7 adressiert werden konnten. Dies war beim alten kleinen Flash kein Problem, mit neuerdings 32 Sektoren sehr wohl.
• Diverse kleine Fehler behoben, wie z.B. Update per USB Flash verhindern wenn SVE eingeschaltet ist oder ändern der Rahmenfarbe im Remotemodus beim Betätigen der RESET-Taste.

• Viele, viele Dinge sind überabeitet. Insbesondere Dinge die mit 'Remote-Update' zu tun haben. Außerdem startet ab hier der Kompatibilitätscheck.
  Soll heißen: PCA und alle Modul-FW, -SW starten nun mit 7.x um klar zu definieren, dass hier etwas neues beginnt und alles andere davor war.