Probleme beim Umwandeln von INT --> Real

Stahlhart · 8 Juni 2010

Hallo,

habe da schon wieder mal ein Problem.

Für die Parametrierung an einem PID-Regler brauche ich Real Format. Ich bekomme über ein paar DBWs mehrere INT und rechne die dann um in REAL. Jetzt mein Problem, in einigen NW funktioniert es in anderen wieder nicht, ich frag mich warum? Ich verwende temporäre Variablen, hier mal ein Auszug von 3 NW in denen es NICHT funktioniert:

Code:

NW 3: Hier bekomme ich den Sollwert und rechne um:
      U(    
      U(    
      U(    
      L     "DB_Analog".Sollwert_ADZ
      T     "DB-Reglerwerte".SW_WRG
      SET   
      SAVE  
      CLR   
      U     BIE
      )     
      SPBNB _01b
      L     "DB-Reglerwerte".SW_WRG
      ITD   
      T     #t_dint
      SET   
      SAVE  
      CLR   
_01b: U     BIE
      )     
      SPBNB _020
      L     #t_dint
      DTR   
      T     #t_real
      SET   
      SAVE  
      CLR   
_020: U     BIE
      )     
      SPBNB _021
      L     #t_real
      L     1.000000e+001
      /R    
      T     #t_SW
_021: NOP   0

NW5: Proportionalwert
      U(    
      U(    
      L     "DB-Reglerwerte".PW_WRG
      ITD   
      T     #t_dint
      SET   
      SAVE  
      CLR   
      U     BIE
      )     
      SPBNB _022
      L     #t_dint
      DTR   
      T     #t_real
      SET   
      SAVE  
      CLR   
_022: U     BIE
      )     
      SPBNB _023
      L     #t_real
      L     1.000000e+001
      /R    
      T     #t_PW
_023: NOP   0

NW6: Totzone
      U(    
      U(    
      L     "DB-Reglerwerte".TZ_WRG
      ITD   
      T     #t_dint
      SET   
      SAVE  
      CLR   
      U     BIE
      )     
      SPBNB _025
      L     #t_dint
      DTR   
      T     #t_real
      SET   
      SAVE  
      CLR   
_025: U     BIE
      )     
      SPBNB _026
      L     #t_real
      L     1.000000e+001
      /R    
      T     #t_TZ
_026: NOP   0

Beim Istwert, den ich im NW2 (genauso) umrechne funktioniert es. Die Temporären variablen (z.B. #t_real und #t_dint)werden ja immerwieder überschrieben, daher kann ich sie ja auch mehrmals verwenden oder nicht?!

Da es anscheinend an der Umrechnung hakt, bekomme ich meinen Regler auch nicht zum laufen, da dort dann an den Parametern für Sollwert, Proportionalwert und Totzone kein Real Format anliegt.

So noch paar Daten:
SW: Step 7 V5.4 SP5 HF1
HW: CPU 317-2

MfG

wolder · 8 Juni 2010

Tach,

so richtig durchblicken tu ich da nicht!
Vielleicht kannst du mal die Code-Funktion hier vom Forum benutzen

Code:

CODE
/CODE

Des weiteren wären ein paar Kommentare sehr hilfreich.

Kann es sein, dass dein BIE = 0 ist?!
Dann sieht es nämlich so aus, als würde er durch die ganze Berechung und Umwandlung durchspringen.

Code:

U     BIE
      )     
      SPBNB _005
...
_005: U     BIE
      )     
      SPBNB _006
...
_006: U     BIE
      )     
      SPBNB _007
...
_007: NOP   0

Wenn dein BIE am Anfang 0 ist und sich der ja bei den Sprüngen nicht ändert, dann springt der komplett durch das Programm ohne irgendwelche Berechnungen bzw. Umrechnungen.

Gruß wolder

vierlagig · 8 Juni 2010

wolder schrieb:
Kann es sein, dass dein BIE = 0 ist?!
Dann sieht es nämlich so aus, als würde er durch die ganze Berechung und Umwandlung durchspringen.

Code:

U BIE ) SPBNB _005 ... _005: U BIE ) SPBNB _006 ... _006: U BIE ) SPBNB _007 ... _007: NOP 0

Wenn dein BIE am Anfang 0 ist und sich der ja bei den Sprüngen nicht ändert, dann springt der komplett durch das Programm ohne irgendwelche Berechnungen bzw. Umrechnungen.

Gruß wolder

das glaube ich nicht, tim.
diese darstellung rührt aus der programmierung in FUP/KOP her.
wandelt man es mal um, sieht es sehr linear und seriell, dazu noch nachvollziehbar aus.

das überschreiben der temp-variablen ist hier auch nicht das problem (s.o. seriellietät)

welche werte stehen denn in t_SW, t_PW und t_PZ?
und welche werte werden vorgegeben?
gib mal ein Bsp. an.

Stahlhart · 8 Juni 2010

Sorry habs nochmal editiert und den Quellcode nochmal komplett neu reinkopiert.

