Step 7 Frage zu Analogwertverarbeitung Wort aus DB auf analogen Ausgang

[klaerbaer2010]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich habe da eine Frage.

Ich bekomme auf meiner S7 Steuerung im DB6.dbw246 einen Wert von 0-100 von einem angeschlossenen Pc geliefert.

diesen Wert möchte ich an meinem Analogen Ausgang PAW 272 ausgegeben bekommen.

Die Hardware ist auf 4-20mA am Ausgang eingestellt.


Ich habe es schon mit dem Standard Scale Baustein ausprobiert. Damit komme ich nicht weiter.

Hat jemand einen Lösungsvorschlag für mich?

Gruß

Markus

 

[borromeus]

Probier mal Unscale, FC106
;-)

Ein weiteres Problem kann sein, dass Du den Wert erst in REAL umwandeln musst, jetzt ist er ja Integer.

Also
L DB6.DBW246
ITD
DTR
und dieser auf den FC106 draufschalten

 

[klaerbaer2010]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo

Ich habe mir jetzt folgendes überlegt:

L DBX.DBW
ITD
DTR
L 27648
*R
L 100.0
/R
Trunc
T PAW


Kann das funktionieren?

 

[borromeus]

Nein!

L DB6.DBW
ITD
DTR
L 27648.0
*R
L 100.0
/R
RND (TRUNC geht theoretisch auch, ist aber nicht passend zum folgendem Befehl)
T PAW

 

[extruder_luder]

Hallo,

ich lese das bei Analogwertverarbeitung immer wieder, oder mein kleines Gehirn packt es nicht.
Warum muss ich einen Integerwert erst nach Real konvertieren, dann Berechnungen in Real machen und dann wieder nach Integer konvertieren. Die obige Lösung ist meiner Meinung nach wunderbar, lediglich alles was mit Real zu tun hat raus.
Das Ergebnis ist exakt das Gleiche, bei weniger Programm und deutlich kürzerer Rechenzeit.

Gruss

Oliver

 

[MRose]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

der Unscale-Baustein akzeptiert nur Real-Werte. Will man den einsetzen, kommt man also um Real nicht drumrum.

Bei eine selbstprogrammierten Scalierung muss man halt den Bereich vom Datentyp Int beachten. Bei der vorliegenden Berechnung rein mit Integerwerten würde man entweder den Bereich verlassen oder durch das Fehlen von Nachkommastellen riesen Ungenauigkeiten haben. Wenn überhaupt, dann müsste man alles in DInt berechnen, vielleicht sogar mit Faktoren. Ob das allerdings übersichtlicher ist, als mit Real-Werten zu rechnen, bezweifel ich.

Edit:
Ok, in dem Fall hast Du Recht. Man kann sich das DTR sparen und den Rest eigentlich auch mit DInt rechnen.

 

[Toki0604]

Hi,
habe einfach mal als Beispiel angenommen es kommt von dem PC die Zahl 91.
Ich habe das einmal als Dint und einmal als Real berechnet.
Bei Dint schneidest du quasi 2 Zahlen weg.
Bei Real werden die 2 Zahlen kaufmännisch gerundet.
Den Unterschied siehst du im Bild.
Ob dieser Rundungsunterschied etwas ausmacht das kommt wahrscheinlich auf die Anwendung drauf an.


Gruß, Toki

 

[klaerbaer2010]

Hallo,

ich habe es mit der ersten kurzen Variante probiert das funktioinert.

Ich habe aber heute gehört das ich den Wert teilen muss.

Der Wert dient zur Ansteuerung von 2 Drehkolbengebläsen. Diese haben einen Frequenzumrichter.

Wenn mein Wert zwischen 0 und 50% ist, dann läuft ein Gebläse mit 4-20mA

Wenn wir bei 51-100% sind dann schaltet das zweite Gebläse mit 4-20mA dazu.

Also 100% = Beide Analogausgänge mit 20mA anfahren


Habt ihr da eine Idee? Ich dachte daran etwas mit Vergleichert aufzubauen.

Gruß

 

[borromeus]

Zuviel Werbung?
-> Hier kostenlos registrieren

?
Zwei Analogausgänge:
Einer 0-50% == 4-20mA, Mit MaxBegrenzung bei 50%
Einer 51-100% == 4-20mA

 

[extruder_luder]

Hallo,

ich möchte noch doch nochmal etwas zu dem Test mit der Real und der DINT Berechnung sagen.

