TIA Telegrammerweiterung Adresszuweisung

[dx145]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen
Ich möchte in meinem SPS Programm die Temperatur r0035 meiner Antriebe auslesen mithilfe einer Telegrammerweiterung. (Ich verwende Technologieobjekte)
Habe das Telegramm um 2 Wort verlänget

den Wert zugewiesen

Eine Funktion geschrieben mit dem Bezugsparameter => 100 Grad

Meinen fb in den mich das ganze verwenden will um einen Input eines Doppelwort erweitert

und versucht die Adresse zuzuweisen. Leider ohne Erfolg.... Wie muss ich das machen? Das ist mir nicht klar..


Stimmt mein Vorgehen? Was mach ich falsche?
ist die Erweiterung überhaupt in DWord bei Adresse 405? oder habe ich da einen Überlegungsfehler?
Danke euch.

 

[zako]

... ich mache sowas mittels Zusatzdaten.
Dann hast Du einen eigenen konsistenten Adressbereich.

 

[dx145]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ob Zusatzdaten oder Telegrammerweiterung ist meiner Meinung nach geschmacksache. Aber wie lese ich den Inhalt an einer Adresse aus. Z.B. das DWord an Adresse I405?
Mit %ID405 funktioniert das leider nicht...???

Danke euch.

 

[zako]

... zumindest die Adresse sollte doch eher 420 sein, oder?

 

[dx145]

Hmm ja, so akzeptiert es die Adresse. Jetzt gibt es einfach einen "tag". Kann ich irgendwo einen symbolischen Namen vergeben?

 

[zako]

Zuviel Werbung?
-> Hier kostenlos registrieren

Markieren, rechte Maustaste und umbenennen.

 

[dx145]

Danke
Gruss

 

[dx145]

Es funktioniert leider noch nicht ganz. Habe nun auf Zusatzdaten umgestellt.

UNd den Temperaturwert zugewiesen

Dann meinem fb übergeben und umgerechnet. Und es kommt auch ein Wert an. Leider Springt der wild hinund her... Was mache ich falsch?

(Beobachtung meiner Umrechnungsfunktion)



(Übergabe des Parameters an meinen fb in dem die Funktion fcTemperature aufgreufen wird.)


Könnt ihr mir bitte helfen, ich bin mit meinem Rat am ende...
Danke

 

[dx145]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da noch ein Bild vom Aufruf der Funktion in meinem fb.

 

[NBerger]

"Problem 1": Von einem Doppelwort nur 16 Bit in Int wandeln führt zu einem falschen Ergebnis...
"Problem 2": Die Werte vom Antrieb werden Normiert übergeben. Bei Word 14 Bit (16384) = 100%. Bei DWord dürften es dann sein 30 Bit (1073741824) = 100%
"Probelm 3": Es fehlt dann noch die Bezugstemperatur ( Die steht in P2006)

 

[dx145]

Danke für die Antwort
Verstehe ich aber nicht ganz.
Ein wort sind ja 16 Bit, oder? Also ein Doppelwort 32 Bit.
https://cache.industry.siemens.com/...2_extended_communication_G120_DOCU_v10_de.pdf
Ich habe mich an obige Anleitung gehlaten. dass ich einen Umrechungsfehler mache kann sein. aber dass der Wert schwankt verstehe ich nicht.
Die Bezugstemperatur ist 100Grad.

Muss ich noch die oberen Bit abschneiden? Mir ist nicht ganz klar wie die Umrechnung funktioniert. Kann mir da jemand ein Beispiel machen?


wenn ich meinen wert durch (1073741424) anstelle 16384 dividieren würde wäre ja einfach die Grössenordnung falsch. aber was mich komisch dünkt dass der Wert so stark schwankt. Von +180 bis -180 Grad...
Habe irgend wie ein Brett vor den Kopf.
Danke für eure Hilfe.

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

Leider Springt der wild hin und her... Was mache ich falsch?

Da für den TemperaturWert 32 Bit spendiert werden, vermute ich, dass er schon als REAL-Zahl angeliefert wird. Versuchs mal mit einem TypeCast DWORD -> REAL statt der (merkwürdigen) Konvertierung.

 

[dx145]

Dann ist die Zahl extrem klein. das Ergebniss spring jedoch nicht mehr hin und her. Scheint aber nicht zu stimmen....


Bin echt ratlos.

 

[NBerger]

Y = dword_to_dint( x ) / real#1073741824.0 *real#100.0°C

1073741824 sind 2^30 ... die 100 sind zur Anpassung an Bezugsgröße. Ergibt bei was mit 17°C

so in der Art...

EDIT:
- Du verwendest ein Doppelwort im Telegramm damit darfst du nicht nur durch 2^14 (16384) teilen sondern must durch 2^30 (1073741824) teilen.
Alternativ kannst du auch die Schnittstelle auf ein Wort umstellen.
- Das Format WORD ist grundsätzlich vorzeichenlos... Der Bereich geht aber von -200% bis 200% der Bezugsgröße ist also als Integerwert mit Vorzeichen zu behandeln.
Daher erst in einen Inetgerwert wandeln (hier DInt) bevor weitergerechnet wird.
- real#1073741824.0 : das real# verwendet das 32 Bit real Format... mist geht nicht (nur sieben Digits) ... also besser das real# weglassen(64Bit).
- Das "Punkt Null" sorgt für die Wandlung in Real VOR der Berechnung. (Also Dint in Real dann Real / Real)

