TIA Abfrage ob Baustein Schnittstelle belegt

[RucksackSepp]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

ich bin momentan dabei einige Eierlegende-Wollmilchsau Bausteine zu schreiben, die für ein Ventil viele Funktionsumfänge bereitstellen. Um die Schnittstell möglichst übersichtlich zuhalten, würde ich gerne an der Bausteinschnittstelle abfragen, ob eine Variable zugewiesen ist oder nicht, anstatt eine "Ein/Aus-Variable" zu definieren.

Beispiel, eine Stellungsüberwachung hat zwei Variablen "posOpen" und "posClosed". Daran werden die Endschalter angeschlossen. An "posAvailable" wird über eine Konstante von außen mitgeteilt, ob die Stellungsüberwachung verfügbar ist. Ansonsten gibt's keine Auswertung.

VAR_INPUT
    trigger        BOOL;
    posOpen        BOOL;
    posClosed    BOOL;
    posAvailable    BOOL;
VAR_END

VAR_OUTPUT
    valveOpen    BOOL;
    valveClosed    BOOL;
END_VAR

IF NOT #trigger AND #posClosed AND #posAvailable THEN
    #valveClosed := TRUE;
    
ELSIF NOT #trigger AND NOT #posAvailable THEN
    #valveClosed := TRUE;
    
ELSE
    valveClosed := FALSE;
END_IF;

Code ist nur mal Beispielhaft aufgesetzt, um einen Eindruck zu vermitteln. Danke!

 

[de vliegende hollander]

Leg doch die Ansteuerung des Ventils auf Stellung AUF und ZU wenn du keine Stellungen hast.

 

[MFreiberger]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin,

mal abgesehen davon, das "eierlegende Wohlmilchsau-Bausteine" meistens keine besonders gute Wahl darstellen (dann doch eher die "biergebende Pommesnudelkuh"), ist die Anfrage an sich tatsächlich interessant.

Ggf. lässt sich mit Variant-Variablen was anstellen (z.B. Datentyp auslesen geht ja). Aber ob darüber diagnostiziert werden kann, ob am Eingang was dran hängt?

 

[RucksackSepp]

Also der Begriff "Biergebende-Pommesnudelkuh" ist ja genial

Was ich noch ergänzen sollte. Der Datentyp der Endschalter ist immer ein BOOL. Bei Zahlenwerten wie INT oder so, könnte man ja auch "0" abfragen, wobei das auch nicht elegant ist.

 

[RucksackSepp]

Leg doch die Ansteuerung des Ventils auf Stellung AUF und ZU wenn du keine Stellungen hast.

Wäre auch eine gute Idee. Ich schau mal, wenn ich nix zu finde, wird's drauf hinauslaufen...

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ob ein Baustein-Parameter beschaltet ist, kann man prinzipiell nicht feststellen, weil man im Baustein nur Zugriff auf die Kopie des Aktualparameters in der Instanz hat. Der Wert in der Instanz kann auch ganz anders zustande gekommen sein, z.B. durch direkte Zugriffe. Ich würde auch niemals irgendwas davon abhängig machen. Wenn ein Baustein abhängig von der Beschaltung unterschiedliche Sachen machen soll, dann einen zusätzlichen "Mode"-Eingang vorsehen, wo ein Code für die gewünschte Funktion angeschaltet werden muss.

 

[RucksackSepp]

Okay, dann werde ich beim ursprünglichen bleiben, und den "posAvailable" Anschluss beibehalten.

 

[Max2.0]

Du kannst GetSymbolName Verwenden um den Namen der Variablen auszulesen.
Das kann dann theoretisch auch gleich zur Felergenerierung oder anzeige in der HMI verwendet werden um anzuzeigen welches BMK an der "Biergebende-Pommesnudelkuh" angeschlossen ist.

Hinweis:

Negierte Variable am Eingangsparameter eines Bausteins

Wenn SIe "GetSymbolName" auf einen Eingangsparameter eines Bausteins anwenden, an dem eine negierte Variable verschaltet ist, wird stets ein leerer String zurückgeliefert.

 

[Januar]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ob ein Baustein-Parameter beschaltet ist, kann man prinzipiell nicht feststellen, weil man im Baustein nur Zugriff auf die Kopie des Aktualparameters in der Instanz hat. Der Wert in der Instanz kann auch ganz anders zustande gekommen sein, z.B. durch direkte Zugriffe. Ich würde auch niemals irgendwas davon abhängig machen. Wenn ein Baustein abhängig von der Beschaltung unterschiedliche Sachen machen soll, dann einen zusätzlichen "Mode"-Eingang vorsehen, wo ein Code für die gewünschte Funktion angeschaltet werden muss.

Zumal es ja auch immer noch passieren kann, dass ein anderer Programmteil schreibend auf den IDB zugreift. Oder hat BigS da inzwischen den Riegel vorgeschoben?

 

[DCDCDC]

Zumal es ja auch immer noch passieren kann, dass ein anderer Programmteil schreibend auf den IDB zugreift. Oder hat BigS da inzwischen den Riegel vorgeschoben?

Ich glaube das geht immer noch, auch wenn ich das noch nie benutzt hab.

 

[JSEngineering]

