TIA TIA Portal V12 Update 3 verfügbar

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

TIA Portal V12 Update 3 verfügbar

http://support.automation.siemens.com/WW/view/de/68321809?Datakey=47071380

Gruß.

 

[vollmi]

wow diese vielen Verbesserungen. Ich bin von Sinnen vor unfassbarer nie versiegender Freude.

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

jo, mühsam ernährt sich der Eichkater... mit V12 SP5 Update 21 wird dann alles gut

 

[IBFS]

nur 37359 KB! - ist doch toll ;-)

 

[HelleBarde]

Hi

Siemens schreibt: "S7-300/S7-400: Die Berechnung von Real Werten als Konstanten wurde korrigiert."

Ich dachte eigentlich, dass ich, da in Deutschland geboren, aufgewachsen, zur Schule, ... also dass ich des Deutschen mächtig wäre. Oben zitierter Satz lässt mich jedoch zweifeln. Ich hab nicht den leisesten Hauch, was die hier korrigiert haben. Was muss man denn an einer Konstanten noch berechnen? Selbst wenn es eine Konstante im Format #.###e## ist, so steht die doch einfach so da.

Also wenn der große S sich zu einem Update bemüht, dann wird das wohl was Schlimmes sein. Ich habe in den letzten Wochen nicht gemerkt, dass sich meine Programme verrechnet hätten. Alle Regler regeln innerhalb der spezifizierten Parameter. Kein Band hat ein Werkstück weg katapultiert. Trotzdem macht mir das Sorgen.

Hat jemand eine Ahnung wie sich ein Programm daneben benehmen kann solange der Fehler nicht korrigiert ist?

 

[MSB]

Zuviel Werbung?
-> Hier kostenlos registrieren

Siemens schreibt: "S7-300/S7-400: Die Berechnung von Real Werten als Konstanten wurde korrigiert."

Das ist eigentlich relativ einfach ...
Wenn du eingibst L 1.0 dann landet das letzten Endes als Hex-Wert im Speicher. Also in der Form L DW#16#...
Heißt also im Klartext, du rechnest nicht mit 1.0 sondern mit was anderen.

