TIA Projektmigration von Classic nach TIA V16

Treut1012

Level-2
Beiträge
11
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Zusammen,

Ich muss aktuell ein Step 7 Projekt nach TIA V16 migrieren und das ist natürlich wie immer nicht so einfach wie gedacht :eek:.

Ich habe in vielen FC´s das selbe Problem. Immer mit dem Befehl L DBNO. Fehlermeldung: Die Anweisung greift auf das DB- bzw. das DI-Register zu. Sie haben jedoch keinen Datenbaustein in diesem Register geöffnet.

Hier mal der Programmcode einer FC.


L DBNO // Datenbausteinregister sichern
T #savdb
TAR1 #savar1 // 1. Adressregister sichern
L P##IN // Pointer auf Inputvariable holen
LAR1 // ins 1. Adressregister laden
L W [ AR1 , P#0.0 ] // Datenbausteinnummer holen
T #t_db
L D [ AR1 , P#2.0 ] // 1. Adressregister auf Anfang
LAR1 // von Inputvariable setzen
OPN DB [ #t_db] // Datenbaustein für Barcode öffnen


L #ANZ_W // Anzahl der Worte laden
LOOP: T #t_i // in Schleifenzähler laden
L 0
T W [ AR1 , P#0.0 ] // Wort zurücksetzen
+AR1 P#2.0 // 1. Adressregister auf nächste Inputvariable
L #t_i // Schleifenzähler laden
LOOP LOOP // Loopschleife ausfürhen


LAR1 #savar1 // Adressregister 1 wiederherstellen
OPN DB [ #savdb] // Datenbausteinregister wiederherstellen

Ich hoffe wie immer das mir jemand von euch weiterhelfen kann:rolleyes:
 
Ich bin jetzt Siemens Laie, aber ich meine mich zu erinnern, dass man zuerst den DB öffnen musste.
Steht denn in Register 1 schon die DB Nummer?
Schau mal hier nach, vielleicht fehlt bei Dir der Befehl AUF DBX noch.
Dieser Forumsbeitrag scheint meine Vermutung noch zu bestätigen.
Soweit es um eine S7-1500 geht könnte auch das weitehelfen. Bei der 1500er fehlen viele Register der 300er, diese werden zwar emuliert, aber nur bedingt weitergegeben (Eins der Fakten, die ich dank der Bücher von Herrn Berger sicher weiß).
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Willst du wirklich den Code 1 zu 1 abschreiben oder lieber die Funktion verstehen und nachbaun. Das hier ist eine Kopierfunktion mit variabler Länge. Könnte Durch etliche fertige Funktionen ersetzt werden. Wie sieht der Aufruf dieses FCs auf?

Wahrscheinlich meckert TIA weil vorher im Code kein DB aufgeschlagen ( mit AUF DB oder symbolischen Zugriff auf eine Variable). Im Classic ist das wohl egal.

Edit: Nicht kopieren, sondern löschen. Zu schnell gelesen
 
Zuletzt bearbeitet:
Da wird der aktuell aufgeschlagene DB gesichert und ganz am Ende wieder aufgemacht. (Genauso das AR1)
Hat mit der Funktion des FCs selber nichts zu tun.
Hat man früher oft gemacht um sicherzustellen das nach dem Aufruf des FCs wieder alles genau so ist wie vor dem Aufruf.
Ich weiß gar nicht ob bei TIA das jetzt autom. passiert !?!?
Allerdings sollte man inzwischen unqualifizierte DW-Aufrufe (also nur L DW 1 statt L DB123.dbw1) komplett wegmachen.
Zu 95% kannst Du 1., 2. und letzte Zeile löschen.
Allerdings hängt das schon davon ab, was da bei den Aufrufen des FC nachher passiert (also hinter dem CALL).
Wenn da immer ein neuer AUF oder ein L DB 123...... ist: dann kann das wech.
Aber genau genommen musst Du dir ALLE Aufrufe ansehen oder rauskriegen ob das bei TIA jetzt autom. passiert.
Kommt auch eine TIA-CPU oder bleibt es classic 300/400er ?
 
Erstmal Vielen Dank für die schnellen Antworten .

Also natürlich will ich die Funktionen auch verstehen :) . Ich würde natürlich erstmal eine schnelle und einfache Lösungen bevorzugen da es doch etliche FC´s sind wo dieses Problem auftritt . Jeden FC neu zu programmieren wäre wahrscheinlich mit sehr viel Zeitlichen Aufwand verbunden.

Also es wird auch die CPU getauscht . Wir haben bei uns im Unternehmen die 1516F als Standartbaugruppe festgelegt .

Der FC wird in mehreren ( in 4 ) unterschiedlichen FB´s aufgerufen .

Das ist z.B ein Aufruf in einen FB. Rot markiert ist die Funktion aus den FC .

ELSE (* Typen-Tybelle voll *)
#ERROR := TRUE; (* Fehler setzen *)

"OTT".anz_fehlertypen:="OTT".anz_fehlertypen+1; (* Anzahl Fehler erhöhen *)
END_IF;




(* Input-Variablen zurücksetzen *)
"L3_REST_IN"(IN:=#V_MFR_TYP, ANZ_W:=7);
"L3_REST_IN"(IN:=#EST00, ANZ_W:=32);
"L3_REST_IN"(IN:=#BIT00, ANZ_W:=32);
 
An sich schreit das nach einem DT.
Dann kannst Du überall schön symbolisch arbeiten. Aber dann musst Du natürlich alle Stellen (HMI !?!) nacharbeiten und die alten Programmstellen sicher verstehen.

Quick & Dirty wäre es die ersten beiden Zeilen und die letzte zu löschen. Und die temp-Variable #savdb
Eventuell auch die dritte und die Vorletzte und die #savar1.

Es macht Sinn das Du das in vielen Hilfs-FC hast. Wie gesagt, Sinn ist es zu 99% Schludereien beim/nach Call des FCs auszuschließen.
Ein Programmierer der sowas gemacht hat hat normalerweise auch hinter den Calls sauber gearbeitet. Wenn allerdings viele verschieden Köpfe dran waren, dann .....

Wahrscheinlich würde dir aber TIA beim übersetzen auch wieder eine Warnung melden, wenn ein unqualifizierter DB-Aufruf danach kommen würde.
 
Zuletzt bearbeitet:
Also das mit dem löschen der 1 / 2. Zeile und letzten Zeile funktioniert soweit erstmal . Beim übersetzen der FC´s bekomme ich erstmal keine Fehler mehr . Die Frage für mich immer noch WARUM :confused::D .
 
Schreit nach einen DT ?

DatenTyp oder bei bei S7 UDT UserDatenTyp

Damit kann man Variablen (Auch Unterschiedliche wie BOOL + DINT) zusammenfassen und entweder zusammen der auch einzeln voll symbolisch bearbeiten/adressieren. Das führt jetzt hier ein bisschen zuweit ... Such mal im www oder hier.

Die Frage für mich immer noch WARUM :confused::D .
Ich hab es in Post 4 probiert zu erklären. Wo genau steigst Du aus?
L DNBO lädt die aktuelle aufgeschlagene DB-Nr.
T #savdb sichert diese in einer Variable

OPN DB [ #savdb] schlägt wieder den vorigeren DB auf

So macht man das heute nicht mehr und TIA kann/oder will es nicht. Da ist am Anfang eines neuen Bausteins kein DB auf (auch nicht der von der vorigen Aufruf-Instanz). Das muss der Programmierer korrekt definieren und darf nicht mehr unbestimmt sein. Darum ERROR beim übersetzen.

 
Zuviel Werbung?
-> Hier kostenlos registrieren
Olli_BS Vielen Dank schonmal für deine Geduld :D;).

Also die "alte Funktion" verstehe ich soweit . Allerdings verstehe ich nicht wirklich wo dann der TIA FC seinen Bezug zum DB herstellt wenn ich einfach nur die Zeilen lösche.
 
Gar nicht. Diese gelöschten Zeilen haben nichts mit der Soll-Funktion des FCs zu tun.
Sie sind bei S5/S7 nur dafür da, das nach den Aufruf des FC es in dem Aufrufenden Baustein HINTER dem CALL alles genauso so ist wie Vor dem CALL.
In Zeile 10 OPN DB [ #t_db] wird ja für die eigentliche Aufgabe der DB aufgeschlagen.
 
Was halt auch hinzu kommt ist die Firmware einer 300er oder 400er CPU hat im Untergrund eine andere Architektur als die 1500er und TIA heute. Heutzutage sind solche indirekten Operationen halt noch möglich um alten Code aus der Classic Welt weiterhin verwenden zu können. Wenn man früher in der Classic Welt viele Daten hin und her geschoben hat z.B. Strings, waren solche indirekten Operationen oder Pointer fast täglich Brot und die gängige Methode um dies zu Programmieren in S7. AWL hatte da halt auch noch einen eindeutig höheren Stellenwert als heute.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
...waren solche indirekten Operationen oder Pointer fast täglich Brot und die gängige Methode um dies zu Programmieren in S7. AWL hatte da halt auch noch einen eindeutig höheren Stellenwert als heute.

Naja, heute gibt es halt auch bessere Möglichkeiten. Und ich muss sagen, die vollsymbolische Programmierung hat für mich nur Vorteile
( und ja, ich bin auch aus einer Zeit in der indirektes + Pointer Standard waren ). Ich bin froh, dass ich dies nicht mehr einsetzen muss.
 
Zuletzt bearbeitet:
Zurück
Oben