Ich habs eigentlich in FUP programmiert nur zum einfügen hier in AWL eingefügt.

Das BIE kann ich doch von FUP aus gar nicht beeinträchtigen? Wieso sollte es also 0 sein?

MfG

Edit:

Sollwert kommt von der Visu. Es sollte eigentlich drinstehen 0000000080.3 es steht aber drin 000000000080.
Bei dem Proportionalwert und der Totzone das gleiche 000000000020 bzw. 000000000002

vierlagig · 8 Juni 2010

Stahlhart schrieb:
Edit:

Sollwert kommt von der Visu. Es sollte eigentlich drinstehen 0000000080.3 es steht aber drin 000000000080.
Bei dem Proportionalwert und der Totzone das gleiche 000000000020 bzw. 000000000002

80.3 lässt sich ja aber in INT gar nicht abbilden?! (ich verstehe doch richtig, dass das der Sollwert, also der Wert aus dem DB sein soll)
wenn die Werte sowieso über die Visu kommen, warum dann nicht auch gleich im richtigen Format?
und wenn dies nicht gewollt ist, dann eben in z.B. INT *10, was die eine, wohl gewünschte Kommastelle, mgl. machen würde. (hier braucht es dann die Wandlung, die so funktioniert, wie sie oben abgebildet ist)

d-eye · 8 Juni 2010

Stahlhart schrieb:
Hallo,

habe da schon wieder mal ein Problem.
...

Sieht irgendwie wild aus. Ich mach das immer in AWL:

Code:

L mein_integerwert
ITD
DTR
T mein_realwert

Wenn du den Integerwert z.B. als Zehntel-Einheit bekommst, musst du noch umrechnen, das sieht dann so aus:

Code:

L mein_integerwert
ITD
DTR
L 10.0
/R
T mein_realwert

vierlagig · 8 Juni 2010

d-eye schrieb:
Sieht irgendwie wild aus.

wenn er in FUP schreibt, dann schreibt er in FUP PUNKT
schöne kleine kästchen ... es interessiert ihn doch nicht die bohne, wie der AWL-code dahinter aussieht.
erspar mir also eine weitere diskussion über KOP/FUP/AWL/SCL oder doch vielleicht gleich mit einem hardwareregler?!

PN/DP · 8 Juni 2010

Wenn in "DB_Analog".Sollwert_ADZ eine 803 (INT) drinsteht, dann kommt auch am Ende in #t_SW = 80.3 (REAL) raus.
Beobachte mal, was von der Visu kommt. Ich vermute den Fehler in der "gedachten" Kommastelle in der Visu (Skalierung?).

Gruß
Harald

PN/DP · 8 Juni 2010

d-eye schrieb:
Sieht irgendwie wild aus. Ich mach das immer in AWL[...]

Code:

L mein_integerwert ITD DTR L 10.0 /R T mein_realwert

Ganz genau das macht der Code von Stahlhart, allerdings mit zusätzlichem Code für die FUP/KOP-Darstellung.
Sein Code ist zwar länger, aber vollkommen in Ordnung.

Gruß
Harald

d-eye · 8 Juni 2010

vierlagig schrieb:
wenn er in FUP schreibt, dann schreibt er in FUP PUNKT
schöne kleine kästchen ... es interessiert ihn doch nicht die bohne, wie der AWL-code dahinter aussieht.
erspar mir also eine weitere diskussion über KOP/FUP/AWL/SCL oder doch vielleicht gleich mit einem hardwareregler?!

Bin mir nicht bewusst irgendeine Diskussion angestoßen zu haben, erst recht nicht mit dir.

d-eye · 8 Juni 2010

PN/DP schrieb:
Ganz genau das macht der Code von Stahlhart, allerdings mit zusätzlichem Code für die FUP/KOP-Darstellung.
Sein Code ist zwar länger, aber vollkommen in Ordnung.

Gruß
Harald

ahh, ok. Die Sprünge haben mich verwirrt.

rostiger Nagel · 8 Juni 2010

jetzt mal ohne Diskussion d-eye, was hast du den da für ein
schönen Link in deiner Signatur http://i-controlcenter.com/home.htm.
Könntest du mal darüber in diesen Thread berichten http://www.sps-forum.de/showthread.php?t=35806&page=4

d-eye · 8 Juni 2010

Helmut_von_der_Reparatur schrieb:
jetzt mal ohne Diskussion d-eye, was hast du den da für ein
schönen Link in deiner Signatur http://i-controlcenter.com/home.htm.
Könntest du mal darüber in diesen Thread berichten http://www.sps-forum.de/showthread.php?t=35806&page=4

Mach ich, wenn der Review-Prozess bei Apple durchlaufen ist. Bis dahin muss ich noch etwas an der Webseite arbeiten...

Stahlhart · 8 Juni 2010

Hallo,

hab mich da vielleicht noch etwas undeutlich ausgedrückt.

