TIA Problem mit UDT inout und Multiinstanz

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

aber die Anlage muss am Dienstag raus und wir haben im Moment soviel zu tun
[...]
Prinzipiell finde ich diese "Lego" Bauweise von Programmen nämlich sehr gut da, wenn so manch ein Baustein überholt wird man bestehende Anlagen verbessern kann.

Tja, wenn Ihr alle Eure Anlagen mit nur so halben Lösungen ausliefert, dann besteht natürlich genügend Verbesserungspotential und -bedarf

Harald

 

[dodi110480]

nun ja, ich wollte, wie gesagt mal was Neues ausprobieren...
Mein nächstes Projekt ist eine Anlage die in Transite programmiert wird. Also, was total "durchdachtes". Selbst in diesem Smileyprogramm gibt es noch den einen oder anderen Bug, wie wir letztens wieder festgestellt haben. Ich denke mal, die perfekte Software wird es nie geben bzw. man kann immer etwas verbessern.

Gruß,
Dominik

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich denke, das ist schon ok - wer nicht mit etwas anfängt der wird es auch nicht fertig bekommen.
Jedes Ding, das man anfängt braucht so seine Entwicklungszeit ...

Gruß
Larry

 

[HelleBarde]

Ich denke mal, dass es erstmal keinen Unterschied macht, in welchen DB du deine Daten von der Visu schreibst. Ob jetzt in diesen oder jenen DB spielt für das Problem mit der "Nebenläufigkeit" keine Rolle - wenn die Übertragung keinen Kontrollpunkt mehr hat dann muss man sich im SPS-Programm "künstlich" einen erschaffen ...

Gruß
Larry

Dodi hat eindeutig ein Problem mit "Nebenläufigkeit". Bausteinstatus ist mit dem Baustein der beobachtet wird synchronisiert und Beobachtungstabellen sind mit dem OB1 synchronisiert. HMI ist das nicht! Wenn du also im Programm wohin schreibst z.B. in den INOUT einer Instanz und mit der Visu machst du das auch, dann gewinnt mal der eine und mal der andere. Du schreibst so schön:

"künstlich" einen erschaffen

Ja wie denn?? Welches Mittel bietet Siemens denn da?? Ich habe in den letzten 20 Jahren keines gefunden. Der Schreibzugriff der Visu platzt irgendwann rein.

Deshalb schreibe ich mit der Visu in einen speziellen DB der dem restlichen Prozess egal ist und dann kopiert sich der Prozess zu einem für den Prozess geeigneten Zeitpunkt die notwendigen Daten.

Aber vielleicht es es das was du mit deinem "künstlichen Kontrollpunkt" meinst.


von welcher Objektorientierung wird denn hier gesprochen? Ich hab im ganzen TIA nirgendwo INTERFACE, IMPLEMENTS oder CLASS gesehen ??? Gibt es irgendwo virtuelle Methoden????

'n schön' Tach auch
HB

 

[Thomas_v2.1]

von welcher Objektorientierung wird denn hier gesprochen? Ich hab im ganzen TIA nirgendwo INTERFACE, IMPLEMENTS oder CLASS gesehen ??? Gibt es irgendwo virtuelle Methoden????

Nur weil die Namen und einige Features fehlen, heißt das nicht dass man bei Step7/TIA keine objektorientierten Konzepte anwenden kann. Denn es ist ein Konzept, und keine Sprache.
In C gibt es deine Schlagwörter auch nicht, aber schau dir mal sowas wie GTK+ oder GObject an. Einen Funktionsbaustein kann man schon als Objekt ansehen, der auch in gewisser Hinsicht über die Multiinstanzen Funktionen von anderen FBs erben kann. Beim TIA-Portal gibt es wenigstens für den HMI-Zugriff entsprechende Zugriffsmodifikatoren, sodass eigentlich nicht mehr viel dagegen spricht ein HMI direkt auf die Instanz zugreifen zu lassen, da man durch die Optionen festlegen kann worauf zugegriffen werden darf und worauf nicht. Riesige Globaldaten-DB sind bestimmt nicht objektorientiert.

 

[HelleBarde]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi Thomas

Ok, OO ist ein Konzept. Da fehlt's aber bei S dann trotzdem hinten und vorne. Objektorientierung ist, wenn das Objekt sagt, welche der abgeleiteten Implementierungen es bei einer Methode aufruft. Ja die ersten C++ Compiler waren Präprozessoren die auf einfaches C herunter sind. Aber C hat ja auch Funktionspointer. Sowas gibt es bei der Simatic nicht. In AWL UC FC[LW10] ... oh nee. Wo sind denn da die Parameter. Nee Simatic ist nicht OO.

