Step 7 SCL Verständnisfrage

Kapide

Level-1
Beiträge
29
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Moin Forum,

Folgendes:
Wenn ich über SCL einen Wert in einem DB setzen will mach ich folgendes:
DB1.DBD0 := REAL_TO_DWORD(10.0);

Dann steht in der Datenbank auch 10.0 (Also als normale Dezimalzahl)
Wenn ich folgendes schreibe
DB1.DBD0 := WORD_TO_DWORD(Analogwert_1); (In dem Fall ein INT mit dem Wert 10)
Dann wird der Wert als Hexadezimalzahl gespeichert... Wieso?
 
Zuletzt bearbeitet:
Naja ... in deinem WORD "Analogwert_1" kannst du ja nun beim besten Willen keine Realzahl drin stehen haben - bestenfalls einen Integer.
Ich unterstelle jetzt mal, dass dein DB1.DBD0 als REAL deklariert ist. Wenn du nun einen (gemutmassten) Integer zu einem DWORD machst so wird daruas dann keine REAL-Zahl und sie wird auch nicht als REAL sinnvoll interpretiert.
Aber ... was willst du denn auf diese Weise eigentlich bezwecken (der Ansatz selbst ist ja schon "etwas" fragwürdig) ?

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es geht um folgende Aufgabe.
Ich soll einen Analogwert zwischen 0..32767 in Prozent umrechnen.
Dabei ist der DB gegeben(Wert_1 .. REAL)
Eigentlich ist es eine ganz einfache Rechnung...
(Analogwert_1/32767)*100

Aber SCL will das nicht, wenn ich 25000(INT) durch 32767(REAL) teilen will und das ganze mal 100 nehmen will muss ich schon folgendes machen
DB1.DBD[0] := REAL_TO_DWORD((INT_TO_REAL(WORD_TO_INT(Analogwert_1))/32767.0)*100.0);
Das ist doch absolut lächerlich das man für so eine einfache Rechnung so einen Aufwand hat..
 
Ich würde es so machen :
Code:
DB1.DBD[0] := INT_TO_REAL(Analogwert_1)/32767.0*100.0;
Voraussetzung dafür wäre :
- Analogwert_1 ist ein INT
- DB1.DBD0 ist ein REAL

Gruß
Larry
 
Aber SCL will das nicht, wenn ich 25000(INT) durch 32767(REAL) teilen will und das ganze mal 100 nehmen will muss ich schon folgendes machen
DB1.DBD[0] := REAL_TO_DWORD((INT_TO_REAL(WORD_TO_INT(Analogwert_1))/32767.0)*100.0);
Das ist doch absolut lächerlich das man für so eine einfache Rechnung so einen Aufwand hat..

ich vertsehe zwar nicht, wieso du erst eine Zahl mit Nachkommastellen (REAL) ausrechnest und das dann wieder in DWORD rundest und überhaupt wofür man bei einem Wert von 0 bis 100 ein DWORD braucht, aber grundsätzlich ist deine Code so vollkommen OK. Wenn du aber ohnehin den gerundeten Wert willst, dann kannst du auch die Umwandlung in REAL weglassen.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Larry Analogwert_1 ist zwar ein INT, ist aber ein Peripherie Eingang wird also als WORD übertragen.

Kann mir jemand sagen wieso
Code:
    IF DB1.DBD[4] > DB1.DBD[0] THEN
        A125.1 := 1;    
    END_IF;
ungültig ist?

Tschuldigung für die eventuell dummen Fragen, ich komm von C# und musste mich nie mit so einem blödsinn rumschlagen..
Ich weiß jetzt schon das SCL und ich niemals Freunde werden.. Da ist mir AWL hundertmal lieber.

@Stoky
Weil wenn ich mein REAL nicht in ein DWORD umwandle dann meckert mit der Compiler rum vonwegen "Unzulässiger Datentyp".
Und, ich brauch kein DWORD aber ein REAL besteht nunmal aus 4 BYTES:?
 
Zuletzt bearbeitet:
Wenn du von C# kommst dann sollte dir dieser "Blödsinn" eigentlich sehr bekannt sein. Auch dort gibt es ein "casten" ... (und zwar sogar so richtig)

Zu deinem Code :
In deinem Fall ist dann DBD0 wohl doch nicht als REAL deklariert sondern tatsächlich als DWORD. DWORDS können nur gleich oder ungleich zu anderen DWORDS sein - größer oder kleiner kennen diese Datentypen NICHT.
Für Verglöeiche brauchst du NUMERISCHE Datentypen - also INT, DINT, REAL ...

