# Vergleicher geht nicht richtig



## bitotec (9 Oktober 2008)

Hallo,

Ich habe ein kleines Problem

Habe eine Temperatursteuerung programiert aber irgendwie gibts Probleme mit den Vergleichern - Wie auf dem Bild zu sehen ist sind beide Vergleicher angesteuert. 







Wo liegt da mein Denkfehler - Danke an alle im Voraus

MfG Thomas


----------



## vierlagig (9 Oktober 2008)

nun, 13,9 ist nun mal größer als 6 aber eben auch kleiner als 90 ... der vergleicher funktioniert also


----------



## bitotec (9 Oktober 2008)

Oh sorry-

Eigentlich hatte ich am 2. Vergleicher 4 eingestellt - aber da fängt es zum flackern an






Die Temp ist für eine Kühlstrecke

Die Temperatur wurde gerade gesenkt - Eigentlich müßte der Merker gesetzt bleiben bis ich die 4 Grad ereicht habe.

Aber es flackert

MfG Thomas
http://file1.npage.de/001856/92/bilder/reglerflackert.jpg


----------



## vierlagig (9 Oktober 2008)

ist das ein FC?
wird dieser mehrfach aufgerufen?
ist #Merker ein Temp?


----------



## bitotec (9 Oktober 2008)

Hi

Das habe ich im Fb geschrieben,

der #Merker ist im Temp

wird im Moment nur einmal aufgerufen


----------



## vierlagig (9 Oktober 2008)

die Temp-Variable #Merker wird nach jedem Aufruf des FB im besten Fall gelöscht, auf keinen Fall aber gespeichert. Schiebe Merker in den STAT-Bereich deines FBs, dann funktioniert das auch. ...das selbe gilt übrigens für Flankenmerker, die müssen auch im STAT-Bereich stehen (oder als INOUT, mach ich aber nur bei FC)


----------



## SPSKILLER (9 Oktober 2008)

bitte löschen


----------



## vierlagig (9 Oktober 2008)

SPSKILLER schrieb:


> bitte löschen



da er in FUP programmiert und ich davon ausgehe, dass er die Typüberprüfung nicht ausgeschaltet hat, geh ich davon aus, dass alle werte REAL-werte sind 

offtopic: email-benachrichtigung ist was schönes


----------



## SPSKILLER (9 Oktober 2008)

ja, das ist richtig.
Falsches Format wäre aber ne Möglichkeit gewesen.

Hab aber nicht richtig gelesen...

Gruß Micha


----------



## bitotec (9 Oktober 2008)

Vielen Dank 

Habe die ganze Sache in einen FC geschrieben - Da gehts komischerweise

Wieso macht der FB solche Probleme

Was wäre eine bessere Lösung?

MfG Thomas


----------



## vierlagig (9 Oktober 2008)

bitotec schrieb:


> Habe die ganze Sache in einen FC geschrieben - Da gehts komischerweise



aber nicht mit #Merker im Temp-Bereich! oder


----------



## bitotec (9 Oktober 2008)

Habe aber den #Merker in die stat geschrieben da wird er gar nicht gesetzt- ???


----------



## vierlagig (9 Oktober 2008)

bitotec schrieb:


> Habe aber den #Merker in die stat geschrieben da wird er gar nicht gesetzt- ???



aufruf aktualisiert und instanz-DB neu geladen?


----------



## Beren (9 Oktober 2008)

*gelöscht*


----------



## vierlagig (9 Oktober 2008)

Beren schrieb:


> FC: Nimm anstatt #Merker (temp) einen Mx.x.



das ist nicht dein ernst, oder? entschuldige aber: bist du von allen guten geistern verlassen - so einen tipp hab ich ja schon lange nicht mehr gelesen! :evil:

bevor ich in einer funktion, die den anspruch hat, mehrfach aufgerufen werden zu können, global zu adressieren lass ich mir lieber ein bein abhacken!

statt global zu adressieren verwendet man ein INOUT ... und ich denke, dass wird er gemacht haben, denn den tipp gab ich vorhin schon einmal!


----------



## bitotec (9 Oktober 2008)

jo - glaube(hoffe) das ich alles draufgeladen habe

Ich probiers nochmal

sah irgendwie witzig aus am Merker stand bei setzten ne 1 und bei rücksetzten ne 0 aber der Merker war nicht gesetzt*ROFL*

----he Vierlagig----

hättest du da ne idee wie ich es anders lösen könnte da ich gerne jedesmal einen extra instanzdatenbaustein möchte

MfG Thomas


----------



## vierlagig (9 Oktober 2008)

bitotec schrieb:


> hättest du da ne idee wie ich es anders lösen könnte da ich gerne jedesmal einen extra instanzdatenbaustein möchte