Wer sagt denn, dass die für die Synchronisierung zwischen Visu und Prozess verwendeten DB rießig sind und dass es nur einen gibt. Solange es keine "sprachliche" Unterstüzung bezüglich der Nebenläufigkeit gibt, z.B. einen SFC BlockHMIAccess und SFC UnblockHMIAccess oder sowas, muss man sich seine Synchronisierung selber schaffen. An Dodi's 1s Lösung sieht man ja was da bei tolles raus kommt.

'n schön' Tach auch
HB

 

[dodi110480]

Nett....
Was meinst du mit "tolles dabei raus kommt"?
Ich kopiere die Werte vorher in STATs die am FB hängen (Funktioniert, Punkt).... mein Problem ist das "Wiederzurückkopieren auf die ursprünglichen Varialben" hast du dazu eine Lösung?

Ich lese nur: "Deshalb schreibe ich mit der Visu in einen speziellen DB der dem restlichen Prozess egal ist und dann kopiert sich der Prozess zu einem für den Prozess geeigneten Zeitpunkt die notwendigen Daten."

Der Sinn eines Forums ist für mich, dass man hilft wenn jemand ein Problem hat und nicht ihn zu diffamieren.

Gruß
Dominik

 

[Thomas_v2.1]

Kannst du deine Visu nicht direkt auf den Instanz-DB schreiben lassen?
Dann wäre das Problem mit sowas wie:

Sollwert_intern := Sollwert_extern;
IF Sollwert_intern > Max THEN
  Sollwert_intern := Max;
  Sollwert_extern := Max;
ELSIF Sollwert_intern < Min THEN
  Sollwert_intern := Min;
  Sollwert_extern := Min;
END_IF;

eigentlich erledigt.

 

[dodi110480]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja schon, so geht es, aber wenn ich direkt im InstanzDB was mache dann ist der Effekt den ich erreichen möchte nicht mehr gegeben. Ich möchte gerne, in Zukunft, aus der Bibliothek mir meine Anlage zusammen stecken können. So wie ich es jetzt gemacht habe, funktioniert alles bis auf dieses eine, nervige Problem.... :-/


Gesendet von meinem iPhone mit Tapatalk

 

[Thomas_v2.1]

Alternative Lösung die auch zuverlässig funktioniert:
Du machst die Sollwertvorgabe als In-Parameter, und den aktuellen ggf. im Baustein begrenzten Sollwert als Out-Parameter. Eine Grenzwertverletzung signalisierst du über einen oder zwei Bool Out-Parameter. Dann schaltest du dem Baustein eine bedingte Move-Anweisung (oder ein If...Then) nach, bei der du bedingt die Sollwertvorgabe bei Grenzwertverletzung korrigierst. Aufwändiger, aber zuverlässig.

 

[Thomas_v2.1]

Ein kleines Codebeispiel wie man das angehen könnte, wenn der Sollwert unbedingt über einen Parameter reinkommen muss.

Baustein der einen Sollwert verarbeitet und ihn evtl. begrenzen muss:

FUNCTION_BLOCK "SP_Async"
   VAR_INPUT 
      SP_Ext : Real;
      Hi : Real;
      Lo : Real;
   END_VAR

   VAR_OUTPUT 
      SP_Out : Real;
      SP_ExtHiAct : Bool;
      SP_ExtLoAct : Bool;
   END_VAR

   VAR_TEMP 
      SP_tmp : Real;
   END_VAR

BEGIN
	#SP_tmp := #SP_Ext;
	IF #SP_tmp > #Hi THEN
	  #SP_tmp := #Hi;
	  #SP_ExtHiAct := true;
	  #SP_ExtLoAct := false;
	ELSIF #SP_tmp < #Lo THEN
	  #SP_tmp := #Lo;
          #SP_ExtHiAct := false;
	  #SP_ExtLoAct := true;
	ELSE
	  #SP_ExtHiAct := false;
	  #SP_ExtLoAct := false;
	END_IF;
	#SP_Out := #SP_tmp;
END_FUNCTION_BLOCK

Beim Aufruf muss man dann etwas nachhelfen um den Sollwert nachzuführen:

FUNCTION "SollwertTest" : Void
   VAR_TEMP 
      SP_tmp : Real;
      SP_ExtHiAct : Bool;
      SP_ExtLoAct : Bool;
   END_VAR

