Step 7 SCL Stringvariable rücksetzen

Azrael666

Level-1
Beiträge
239
Reaktionspunkte
18
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Leute,

ich hab ein Problem mit meinem SCL Baustein.

Der Baustein ist ein FB mit einem DB. Dieser FB besitzt als Eingänge in der Form String[10]
Diesen FB rufe ich in einem eigenen FC auf und an die Eingänge des FBs sind dort Strukturen an parametriert in der Form String[10].

Mein Problem ist wenn ich dort im FC einen String an parametriert dann steht der auch wunderbar im DB des FBs
Wenn ich diesen String jedoch wieder entferne bleibt der ursprüngliche String Wert im DB bestehen, es sei denn ich initialisieren den DB von Hand wieder.

Gibt es eine Möglichkeit dass sich der Wert im DB von selbst wieder zurücksetzt wenn ich den Parameter entferne?


MFG
 
Nur das ich es recht verstanden habe : du nimmst die Beschaltung des IN-Parameters weg ?
In dem Fall bliebe die letzte inhaltliche Zuweisung des FB's bestehen.
Du müßtest dir also so etwas wie einen Reset für den Baustein parameterieren, der den IN-Parameter löscht ...

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Larry's Frage ist berechtigt. Falls es in die Richtung geht:

Ich mache mir hin und wieder leere "Dummystrings", die ich dann an solche INs hänge.
Falle da auch hin und wieder rein, weil FBs halt netterweise nicht beschaltet werden müssen (Großteils). Versuche aber eigentlich immer alles auszufüllen. Und wenn ich 5x nen temporären bool_dummy wo dran hänge! Dann kommt man in weniger Probleme!

grüßle
 
Strings in DBs sind Variablen - der Wert von Variablen ändert sich nicht von alleine, der zuletzt zugewiesene Wert bleibt erhalten. (außer TEMP-Variablen)
Strings an Inputs von FB werden beim FB-Aufruf in die Instanz (den IDB) kopiert. Wird der FB ohne anparametrierten String aufgerufen, dann wird nichts in den IDB kopiert, der Wert im IDB bleibt erhalten. Der FB kann nicht unterscheiden, ob beim Aufruf der Instanz "außen" ein String anparametriert ist oder nicht.

Dein Problem ist doch eigentlich nur ein Problem, wenn Du am Programm rumschraubst. Dann solltest Du auch selbst entscheiden, ob bei der Programmänderung auch die Variablenwerte ("Aktualwerte") erhalten bleiben sollen oder frisch initialisiert werden sollen.

Harald
 
Moin,
erst mal Danke für die Antworten.

Genau wie Larry es vermutet habe kann ich meinem FB die Beschaltung "klauen" und leer lassen. Somit bleibt ja der letzte Wert der dort stand im DB gespeichert.

Mein FB Baustein hat 4 Eingänge an denen Strings angehängt werden können. Je nachdem was wo dran hängt, werden im FB diese Einzelstrings zu einem GesamtString kombiniert.
Das Problem dabei ist, wenn z.B. ein Eingang beschaltet wurde und diese Beschaltung wieder gelöscht wird und leer bleibt, dann wäre der zusammengesetzte GesamtString nicht korrekt.

Ich habe mir jetzt erst mal dadurch geholfen, dass ich ganz am Ende des SCL Bausteins alle Eingangsstrings erst mal mit String:='' beschreibe.
Das funktioniert auch, allerdings finde ich diese Lösung nicht sonderlich elegant.

MFG
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Asrael,

nachdem ich dein Problem und auch die Antworten gelesen habe ist mir überhaupt nicht klar, warum du überhaupt einen FB nimmst.
Wie wäre es denn mit einem FC, der dir deine Strings zusammensetzt und das Ergebis als Funktionswert zurückgibt?
Also in etwa so:
FUNCTION "strgconcat" : String

VAR_INPUT
a : String;
b : String;
c : String;
END_VAR

#strgconcat := CONCAT(IN1:=CONCAT(IN1:=#a, IN2:=#b),IN2:=#c);

END_FUNCTION


Oder noch besser: warum nimmst du nicht einfach die Concat Funktion und setzt deinen String direkt zusammen.

Ausserdem willst du doch bestimmt nicht für jede neue Eingangsbelegung umprogrammieren, sondern mit Varaiblen beschalten, die dann auch ihre Inhalte ändern.
Dann regelt sich dein Problem von selbst. Auch wenn du unbedingt einen FB brauchst.

MFG
 
