FC-Vereinfachungen, Modifizierung Code

OKL

Level-1
Beiträge
143
Reaktionspunkte
3
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Automatisierungs-Experten,

ich poste meine Frage hier, da diese so besser aufgehoben ist. Ich habe einen schönen FC20, welcher anhand dem ihn übergebenen DB überprüft, ob zur aktuellen Zeit geheizt werden soll oder nicht. Dabei überprüfe ich auf Heizbetrieb, Warmwasserbetrieb und Zirkulationsbetrieb. Da ich mehrere Betriebsarten habe (Wochenprogramme 1 bis 3), rufe ich das Ganze mehrfach auf.

Ab Netzwerk 7 sieht man das Ganze. Mein Problem ist, dass ich die Bits (Temp) am Anfang zurücksetzen muss, denn ändere ich die Betriebsart, dann bekomme ich von dem FC20 ja keine Rückmeldung mehr und die temp. Variable hält den letzten Wert inne. Ich hatte das auch für jeden Bereich (Warmwasser, Heizung, Zirkulation) mit einem Bit versucht, klappte aber auch nicht so recht.

Wie könnte ich das besser lösen? Ich möchte beim Vergleich der Betriebsart nur die gültigen Zeitschaltzeiten vergleichen.

Noch eine kurze Frage. Lege ich das Netzwerk17 weiter hoch, z. B. als 3. Netzwerk, dann schalten sich komischer Weise einige Bits an, obwohl nichts doppelt adressiert ist. Wo habe ich hier einen Denkfehler?

Mit Step7 habe ich nicht zu viel Erfahrung, mehr so Datenbanken und VB.

Danke für eure Hilfe

Beste Grüße

Olaf

Anhang anzeigen FC4.pdf
 
Hi,
Ein Stück Programm als PDF Datei hilft nicht sehr bei der Suche nach mögliche Fehler.
Schau erstmal ob DB1.HZBA sein Wert ändert bei einer Betriebsart Umschaltung,
Falls Ja (es dürfte kein Problem sein, ich seh keinen Fehler da), dann schau mal ob HZB oder HZB1 oder ... sein Zustand ändert, wenn nein dann öffne einfach dein FC20 (Online) und schau mal stück per Stück wo dein Fehler ist.
Bei deiner zweiten Frage schau mal ob A11.5 wo anders verwendet wurde!
Wie gesagt mit dein PDF Datei kommt man nicht weiter.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

HZB wird nach der Änderung der Betriebsart (war dort z. B. true) nicht mehr geändert, weil der FC kein Eingangssignal mehr hat und daher die Variable nicht mehr füttert. Daher setze ich das immer zurück, mir gefällt das aber so nicht so ganz. Der FC20 schaut nach der Zeit und gibt entweder True oder False raus, Voraussetzung ist natürlich, dass er angesteuert wird. Ich würde das gern schöner lösen wollen.

Der Ausgang selbst ist nicht das Problem im Fall 2, denn einige HZB, ZIB etc.-Variablen waren gesetzt. Ich verlagerte das Netzwerk nach weiter unten und schon war das in Ordnung. Dort frage ich mich nach dem WARUM.

Danke für die Hilfe.
 
Ich habe den Code mal nur so überflogen.
Grundsätzlich drängt sich hier eine Multi-Instanz und damit ein FB auf.
Weiter muss man bei der Verwendung von TEMP-Variablen ein paar Spielregeln beachten. Ich denke Du hast das Verhalten noch nicht ganz verinnerlicht. Die Werte von TEMP-Variablen sind bei Aufruf eines Bausteins zunächst undefiniert. Das Initialisieren am Anfang behebt das zwar, ich denke aber Du willst die Zählerstände dauerhaft speichern. Das geht mit TEMP-Variablen aus o.g. Grund aber nicht. Nach Verlassen des Bausteins sind die Werte futsch.
Wenn Du einen FB nutzt, kannst Du die Werte die gespeichert werden sollen als STAT-Variablen deklarieren. In diesem Zug kannst Du Dir gleich mal das Thema Multi-Instanzen ansehen.
 
Du weißt schon, dass
Code:
L    0
nichts mit den VKE zu tun hat?

Bei den nächsten Zuweisungen wird das VKE in den Status der betreffenen Variablen geschrieben.
Bei der Ladefunktion wird "nur" der Akku1 beschrieben, der nichts mit dem VKE zu tun hat.

Deine Löschung funktioniert so nicht. (zumindest nicht sicher)

Gruß wolder
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo

@Tigerente1974
Die aktuelle Betriebsart speichere ich im DB1 ab. Die temporären Variabelen sollten eigentlich nur nachschauen, ob gerade eine Ein-Zeit für die gewählte Betriebsart vorliegt. Wenn ja, speichere ich dies ebenfalls im DB1 ab. Hätte ich nur eine Betriebsart, wäre das kein Problem. Ich war schon froh, dass ich soweit gekommen bin ;)

Einen Multi-Instanz-DB habe ich in meinem Projekt drin, ich dachte für diese Anwendung reicht ein FC aus. Vielleicht die falsche wahl. Sicher habe ich noch nicht alles so gut verstanden... Die Werte die gespeichert werden sollen werden aber derzeit auch gespeichert und stehen auch der Visualisierung zur Verfügung.

