Bedingt einen FC anspring

A

Anonymous

Guest
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe folgendes Problem:
In FC1 befindet sich die Programmierung für Rolltor 1.
In FC2 die Programmierung für Rolltor 2.
beide Rolltore dürfen nicht gleichzeitig auf sein.
Da ich in FC1 nicht jede Verknüpfung nach E2.3 (Unterer Totpunkt des Rolltor2) -und umgekehrt abfragen möchte, wollte ich dies über den OB1 lösen.

Frei nach dem Motto:
Wenn E1.4 (Unterer Totpunkt von Rolltor 1) das Signal 1 führt,
dann darf FC2 angesprungen werden.
Wenn E2.3 (Unterer Totpunkt von Rolltor 2) das Signal 1 führt,
dann darf FC1 angesprungen werden.
Führt E1.4 das Signal 0, darf FC2 nicht angesprungen werden.
Führt E2.3 das Signal 0, darf FC1 nicht angesprungen werden.

Kann mit jemand den OB1 so schreiben?
Ich bekomme das nicht hin mit dem SPB und oder SPA...
 
OB1

Hallo,

auch wenn ich das nicht so machen würde ein Tip. Im OB1 je 1 Netzwerk für den Aufruf der FC. Diese in KOP aufrufen und die Bedingung vor den "EN" reinmachen.

MfG
André Räppel
 
mhm

Ich habs probiert mit
Code:
U E2.3
= FC1
und
Code:
U E2.3
CALL FC1

Beide kennt das Programm nicht an, auch wenn ich zwischen FC und 1 ein Leerzeichen habe.
Hab ich dich falsch verstanden?
 
Tor

na was passiert denn in nem Störungsfall wenn zb 1 Tor offen ist und bei dem anderen die Endlage "unten" weggeht? Dann kannste nichmal das offene zufahren. Ausserdem macht man ja in ner Ansteuerung auch Störungsauswertungen usw.

Was passiert wenn du Tor 1 auffährst und die Endlage "unten" von Tor 2 geht weg? Dann springst du beide Bausteine nicht mehr an und der Ausgang Tor 1 öffnen bleibt auf 1 weil er nicht mehr zugewiesen wird?


Was ist das Problem nur die Ansteuerung zu verriegeln? Ich bin kein Fan von bedingtem Anspringen von Bausteinen mit Verknüpfungslogik.. Berechnungen ja.

Zurück zum Problem: Ob nun KOP oder FUP, egal. Geh ins leere Netzwerk, drück ALT + F9 und gib FC1 ein. Dann mach die Bedingung vor den "EN" und fertig.

MfG
André Räppel
 
Besser ist es, in den Baustein hineinzuspringen und mit dem Eingang eine Freigabe zu bilden.

Zu Vollständigkeit hier der bedingte Bausteinaufruf (ohne Parameter)

CC <Kennung des Codebausteins> (bedingter Bausteinaufruf) ruft bei VKE = 1 einen Codebaustein vom Typ FC oder FB ohne Parameter auf. Die Operation CC gleicht der Operation CALL, mit dem Unterschied, daß keine Parameter übergeben werden können. Die Operation speichert die Rücksprungadresse (Selektor und relative Adresse), die Selektoren der beiden aktuellen Datenbausteine sowie das MA-Bit im B-Stack, deaktiviert die MCR-Abhängigkeit, erstellt den Lokaldatenbereich des Bausteins, der aufgerufen werden soll, und beginnt, den aufgerufenen Code auszuführen. Die Kennung des Codebausteins kann absolut oder symbolisch angegeben werden.

Aufruf mit Parameter geht durch umspringen:

UN E 2.3
SPB NIXM

CALL FC1

NIXM: NOP 0
 
Immer dieses Logout. Nach wievielen Minuten fliegt man eigentlich raus, aus dem Login?

Edit

UN E 2.3
SPB NIXM

CALL FC1
IN ...
OUT ...
INOUT...

NIXM: NOP 0
 
frage zu:
Ja, beim bedingten Aufrufen eines FC bedenke das ein zugewiesener Ausgang auf "1" bleibt, wenn er nicht mehr im Programm aufgerufen wird.

das ist bei einem fb wohl korrekt mit statischen variablen, beim fc arbeite ich aber nur mit temp-variablen die kein speicherndes verhalten haben
 
hallöchen

wenn du in einen bedingt aufgerufenen bausteinn zb so was stehen hast

u e0.0
= a4.0


und der ausgang wird zugewiesen danch rufst du deinen baustein nicht mehr auf bleibt dir der ausgang auf eins wie bei einen setzen
 
Zuviel Werbung?
-> Hier kostenlos registrieren
ok , danke kpeter,
ich dachte es geht um parametrierte fc´s, wo ich eigentlich mit temps arbeite ( weder merker noch E x.x ), da geht der ausgang aber auf jeden fall weg , oder?
 
@ th@omas

Wenn du einen FC bedingt aufrufst, kannst du keine Parameter (IN, OUT, INOUT) mitgeben, das geht nur bei unbedingtem Aufruf. Umspringst du diesen Aufruf (siehe oben), dann bleiben alle Output-Variablen so stehen, wie sie beim letzen Aufruf des FC waren, es sei denn du beschreibst sie noch anderswo im Programm. Wenn du auschließlich mit temp-Parametern in deinem FC arbeitest, dann tut er eigentlich überhaupt nichts, du gibst ja keinerlei Infos nach außen, es sei denn über den Stack, oder?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Alternativ kannst du ja alle Merker die z.b. im FC1 bearbeitet werden
am Anfang des FC2 zurücksetzen.

....
R A 0.0
R A 0.1
R A 0.2

......

dann erst weiter mit den neuen Bedingungen.
 
morgen

abersinvoller wäre wenn man schon einen baustein bedingt aufruft nicht einen ausgang setzen sodern einen merker

und in einen ausgabe fc dann beide merker zusammen führt und noch einmal die lebensbedrohlichen verriegelungen reingibt z.b

nicht gleichzeitig rauf und runter oder sowas

natürlich passiert mit denn merker das selbe wie mit denn ausgängen sie bleiben auf ihren alten status außer sie werden noch einmal beschrieben



// bedingter aufruf mit call


ich will ja ungern wie ein besser wisser klingen aber ich kann schon mit call einen bedingten aufruf machen


erstens in fup und kop kein problem


und in awl ( steht ja weiter oben auch schon mal )

un e0.0
spb ende

call fb10,db10
.....
.....
.....

ende: nop 0
 
Um das Problem mit "stehengebliebenen" Ausgängen oder Merkern wegzukriegen, würd ich versuchen, gar alles mit Verknüfungslogik zu machen, so dass überhaupt kein bedingter Aufruf mehr nötig ist. Das ist im Normalfall sicherer, weil dann nichts mehr "stehenbleiben" kann.

Falls es Probleme mit der Zykluszeit geben sollte, dann kann man immer noch Teile des FBs bedingt überspringen (und zwar im FB innendrin) oder den FB vorzeitig verlassen. Das hat den Vorteil, dass man die "Abkürzung" mit feinerer Granularität bestimmen kann.

Bedingte Aufrufe würd ich grundsätzlich vermeiden wo es nur geht, die machen meist mehr Folgeprobleme als sie nützen. Es geht halt nichts über die gute alte Verknüpfungslogik.

Gruss, Thomas
 
Zurück
Oben