Ich habe mir jetzt erst mal dadurch geholfen, dass ich ganz am Ende des SCL Bausteins alle Eingangsstrings erst mal mit String:='' beschreibe.
Das funktioniert auch, allerdings finde ich diese Lösung nicht sonderlich elegant.

Ich kenne jetzt deine Anforderung nicht, unterstelle aber erstmal, dass du dir dabei schon etwas gedacht hast.
In dem Fall ist das vielleicht nicht "besonders elegant" ... aber legitim - ich selbst habe etwas Ähnliches für eine andere Beschaltung (bei mir waren es INT's) auch schon mal gemacht.
Entscheidend ist, dass dein Baustein in seiner angedachten Funktion dem Rechnung trägt ...

Gruß
Larry
 
Wie Keops finde ich ebenfalls daß die beschriebene Aufgabe eigentlich eine klassische Anwendung einer Function ist. Du jedoch benutzt einen FB und anscheinend mehrfach (oder jedes Mal?) auch noch die selbe Instanz. So ist die Verwendung von Funktionsbausteinen eigentlich nicht vorgesehen.

Du schreibst die Funktion vermutlich nur deshalb als FB, um Eingänge unbeschaltet lassen zu können? Statt einen Eingang manchmal unbeschaltet zu lassen kannst Du einen leeren String (String mit der Länge 0) anschalten, so geht es dann auch mit FC.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also ich nutze einen FB weil ich diesen eventuell mehrfach aufrufen möchte und somit immer einen eigenen Instanz-DB habe.

Der Baustein macht im Prinzip folgendes:
- Er hat vier Eingänge in der Form STRING[10] und vier Eingänge BOOL
- Jeder BOOL Eingang gehört zu einem STRING Eingang

Nehmen wir an es ist der Eingang BOOL1 und STRING1 beschaltet. Bei einem Signalwechsel an BOOL1 wird der STRING1-WERT ("Präfix") genommen mit anderen internen Strings (u.a. die IP-Adresse der CPU) kombiniert und als Telegram per TCP verschickt.

Ich habe unter anderem auch noch mehrere Routinen eingebaut die diesen "Präfix"-Wert auf seine Beschaffenheit überprüft, da diese für das Telegram wichtig ist.
Bei einem Fehler wird kein Telegram verschickt sondern eine Parameter-Fehler-Ausgang gesetzt.

Das Problem ist/war das wenn ich etwas an den Eingang STRING2-WERT, etc schreibe und wieder lösche (also leer lasse) immer noch der letzte Wert im DB bestehen bleibt und somit meine Prüfroutine auch immer wieder diesen letzten Wert prüft.
Bedeutet wenn jemand etwas falsches anparametriert und wieder löscht, würde der Fehler-Ausgang so lange bestehen bleiben bis entweder etwas richtiges dran steht oder der DB initialisiert wird.
 
Lass doch den Eingang nicht unbeschaltet sondern schreib ein "" drann wenn kein Wert kommt, daß sollte die Variable im IDB löschen.
Mal abgesehen davon finde ich das eine eigenwillige Konstrutkion. Bei so Telegrammgeschichten benutze ich meist FCs und globale DBs, daß macht es auch für das Spooling einfacher.
 
Bedeutet wenn jemand etwas falsches anparametriert und wieder löscht, würde der Fehler-Ausgang so lange bestehen bleiben bis entweder etwas richtiges dran steht oder der DB initialisiert wird.
Du mußst Dein Programm nicht so schreiben, daß jedes unqualifizierte 'rumprogrammieren Fremder automatisch "geheilt" wird. Fehlerhaftes Folge-Verhalten ist das Problem desjenigen, der das Programm ändert - der wird schon merken, daß durch seinen Eingriff ungewollte Effekte auftreten.

Außerdem: wenn ein FB-Eingang nicht beschaltet wird, dann kann direkt der Wert im Instanz-DB beschrieben werden (durch Programm oder Variable steuern) - diese (fehlerhafte) Manipulation kannst Du nicht verhindern.

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ja eigentlich hast du recht. Ich wollte es aber doch so schreiben, dass es "idiotensicher" ist. Ich weiß nicht wer später mit dem FB rumspielen darf und es soll dann nicht heißen, "scheiß FB, der funktioniert gar nicht" nur weil die parametrierung falsch war.

Aber wie gesagt mit meiner Notlösung funktioniert das ganze auch so wie es soll, von daher werd ich es so lassen.

Trotzdem Danke für die Hilfe
 
Zurück
Oben