BEGIN
	"SP_Async_DB"(SP_Ext := "DB_HMI".Solltemperatur,
	              Hi := REAL#70.0,
	              Lo := REAL#20.0,
	              SP_Out => #SP_tmp,
	              SP_ExtHiAct => #SP_ExtHiAct,
	              SP_ExtLoAct => #SP_ExtLoAct);
	// Sollwertvorgabe ggf. korrigieren
	IF #SP_ExtHiAct OR #SP_ExtLoAct THEN
	  "DB_HMI".Solltemperatur := #SP_tmp;
	END_IF;
END_FUNCTION

Wenn man dafür sorgen könnte, dass ein In-Out Parameter garantiert als Zeiger übergeben wird, könnte man das Prinzip auch auf einen In-Out anwenden. Bei einer 300/400er ist das so wenn der In-Out aus einem zusammengesetzten Datentyp (Struct, Array, etc.) besteht.
Bei der 1500 weiß ich es nicht wie diese es handhabt.

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

@HB:
Nicht, dass wir dieses OO-Thema nicht schon x mal diskutiert haben ... 8)
Man kann sich da mit einigen wenigen kleinen Tricks schon ziemlich nah daran tasten. Ich und auch einige andere haben dazu mehrfach etwas geschrieben.
Was die Sache mit dem Schreiben der Visu angeht - wie ich schon geschrieben habe : einfach nur dafür sorgen, dass nicht Visu UND SPS an dem selben Datensatz herumändern wollen...

Gruß
Larry

 

[Thomas_v2.1]

Ich muss Dominik aber beipflichten, dass bisher mehr rumgeschwafelt als konkrete Lösungen gegeben wurden.

Ich kann mir unter "eigenen Zykluskontrollpunkt schaffen", oder dieser Lösung mit irgendwelchen Sequenz-IDs in einem globalen Koppel-DB auch nichts Konkretes vorstellen. Ich bin gespannt wie man damit das Problem gelöst bekommt. Da sollte doch ein kleiner Codeschnippsel reichen um zu zeigen wie das funktionieren soll.

 

[PN/DP]

Das ab und zu auffällige Nebenläufigkeits-Problem bei IN/OUT ist imho nicht das größte Problem, wenn es keinen definierten HMI-Kontrollpunkt gibt. Wenn die HMI zu beliebigen Zeitpunkten in die Programmvariablen schreibt, dann kann man nie sicher sein, daß die Programmvariablen bei der Verarbeitung zulässige Werte enthalten, egal wie tricky man die Begrenzung programmiert. Genau NACH der Prüfung kann die HMI einen unzulässigen Wert in die Variable schreiben und das Programm verarbeitet dann 1 Zyklus lang den unzulässigen Wert. Das Problem bekommt man nur in den Griff, wenn man im Programm nicht direkt die von der HMI beschriebenen HMI-Variablen verwendet, sondern Kopien. So wie Hellebarde schon mehrmals schrieb. Wenn man von extern kommende Daten sicher verarbeiten will, dann muß man diesen Mehraufwand mit den doppelten Variablen betreiben. Die HMI-Variable darf nur genau einmal gelesen werden, geprüft und auf die Programmvariable kopiert werden, und nur bei Bedarf beschrieben werden.

Harald

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das sehe ich nicht so, wie du Harald ...
Die doppelte Datenhaltung löst das Problem doch genau so wenig ... wer hat dann in dem Fall den richtigen Datensatz ...?
An der Stelle ist also der Vorwurf von Thomas absolut korrekt - das bringt die Sache nicht weiter ...
Ich habe mich irgendwann auch schon mal mit dem Thema herumgeschlagen - die einzige Möglichkeit, die ich gefunden habe war, wie ich schon ein paar Mal geschrieben habe : nicht die Visu UND das SPS-Programm den gleichen Datenbereich verändern lassen. Das braucht es m.E. bei so einem Sammel-FB auch gar nicht ... Einfach mal darüber nachdenken und dann "schwafeln" ...

Gruß
Larry

 

[PN/DP]

Wie begrenzt bzw korrigierst Du einen Eingabewert von der Visu? Erzeugst Du eine Meldung, daß der Bediener den Wert ändern möge?
Wie bekommst Du überhaupt Visu-Eingabewerte überprüft ins Programm übernommen?

Harald

 

[rostiger Nagel]

Mal so als Laie,
wenn ich die Daten so Konsitent brauche, Siemens das nicht hinbekommt eine einfache
Lössung dafür zu bieten. Wie währe es wenn man sich diese mittels einer Rezeptur abholt?

