Winkelfunktionen

[Longbow]

Zuviel Werbung?
-> Hier kostenlos registrieren

gibt es unterschiede zwischen FW2.6 und 3.3??

Ab FW3 wird eine vollkommen andere Hardware eingesetzt, MIPS statt C165.

 

[zloyduh]

Ab FW3 wird eine vollkommen andere Hardware eingesetzt, MIPS statt C165.

ändert sich dadurch auch irgendwas in der Programmierung ....??
viellecht ist dass das Problemm bei meiner Anwendung
weil mit FW2.6 funktioniert es

 

[Longbow]

Zuviel Werbung?
-> Hier kostenlos registrieren

ändert sich dadurch auch irgendwas in der Programmierung ....??
viellecht ist dass das Problemm bei meiner Anwendung
weil mit FW2.6 funktioniert es

Einfach mal die Bugliste bei den Firmwareupdates ansehen, SIEMENS kocht auch nur mit Wasser (aber meistens relativ gut).
Es gibt aber bei SIN/COS auch noch größere Unterschiede zwischen der 300er und 400er. Ich hab noch nicht geprüft ob es da von FW2 auf FW3 auch noch unterschiede bei z.B. den denormalisierten Zahlen (sehr klein) gab. Aber die Winkelfunktionen sind nicht
ganz so trivial wie es zunächst aussieht.

 

[Senator42]

Du dividirst Daten durch das Ergebnis von cos(Winkel_Bogenmaß) .

Bei 90 Grad ist doch cos( .. ) recht genau 0, oder viell. genau 0.0.

x / 0 --> error !

Ergebnis:= Daten/cos(Winkel_Bogenmaß);

nur mal so am rande.

 

[zloyduh]

Du dividirst Daten durch das Ergebnis von cos(Winkel_Bogenmaß) .

Bei 90 Grad ist doch cos( .. ) recht genau 0, oder viell. genau 0.0.

x / 0 --> error !

Ergebnis:= Daten/cos(Winkel_Bogenmaß);

nur mal so am rande.

nur mal so am rande: cos(0) = 1

 

[zloyduh]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wenn es denn ein Bug ist und Sinus funktioniert, dann vielleicht umwandeln.

sin^2(x) + cos^2(x) = 1

cos(x) = sqrt(1 - sin^2(x))

so funktioniert es :-D
d.h. es muss ein Fehler in der FW3.3 sein

 

[Ralle]

Du dividirst Daten durch das Ergebnis von cos(Winkel_Bogenmaß) .

Bei 90 Grad ist doch cos( .. ) recht genau 0, oder viell. genau 0.0.

x / 0 --> error !

Ergebnis:= Daten/cos(Winkel_Bogenmaß);

nur mal so am rande.

Da hast du wohl Recht.
Anscheinend arbeiten die SPS mit den unterschiedliche Firmwareständen und auch der Simulator da etwas anders.
Das Ergebnis, das die SPS anzeigt --> 16#7F800000 erhält man z.Bsp. bei Division durch Null, das bedeutet '3.4e39'
und ist wohl außerhalb des gültigen Bereiches. Währe noch interessant was die Zustandsbits sagen, damit könnte man einen Sprung ausführen bei Division durch Null. Das Bogenmaß von 90° ist ja 1.5707963267948966 das wird in der SPS eingekürzt und dann ist der Cos davon vielleicht nicht genau 0.0.

 

[alicikcik]

Heute hatte ich dasselbe Problem.

Auch wollte ich genau wissen, was das Ergebnis von der Anweisung
L 0.0
ist. Deshalb die Variable Test2.

DAs Ergebnis:



Es wird tatsächlich eine Null in der Variable Test2 erhalten.
Aber das Ergebnis nach Ausführung von COS-Anweisung ist völlig daneben. Das Ergebnis hätte eine 1 sein müssen.

Deshalb addiere ich im Voraus auf den eigentlichen Winkel 2*pi = 6,28...