Der Unterschied der Berechnung ist genau 1. Der Analogwandler wird also um diesen Wert falsch angesteuert. Richtig.
Damit dieser falsche Wert analog eine Auswirkung hat, müsste der AD Wandler eine Auflösung von 27648 Stufen haben. Solche Wandler gibt es bestimmt, aber nicht für S7. Entweder man hat 10 Bit oder vielleicht 12 zur Verfügung. Wieviel diskrete Stufen das sind, sollte jeder der SPS programmiert ausrechnen können. Dazu kommt das industrielle Umfeld, in denen Maschienen benutzt werden. Da gibt es FU's und alle möglichen Dreckschleudern, deren Störungen schon weit mehr als die Auflösung eines 12 Bit Wandlers darstellen.

Mit der Anwendung hat das also gar nichts zu tun, in der realen Welt gibt es diesen Unterschied nicht.

Der einzige Grund solche Berechnungen in Real zu machen ist, das man nicht in der Lage ist, die Operationen so anzuordnen, das kein Überlauf der Akkus stattfindet. Ich habe früher dividiert, indem vorher multipliziert wurde und dann den Akku getauscht, was einer Division gleichkommt. Dann laufen Programme schnell ab. Heute schöpft man nur aus dem Vollem und wundert sich wenn man unglaubliche Zykluszeiten bekommt.
Es gibt von Siemens CPU Daten, woraus man ersehen kann, wie lange eine Real Division dauert. Wer weiss wie das gemacht wird, weiss auch warum das solange dauert

Hilft zwar bei dem Problem nicht weiter, ist aber eine Grundlage derProgrammiereung.
Kleiner Tip: Wie man jetzt einem Wandler die 0..50% vorgibt und den aneren erst bei 50 % starten lässt, das ist subtrahieren und Dreisatz.


Gruss

Oliver

 

[vollmi]

Der einzige Grund solche Berechnungen in Real zu machen ist, das man nicht in der Lage ist, die Operationen so anzuordnen, das kein Überlauf der Akkus stattfindet. Ich habe früher dividiert, indem vorher multipliziert wurde und dann den Akku getauscht, was einer Division gleichkommt.

Das musste ich früher schon in der SattCon so machen. Aber heute macht man das in Real nicht weil man es nicht anders kann. Sondern weil man heute die Möglichkeit hat, das direkt so im Programmcode abzulegen wie man es auch auf ein Blatt papier schreiben würde wenn man will dass der Nächste die Formen auf einen Blick versteht.

Dann laufen Programme schnell ab. Heute schöpft man nur aus dem Vollem und wundert sich wenn man unglaubliche Zykluszeiten bekommt.
Es gibt von Siemens CPU Daten, woraus man ersehen kann, wie lange eine Real Division dauert. Wer weiss wie das gemacht wird, weiss auch warum das solange dauert

Wir sind heute in der glücklichen Lage das wir Programme nicht mehr optimal bis fast auf den Assembler runter ausprogrammieren müssen damit die CPU nicht in die Knie geht sondern wir können es heute so programmieren dass es einfach zu lesen und zu verstehen ist.

Es ist heute ja auch nicht mehr nötig Bitmeldung händisch in übertragungsworte zu verpacken um Telegrammverkehr klein zu halten. Wir können es uns heute leisten aus dem Vollen zu schöpfen. Denn Leistung ist billig. Entwicklungszeit ist es nicht.

Ich will nicht sagen dass es nicht sinnvoll ist auch zu wissen wie die CPU im Hintergrund die Bits schubst aber auf den Programmierstil sollte es nicht mehr so grossen Einfluss haben wie früher wo man noch um jedes Byte feilschen musste.

mfG René

 

[extruder_luder]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Rene,

ich sehe dass Du noch die Grundlagen kennst.

Prinzipiell gebe ich Dir vollkommen recht. Code sollte so übersichtlich und einfach wie möglich geschrieben werde, solange ich dann nicht eine 400er statt einer Logo einsetzen muss.

Wie Akkus und Register behandelt werden, gehört jedoch meiner Meinung nach zur Grundausstattung eines Programmieres. Sobald man nicht mehr daran verzweifelt Werte von 0..50 auf einen Wertebereich von 0..27648 abzubilden sondern es z.B. mit indirekter Adressierung zu tun bekommt, hört es so glaube ich auf das man mit Realzahlen operieren kann.

Ich habe viel mit völlig unerfahrenen Ingenieuren zu tun, die bei analoger Technik mit x Stellen hinter dem Komma rechnen und glauben damit ein tolles Programm zu schreiben, hinterher wundern sie sich warum sie Sprünge in den Werten feststellen und haben noch nie etwas von Auflösung und Wandlungszeit gehört.

Statt ein fertiges Programm als Hilfestellung zu schicken, denke ich das man am Besten lernt, indem man sich Gedanken über das Problem macht, abschreiben kann jeder.

Deshalb sollte es reichen, einen Tip zu geben wie subtrahieren und den guten alten Dreisatz auspacken, dann ist die Normierung kein Problem.

Gruss

Oliver