Da bekommt man doch eine Rückmeldung über den Status.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Wie begrenzt bzw korrigierst Du einen Eingabewert von der Visu? Erzeugst Du eine Meldung, daß der Bediener den Wert ändern möge?
Wie bekommst Du überhaupt Visu-Eingabewerte überprüft ins Programm übernommen?

Bei meinem Beispielbaustein aus #31 darf natürlich im weiteren Programm nur der Wert des Ausgangs SP_Out verwendet werden. Dann werden soweit ich das sehen kann alle Fälle abgefangen, bzw. es werden keine Eingaben von der Visu unterschlagen die mitten im SPS OB1 Zyklus in die Daten eingebunden werden. Einzig unschön ist, dass die komplette Funktionalität nicht in einem einzigen Baustein gepackt werden kann. Zumindest nicht in einem FB, FC mit In-Out sollte funktionieren.

Es gibt noch einen zumindest theoretischen Fall, wenn ein Benutzer es schafft innerhalb 1 oder 2 SPS-Zyklen erst einen Wert außerhalb der Grenzen zu schreiben, und dann einen innerhalb der Grenzen, wird der zweite eingegebene Wert womöglich nicht übernommen. Theoretisch möglich, praktisch unmöglich.

 

[Larry Laffer]

Ich denke mal, dass der TE folgendes macht :
Es gibt einen Baustein, der die Daten von mehreren Stationen / Aggregaten einer Anlage verwaltet. Jede Station holt sich beim Bausteinaufruf ihre Daten aus dem Sammel-FB (über In-Out) , arbeitet damit und schreibt sie (ggf. verändert wegen neuer Ergebnisse) am Baustein-Ende wieder zurück. So könnte ich mir das aufgrund der Beschreibung jedenfalls vorstellen ...
Nun greift dann irgendwann die Visu da ein - auch auf die gleichen Daten. Solange nur gelesen wird (zum Anzeigen) ist alles OK. Aber nun schreibt die Visuche anscheinend auch was ... und an der Stelle wird es dann problematisch ...

 

[HelleBarde]

Hi all

nochmal Öl ins Feuer.

Harald hat verstanden: "Das Problem bekommt man nur in den Griff, wenn man im Programm nicht direkt die von der HMI beschriebenen HMI-Variablen verwendet, sondern Kopien"
und Larry schreibt doch das Gleiche: "nicht die Visu UND das SPS-Programm den gleichen Datenbereich verändern lassen"

Mein Vorschlag: Für die Informationsflussrichtung von Visu zu PLC: die Visu schreibt in den DB_A und das Programm liest normalerweise aus DB_B. An einer einzigen Stelle wird durch das Programm von DB_A nach DB_B kopiert. Für die Gegenrichtung verwende man DB_C und DB_D oder andere disjunkte Bereiche von DB_A und DB_B.

Und wenn jetzt mehr als 460 Bytes (oder so) übertragen werden müssen, dann kommt der Trick mit der Sequenznummer zum Einsatz, mit dem sichergestellt wird, dass der Datensatz im DB_A konsistent ist. Im DB_A werden zwei zusätzlich Variablen angelegt. Ich nenne sie jetzt mal SeqA und SeqB. Die Visu schreibt nicht nur einfach die Nutzdaten, sondern sie schreibt drei Mal.
Zuerst SeqA := x, dann die Nutzdaten, dann SeqB := x, danach x := x+1. Ja, das ist zusätzliche Arbeit.
Und auch das Programm muss mehrere Schritte machen. Zuerst kopiert man SeqB nach tmpB, dann kopiert man die Nutzdaten von DB_A in einen Puffer. Dann vergleicht man SeqA mit tmpB. Ist tmpB == SeqA, dann sind die Nutzdaten konsistent und man kann den Puffer nach DB_B kopieren, wenn nicht, dann vergiss die Daten für diesen Zyklus, DB_B bleibt unverändert.

Wieso klappt das? Nehmen wir mal an, dass HMI platzt in den Kopiervorgang. Dann hat das Programm SeqB gelesen und einen Teil der Nutzdaten. Die Visu schreibt aber zuerst SeqA, das ist aber das, was das Programm als letztes liest. Damit ist tmpB <> SeqA, die Unterbrechung ist erkannt.

Ja, ja, das ist alles recht kompliziert. Aber erst nötig, wenn beide Problem zuschlagen. Große Datenmengen und Nebenläufigkeit. Nochmal Larry: "Solange nur gelesen wird (zum Anzeigen) ist alles OK"

'n schön' Tach auch
HB