Dann kommt auch das richtige Ergebnis.
Na ja! Fast richtig.
Aber für meine Zwecke genau genug-.



Und hier die CPU:



Siehe da, die gleiche Firmware wie in diesen Thread: V 3.3.7

Gruss

 

[hucki]

Zuviel Werbung?
-> Hier kostenlos registrieren

...
DAs Ergebnis:



Es wird tatsächlich eine Null in der Variable Test2 erhalten.
Aber das Ergebnis nach Ausführung von COS-Anweisung ist völlig daneben. Das Ergebnis hätte eine 1 sein müssen.
...

Wieso wird bei Dir das Ergebnis hexadezimal angezeigt, obwohl Du Gleitpunkt eingestellt hast?
Wird das irgendwo gewandelt, denn binär (nicht real) ist es ja 1?

 

[RobiHerb]

Winkelfunktionen haben schon ihre Spezialitäten, wie ich aus der Implementierung bei anderen SPS weiss, gibt es da schöne Überraschungen.

Manche SPS haben Tabellen in Grad und interpolieren bei Zwischenwerten, andere rechnen den Sinus per Reihenentwicklung und unter Benutzung von Bogenmass aus und der COS ist dann SIN (Winkel + Pi/2) etc.

Eine Spezialität dabei ist die Zahl Pi (3,14...), wenn man den COS aus dem SIN ermittelt. So genau rechnet keine CPU, dass das klappt. So verwendet man Reihenentwicklungen, um mit 16/32 Bit Integer rechnen zu können, und nimmt (2200 / 7) als Wert für 100*Pi.

 

[alicikcik]

Wieso wird bei Dir das Ergebnis hexadezimal angezeigt, obwohl Du Gleitpunkt eingestellt hast?
Wird das irgendwo gewandelt, denn binär (nicht real) ist es ja 1?

Wenn das betr. Doppelwort als hexadezimale oder dezimale Zahl interpretiert wird, dann ist der Zahlenwert eine 1. Aber wenn das Doppelwort als Real-Zahl interpretiert wird, ist der Zahlenwert eine 1,4... *10^(-45).
Ich habe nicht kontrolliert, ob es "not a number" ist. Wahrscheinlch ja und vermutlich schaltet in diesem Fall die Variablentabelle automatisch um zu Hexadezimaldarstellung.

Gruss

 

[alicikcik]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo RobiHerb.

Die vielen Möglichkeiten der trigonometrischen Funktionen ist auch das Schöne an der Sache. Man kan auf vielerlei Weise ausweichen und anders rechnen. In diesem Fall gibt es bestimmt 10 Ausweichmöglichkeiten, den Cosinus zu berechnen.

Gruss

 

[alicikcik]

Heute habe ich Siemens-Hotline angerufen, um dort Bescheid zu sagen. Siemens wusste aber schon von dem Problem. Siemens's Vorschlag ist, Firmware von Version 3.3.7 auf Version 3.3.6 zu upgraden.

Gruss

 

[Oberchefe]

Wieso wird bei Dir das Ergebnis hexadezimal angezeigt, obwohl Du Gleitpunkt eingestellt hast?

wie in Beitrag #31 bereits vermutet zeigt die Siemens Software (zumindest die 5.5) einen Wert als Hex an wenn eine nicht vernünftig interpretierbare Realzahl in der Variable steht

 

[ducati]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die vielen Möglichkeiten der trigonometrischen Funktionen ist auch das Schöne an der Sache. Man kan auf vielerlei Weise ausweichen und anders rechnen. In diesem Fall gibt es bestimmt 10 Ausweichmöglichkeiten, den Cosinus zu berechnen.

Naja, was daran schön ist Wenn Dir die Anlage um die Ohren fliegt, nur weil der Fehler erst bei der Inbetriebnahme auffällt, dann kannst nur hoffen das Du SCHÖN weit weg bist...

Gruß.