machs als FB, das funktioniert, ich schwör!


----------



## Beren (9 Oktober 2008)

*gelöscht*


----------



## Ralle (9 Oktober 2008)

Beren schrieb:


> INOUT habe ich bisher nie benutzt. Wo liegt der Vorteil?



Da kannst du deinen Merker dann außen an den FC schreiben und den FC dadurch beliebig oft verwenden.


----------



## vierlagig (9 Oktober 2008)

Beren schrieb:


> Bei uns wurde das bisher immer so gemacht. Aber ich lerne ja gerne dazu. Ich muss aber auch dazu sagen, daß die Regel besteht einen Merker nur einmal zu verwenden. Wenn man sich daran hält, kann doch nichts schief gehen...
> 
> INOUT habe ich bisher nie benutzt. Wo liegt der Vorteil?



pass auf:

du schreibst eine funktion, sei es fb oder fc, du übergibst die eingangsvariablen und holst die ausgangsvariablen ab, aber intern ist alles lokal. diese funktion kannst du in eine bibliothek packen und immer wieder ausgraben, wenn du sie mal wieder brauchst ohne darauf achten zu müssen welche globalen variablen darin verwendet wurden - sind ja keine drin.

darüber hinaus kannst du in einem projekt so, die selbe funktion mehrfach mit unterschiedlichen parametern aufrufen ohne die bausteinnummer und die verwendeten globalen variablen anpassen zu müssen.

verstehste?


----------



## Beren (9 Oktober 2008)

*gelöscht*


----------



## Ralle (9 Oktober 2008)

Beren schrieb:


> Jo, hab verstanden. Habe bisher nur "IN" und "OUT" verwendet. Nie "INOUT". Wo wird dann die INOUT-Variable gespeichert? Muss ich dem FC einen eigenen DB zuweisen?



In der Variable, die du dann außen an den FC scheibst wird das gespeichert. Das kann ein Merker oder eine Variable aus einem Datenbaustein sein, auch ein Ausgang ist möglich. Dabei kann man je nach Variablendefinition Bit, Byte, Word ... nutzen.


----------



## Beren (9 Oktober 2008)

*gelöscht*


----------



## vierlagig (9 Oktober 2008)

Beren schrieb:


> Jo, hab verstanden. Habe bisher nur "IN" und "OUT" verwendet. Nie "INOUT". Wo wird dann die INOUT-Variable gespeichert? Muss ich dem FC einen eigenen DB zuweisen?



die inout steht an der eingangsseite der funktion und kann mit globalen variablen (aber auch lokalen der aufrufenden) des passenden typs beschaltet werden, im fall des SR wäre die z.b. ein merker-bit, ein datenbaustein-bit oder ein bit aus dem aufrufenden baustein


----------



## Beren (9 Oktober 2008)

*gelöscht*


----------



## vierlagig (9 Oktober 2008)

da sind bestimmt auch aggregate dabei, die funktionell das selbe machen oder funktionen der aggregate die gleich sind ... dafür sind funktionen da, also meiner meinung nach: kleine funktionelle gruppen bilden und dann entsprechend den anforderungen zusammenklicken und nur noch beschalten ... wird doch nervig wenn man z.b. 100 mal die selbe überwachungsfunktion coden muß, wenn sie doch schon in einem FC implementiert sein könnte...


----------



## Beren (9 Oktober 2008)

*gelöscht*


----------



## bitotec (9 Oktober 2008)

Jetzt Gehts - wieso?







Naja auf jeden Fall Vielen Dank an Alle


MfG Thomas


----------



## vierlagig (9 Oktober 2008)

bitotec schrieb:


> Jetzt Gehts - wieso?



ich vermute, weil du jetzt den aufruf aktualisiert hast, den IDB neu generiert und auch übertragen hast


----------



## Maeggy (9 Oktober 2008)

Hallo Bitotec

sollte dein Programm im FC funktionieren,  so ist das reiner Zufall.
Eine temporäre Variable hat vor ihrer ersten zu Zuweisung nach jedem Zyklus einen undefinierten Zustand. Nach der ersten Zuweisung hat diese nur eine Lebensdauer innerhalb des aktuellen Bausteins. Diese #Variable wird also nach dem verlassen des aktuellen Bausteins nicht gespeichert. Nach verlassen des Bausteins wird derselbe Speicher eventuell für was ganz anderes genutzt.
Vierlagig ist besser als Einlagig. Also Variable im FB als STAT deklarieren, dann wird es im Instanz-FB gespeichert und hat im nächsten Zyklus den gleichen Status, wie beim verlassen des FB's im letzten Zyklus. 
Informiere dich generell äber die lebenszeit der temporären Speichervariablen, dann wirds klarer.

Gruß Maeggy


----------