Y = dword_to_dint( x ) / 1073741824.0 * 100.0°C

 

[Heinileini]

Zuviel Werbung?
-> Hier kostenlos registrieren

- Du verwendest ein Doppelwort im Telegramm damit darfst du nicht nur durch 2^14 (16384) teilen sondern must durch 2^30 (1073741824) teilen.

Hmmm. Egal, ob nun ein DWORD durch 2^30 oder ein WORD durch 2^14 dividiert wird, in beiden Fällen bleiben nur die beiden höchstwertigen Bits übrig.
Bedeutet das, dass der TemperaturWert tatsächlich in nur 2 Bit codiert ist? Dass also 1 von nur 4 verschiedenen TemperaturWerten hier übergeben werden soll?
Kann ich mir nicht vorstellen.

PS:
Eine solch miese Auflösung würde allerdings die riesigen Sprünge erklären ...

 

[PN/DP]

100°C = 100% = 16#4000_0000 = 1073741824 dez
#dwTemperaturedataFromDrive = x = 16#0BE76C40 = 199715904


0 bis 16#4000_0000 entspricht 0.0 bis 100.0 °C
bzw.
-16#4000_0000 bis 16#4000_0000 entspricht -100.0 bis 100.0 °C
-1073741824 bis +1073741824 entspricht -100.0 bis 100.0 °C

Y / 100 = x / 1073741824

Y = x / 1073741824 * 100

mit x = 199715904 ergibt sich Y = 18.6 °C

Das müsste man so rechen:

Y = dint_to_real(dword_to_dint( x )) / 1073741824.0 * 100.0;

Allerdings gibt es real#1073741824.0 nicht wirklich, weil Real gar nicht so viele Ziffern darstellen kann. Die Berechnung wird gerundet (ist hier vermutlich ausreichend genau) oder man müsste das als LREAL (64 Bit) rechnen.

Harald

 

[dx145]

Vielen Dank. Jetzt verstehe ich das.

 

[NBerger]

Zuviel Werbung?
-> Hier kostenlos registrieren

@Harald

Das müsste man so rechen:
Code:

Y = dint_to_real(dword_to_dint( x )) / 1073741824.0 * 100.0;
Allerdings gibt es real#1073741824.0 nicht wirklich, weil Real gar nicht so viele Ziffern darstellen kann. Die Berechnung wird gerundet (ist hier vermutlich ausreichend genau) oder man müsste das als LREAL (64 Bit) rechnen.

Eine Konstante wird immer im höchst möglichem Format angegeben, solange dies nicht expliziet vorgegeben wird: 1073741824.0 ist automatisch LReal... das "LReal#" kann man sich sparen.

LReal hat 12 Dezimalstellen Genauigkeit passt also... (Real: 7 Stellen)

Vor einer Berechnung pass TIA automatisch die Formate an (soweit möglich). Gerechnet wird immer im "höheren" Format also Lreal. Daher die Angabe 1073741824.0 und nicht 1073741824
Die expliziete Wandlung kann man sich also sparen (DInt_To_LReal).

Das Ergebnis der Division ist ein Faktor von -2.0 bis 2.0 der noch mit dem Bezugswert multipliziert werden muss.

Wenn's um die Genauigkeit geht, sollte erst dividiert werden und dann multipliziert. (Macht TIA aber schon von selbst...)

Y = (dword_to_dint( x ) / 1073741824.0) * 100.0;

 

[Heinileini]

Wenn's um die Genauigkeit geht, sollte erst dividiert werden und dann multipliziert.

Diese Aussage mag für das Rechnen mit GleitKommaZahlen richtig sein (warum eigentlich?).
Aber ich möchte davor warnen, diese Regel gedankenlos auf das Rechnen mit GanzZahlen anzuwenden.
Solange das Multiplizieren vor dem Dividieren nicht zum Überlauf führt, würde ich unbedingt zuerst Multiplizieren und dann erst Dividieren, da durch das zuerst-Dividieren die Auflösung ggfs unnötig eingeschränkt und durch das danach-Multiplizieren um diesen Faktor verschlechtert wird. Ich hoffe bzw. erwarte deshalb, dass der Compiler beim Rechnen mit GanzZahlen nicht generell zuerst die Division ausführen lässt.

 

[PN/DP]

Y = dword_to_dint( x ) / real#1073741824.0 *real#100.0°C

1) Wenn man schreibt "real#1073741824.0", sagt sich das TIA dann automatisch "Ich weiß der Programmierer ist doof und weiß nicht was er tut - ich nehme automatisch LREAL"?
2) Kann die SPS des Fragestellers LREAL?

Wenn's um die Genauigkeit geht, sollte erst dividiert werden und dann multipliziert.

Warum meinst Du das?
Ich würde vermuten, falls da wirklich ein Unterschied ist, daß zuerst Multiplikation mit 100.0 und erst danach Division durch die große Zahl genauer werden würde. Weil da die Mantissen bei kleinen x näher angeglichen sind.

Y = dint_to_real(dword_to_dint( x )) * 100.0 / 1073741824.0;

Ich vermute aber, daß der TIA-Compiler den Faktor "100.0 / 1073741824.0" eh' sofort berechnet und im Programmcode sowieso nur die Multiplikation mit 9,313225746154785e-8 ankommt.

Harald