TIA Variablenwert online ändern

Beiträge
7.080
Reaktionspunkte
1.840
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,
ich habe, um etwas nachzuvollziehen, einen FB geschrieben der zwei Static Variablen enthält. Der Wert einer Variable wird unter Verwendung der anderen errechnet. Der FB wird in OB1 aufgerufen und das Ganze soll mangels Steuerung in PLCSIM laufen. Was ich jetzt nur nicht hinbekomme ist, wie ich die eine Variable ändern kann und dann den Wert der Errechneten sehe.
Ach ja, es geht um TIA V14.
 
Hallo Oliver,

du musst PLCSIM starten und deine Bausteine laden. Anschließend öffnest du eine Beobachtungstabelle und trägst dort deine 2 Variablen ein. Diese findest du im Instanz-DB zu deinem FB. Wenn du in die Onlineansicht wechselst, siehst du die aktuellen Werte. In der rechten Spalte kannst du nun den Steuerwert für deine Variable eintragen. Nach einem Klick auf das Blitzsymbol wird der Steuerwert in die Variable geschrieben.

Viel Erfolg,

Gruß Ben


Gesendet von iPhone mit Tapatalk
 
Öffne mal eine Beobachtungsliste. Dort trägst du deine beiden Variablen ein. z.B. DB1.DBD0 kannst die Variablen aber auch Symbolisch eintragen, wenn dir dieses lieber ist. z.B. „Berechnung_IDB“.Variable1.


Gesendet von iPhone mit Tapatalk
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Würdest Du bitte noch schilderen, worin der "Fehler" bestand?
Vlt. hat mal jemand anderes genau das gleiche Problem, dem das dann weiterhelfen könnte.
;)
Gerne, der Fehler lag bei Oliver Tonn. [emoji6]
Ich bin noch nicht so fit in TIA und hatte nicht erkannt, das eigentlich alles geklappt hatte mit dem Setzen der Variable. Ich arbeite ja gerade an einer FAQ zum Thema Skalierung und wollte da auch zeigen, welche Fehler man bei der Programmierung machen kann und da will ich Beispiele von Codesys Derivaten und Step 7/TIA vorstellen. Bei TwinCAT 3 hatte ich bei falscher Programmierung anstatt ca. 2,75 als Ergebnis 2 erhalten, was ich auch erwartet hatte, bei TIA blieb das Ergebnis jedoch 0 und da dachte ich es hat etwas mit dem online Setzen der Variablen nicht geklappt. Der Grund das die Variable 0 blieb war aber, das Siemens beim Rechnen mit einer INT-Variable und zwei festen Zahlen, die im INT-Bereich liegen, das Zwischenergebnis auch als INT ablegt und nicht wie Beckhoff/Codesys da ein DINT nimmt.

Von irgendwas mit Internetzugang gesendet
 
und nicht wie Beckhoff/Codesys da ein DINT nimmt.
Hallo Oliver
Passt zwar eigentlich nicht hier her :ROFLMAO: aber kennst du eine Möglichkeit das Verhalten irgenwie zu beeinflussen?
Bei verschiedenen Codesysderivaten wird folgender Code (mit A & B als INT)
Code:
A:= B +1;
als Feher vom Compiler bemängelt.
Sinngemäß: "Kann INT nicht zu DINT addieren" da die 1 als DINT gewertet wird.
Holger
 
Hallo, man kann den Datentyp angeben, bedeutet du kannst vor die 1 ein INT# schreiben. Dann wird die eiins auch als int behandelt. Gruß Robert

