Welche 300er SPS soll ich nehmen?

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

wenn das die quelle von longbow, finde ich deine Anweisung nicht....

ich sag ja mach eine vernünftige Quelle daraus, so wie du es gelernt hast.

 

[BoxHead]

In der SCL Quelle steht:

 [B][COLOR=red]Ergebins := 20.2 x 5.5[/COLOR][/B]

Ja und das sind zwei Konstanten die Multipliziert werden. Der Compiler ist so nett diese unnötige Berechnung fix in den Code einzubauen.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

In der SCL Quelle steht:

 [B][COLOR=red]Ergebins := 20.2 x 5.5[/COLOR][/B]

Keine Ahnung warum er das im AWL Code nicht anzeigt sondern nur das Ergebnis von L 1.111000e+002

Weil alle Faktoren Konstanten sind.
Jeder vernünftige Compiler zieht die Konstanten zusammen und legt gleich das Ergebnis in den Programmcode.
Wenn Du SCL zur Berechnung zur Runtime zwingen willst, dann muß mindestens ein Faktor eine Variable sein.

Gruß
Harald

 

[rostiger Nagel]

@Paule,
dann ist am Ende, die neue 300er gar nicht so schnell wie eine VIPA *ROFL*

 

[Paule]

Weil alle Faktoren Konstanten sind.
Jeder vernünftige Compiler zieht die Konstanten zusammen und legt gleich das Ergebnis in den Programmcode.
Wenn Du SCL zur Berechnung zur Runtime zwingen willst, dann muß mindestens ein Faktor eine Variable sein.

Gruß
Harald

Ja, habe jetzt auch die ganze Zeit gegrübelt und bin zu dem Ergebnis gekommen das es so sein muss wie Ihr schreibt.
Jetzt wollte ich Euch meine Gedankengänge mitteilen und sehe Ihr habt die Lösung schon geschrieben.

@Helmut, das hat mit der VIPA ja gar nichts zu tun.
Ich habe ja nur die neue mit der alten verglichen.
Ok, dann sind es halt nur Doppelwortoperation, sei’s drum.
Wie ich schon geschrieben habe, der Unterschied ist trotzdem erkenn bar.

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Paule,
du hast doch in Beitrag #19 deinen Hut in den Ring geworfen
http://www.sps-forum.de/showpost.php?p=273617&postcount=19

wo du den "Chefmech" mit den neuen CPU's ein wenig Gegenwind
geben wolltest

 

[dalbi]

Hi,

...In diesem Programm gibt es keine einzige Realzahloperation!
Nur ein paar Doppelwortadditionen und Subtraktionen und einer kurzen Schleife...

Danke! Das Teil stammt von mir. Ich hab mir den generierten Code nicht angeschaut. :roll: Aber ihr habt alle recht, bekenne mich voll und ganz schuldig.

Gruss Daniel

 

[rostiger Nagel]

Hi,



Danke! Das Teil stammt von mir. Ich hab mir den generierten Code nicht angeschaut. :roll: Aber ihr habt alle recht, bekenne mich voll und ganz schuldig.

Gruss Daniel

also Angeklagter erwarten Sie ihr Strafe, schreiben Sie 1.000.000 mal
fogenden Satz an die Tafel, aber bitte in 5,6 sec.:

"Ich soll nur AWL verwenden, SCL ist tabu"

 

[dalbi]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,

Ich soll nur AWL verwenden, SCL ist tabu.
Ich soll nur AWL verwenden, SCL ist tabu.
Ich soll nur AWL verwenden, SCL ist tabu.
Ich soll nur AWL verwenden, SCL ist tabu.
.... :-D

Gruss Daniel

 

[dalbi]

Hi,

man sollte um diese Zeit nichts mehr anfangen.

Gruss Daniel

 

[Perfektionist]

[B][COLOR=black]Ergebins := 20.2 x 5.5[/COLOR][/B]

dem möchte ich noch hinzufügen, dass andere Zahlenwerte zu anderen Ausführungszeiten führen können (wenn es dann zur Laufzeit berechnet wird).

 

