Step 7 Step 7, SCL, Formel in Funktionsbaustein

Tyson92

Level-1
Beiträge
18
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Community,

ich bearbeite gerade folgende Aufgabe.
2.JPG

Ich habe bereits einen geforderten FB erstellt mit folgenden Code:
Code:
FUNCTION_BLOCK FB10


// Eingangsvariablen
VAR_INPUT
x : REAL;        
a : REAL;         
END_VAR


// Ausgangsvariable
VAR_OUTPUT        
y : REAL;
END_VAR


// Temp Variablen
VAR_TEMP
    Real_y : REAL;    // Temp. Variable fuer Ausgangsvariable y
    Real_x : REAL;    // Temp. Variable fuer Eingangsvariable y
    Real_a : REAL;    // Temp. Variable fuer Eingangsvariable a
END_VAR


// Temp Variablen


// Werte uebergeben an Temp. Variablen
Real_x := x;
Real_a := a; 


// Berechnung der Formel
Real_y := Real_x**Real_a;


y := Real_y; 


END_FUNCTION_BLOCK

Bei der Eingabe von Werten mit dem PLC-Editor über Beobachten/Steuern wird nichts berechnet und das direkte beobachten über die Brille im Code zeigt keine Werte.
Ich habe gerade leider keine Ahnung wo mein Fehler liegt oder ob ich für diese Aufgabe etwas grundlegend falsch mache im FB (FB wird in OB1 aufgerufen und DB1 zugeordnet).
Vielleicht liegt die Lösung auch irgendwie in den weiteren Fragen die in der Aufgabe gestellt wurden.
Ein vorheriges Programm konnte ich in einem FC ohne Probleme steuern und beobachten.

Grüße
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe es nochmal probiert, allerdings kann ich den FB scheinbar nicht richtig testen, wenn der Code allerdings an sich funktioniert (was ja auch theoretisch passt) sollte es ja richtig sein und der Fehler liegt beim Testen.

So sehen meine Symboltabelle und die Beobachtungs-/Steuerungstabelle aus.
Bei einer vorherigen Aufgabe war es mit sehr ähnlichen Einstellung kein Problem.

11.JPG12.JPG
 
Sorry, OT:
Warum sind solche Aufgaben eigentlich immer so neben der Realität?

Ist doch eigentlich eine total typische Anwendung einer Funktion.
Paar Eingänge, eine Berechnung, ein Ergebnis, keine STATS.
Wozu also einen unnötigen IDB ...
:confused:
 
Bei der Eingabe von Werten mit dem PLC-Editor über Beobachten/Steuern wird nichts berechnet und das direkte beobachten über die Brille im Code zeigt keine Werte.
Ich habe gerade leider keine Ahnung wo mein Fehler liegt oder ob ich für diese Aufgabe etwas grundlegend falsch mache im FB (FB wird in OB1 aufgerufen und DB1 zugeordnet).

Nichtsdestotrotz sieht es so aus als würde der FB sich nicht auf der CPU befinden. Oder die Variablen sind nicht korrekt angeschlossen (das MW für REalvariablen deutet z.B. drauf hin)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hast du den Baustein auch auf die CPU geladen? Nur der Aufruf im OB1 und das Überspielen von OB1 genügt nicht. Baustein und IDB musst du auch übertragen
 
Habe es nun nochmal probiert. Die Brille hatte ich bereits verwendet.
Nachdem ich den Aufruf im OB1 und den dazugehörigen IDB erneut erzeugt habe werden mir nun auch Werte direkt in der Beobachtungsansicht in dem SCL-Editor angezeigt. Allerdings bleiben diese unverändert beim Ansteuern mit der Steuertabelle.

Wenn ich die Aussage Mit dem Merkerwort richtig verstehe, liegt das Problem bei der Zuordnung von dem Merkerwort zu einer REAL Variable?
Ich wüsste nicht wie ich sonst Werte steuern kann, außer über ein Merkerwort.

