TIA SCL-Codefehler nach hochrüsten von V15 auf V16

S

schwimmer

Level-3
Beiträge
1.056
Reaktionspunkte
309
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Forum,
ich habe ein bestehendes Projekt indem SCL-Code verwendet wurde. Leider ich damit bisher noch nicht gearbeitet.
Wenn ich das Projekt (erstellt mit V15) in V16 öffne und übersetze bekomme ich einen Fehler im SCL - Code, in V15 arbeitet alles.
Die Codezeile lautet:
#MB_Client_Conn1.ID := #inConnID + 1;
#inConnID ist im Datenformat CONN_OUC angelegt.
Als Fehlermeldung wird "Operator '+' ist nicht kompatibel mit den Datentypen von 'CONN_OUC' und 'Word' " ausgegeben.
Kann mir jemand sagen wie der Code unter V16 richtig heißen muss?

Danke für eure Unterstützung.
 
Das liegt, so wie es sich für mich liest, daran das der Datentyp WORD nur Vergleiche aber keine Rechenoperationen zuläßt. Scheinbar hat TIA V15 dir das noch durchgehen lassen oder du hast da in den Voreinstellungen etwas anderes stehen.
Quick'and'dirty müße die Codezeile ungefähr so heißen (ich habe gerade kein TIA zur Hand) :
Code: 
[COLOR=#333333]#MB_Client_Conn1.ID := Int_to_Word(Word_to_Int(#inConnID) + 1) ;[/COLOR]
Nachsatz :
Bei deinem Typ Conn_OUC kann ich gerade gar nicht wechseln ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich kann es gerade nicht testen, aber ich vermute, dass in V16 direkte mathematische Operationen bei Bitvariablen (WORD, BYTE, usw.) nicht mehr zulässig sind oder er die 1 "falsch" interpretiert. Hast Du mal versucht die Variable inConnID als UINT zu deklarieren und bei der Übergabe nach der Erhöhung mit UINT_TO_WORD zu konvertieren.
 
Danke für die schnelle Info, wie gesagt SCL habe ich bisher noch nicht genutzt.
Jetzt gibt es keine Fehlermeldung mehr, werde es dann austesten sobald ich die Anlage zur verfügung habe.
 
Larry Laffer schrieb:
Das liegt, so wie es sich für mich liest, daran das der Datentyp WORD nur Vergleiche aber keine Rechenoperationen zuläßt. Scheinbar hat TIA V15 dir das noch durchgehen lassen oder du hast da in den Voreinstellungen etwas anderes stehen.
Quick'and'dirty müße die Codezeile ungefähr so heißen (ich habe gerade kein TIA zur Hand) :
Code: 
[COLOR=#333333]#MB_Client_Conn1.ID := Int_to_Word(Word_to_Int(#inConnID) + 1) ;[/COLOR]
Nachsatz :
Bei deinem Typ Conn_OUC kann ich gerade gar nicht wechseln ...
Zum Vergrößern anklicken....

Der Baustein regelt die kommunikation mit zwei PAC3220 via ModBus. Über den Parameter wird die ID der Geräte hochgezählt.
Wie gesagt der Baustein ist nicht von mir, ich muss ihn nur in V16 benutzen, warum hier das Format CONN_OUC genutzt wurde kann ich nicht sagen.
Als Fehlermeldung wird ja nicht das Format sondern die Funktion "+" bemängelt.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
oliver.tonn schrieb:
OK, aber warum da Siemens als Datentyp WORD statt z.B. UINT nimmt bleibt trotzdem ein Rätsel.
Zum Vergrößern anklicken....
Vermutlich, weil man als professioneller Programmierer mit Referenznummern nicht arithmetisch rechnen soll. Welcher Sinn besteht in der Addition oder einem größer/kleiner-Vergleich von Referenznummern? Zwischen den Referenznummern besteht doch kein "natürlicher" Zusammenhang den man berechnen könnte. Verwendet das Programm womöglich auch Schrittketten wo der nächste Schritt aus "Schrittnummer + 1" berechnet wird oder Schrittnummern größer/kleiner verglichen werden?

Harald
 
Es wäre sicher auch möglich statt der Addition +1 einen zusätzlichen IN-Parameter zu definieren, wie gesagt ich weiß nicht warum der ursprüngliche Programmierer so vorgegangen ist.
Auch wenn es nicht zu diesem Thema gehört, was spricht dagegen einen Programmablauf über Schrittketten zu realisieren und diese hochzuzählen?
 
Das Verhalten ist in den Release-Notes von V16 offer von einem der updates genau beschrieben.
V16 lässt das Rechnen mit abgeleiteten Systemdatentypen nicht mehr zu. Dazu gehören so Dinge wie CONN_OUC, HW_IO usw.

Wie PN/DP schon bemerkt hat, passt es zu einer modernen Programmierweise nicht, wenn man mit Referenzen rechnet. Ich denke hier noch mit Grauen an die Fehlersuche bei mehrfach verwendeten OUC-IDs an einer Anlage.
Ich denke dass auch Siemens bemerkt hat das da ziemlich viel Schindluder getrieben wird und hat dementsprechend einen Riegel vorgeschoben.

Technisch betrachtet macht es Sinn, da bei solchen Systemdatentypen eigentlich nicht klar ist, auf welchen Typen hier impliziert gecastet werden müsste um korrekt zu rechnen. Bei HW_IO, das von Uint abgeleitet ist, geht das ja noch, aber alles das von Bitarrays abgeleitet ist geht nicht eindeutig. Kann mir gut vorstellen das hier die Qualitätssicherung eines großen Kunden gemeckert hat.....
 
Zuviel Werbung?
-> Hier kostenlos registrieren
schwimmer schrieb:
Auch wenn es nicht zu diesem Thema gehört, was spricht dagegen einen Programmablauf über Schrittketten zu realisieren und diese hochzuzählen?
Zum Vergrößern anklicken....
Musstest Du schon mal in einer solcherart programmierten Schrittkette Schritte einfügen? Und hast auf Anhieb tatsächlich alle davon abhängigen Programmstellen korrekt angepasst?

Harald
 
maxder2te schrieb:
Das Verhalten ist in den Release-Notes von V16 offer von einem der updates genau beschrieben.
V16 lässt das Rechnen mit abgeleiteten Systemdatentypen nicht mehr zu. Dazu gehören so Dinge wie CONN_OUC, HW_IO usw.

Wie PN/DP schon bemerkt hat, passt es zu einer modernen Programmierweise nicht, wenn man mit Referenzen rechnet. Ich denke hier noch mit Grauen an die Fehlersuche bei mehrfach verwendeten OUC-IDs an einer Anlage.
Ich denke dass auch Siemens bemerkt hat das da ziemlich viel Schindluder getrieben wird und hat dementsprechend einen Riegel vorgeschoben.

Technisch betrachtet macht es Sinn, da bei solchen Systemdatentypen eigentlich nicht klar ist, auf welchen Typen hier impliziert gecastet werden müsste um korrekt zu rechnen. Bei HW_IO, das von Uint abgeleitet ist, geht das ja noch, aber alles das von Bitarrays abgeleitet ist geht nicht eindeutig. Kann mir gut vorstellen das hier die Qualitätssicherung eines großen Kunden gemeckert hat.....
Zum Vergrößern anklicken....

Bei HW_IO ist das aber recht ungünstig.
Ich hatte gestern eine Profinetklemme von Beckhoff einzubinden.
Die hatte ja 4 Eingangsbereiche und 4 Ausgangsbereiche. Das ging dann mit dpread und dpwrite mit der HW_IO, HW_IO+1, HW_IO+2, HW_IO+3.
Woe könnte man das machen, wenn man nicht 4 oder gar 8 HW_IO übergeben will?
Gab es da nicht noch einen Befehl, mit den man die Struktur auslesen kann?
 
Wer weiß ob das in V17 nicht schon wieder ganz anders ist.
Wie war das noch bei Step7 mit der Typüberprüfung der Operanden? Die Funktion kam hinzu und ich habe sie gerne genutzt weil sich damit viele Fehler bei den verschiedenen Datentypen erkennen lassen. Und mit einem späteren Servicepack war die Funktion dann wieder entfernt worden.

Da hatte bestimmt die "Qualitätssicherung eines großen Kunden" Probleme damit, dass ihre Schmierprogramme nun rot angezeigt wurden.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ralle schrieb:
Bei HW_IO ist das aber recht ungünstig.
Ich hatte gestern eine Profinetklemme von Beckhoff einzubinden.
Die hatte ja 4 Eingangsbereiche und 4 Ausgangsbereiche. Das ging dann mit dpread und dpwrite mit der HW_IO, HW_IO+1, HW_IO+2, HW_IO+3.
Woe könnte man das machen, wenn man nicht 4 oder gar 8 HW_IO übergeben will?
Gab es da nicht noch einen Befehl, mit den man die Struktur auslesen kann?
Zum Vergrößern anklicken....

Du meinst Log2Geo und Geo2Log?
Ich hab diese Funktionen immer benutzt, um die hw_io von zusammenhängender Hardware zu bestimmen. Bei den Sinamics S120 konnte man das wunderbar benutzen, um mit einer hw_io jene von allen 3 subslots zu bestimmen (safety, Telegramm und zudatzdaten)
 
Zurück
Oben