Früher, in der guten alten Zeit, konnte man das auch noch Nativ als MC7 Code sehen, leider hat sich Siemens davon mit TIA aber verabschiedet (wenigstens von den "einfachen" Möglichkeiten.

Die Auswirkung ist: Du rechnest Murks.

Mfg
Manuel

 

[VISTAnwender]

Soviel vorweg --> Ich finde das TIA-Portal Eigentlich nicht schlecht!
_______________________________

Hätte das früher lesen sollen. Habe gerade in einem Programm einen Fehler gesucht. Ein Programmgeber für einen Ofen lief unter TIA11 einwandfrei.
Ich habe ein paar Änderungen an dem Ofen unter TIA12 vorgenommen.
Danach lief der Programmgeber ca. 1000 mal so schnell, obwohl ich am Programmgeber nichts geändert habe.

Das Problem:
15.0 * 3600.0 ergibt auf einer 300er Steuerung:
mit TIA11 --> 54000.0
mit TIA12 --> 45.0

Wie kann man so etwas veröffentlichen?

Frust.... :sb6:

 

[Thomas_v2.1]

@VISTAnwender
Und das wurde mit dem Update 3 behoben?
War die Berechnung 15.0 * 3600.0 im Programm mit Konstanten oder mit Variablen? In SCL, FUP oder AWL?

 

[VISTAnwender]

Zuviel Werbung?
-> Hier kostenlos registrieren

Habe es gerade getestet und
NEIN, es funktioniert immer noch nicht.

Problem besteht nur in SCL:
Sekunden := Stunden * 3600.0;

Berechnet wird: Sekunden = Stunden * 3
Unter "Classic" und TIA v11 lief dieser Programmcode einwandfrei.

Ich muss dem Compiler wohl erst beibringen, dass dies ein REAL ist oder
eine echte Konstante verwenden.

Melde mich nochmal.......

 

[VISTAnwender]

Eben war ich zu schnell...

Also nach Update 3 funktioniert alles wieder.
Auch ohne Kostante.

Endlich.....

 

[ducati]

oha... man glaubt es nicht...

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich muss dem Compiler wohl erst beibringen, dass dies ein REAL ist oder
eine echte Konstante verwenden.

Bei Konstanten muss man höllisch aufpassen dass einem die implizite Typkonvertierung die Berechnung nicht kaputtmacht. Das kann man aber nicht dem TIA anlasten.

Beispiel:

INTvar := 10;
REALvar := INTvar * 3600;

Hier wird die Multiplikation auf dem Datentyp Integer durchgeführt, und erst bei der Zuweisung in eine Real-Zahl konvertiert. Da das Ergebnis von 10*3600 nicht mehr vom Wertebereich Integer abgedeckt wird gibt es einen Überlauf. In REALvar steht dann -29536.0 (was wahrscheinlich nicht so geplant war).

Wenn man also Konstante hingegen 3600.0 schreibt, erkennt der Compiler die unterschiedlichen Typen und konvertiert INTvar vor der Multiplikation in eine Real-Zahl.
Das trifft auch für alle anderen numerischen Datentypen zu. Bei der 1200 gibt es beispielsweise den Typ USINT (8-Bit Ganzzahl).
Bei
USINTvar = 100;
INTvar = USINTvar * 100;
wird die Multiplikation ebenfalls auf USINT mit dem bei diesen Werten daraus resultierendem Bereichs-Überlauf durchgeführt.

 

[Jochen Kühner]

Unittests sind für Siemens wohl auch ein Fremdwort, wenn sich solch ein fehler in den compiler einschleichen kann...

 

[Ralle]

Bei Konstanten muss man höllisch aufpassen dass einem die implizite Typkonvertierung die Berechnung nicht kaputtmacht. Das kann man aber nicht dem TIA anlasten.

Beispiel:

INTvar := 10;
REALvar := INTvar * 3600;

Hier wird die Multiplikation auf dem Datentyp Integer durchgeführt, und erst bei der Zuweisung in eine Real-Zahl konvertiert. Da das Ergebnis von 10*3600 nicht mehr vom Wertebereich Integer abgedeckt wird gibt es einen Überlauf. In REALvar steht dann -29536.0 (was wahrscheinlich nicht so geplant war).

Wenn man also Konstante hingegen 3600.0 schreibt, erkennt der Compiler die unterschiedlichen Typen und konvertiert INTvar vor der Multiplikation in eine Real-Zahl.
Das trifft auch für alle anderen numerischen Datentypen zu. Bei der 1200 gibt es beispielsweise den Typ USINT (8-Bit Ganzzahl).
Bei
USINTvar = 100;
INTvar = USINTvar * 100;
wird die Multiplikation ebenfalls auf USINT mit dem bei diesen Werten daraus resultierendem Bereichs-Überlauf durchgeführt.

Aber wohl nicht in V12 SP2, siehe meinen Thread zu diesem Thema.

 

[LowLevelMahn]

Zuviel Werbung?
-> Hier kostenlos registrieren

und in Hochsprachen C/C++,Delphi,Java,.Net Variante... ist das ja auch nicht so

INTvar := 10;
REALvar := INTvar * 3600;

als C/C++ unter 32Bit VS,GCC,etc.

INT == short
REAL == float

short intvar = 10;

float realvar = intvar * 3600; ==> 36000.0

short tmp = intvar * 3600;
float realvar = tmp; ==> -29536.0

wird immer mit dem linksseitigen Typ (oder eher der groesste und das konvertiert) gerechnet - d.h. 1000Trillzillionen Zeilen Code und Entwickler verstehen das als normal
nur in der (Siemens)SPS ist das anders?

und C auf einem ARM ist nur ein Hauch weg von dem Code wie er native auf der S7 1200 läuft - es hat nichts mit der Hardwareplatform oder Optimierung und sonstiges
zu tun der SCL Kompiler macht meiner Meinung nach einfach falschen Code (oder verhält sich unkonform zum kompletten Rest der Welt)

Kann hier jemand mal klar ein Beispiel bringen was mit dem SP3 wirklich gefixt wurde (also SP2 SPS3 vergleich)
und mir erklären warum die SPS sich anders verhält als alle anderen Programmiersysteme?

 

[Ralle]

@LowLevelMan

Siehe hier.
Allerdings kann ich das nicht noch einmal machen, da ich nun auf UPD3 bin.
Zur Not kann ich evtl. noch einmal eine ältere VM-Sicherung reaktivieren, aber frühestens heute Abend, um das nochmals nachzuvollziehen.

PS: Nein, geht leider nicht mehr, UPD2-->UPD3 habe ich als Zwischensicherung nicht mehr parat.

 

[Thomas_v2.1]

wird immer mit dem linksseitigen Typ (oder eher der groesste und das konvertiert) gerechnet - d.h. 1000Trillzillionen Zeilen Code und Entwickler verstehen das als normal
nur in der (Siemens)SPS ist das anders?

Also diese Norm wäre mir neu, Siemens macht es genauso wie es bei C gemacht wird (den Bug mal ausgenommen).
Laut K&R ist es so dass die Typumwandlungen anhand der Operanden bestimmt werden.

Dass deine Tests funktionieren liegt einfach daran dass du auf einer 32- oder 64-Bit Maschine bist. Lass das alles mal auf einer 8- oder 16-Bit Maschine laufen, und wundere dich was passiert.

 

[LowLevelMahn]

Zuviel Werbung?
-> Hier kostenlos registrieren

Laut K&R ist es so dass die Typumwandlungen anhand der Operanden bestimmt werden.

ja und bei shorts und kleiner als int wird auf int oder unsigned int promoted - was C/C++ und alle anderen auch so machen
also sollte der SCL-Kompiler doch auf DInt(DWORD) promoten - das macht er aber nicht

bei nur float operanden wird auf float bei double und float wird auf double promoted (also REAL und LREAL)

Dass deine Tests funktionieren liegt einfach daran dass du auf einer 32- oder 64-Bit Maschine bist. Lass das alles mal auf einer 8- oder 16-Bit Maschine laufen, und wundere dich was passiert.

die SPS ist aber eine 32Bit Maschine - also erwarte ich schon irgendwie gleiches verhalten (ein C auf 32Bit ARM macht es ja auch genau so)

 

[Thomas_v2.1]

Integer promotion ist ja nochmal eine andere Baustelle.

Dann lass auf deiner 32-Bit Maschine mal folgendes laufen:

double double_testfunc1(int32_t op1)
{
	double f;
	f = op1 * 2000000000;
	return f;
}

double double_testfunc2(int32_t op1)
{
	double f;
	f = op1 * 2000000000.0L;
	return f;
}

Da hast du bei testfunc1 mit dem Parameter 1000 den gleichen Effekt den du hier Siemens anlastest.

 

[LowLevelMahn]

Integral promotion ist ja nochmal eine andere Baustelle.

und es ist in Ordnung das der SCL-Kompiler hier nicht richtig handelt?

Da hast du bei testfunc1 mit dem Parameter 1000 den gleichen Effekt den du hier Siemens anlastest.

Aber die S7 1200 ist doch eine 32 Bit Maschine (also ist doch ein 8/16Bit integral promotion "falsch") und der SCL-Kompiler sollte meiner Meinung nach die
Integral promotion so durchführen wie C auf 32 Bit ARM es macht oder verstehe ich deine Erklärungen einfach nicht

und dein Tip 3600 als 3600.0 zu schreiben kompensiert nur die fehlerhafte Integral promotion

Ich erwarte einfach das

INTvar := 10;
REALvar := INTvar * 3600;

als

INTvar := 10;
REALvar := DInt(INTvar * 3600);

kompiliert wird

Wie verhalten sich andere da - also z.B. Codesys?