[dalbi]

Zuviel Werbung?
-> Hier kostenlos registrieren

[B][COLOR=black]Ergebins := 20.2 x 5.5[/COLOR][/B]

dem möchte ich noch hinzufügen, dass andere Zahlenwerte zu anderen Ausführungszeiten führen können (wenn es dann zur Laufzeit berechnet wird).

Schon klar, es ging auch nur darum mal einen Vergleich zu haben.

In der neuen Version hab ich es jetzt über Merkerdoppelwörter gelöst, ich bin der Meinung das dies realistischer ist, ebenfalls werden die für die Berechnung notwendigen Schleifenoperationen vom Wert subtrahiert, somit bleibt die reale Zeitdauer der Rechenoperation übrig.

Gruss Daniel

 

[Longbow]

Schon klar, es ging auch nur darum mal einen Vergleich zu haben.

In der neuen Version hab ich es jetzt über Merkerdoppelwörter gelöst, ich bin der Meinung das dies realistischer ist, ebenfalls werden die für die Berechnung notwendigen Schleifenoperationen vom Wert subtrahiert, somit bleibt die reale Zeitdauer der Rechenoperation übrig.

Gruss Daniel

Die Anmerkung von Perfektionist ist vor allem auch dahingehen wichtig, dass die 400er, 318 und die Speed7 CPUs bei Floatingpoint Arithmetik mit denormalisierten Zahlen rechnen können und die meisten 300er nicht.
Spielt vor allem für Regler eine Rolle, wenn die Regeldifferenz gegen 0 geht.
Bei einem Vergleich dieser CPUs würden dann unterschiedliche Ergebnisse von den Zahlen und von den Laufzeiten herauskommen.

 

[dalbi]

Hi,

Die Anmerkung von Perfektionist ist vor allem auch dahingehen wichtig, dass die 400er, 318 und die Speed7 CPUs bei Floatingpoint Arithmetik mit denormalisierten Zahlen rechnen können und die meisten 300er nicht.
Spielt vor allem für Regler eine Rolle, wenn die Regeldifferenz gegen 0 geht.
Bei einem Vergleich dieser CPUs würden dann unterschiedliche Ergebnisse von den Zahlen und von den Laufzeiten herauskommen.

Wie kommst Du da drauf bzw. wo kann man das nachlesen?
Die Formel für den Siemens Float 32 ist auf allen CPUs gleich G(Z)=VZ*Mantisse*2**(Exponent-127).

Hab das auf einer WinAC Maschine mal getestet, die größe der Zahlen spielt keine Rolle.

Gruss Daniel

 

[Rainer Hönle]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie kommst Du da drauf bzw. wo kann man das nachlesen?

Weil er sich die Teilchen auch gerne mal von ganz innen ansieht ;-)

Die Formel für den Siemens Float 32 ist auf allen CPUs gleich G(Z)=VZ*Mantisse*2**(Exponent-127).

Hab das auf einer WinAC Maschine mal getestet, die größe der Zahlen spielt keine Rolle.

Gruss Daniel

WinAC läuft auf einem X86. Dort ist heuzutage ein mathematischer Coprozessor immer dabei. Da gibt es keine Probleme mit der Arithmetik (wenn wir mal von dem letzten Pentium-Floatingpoint-Bug absehen )

 

[Longbow]

Hi,



Wie kommst Du da drauf bzw. wo kann man das nachlesen?
Die Formel für den Siemens Float 32 ist auf allen CPUs gleich G(Z)=VZ*Mantisse*2**(Exponent-127).

Hab das auf einer WinAC Maschine mal getestet, die größe der Zahlen spielt keine Rolle.

Gruss Daniel

Wie ich darauf komme:
Wir hatten da so unsere Diskussionen als eine geeignete Floatingpointunit am Tisch gegenüber entstanden ist...

Folgendes Beispiel:

L 2.000000e-038 //sehr kleine Zahl, aber noch normalisiert
L 5.000000e-001 //jetzt mit 0.5 multiplizieren
*R //Ergebnis anschauen


