TIA Bereichslängenfehler nach Hochrüsten auf TIA V16

ioStart

Level-2
Beiträge
242
Reaktionspunkte
43
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo allerseits,

nach dem Hochrüsten eines V15.1 - Projektes auf V16 geht mindestens ein Profinet-Frequenzumrichter nicht mehr.
Laut Diagnosepuffer der SPS stimmen nun 2 Zugriffsadressen nicht mehr, bzw sind nicht mehr im zulässigen Operandenbereich.
Ok, müsste irgendwie find- und lösbar sein. Vermutlich hängt es damit zusammen, dass die Technologieobjekte neu übersetzt wurden.

heutiger Test
- mit V15.1 eine Onlinesicherung erstellt
- das Projekt auf V16 hochgerüstet und die Software geladen
- es kommt zu den Bereichslängenfehlern
- die Onlinesicherung wieder eingespielt. Nun läuft wieder V15.1. Fehlerfrei


Jetzt liegt es nahe mit V16 die Hardware zu übersetzen und reinzuspielen. Allerdings hätte ich gerne die Sicherheit, bei Notwendigkeit die funktionierende V15.1 Hardwarekonfiguration wieder aktivieren zu können.
Weis jemand, ob die Online-Sicherung auch die Hardwarekonfiguration zuverlässig händelt? Die Doku ist da etwas irreführend
 
Was für eine CPU?
Die Online-Sicherung sollte auch die Hardware-Konfig händeln. Aber bei "frühen" TIA-Versionen ist man da nie sicher.
Ich halte es für keine gute Idee, die HW Konfig mit V15.1 zu machen und die Software mit V16. Mit viel Sorgfalt könnte es aber vielleicht gehen.
Warum machst du überhaupt das hochrüsten nach V16?
 
Es handelt sich um eine 1513F
Es ist eine gekaufte Maschine die bei uns im drei-Schichtbetrieb läuft. Stillstände sind unerwünscht. Daher ist ein umfangreiches Testen nicht leicht möglich.
Nun sollen aber recht umfangreiche statistische Funktionen hinzugefügt werden, wie wir sie bei den selbst gebauten Maschinen verwenden. Und die haben mindestens V16.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Falls es beim Hochrüsten Probleme gibt und keine Zeit für größere Tests etc. zur Verfügung stehen, kannst du die benötigten Bausteine dann nicht einfach in das 15.1 Projekt integrieren?

Der schnellste Weg dafür dürfte sein, Bausteinquellen aus einem V16 Projekt zu genieren, diese Quellen kannst du auch in 15.1 importieren und hast die Bausteine fix zur Hand. Natürlich mit der Einschränkung, dass dadurch keine Funktionen unter 15.1 funktionieren, die erst seit 16 gehen. Aber es sind vermutlich selbst geschriebene Bausteine? Da sollte dies in den meisten Fällen funktionieren.
 
Falls es beim Hochrüsten Probleme gibt und keine Zeit für größere Tests etc. zur Verfügung stehen, kannst du die benötigten Bausteine dann nicht einfach in das 15.1 Projekt integrieren?