Gesendet von meinem HUAWEI CAN-L11 mit Tapatalk
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Oliver
Passt zwar eigentlich nicht hier her :ROFLMAO: aber kennst du eine Möglichkeit das Verhalten irgenwie zu beeinflussen?
Bei verschiedenen Codesysderivaten wird folgender Code (mit A & B als INT)
Code:
A:= B +1;
als Feher vom Compiler bemängelt.
Sinngemäß: "Kann INT nicht zu DINT addieren" da die 1 als DINT gewertet wird.
Holger
Fällt mir nur DINT_TO_INT (1) ein. Kommt die Fehlermeldung auch wenn Du statt 1 das ganze in hexadezimaler Darstellung (16#0001) übergibst?

Von irgendwas mit Internetzugang gesendet
 
Bei verschiedenen Codesysderivaten wird folgender Code (mit A & B als INT)
Code:
A:= B +1;
als Feher vom Compiler bemängelt.
Sinngemäß: "Kann INT nicht zu DINT addieren" da die 1 als DINT gewertet wird.
Das klingt für mich ziemlich unglaublich. Bei welchem Codesys-Derivat z.B. ist das so?


Der Grund das die Variable 0 blieb war aber, das Siemens beim Rechnen mit einer INT-Variable und zwei festen Zahlen, die im INT-Bereich liegen, das Zwischenergebnis auch als INT ablegt und nicht wie Beckhoff/Codesys da ein DINT nimmt.
Das wiederum halte ich für ziemlichen Schwachfug von Beckhoff/Codesys, der vermutlich der Unfähigkeit oder Faulheit vieler ST-Programmierer geschuldet ist, Programmcode mit Berechnungen korrekt zu formulieren - also soll der Compiler nicht Fehler melden sondern automatisch/implizit/heimlich verbessern und konvertieren? :roll:

Harald
 
Das wiederum halte ich für ziemlichen Schwachfug von Beckhoff/Codesys, der vermutlich der Unfähigkeit oder Faulheit vieler ST-Programmierer geschuldet ist, Programmcode mit Berechnungen korrekt zu formulieren - also soll der Compiler nicht Fehler melden sondern automatisch/implizit/heimlich verbessern und konvertieren?

Und in allen anderen Sprachen der IEC wie IL, LAD, FBD und SFC ist das nicht so, nur in ST? Extra für die faulen und dummen ST-Programmierer?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Und in allen anderen Sprachen der IEC wie IL, LAD, FBD und SFC ist das nicht so, nur in ST? Extra für die faulen und dummen ST-Programmierer?
Das weiß ich nicht. Doch wenn es in ST so gemacht wird, dann müsste es konsequenterweise auch in den anderen Sprachen so gemacht werden - und dann würde ich es auch da für Schwachfug halten. Wo in der IEC steht, daß der Compiler (z.B. zur Erhöhung der Genauigkeit) bei der Berechnung ohne Warnung selbständig auf die auf der Zielplattform verfügbaren "höchsten" Datentypen ausweichen/konvertieren darf?

Harald
 
Skalierung mit INTs ?

Dann sollte man intern auf REALs umwandeln und damit berechnen und nur am ende zurück auf INT umwandeln und ausgeben.
Sonnst bekommt man Rundungsfehler, abhänging von die Skalierungsgrenzen eventuell extreme Rundungsfehlern.
 
Das Endergebnis soll ja ein Real-Wert sein und ich möchte in der FAQ aufzeigen was passiert, wenn man die "falschen" Variablentypen zum Berechnen nimmt.

Von irgendwas mit Internetzugang gesendet
 
Das weiß ich nicht. Doch wenn es in ST so gemacht wird, dann müsste es konsequenterweise auch in den anderen Sprachen so gemacht werden - und dann würde ich es auch da für Schwachfug halten. Wo in der IEC steht, daß der Compiler (z.B. zur Erhöhung der Genauigkeit) bei der Berechnung ohne Warnung selbständig auf die auf der Zielplattform verfügbaren "höchsten" Datentypen ausweichen/konvertieren darf?

Es wurde hier TwinCat3 erwähnt, und das orientiert sich an der IEC61131-3 Third Edition. Ich kann nicht sagen ob sich da in der Beziehung etwas geändert hat, ist ja leider nicht öffentlich. Es gab mal eine grobe Übersicht über die Änderungen, und dort waren auch diverse Änderungen an Datentypen und impliziter/expliziter Typkonvertierung angemerkt.

Bei den Normen ist auch immer einiges Auslegungssache. Z.B. das oft angemäkelte Verhalten bei Codesys, arithmetische Operationen von Integer-Variablen und Konstanten wie 16#1234 vornehmen zu können ist durchaus durch die Norm gedeckt. 16#1234 ist einfach ein numerisches Literal zur Basis 16, und nicht wie bei Dezimalzahlen zur Basis 10.
 
Bei den Normen ist auch immer einiges Auslegungssache. Z.B. das oft angemäkelte Verhalten bei Codesys, arithmetische Operationen von Integer-Variablen und Konstanten wie 16#1234 vornehmen zu können ist durchaus durch die Norm gedeckt. 16#1234 ist einfach ein numerisches Literal zur Basis 16, und nicht wie bei Dezimalzahlen zur Basis 10.
Ich habe noch nicht gehört/gesehen, daß das an Codesys angemäkelt würde - das geht sogar auch in S7-SCL:
Code:
IntVar1 := 16#1234;
IntVar2 := IntVar1 + 16#1234;

Was ich an Codesys doof finde ist, daß arithmetische und numerische Operationen sowie Vergleiche größer/kleiner mit WORDs (Bitstrings) möglich sind, weil da einfach WORD mit UINT gleichgesetzt wird. Konsequente Folge: es gibt keine direkte Möglichkeit, das Bitmuster aus einem (z.B. zusammengebastelten oder ge-SWAP-ten ) DWORD einer REAL-Variable zuzuweisen - das geht nur mit UNION/AT oder per Pointer.

Harald
 
Zurück
Oben