Der aktuelle Zustand:
1234.JPG
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Du kannst dafür natürlich Merker benutzen, nur ein Real benötigt halt 2 Wörter bzw 4 Byte. Du musst in deiner Symboltabelle also ein MD für deine Real anlegen und sie auch als Real deklarieren.
 
Wenn ich die Aussage Mit dem Merkerwort richtig verstehe, liegt das Problem bei der Zuordnung von dem Merkerwort zu einer REAL Variable?
Ich wüsste nicht wie ich sonst Werte steuern kann, außer über ein Merkerwort.

Ein Real besteht aber nicht nur aus einem Merkerwort sondern aus deren zwei also MD (Merkerdoppelwort).
Ausserdem ist DEZ kein Format das irgendwas mit REAL zu tun hat. Das heisst in der VAT muss du die Darstellung auch auf Gleitpunkt umstellen.

Edit: Wie konntest du überhaupt MW102 und MW104 symbolisch an deinen FB anschliessen? Das müsste eigentlich einen Fehler geben weil die Typen nicht zusammenpassen. Ausserdem überschneidet sich dann natürlich die Variablen wenn du sie als Real deklarierst eben wegen Doppelwort.
In einem DB Symbolisch deklariert hätte man diese Probleme aber nicht und DBs kann man auch in einer VAT beobachten.
Bitte zeig uns mal den Aufruf des FBs.
 
Zuletzt bearbeitet:
Die Ansteuerung von FB10 war falsch, diese sieht nun wie folgt aus:
FB10.JPG
Nun ändern sich auch die beobachteten Variablen, allerdings stimmen diese nicht mit den eingegebene Steuerwerten in Gleipunktformat überein.

Bei der Steuerung ergeben sich bei der Beobachtung folgende Werte:
FB steuern.JPG

Aufbau Symboltabelle:
Symboltabelle FB10.JPG

Vielleicht verstehe ich auch die Eingabe von den Gleitpunktzahlen falsch und das Ergebnis stimmt.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

Du hast da eine Adressbereichsüberschreitung. Das ist, je nach Betrachtungsweise, etwas speziell bei Siemesn. Sieh Dir mal die Tabelle hier im zweiten Beitrag an: Merkerdoppelwort

Die Adressen orientieren sich an den Bytes

Gruß
 
Zuletzt bearbeitet:
Die Ansteuerung von FB10 war falsch, diese sieht nun wie folgt aus:
Anhang anzeigen 42103
Nun ändern sich auch die beobachteten Variablen, allerdings stimmen diese nicht mit den eingegebene Steuerwerten in Gleipunktformat überein.

Wie vorhin schon gesagt. Merker können symbolisch bereichsüberschreitend adressiert werden. Kann manchmal sinn machen. Hier aber nicht. Die adressensind immer byteweise. MD1 belegt also byte 123und4. Es macht also sinn die variablen auf gerade adressen zu legen. Und bei doppelworten kann man durchaus eine fakor 4 adresse wählen. Also md4 md8 md12 etc
 
Edit: Wie konntest du überhaupt MW102 und MW104 symbolisch an deinen FB anschliessen? Das müsste eigentlich einen Fehler geben weil die Typen nicht zusammenpassen.

Die Datentyp-Überprüfung hat Siemens doch mit irgendeinem Servicepack für V5.5 wieder entfernt, ich meine weil die einen von ihren eigenen Siemens-Bausteinen mit den Datentypen so schlampig programmiert haben, dass es da Probleme gab.
Ich hatte die Überprüfung immer eingeschaltet gehabt, weil es doch einiges an potentiellen Fehlern schon bei der Programmierung abgefangen hat.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Okay, dadurch wird es verständlicher.
Mit der Wahl von MD10, MD20 und MD30 funktioniert die Rechnung nun ohne Bereichsüberschreitungen, danke.

