V2.17 V2.16 V2.15 V2.14 V2.13 V2.12 V2.11 V2.10
V2.09 V2.08 V2.07 V2.06 V2.05 V2.04 V2.03 V2.02
Das Abspeichern von Einstellungen wurde optimiert, die Daten werden jetzt schneller in Speicher geschrieben
Baudraten-Erkennung des Busses wurde optimiert
Bei nicht definierter PIN-Nummer konnte teilweise die Fehler-LED aufleuchten
Abbruch der Kommunikation beim Lesen von Bausteinen über eine GSM-Verbindung
S7Technologiesoftware V4.1: eingeschalteter ON/OFFLinevergleich über mehrere Antriebe bleibt bei 95% stehen. Ebenfalls bricht die Kommunikation teilweise ab
Kommunikationsprobleme in Verbindung mit S7-Technologie-Steuerungen und S7-Technologiesoftware mit Antrieben am Drive-Bus sowie am Profibus behoben
Nach Konfiguration von MPI-Baudrate auf 187k5 und Profil auf DP per Tastatur war anschließend kein ONLINE-Zugriff möglich. Die selbe Konfiguration durchgeführt über TS-Software oder MPI-Kabelmanager war OK
Ein in der Betriebsart "PPIUSB96" befindliches Tele-Service und zusätzlich aktiviertem "Daten sperren" konnte nicht mit dem MPI-Kabelmanager aktualisiert werden
Der Parallelbetrieb von Step7-Software und Starter-Software führte zu Kommunikationsabbrüchen
Die Betriebsarten "PPISER96" und "PPISER19" können nur auch durch den MPI-Kabelmanager auf das Standard-MPI-Protokoll umgeschaltet werden
bestimmte Laptop's, serieller Zugriff, Step 7 V5.4SP3, Kommunikationsabbrüche
Protokoll- und Timeoutverarbeitung korrigiert
PPI9K6/PPI19K21 funktionierte seit V 2.41 nicht mehr
Sonder-Ser Einstellung unter Konfig/Mode, Parität, wenn "odd" ausgewählt und gespeichert wurde, ist "even" eingestellt worden und umgekehrt
In der PPIMultimaster-Betriebsart wurde bei 9K6 nicht immer die S7-2xx-CPU gefunden
Defaultwert für die CPU-Nummer ist jetzt wieder 255 (direkt gesteckte SPS-Steuerung) anstatt 2
Der Urloader enthält jetzt textuell im Code seinen Namen
Kommunikationsabbrüche bei Zugriffe auf die MicroMaster 4x0 (z.Bsp. 420) in Verbindung mit der Starter-Software wurden behoben
Der Aufbau einer Verbindung zu einer CPU funktionierte nicht immer
Der Zugriff auf Movitrac über PFB21 funktionierte nicht. Dieser Zugriff ist nur über USB mit dem MPI_DP_PPI-Treiber möglich!
Das Laden eines Betriebssystems eines OP73 funktionierte nicht korrekt
Der Firmware-Transfer eines MP370 geht nur über die Breakout-Box, da nur dort der Bus (MPI oder Profibus) mit korrekten Pinning aufgelegt ist In den Einstellungen des Pannels muß bei "Schnittstelle2" dann entsprechend MPI/Profibus ausgewählt sein
Der Zugriff über Profibus mit Graph7 war stockend, brach teilweise nach kurzer Zeit ab
Konfigurationsmenu auf zukünftige Funktion mit zuschaltbarem stärkerem Bus-Abschluss vorbereitet
Das Aufstecken des extern versorgten Gerätes auf einen Bus mit anderen Parameter führte zu einer Bus-Störung. Das Gerät gab sich selbst immer ein Token obwohl "PG/PC ist einzigster Master" nicht aktiviert war
Ein "Versionscheck" durch den MPI-Kabelmanager führte auf Grund eines Codierungsfehlers zu Fehlermeldungen
Ein Firmware-Update nach Setzen der Werkseinstellung und aktivieren von "Daten Sperren" führt zu einer Endlos-Neustart-Schleife
Der NotLoader wurde nochmals überarbeitet
Die Konfiguration über Modemstrecke eines MPI-Modem mit der Firmware V2.09 und V2.10 mit dem MPI-Kabelmanager V3.12 führte zu einem einem "Nicht_mehr_ansprechbar-Verhalten" des Gerätes
Die angezeigte Versionsnummer der version V2.09 ist V2.08
Kommunikationsabbrüche an ET200S behoben
Fehleranzeige im Display: Wenn der selbe Fehler seit dem letzten Anzeigen nochmals auftritt wird jetzt in der 2. Zeile im letzten Zeichen ein "*" ausgegeben
Zugriffe auf den Profibus DP mit Baudrate 1M5 konnten zu einem Abfallen der Ausgänge der SPS führen
PPI-MultiMaster funktionierte Seriell nicht mehr
PPI-Multimaster-Kommunikation funktionierte nach dem Ändern der PPI-Baudrate nicht mehr
Bei einer Abfrage der internen Flags mit dem MPI-Kabelmanager wird nun diese Information aus dem Flash anstatt RAM gelesen
Checksummen der Firmware aus dem Konfigurationsbereich verschoben
Update des Produkts aus dem NotLoader funktionierte nicht immer. Ursache war eine nicht korrekte Baudratenerkennung bei 19K2 Baud
In der Betriebsart "PPI-Multi" konnte die Suche nach möglicherweise vorhandenen Teilnehmer mit der MicroWin-Software V4.0 stehen bleiben
Der Konfigurationsspeicher wurde anders aufgeteilt und verwaltet. Das NotLoaderBrennProgramm wurde entsprechend angepaßt
Teilweise wurde nach Neustart einer Konfigänderung der falsche Bustyp verwendet
Die Verbindungs-LED zeigte teilweise falsche Zustände an
Es konnte die Kommunikation bei direktem PG/PC-Zugriff und gleichzeitiger aktiver SMS/VOICE-Verarbeitung abbrechen
TS-Software V6.0, Bus-Auswahl "Auto" wurde ignoriert und somit nicht ausgeführt. Dadurch war kein ONLINE-Zugriff auf den angeschlossenen Bus möglich
Es war nach einer SPS-Kommunikation anschließend kein serielles Firmware-Update möglich
Die automatische Erkennung von Baudrate und Busprofil-Parameter wurde nach Konfigurationsänderungen über den MPI-Kabelmanager nicht mehr korrekt durchgeführt
Teilweise musste mehrfach bei den "Erreichbaren Teilnehmern" bei Profibus 6MBd zugegriffen werden, bis die gewünschten Informationen anstanden
Anstehende Fehler bei Version "GSM" wie "SIM-Karte fehlt" oder "PIN nicht korrekt" wurden nach einem Neustart nicht mehr angezeigt
Im Meldungsfenster des MPI-Kabelmanager tauchte die Variante "GSM" immer mit der Meldung "Modem antwortet nicht" auf. Dies wurde korrigiert
Bei aktiver Busparameter-Erkennung von Steuerungen im Netz, die dies nicht unterstützen, wird jetzt eine entsprechende Rückmeldung angezeigt Achtung: Step7 V5.4 und folgende zeigen in diesem Fall nur ein leeres Fenster "Erreichbare Teilnehmer" an
Anstehende Protokollfehler auf der RS232-Seite werden nun bei korrekten Protokollen wieder gelöscht
Die Modem-Data-LED leuchtete teilweise bei der SPS-Kommunikation mit auf, obwohl seriell mit dem TeleService kommuniziert wurde
Die serielle Baudrate "19K2" wurde teilweise nicht korrekt erkannt
Die Anzeige Status Baustein einer S7-CPU 314-2DP (V1.0.3) über Profibus 1M5 Profil DP wurde nicht angezeigt, wenn diese CPU als Slave im Bus vorhanden war
V2.04 zeigte als Versionskennung immer V2.03 an
TS-Software V6.0, Bus-Auswahl "Auto" wurde ignoriert und somit nicht ausgeführt. Dadurch war kein ONLINE-Zugriff auf den angeschlossenen Bus möglich
Der Rückruf funktionierte nicht immer, was am verwendeten PC-Modem lag
Bei Kommunikationsfehler auf der seriellen oder Modemseite blinkt nun die Fehler-LED. Des weiteren können diese Fehler im MPI-Kabelmanager angezeigt bzw. ausgelesen werden
Im "Info/Meldungen"-Menu wurde der Zeilentrenner bei Cursor-hoch/runter korrigiert
Das Modem wechselte die Betriebsart bei Ansprechen durch ein Tele-Prof, wenn es sich im Automatik-Mode befand
Seit V2.03 konnten serielle Kommunikationsprobleme auftreten, wenn das Modem ohne angeschlossene SPS-Steuerung betrieben wurde
Beim Zugriff auf die Parametrierung des MPI-Modems über die Telefonleitung wurde beim Auflegen-String an den PC die Kombination "+++ATH" gesendet Dies wurde vom MPI-Modem aber ausgewertet und es legte somit sofort auf
Der Zugriffsschutz war während der Anmeldung noch nicht aktiv. Es konnte bevor man sich angemeldet hatte bereits mit der S7-SPS kommuniziert werden
Bei aktiver MPI-Baudratenerkennung wurde bei einer SPS-Steuerung die länger zum Hochlaufen benötigte wie das MPI-Modem selber eine Default-Baudrate von 187.5 KBd gesetzt und eine Kommunikation war anschließend nicht mehr möglich
Der Neustart des NC-Teils einer S7-Sinumerik mit der Software "HMIAdvanced" funktionierte nicht korrekt
Protokolle, die V3.0-Protokolle gekapselt hatten, wurden nicht korrekt verarbeitet
Unterstützung für den OPCmanager für den S7-200-Mode implementiert
Im Menubaum "Konfig" -> "Mode" wurde bei der Einstellung "PPIMulti" nicht mehr auf das Ausgangsmenu zurückgesprungen
Der Verbindungsaufbau (Zugriff auf den BUS) nach Stromwiederkehr funktionierte nicht immer
Die Meldungen "ErCodes<XX>" können nun zu/abgeschaltet werden. Die anderen Fehlermeldungen werden trotzdem über den MPI-Kabelmanager angezeigt. Oder aber über den Menupunkt Info => Meldung
ErrorCode 15h wird bei FunktionCode 46 nicht mehr ausgelöst. Es handelt sich hierbei im einen Broadcast an die im Bus befindlichen Slaves
Protokollart "HMI" in Verbindung mit der Visualisierung "IGSS32" war kein Kommunikationsaufbau möglich bzw. wurde nach 16 Protokollen mit Fehler abgebrochen
 |
|