Ich bekomme Werte von der Visu und die möchte ich an meinen FB41 (PID Regler) anparametrieren, dafür müssen sie in Real sein. Der Sollwert war schon vorhanden, den möchte ich nur mitbenutzen.

Mich wundert nur, dass ich meinen Istwert (über PEW eingelesen --> über einen Baustein ausgewertet und danach rechne ich den genauso um wie den Sollwert, Proportionalwert und Totzone, da funktioniert es) und bei den nachfolgenden Netzwerken funktioniert es nicht mehr

Hintergrund ist folgender. Es sind schon einige andere Softwareregler vorhanden. Sie sollen aber über eine Benutzergruppe in der Visu verstellbar sein. Darum arbeite ich mit DBs in meinem Programm.

Ich habe mich weitgehend an die vorhandene Struktur des vorhandenen Programmes gehalten.

Anbei noch ein Bild von meinem PID Regler da sieht man auch die fehlerhaften Anbindungen.

MfG

wolder · 8 Juni 2010

Ich hab da mal ne Frage.

Warum schreibst du nicht direkt mit der Visu auf den entsprechenden DB des FB?

Dann natürlich in dem richtigen Format (Real, Int etc.)

gruß wolder

PN/DP · 8 Juni 2010

Stahlhart schrieb:
Mich wundert nur, dass ich meinen Istwert

Wie sollte dieser Satz weitergehen? Was wolltest Du sagen?

Stahlhart schrieb:
und bei den nachfolgenden Netzwerken funktioniert es nicht mehr

Geht es nicht etwas exakter? Was genau ist: "funktioniert es nicht mehr"?

Ist es nur die Umrechnung, wo scheinbar die Nachkommastelle verschwindet?
Ich meine, eventuelle Nachkommastellen werden schon in der Visu unterschlagen.

Mit welchem Instanz-DB wird Dein FB241 aufgerufen?
Beobachte mal in einer VAT den INT-Sollwert von der VISU und den zu REAL gewandelten Wert SP_INT:
* 10-fach-Sollwert von Visu: "DB-Reglerwerte".SW_WRG (?) als DEZ
* Sollwert an Regler: "IDB241".SP_INT als Gleitpunkt
Wird da der Visu-Sollwert korrekt als 803 angezeigt?
Wird da für SP_INT korrekt 80.3 angezeigt?

In Deinem Screenshot ist leider alles nur sehr verschwommen sichtbar.

Man sieht aber, daß der FB241 (zumindest zeitweilig) an LMN ungültige Real-Werte #QNAN ausgibt.
Daran ist aber nicht die fehlende Nachkommastelle schuld.
Wie realisierst Du, daß Dein Reglerbaustein genau alle 1000ms aufgerufen wird? OB35? Timer?

Gruß
Harald

Stahlhart · 9 Juni 2010

Hallo Harald.
Also laut Siemens kommt der ungültige Wert #QNAN durch einen falsch anparametrierten Wert zustande. Schuld daran muss laut Siemens auch einer der 3 genannten Parameter sein.

Mich wundert dass die Umrechnung bei meinem Istwert funktioniert, der wird genauso umgerechnet. In den darauffolgenden Netzwerken wird der Wert auch so umgerechnet da funktioniert es aber nicht mehr...

Wie gesagt, laut Siemens liegt es an der Kommastelle, da es ohne Komma ein INT Wert ist, den der Baustein nicht lesen kann.

Der Instanz DB ist mein DB231.

Im OB 35 rufe ich meinen FC545 auf und in diesem wird dann mein FB241 aufgerufen, dass müsste ja so passen.

Der Wert an LMN bleibt immer mit #QNAN belegt und LMN_PER bleibt immer mit ffff belegt.

Fahr jetzt nochmal raus und schau mir die Sache nochmal online an, bzw. werde mal andere Werte an denFB241 anparametrieren mal schaun was dann passiert.

Vielleicht fällt jemanden noch was auf bis dahin

Stahlhart · 9 Juni 2010

Lösung des Problems:

Instanzdatenbaustein neu übertragen und überschreiben und schon funktioniert die Geschichte. Die Rechnung war demnach richtig. Da hat der Siemens Mensch etwas falsches gesagt.

Danke trotzdem für eure Mühen

MfG

Probleme beim Umwandeln von INT --> Real

Stahlhart

Level-1

wolder

Level-2

vierlagig

Level-1

Stahlhart

Level-1

vierlagig

Level-1

d-eye

Level-1

vierlagig

Level-1

PN/DP

User des Jahres 2011-2013; 2015-2017; 2020-2022

PN/DP

User des Jahres 2011-2013; 2015-2017; 2020-2022

d-eye

Level-1

d-eye

Level-1

rostiger Nagel

Forums-Knochenbrecher

d-eye

Level-1

Stahlhart

Level-1

Anhänge

wolder

Level-2

PN/DP

User des Jahres 2011-2013; 2015-2017; 2020-2022

Stahlhart

Level-1

Stahlhart

Level-1

Similar threads

Wir schützen deine Privatsphäre