TIA Problem beim Umstieg auf TIA und S7-1500

CNC840D

Level-2
Beiträge
161
Reaktionspunkte
10
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich muss nun leider auch nach 20 Jahren von meinem guten alten Classic Abschied nehmen.
Hab gerade mal versucht ein paar Hilfsbausteine umzusetzen und hänge gerade bei einer kleinen Funktion die wir so immer wieder mal nutzen.

Beschreibung der Funktion:
Bei einem von aussen anparametrierbaren DB wird die gesamte Länge ausgelesen und dann anschliessend der gesamte DB ( egal wie er innendrin aussieht) auf einen Wert initialisiert.

Das auslesen der DB- Länge scheint zu funktionieren, allerdings meckert der Compiler ständig in meiner For Schleife.
Hat jemand ne Ahnung woran das liegt.

// Auslesen der absoluten Länge des DB's
#RetvalAttrDB := ATTR_DB(REQ := TRUE, DB_NUMBER := #MeldeDB, DB_LENGTH => #DB_length, ATTRIB => #Attrib);
// Alle bits wortweise zurücksetzen in einer Schleife
FOR #i := 0 TO UDINT_TO_INT(#DB_length) - 2 DO
#MeldeDB.DW[#i]:=0;-----> hier bei DW meckert immer der Compiler
END_FOR;

Danke schonmal für Eure Hilfe
 
Ha glaub ich die Lösung selber gefunden.
Aber evtl. gints ja noch was besseres?

Hier meine Lösung
/ Alle bits wortweise zurücksetzen in einer Schleife
FOR #i := 0 TO UDINT_TO_INT(#DB_length) - 2 DO
POKE(area:=16#84,
dbNumber:=#MeldeDB,
byteOffset:=#i,
value:=#Wert,
ENO => ENO);
END_FOR;
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn ich Poke-Befehle sehe, dann stellen sich mir die wenigen noch verbliebenen Haare :ROFLMAO:

Nutz doch den Umstieg auf TIA um auf symbolische Programmierung zu wechseln.
Man muß zwar Anfangs viel Hirnschmalz und Zeit investieren, aber das zahlt sich sehr sehr schnell aus.

Dein aktuelles Problem kannst du mit FILL wahrscheinlich einfacher lösen.

Gruß
Blockmove
 
FILL kann bei TIA zu Problemen führen wenn Strings damit gelöscht werden. Die Längeninfos des Strings werden such initialisiert und das führt zu Problemen (zu noch mehr als bei Classic) bei der Weiterverarbeitung der Strings. Ausserdem funktioniert FILL nur im nicht optimierten Bereich. Bei uns werden DBs die zur Laufzeit initialisiert werden müssen nur noch aus UDTs aufgebaut und mir Leerdatensätzen überschrieben. Das gwht in FUP mit Move, in SCL als Zuweisung und funktioniert auch im optimierten Bereich. Ausnahme ist wie im Beispiel der Melde DB, der immer nicht optimiert ist und nur Bits enthält. Hier verwenden wir noch FILL.
 
FILL kann bei TIA zu Problemen führen wenn Strings damit gelöscht werden. Die Längeninfos des Strings werden such initialisiert und das führt zu Problemen (zu noch mehr als bei Classic) bei der Weiterverarbeitung der Strings. Ausserdem funktioniert FILL nur im nicht optimierten Bereich. Bei uns werden DBs die zur Laufzeit initialisiert werden müssen nur noch aus UDTs aufgebaut und mir Leerdatensätzen überschrieben. Das gwht in FUP mit Move, in SCL als Zuweisung und funktioniert auch im optimierten Bereich. Ausnahme ist wie im Beispiel der Melde DB, der immer nicht optimiert ist und nur Bits enthält. Hier verwenden wir noch FILL.

FILL ist bei Strings nie eine gute Lösung ... Weder bei Classic noch bei TIA.
POKE funktioniert auch nur bei nicht optimierten DBs.

Ansonsten stimme ich dir zu 100% zu.
Sauber definerte Datentypen machen einem das Leben leichter.
Man kommt aber auch viel schneller in die Reinitialiserungshölle damit :p
Segen und Fluch zugleich eben
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das auslesen der DB- Länge scheint zu funktionieren, allerdings meckert der Compiler ständig in meiner For Schleife.
. . .
FOR #i := 0 TO UDINT_TO_INT(#DB_length) - 2 DO
#MeldeDB.DW[#i]:=0;-----> hier bei DW meckert immer der Compiler
END_FOR;
Darf man erfahren, wie die Meckereien des Compilers lauten?
Warnt er vielleicht nur, weil sich die ZielBereiche überschneiden?
Funktioniert es denn
- entweder mit #MeldeDB.DB[#i]:=0
- oder, wenn #i mit Schrittweite 2 erhöht wird?
 
ich vermute mal bei dem Nick CNC840D gehts hier um Sinumerik.
Warum muss der Melde DB ich vermute mal DB2 komplett mit null überschrieben werden ?
die letzte Begründung die ich hörte war "Das haben wir schon immer so gemacht"


@TP-Inc warum führt Fill auf eine String in TIA zu mehr Problemen als in Classic ?
 
Darf man erfahren, wie die Meckereien des Compilers lauten?
Der Compiler meckert, weil es in TIA-SCL die Schreibweisen MyDB.DB[..], MyDB.DW[..], MyDB.DD[..] für indizierten Zugriff auf absolute Adressen/Speicherbereiche der CPU nicht mehr gibt und man dafür nun die neuen Anweisungen PEEK und POKE verwenden muß. (damit die Schreibweise nicht mit Zugriffen auf Arrays verwechselt wird?)

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Peter,

Sinumerik war mal...muss hier gerade innerhalb ein-/2 Woche unser altes Standard-Projekt von Classic auf TIA umziehen.
Wir versuchen das nun schon seit 2 jahren aber irgendwie war ich ständig on Tour und mein Chef hatte immer andere Ideen
Ich weis das PEEk POKE usw. nicht unbedingt der Hit sind aber auf die schnelle fiel mir halt nix besseres ein.
Zudem muss ich erstmal ein bisschen Erfahrung mit TIA sammeln. Ich programmier zwar schon ein paar Jährchen, aber TIA hab ich bis jetzt vermieden.

Ich gelobe auf jedenfall Besserung..brauch aber halt noch ein wenig Zeit :)
 
Nein alles gut.:)
unsere Sinumerik Truppe ist erst am Anfang ..hab aber noch nix davon gesehen..ich bin da Gott Sei Dank raus.
Allerdings sind die ersten Kontakte mit TIA bei mir auch leicht frustrierend...es fehlt halt schlichtweg die Zeit
 
Zurück
Oben