Dein Perepherie-Eingang wird als WORD übertragen weil du ihn so deklariert hast. Wenn er eigentlich ein INT ist dann kanst du ihn auch so deklarieren - dann sparst du dir das casten weil er ja gleich richtig interpretiert wird ...

Gruß
Larry

Nachsatz :
Die Zuweisung von 1 auf einen Ausgang wird zwar von der SPS geschluckt - korrekt wäre hier aber TRUE (wir haben es hier ja mit einem BOOL zu tun) ...
 
Zuletzt bearbeitet:
@Larry nunja das casten ist mir zwar bekannt, hat aber in C# einen meiner Meinung nach viel kleineren Stellenwert, C# ist da ein bisschen freundlicher..
Das mit dem PEW.. Stimmt, hatte ich nicht daran gedacht..

DBD0 ist im Datenbaustein aber als REAL deklariert:confused:
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Nanana ... weis mal in C# einen Integer auf einen Single zu - oder umgekehrt.
Bei VB hast du Recht - da kann man die Typprüfung abschalten - bei C# meines Wissens nach nicht ...

Die Datentypen werden in der SPS nur mitgenommen wenn du die Variablen symbolisch ansprichst. Sprichst du sie absolut an dann wird IMMER der Elementar-Datentyp angenommen (also BOOL, BYTE, WORD, DWORD).

Gruß
Larry
 
@Larry hab ich lustiger genau vor 30 Sekunden gemerkt.. sobald ich DB1.Wert_1 schreibe geht das ganze problem über die Bühne..

Danke für die Hilfe, 2 Stunden Frust umsonst :ROFLMAO:
 
Versuch ganz generell immer mit den Variablen symbolisch zu arbeiten. Das erhöht dann (bei sinnvollen Variablennamen) die Lesbarkeit des Programms ganz ungemein ... 8)

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Es geht um folgende Aufgabe.
Ich soll einen Analogwert zwischen 0..32767 in Prozent umrechnen.
Interessant wäre bei dem ganzen "Blödsinn" auch, ob das Eingangsanalogsignal bei 100% wirklich 32767 ist und nicht etwa 27648...

Das ganze funktioniert auf Dauer nur, wenn man sich mit der Automatisierungsmaterie auch intensiv befasst ;)

Gruß.
 
@ducati da es sich ja nur um eine Simulation handelt und das ganze über PLCSim läuft(Slider:INT) hab ich einen Bereich zwischen -32767 und 32767.
Da tut man sich einfacher wenn man mit 32767 anstatt 27648 rechnet.
Aber danke für die Information:)

Das ganze funktioniert auf Dauer nur, wenn man sich mit der Automatisierungsmaterie auch intensiv befasst :wink:
Was glaubst du was ich hier mache ;) :ROFLMAO:
 
@ducati da es sich ja nur um eine Simulation handelt und das ganze über PLCSim läuft(Slider:INT) hab ich einen Bereich zwischen -32767 und 32767.
Da tut man sich einfacher wenn man mit 32767 anstatt 27648 rechnet.
Aber danke für die Information:)

Was glaubst du was ich hier mache ;) :ROFLMAO:

Bei dem Slider kann du aber auch die Ober-/Untergrenze angeben, die er ausgeben soll ;)
Ist halt wichtig zu wissen, was deine Eingangskarte später für einen Messbereich liefert. Der Messwert 4-20mA (min / max Messbereich vom Sensor)liegt oft zwischen 0..27648. Ausserhalb gibt es dann einen Unter-/Überlauf.


-chris
 
Zuviel Werbung?
-> Hier kostenlos registrieren
DBD0 ist im Datenbaustein aber als REAL deklariert:confused:
sobald ich DB1.Wert_1 schreibe geht das ganze problem über die Bühne..
Wenn Du in SCL schreibst "DB1.DBD0 := ..." (absolut adressierter Zugriff!) (*) dann ist dem Compiler schnurzegal als was das DBD0 deklariert ist - es wird immer als DWORD interpretiert. Nur wenn Du die Variable symbolisch angibst "DB1.Wert_1" wird auch der Datentyp der Variable beachtet/ausgewertet.

(*) und wenn Du Dich an die in SCL dokumentierte Schreibweise halten willst/sollst, dann müsstest Du "DB1.DD0" schreiben anstatt der undokumentiert möglichen Schreibweise "DB1.DBD0"

Harald
 
Zurück
Oben