@wolder
Ich habe in meinem Halbwissen gehofft, dass ich damit die Variable zurücksetze. Als es bis dort hin funktionierte, ging ich davon aus, dass es richtig ist. Aber ich bemerkte auch an, dass das nicht meine Endlösung sein kann und habe mich an euch gewendet.

Ich möchte gern den FC20 wie im PDF mehrfach aufrufen und je nach Betriebsart ein Ergebnis ob EIN (Heiz-Zeit) oder Aus bekommen. Wie könnte ich das generell besser lösen (einige Details wären echt gut)?

Danke euch.


Olaf
 
Zuletzt bearbeitet:
Ich möchte gern den FC20 wie im PDF mehrfach aufrufen und je nach Betriebsart ein Ergebnis ob EIN (Heiz-Zeit) oder Aus bekommen. Wie könnte ich das generell besser lösen (einige Details wären echt gut)?

Einfach den FC gegen einen FB tauschen, die Temp Variablen in Stat schieben und für jedes Wochenprogramm einen IDB anlegen fertig. Dann rufst du den FB mit dem jeweiligen zugehörigen IDB auf und du brauchst nix manuell rücksezten.
z.B. Heizung FB20/DB120
Zirkulation FB20/DB121
Warmwasser FB20/DB122

mfg
DerMatze
 
Hallo,

bin noch nicht ganz durch damit. Der FC20 aktuell wie er ist liefert mir lediglich als Output, ob die Heizung aktiv ist, je nachdem welchen DB er übergeben bekommt. Daher ist der Aufruf schon jetzt so - FC20 bekommt DB20 übergeben = Heizung Wochenprogramm 1, dann Übergabe DB21 = Warmwasser Wochenprogramm 1, dann DB22 = Wochenprogramm1 Zirkulation, DB23 dann Heizung Wochenprogramm 2. Das klappt. Ein Wochenprogramm beinhaltet 3 Bereiche, eben Heizung, WW und Zirk. Wenn ich jetzt den FC20 (Zeitschaltuhr) in einen FB20 wandle, dann hätte ich doch aber auch wie jetzt schon das Bit, ob Heizungsbereich ein oder aus. Nur, dass sich der Instanz-DB den Wert merkt. Aber, wenn ich dann den FB20 DB21 nicht mehr aufrufe, weil eben ein anderes Wochenprogram als 1 aktiv ist, dann bleibt ja dennoch der falsche Wert 1 darin stehen. Oder es gibt noch einen anderen Grund, warum sich das so eigenartig verhält. Ich wollte eigentlich nicht alle 9 möglichen Varianten der Zeitschaltuhr jedes Mal durchschalten, wenn doch immer nur max. 3 aktiv sein können. Daher würde ich ungern alle 9 immer aufrufen.

Oder meintest du, ich solle den FC4 in einen FB4 wandeln und mir dann statt Temp die STAT-Variablen merken? Sobald ich aber auch dann den FC20/FB20 wie auch immer nicht mehr aufrufe, weil die Betriebsart sich geändert hat, bleibt das Bit ja dennoch falsch sitzen, weil der FB/FC ja nicht mehr aufgerufen wird.

Kompliziert, oder? Auch das mit dem einen Netzwerk, was sich so äußert, dass bei Frostschutz-Bit sich andere Bits gleich dazugesellen und aktiviert sind.

Pu, danke euch für die Hilfe.


Olaf
 
Zuletzt bearbeitet:
Hi, dann müsste ich aber alle 9 Varianten immer aufrufen? Sonst hätte ich ja wie jetzt auch kein Ergebnis von den nicht verwendeten...
 
Hallo again,

wenn ich statt des FCs nun einen FB nehmen und diesen aber nicht mehr aufrufe (Wochenprogrammwechsel), dann steht ja denoch im Instanz-DB der falsche nicht mehr aktuelle Wert. Allein mit der Umstellung auf einen FB ist es leider nicht getan. Wie könnte man denn das Ganze sonst aufbauen, ohne jedes Mal alle 9 Varianten (später vielleicht noch mehr) aufzurufen?

Dankeschön.

MfG

Olaf
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn ich den Code richtig deute, werden je nach Programm nur andere DB´s an den FC20 übergeben.

Um bei dieser Struktur zu bleiben könntest Du auch folgendes machen:

Du machst Dir 3 zusätzliche DB´s, die den Programm-DB´s entsprechen. Nennen wir sie Aktual-DB.
Je nach Heizprogramm kopierst Du den entsprechenden Programm-DB in den Aktual-DB.

Den Aktual-DB schließt Du dann an den FC20 an.

Eine elegante Lösung könnte noch anders aussehen:

Du legst ein UDT mit den Elementen an, die in Deinem Programm-DB vorkommen. Dieses legst Du dann als Array in einem Global-DB ab. Das macht die Erweiterbarkeit viel einfacher, denn Du musst nur das Array verlängern, wenn mehr Programme dazukommen. Dann musst Du nur noch einen Pointer auf die Adresse gemäß des gewünschten Programms bauen, um je nach Heizprogramm das gewünschte Feldelement im Array anzusprechen.
 
Zurück
Oben