Es wurde in der Aufgabenstellung noch nach zwei weiteren Dingen gefragt.

1. Welche Problematik entsteht, wenn x,a gebrochene Zahlen sind?
- Hierzu würde ich mich auf den REAL-Datentypen beziehen, dieser kann nur 6 Nachkommastellen speichern. Dabei ist die Eingabe eine gebrochenen Zahl begrenzt und auch das Ergebnis der Potenzierung.
Ich hatte gelesen, dass die Eingabe und Ausgabe bei weiteren Nachkommastellen automatisch gerundet wird aber beim Testen wurde es nicht bestätigt.
2,36^2,3 = 7,206055569
Hier müsste nach der Berechnung 7,206056 ausgegeben werden, wird es allerdings nicht (7,206055), ist meine Info falsch?

2. Gibt es vorgefertigte Lösungen(für die Formel-Berechnung)?
- Bis jetzt fällt mir dazu nur ein, dass es bei KOP/FUP/AWL unter dem Punkt Gleichpunk-Funktionen die fertige Funktion "EXP" gibt. Gibt es noch weitere bereits vorhandene Lösungen in STEP7 bzw. ein Bereich mit Bausteinen der mir noch nicht bekannt ist?
 
Sag ich doch, der FB hat funktioniert :)

zu 1.

Nicht ganz korrekt, Gleitpunkt in Step7 kann nur 7 Ziffern insgesamt darstellen.

Heißt:
123,4567 hat 4 Nachkommastellen
123456,7 hat eine Nachkommastelle

Alles Andere wird abgeschnitten, das ist ja auch eine Art zu Runden.
Begründet ist das in der Art, wie eine Gleitkommazahl in einem Rechner abgebildet wird, Stichwort IEEE 754.

zu 2.
Das was du da in SCL genutzt hast, ist ja auch schon eine vorgefertigte Lösung.
 
Zuletzt bearbeitet:
Daran habe ich auch nicht gezweifelt, nur die Übergabe der Parameter + richtige Zuordnung hatte ich nicht ganz verstanden :D

Teil 1:
Ok, dann ist mir nun klar wie meine Ergebnisse entstanden sind und was mit "Runden" hier gemeint ist.

Teil 2:
Dann wird bei der weiteren Frage nach einer "herkömmlichen Lösung" wohl nach einer Programmierung ohne die Potenzfunktion "**" gefragt sein.
- mit ganzen Zahlen würde ich einfach eine Schleife durchlaufen lassen für die Potenzrechnung
- bei einer gebrochenen Zahl in der Basis ebenfalls

Wenn ich nun allerdings eine gebrochene Zahl im Exponenten habe, kann ich ja diesen Weg nicht gehen.
Mir fällt gerade kein Ansatz dazu ein, außer vielleicht die Funktion die hinter der Potenzfunktion "**", muss ja irgendwie herkömmlich programmiert sein, dazu finde ich allerdings nichts.

Jetzt habe ich doch noch was gefunden:
a.gif
Real_y:= EXP(a*LN(x));

Ich bin mir allerdings unsicher ob diese Lösung einer herkömmlichen Lösung entspricht, das es ja eigentlich auch nur wieder andere Funktionen sind.
 
Zuletzt bearbeitet:
Der Beitrag von Zottel hatte mir bereits geholfen, daher hatte ich die Lösung mit der Formel im Zitat.
Jetzt habe ich doch noch was gefunden:

Real_y:= EXP(a*LN(x));

Ich bin mir allerdings unsicher ob diese Lösung einer herkömmlichen Lösung entspricht, das es ja eigentlich auch nur wieder andere Funktionen sind.

Den restlichen Teil (Code) habe ich leider nicht zu 100% verstanden, bzw. ich finde dort keinen Part der Kommazahlen in herkömmlicher Weise potenziert, sondern nur mit "**".
 
Zurück
Oben