Mir fallen spontan zwei Varianten ein, die man machen könnte:

Zum einen über Default-Werte gehen und dem Eingang als Standardwert einen "unplausiblen" Wert geben (ist bei Bool natürlich schwierig). Wenn also der Default-Wert übernommen wird, weiß man, daß der nicht beschaltet ist.

Die zweite Möglichkeit ist, daß man ja mit der Eierlegenden Wollmichsau (oder auch mit der biergebenden Pommeskuh) dann doch bestimmte Geräte/Szenarien abbildet. Also spendiert man einen Eingang, an dem man entweder den Typ angibt und damit definiert ist, welche E/As benutzt werden oder aber man macht einen Flag-Eingang, über den man dann E/As abschalten/zuschalten kann.

Wir haben auch mal einen Ventilbaustein mit genau diesen Funktionalitäten geschrieben, da haben wir das über Typen gemacht, dann wußte man auch sofort, ob man es mit einem einfach- oder zweifach wirkendem Antrieb zu tun hatte, wußte, welche Optionen dran sind. Beliebig viele Varianten gibts da ja nicht und das Programm wurde durchaus sprechend durch die Beschriftung mit Ventiltypen. Ich glaube produktiv hatten wir 4 oder 5 Typen, ausprogrammiert um die 10.

Mit diesen Typen läßt sich dann auch intern über Case etc. schön der Code strukturieren, weil ansonsten ist das Spaghetticode, bei dem dann die Fehlersuche müßig wird, wenn man überall abfragt, ob Eingang A benutzt wird oder nicht.

 

[JSEngineering]

Zuviel Werbung?
-> Hier kostenlos registrieren

Noch eine Idee für die Endlagenerfassung, ob die belegt ist oder nicht:
Mit Hilfe des Analogwertes eine Referenzfahrt machen und schauen, ob es Endlagen gibt.
Kommt natürlich auf die Anlage an, ob man das machen kann oder nicht. Aber grundsätzlich könnte man beim Hochfahren so vorgehen:
Defaultwert Stellung = -100% --> Du hast den Eingang Stellungsrückmeldung nicht beschaltet, also müssen O/C-Rückmeldungen kommen.
Defaultwert Stellung 0..100% --> Analogventil: Entweder hast Du in der momentanen Stellung eine Rückmeldung O/C oder Du schaust Dir die Eingänge bei der ersten Betätigung an. Die O/C-Rückmeldungen sind dann ja in der Regel eh nur zur Fehlermeldung oder zum Kalibrieren da.

 

[winnman]

Mal überlegen das aufzuteilen:
ein FB Wollmilchsau
mehrere FB je nach Beschaltung als Vorsatz, der gibt dann an die Wollmilchsau über zB. Int die Info weiter was da beschaltet ist.
FB Wollmichlsau kann alle varianten abdecken
Vorschalt FB wird je nach Beschaltung ausgewählt

 

[Tschoke]

Ob ein Baustein-Parameter beschaltet ist, kann man prinzipiell nicht feststellen

Eine Ausnahme gibt es.
Eine Input-Variable vom Typ Variant kann auf NULL abgefragt werden, ob sie beschaltet ist.
Das hilft hier zwar nicht weiter aber trotzdem gut zu wissen.


Oder doch? Einfach alle Eingänge als Variant deklarieren!
War nicht ernst gemeint.

 

[Onkel Dagobert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Eine Ausnahme gibt es.
Eine Input-Variable vom Typ Variant kann auf NULL abgefragt werden, ob sie beschaltet ist.
Das hilft hier zwar nicht weiter aber trotzdem gut zu wissen.


Oder doch? Einfach alle Eingänge als Variant deklarieren!
War nicht ernst gemeint.

Natürlich geht das. Zum Beispiel ersetze ich eine Rückmeldung bausteinintern durch die entsprechende Ansteuerung, wenn der Eingang mit NULL beschaltet ist, genau wie es weiter oben schon erwähnt wurde. Man sollte es nur nicht übertreiben mit den Wollmilchsauereien! Einen Nachteil hat es auch, man kann nicht mal eben schnell eine Konstante wie "true" oder "21.0" dran schreiben. Das geht dann nur über Variablen.

 

[ducati]

Zum Beispiel ersetze ich eine Rückmeldung bausteinintern durch die entsprechende Ansteuerung

Ich verschalte halt einfach am Bausteineingang die Ansteuerung, falls RM nicht vorhanden sind... und schon versteht JEDER, was da gemacht wird... ohne Wollmilchsauereien...

 

[RucksackSepp]

Hab die Auswertung nach alter Schule gelöst:
Einen Eingang mehr pro Funktion, wie Stellungsüberwachung, Durchflusssensor oder so. Also den Sensor Eingang und einen Available. Die sind als Standard mit "true" deklariert. Dadurch kann man wenn man in SCL den Baustein aufruft entweder die Sensoren sehen, oder bei "Available" den Wert "FALSE". Damit kommt glaub ich jeder gut zurecht.

Die Wollmilchpommeskuh ist damit auf ein einfach wirkendes Ventil beschränkt, mit "modifizierbaren" Überwachungen. Für ein doppelt wirkendes oder analoges Ventil gibts nen anderen FB.