Der schnellste Weg dafür dürfte sein, Bausteinquellen aus einem V16 Projekt zu genieren, diese Quellen kannst du auch in 15.1 importieren und hast die Bausteine fix zur Hand. Natürlich mit der Einschränkung, dass dadurch keine Funktionen unter 15.1 funktionieren, die erst seit 16 gehen. Aber es sind vermutlich selbst geschriebene Bausteine? Da sollte dies in den meisten Fällen funktionieren.
stimmt, dass integrieren ist vermutlich der Weg mit dem kleinsten Risiko - und wie du schreibst vermutlich auch recht einfach umzusetzen. Das Hochrüsten hätte halt den Vorteil, dass wir wieder eine Maschine mehr auf den neueren Programmiergeräten bearbeiten können. V15... und die Vorgänger haben wir nur auf den etwas älteren PG`s.
 
Wie lauten die Fehlermeldungen im Diagnosepuffer genau? Bitte zeig uns die.
Hast du eine neue Achse hinzugefügt oder warum haben sich die E/A-Adressen verschoben? Kannst du die nicht auf dieselbe Adresse wie in V15.1 projektieren?
Kann man eigenlich die Zugriffe aufs PAE/PAA zu Peripheriezugriffen ändern?

Es ist eine gekaufte Maschine die bei uns im drei-Schichtbetrieb läuft. Stillstände sind unerwünscht. Daher ist ein umfangreiches Testen nicht leicht möglich.
Das V15.1 Programm ist gar nicht von dir? Trotzdem traust du dich, das Programm zu V16 zu migrieren und ohne "umfangreiche" Tests zu verwenden?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das V15.1 Programm ist gar nicht von dir? Trotzdem traust du dich, das Programm zu V16 zu migrieren und ohne "umfangreiche" Tests zu verwenden?
ja was soll ich sagen. Ist doch häufig so. Irgendwo läuft ein Programm und das soll verbessert oder erweitert werden. Da sind Risiken nicht zu vermeiden. Aber eben in diesem Fall möchte ich größeren Schwierigkeiten aus dem Weg gehen und einfach die Sicherheit haben, dass ich mir den Rückweg nicht verbaue wenn ich die Hardware übersetze und reinspiele. (Eine Änderung am realen Aufbau gibt es ja nicht)


1720072827556.png

1720072901149.png
 
...wäre vielleicht mal interessant den FB28 von innen zu sehen ...
Will der FB28 für den Eingang und den Ausgang wirklich jeweils nur ein Bit ?
Als was ist denn der Status deklariert ?
 
Will der FB28 für den Eingang und den Ausgang wirklich jeweils nur ein Bit ?
Das wird nur so in TIA dargestellt, dass P#E354.0 angezeigt wird (die Bitadresse des Bereichs-Anfangs). TIA zeigt da nie den gesamten ANY-Pointer an. In Step7 classic kann man da den Mauszeiger drüberstellen und dann wird "Zugriffsbreite xxx Byte" angezeigt. Ich meine, das macht TIA aber nicht. (Wozu den Programmierer mit zu viel Informationen verwirren/überfordern ;) )
Es könnte aber auch sein, dass in dem FB28 die Eingangsparameter explizit als "POINTER" deklariert sind, und dann lustig auf die nachfolgenden Adressen der vermeintlich angeschalteten Struktur zugreift. Dann meckert der Compiler den Fehler nicht an und das SPS-Programm merkt den Fehler erst zur Laufzeit.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Was passiert, wenn man an der Stelle zu "gehe zu" klickt? Landet man am äußeren Teil des Bausteins oder wird der Baustein (inklusive der relevanten Codezeilen) geöffnet?

Hattest du nach dem Hochmigrieren nur die SW komplett übersetzt, die HW aber nicht geladen gehabt? HW aus 15.1 und SW aus 16 hat vielleicht auch Probleme, die sonst nicht entstehen würden.
 
Hattest du nach dem Hochmigrieren nur die SW komplett übersetzt, die HW aber nicht geladen gehabt? HW aus 15.1 und SW aus 16 hat vielleicht auch Probleme, die sonst nicht entstehen würden.
genau das ist der Punkt. Ich habe mich nicht getraut die Hardware mit V16 zu aktualisieren. Möchte ich aber. Ich möchte aber auch einen Weg zurück
 
Zuviel Werbung?
-> Hier kostenlos registrieren
genau das ist der Punkt. Ich habe mich nicht getraut die Hardware mit V16 zu aktualisieren. Möchte ich aber. Ich möchte aber auch einen Weg zurück
Irgendwie verstehe hier was nicht. Du hast doch eine Prg. Sicherung in V15.1, damit ist doch der Weg zurück gesichert....
 
Also Onlinesicherung (die mit dem CPU-Stop) beinhaltet auch die HW-Konfig, damit musste ich auch schonmal die Rolle rückwärts machen.

Was mir noch einfallen würde: Das V16 Projekt auf eine andere Speicherkarte laden und dann damit testen? Falls es nicht geht, dann die Original Karte wieder stecken. Kommt aber auch natürlich darauf an, wie hier mit Einstellwerten etc. im Projekt gearbeitet/umgegangen wird.
 
Irgendwie verstehe hier was nicht. Du hast doch eine Prg. Sicherung in V15.1, damit ist doch der Weg zurück gesichert....
bei der Hardware habe ich eben Zweifel, unter anderem auch dadurch, weil das Projekt nicht von mir ist. Deshalb wäre es mir lieber einen Weg zu wissen, wie ich die laufende Konfiguration sichern und wieder herstellen kann


Also Onlinesicherung (die mit dem CPU-Stop) beinhaltet auch die HW-Konfig, damit musste ich auch schonmal die Rolle rückwärts machen.
Danke für die Aussage.

Auch das mit der Speicherkarte werde ich in Betracht ziehen
 
Zurück
Oben