319/317 : 0.000e+000

318/400: 1.000e-038

 

[dalbi]

Hi,

Wie ich darauf komme:
Wir hatten da so unsere Diskussionen als eine geeignete Floatingpointunit am Tisch gegenüber entstanden ist...

Folgendes Beispiel:

L 2.000000e-038 //sehr kleine Zahl, aber noch normalisiert
L 5.000000e-001 //jetzt mit 0.5 multiplizieren
*R //Ergebnis anschauen


319/317 : 0.000e+000

318/400: 1.000e-038

irgendwie lässt mir das ganze keine Ruhe. Floatingpoint ist gut, ich hab auch Funktionen für die S7 geschrieben, damit kannst Du dann auch mit größeren Zahlen rechnen IEEE 754 "double" und die entstand nicht am Tisch gegenüber , sondern an meinen.

Die Frage ist nur was bringt dir das ob das Ding jetzt 0.0e+000 oder 1.0e-038 anzeigt?

Gruss Daniel

 

[rostiger Nagel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi,



irgendwie lässt mir das ganze keine Ruhe. Floatingpoint ist gut, ich hab auch Funktionen für die S7 geschrieben, damit kannst Du dann auch mit größeren Zahlen rechnen IEEE 754 "double" und die entstand nicht am Tisch gegenüber , sondern an meinen.

Die Frage ist nur was bringt dir das ob das Ding jetzt 0.0e+000 oder 1.0e-038 anzeigt?

Gruss Daniel

Daniel da muß ich dir wiedersprechen, ich finde es nicht gut wenn
aufeinmal unterschiedliche Ergebnisse, im selben Programm herauskommen
aber in unterschiedlichen Plattform.
Stell dir mal vor der Wert steht für eine Achse und Sie fährt nicht den
negativen Wert an, sondern fährt auf "0", obwohl das eigentliche Ziel noch
weit von dieser "0" entfernt ist. Was kann mann da noch so merkwürdiges
erwarten.

Das ist nicht gut.....garnicht gut...

 

[dalbi]

Hi,

...318/400: 1.000e-038

auch hier ist spätestens nach 1.401e-45 Schluss danach ist es auch einfach 0.

Gruss Daniel

 

[Longbow]

Hi,



irgendwie lässt mir das ganze keine Ruhe. Floatingpoint ist gut, ich hab auch Funktionen für die S7 geschrieben, damit kannst Du dann auch mit größeren Zahlen rechnen IEEE 754 "double" und die entstand nicht am Tisch gegenüber , sondern an meinen.

Die Frage ist nur was bringt dir das ob das Ding jetzt 0.0e+000 oder 1.0e-038 anzeigt?

Gruss Daniel

Was bringt es:
Beispiel: PID Regler, dort soll auf eine Regeldifferenz von 0 geregelt werden, fehlt der Zahlenbereich um die 0 herum, kann der Regler etwas unruhig werden.
Aus dem Grund hat SIEMENS in ihrem FB41 ein spezielles Konstrukt drin um genau diese "Ungenauigkeit" der 300er zu kompensieren.

Ist es notwendig:
Für manche Anwendung ja, aus dem Grund ja auch die REAL2-Bausteine in der OSCAT LIB...


Bezüglich Benchmark (und darum ging es eigentlich):
Wenn man mit einem Benchmark in diesen Bereich hineinkommt,
muss ein System mit denormalisierten Zahlen wirklich etwas tun während ein System ohne denormalisierten Zahlen einfach aufhören kann...


@Helmut:
Es gibt ja noch viel mehr Unterschiede zwischen 318/400 und den anderen 300ern:

Die Akkus sind der offensichtliche
Die fehlenden 3 Statusbits der 300er
Die falsche Abarbeitung von Sprungbefehlen in Verknüpfungsketten hinein bei der 300er
Anderes Handling von S7-Timer und Counter Befehlen bezüglich BCD Wandlungsfehlern