Zuviel Werbung? - > Hier kostenlos beim SPS-Forum registrieren

Seite 4 von 5 ErsteErste ... 2345 LetzteLetzte
Ergebnis 31 bis 40 von 42

Thema: Problem mit UDT inout und Multiinstanz

  1. #31
    Registriert seit
    29.03.2004
    Beiträge
    5.800
    Danke
    144
    Erhielt 1.708 Danke für 1.240 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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:
    Code:
    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:
    Code:
    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.
    Geändert von Thomas_v2.1 (16.02.2015 um 22:29 Uhr) Grund: Rücksetzen fehlte im Code

  2. #32
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.794
    Danke
    398
    Erhielt 2.417 Danke für 2.013 Beiträge

    Standard

    @HB:
    Nicht, dass wir dieses OO-Thema nicht schon x mal diskutiert haben ...
    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

  3. #33
    Registriert seit
    29.03.2004
    Beiträge
    5.800
    Danke
    144
    Erhielt 1.708 Danke für 1.240 Beiträge

    Standard

    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.

  4. #34
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.316
    Danke
    932
    Erhielt 3.330 Danke für 2.689 Beiträge

    Standard

    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
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  5. #35
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.794
    Danke
    398
    Erhielt 2.417 Danke für 2.013 Beiträge

    Standard

    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

  6. #36
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.316
    Danke
    932
    Erhielt 3.330 Danke für 2.689 Beiträge

    Standard

    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
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  7. #37
    Registriert seit
    13.10.2007
    Beiträge
    12.065
    Danke
    2.793
    Erhielt 3.288 Danke für 2.168 Beiträge

    Standard

    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.
    - - -
    Wer als Werkzeug nur einen Hammer hat, sieht in jedem Problem einen Nagel.

  8. #38
    Registriert seit
    29.03.2004
    Beiträge
    5.800
    Danke
    144
    Erhielt 1.708 Danke für 1.240 Beiträge

    Standard

    Zitat Zitat von PN/DP Beitrag anzeigen
    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.

  9. #39
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.794
    Danke
    398
    Erhielt 2.417 Danke für 2.013 Beiträge

    Standard

    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 ...

  10. #40
    Registriert seit
    24.04.2013
    Beiträge
    309
    Danke
    23
    Erhielt 160 Danke für 88 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    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

Ähnliche Themen

  1. Step 7 UDT als Eingangsvariable eines Multiinstanz-FBs
    Von Bär1971 im Forum Simatic
    Antworten: 12
    Letzter Beitrag: 20.08.2013, 19:11
  2. Timer mit Instanz als InOut Varíable
    Von blubbi im Forum CODESYS und IEC61131
    Antworten: 3
    Letzter Beitrag: 31.01.2013, 20:37
  3. Baustein mit IN & OUT Paramtern, oder INOUT`erstellen?
    Von Bensen83 im Forum CODESYS und IEC61131
    Antworten: 13
    Letzter Beitrag: 23.11.2012, 13:08
  4. Problem mit Multiinstanz und SFB4
    Von shephard im Forum Simatic
    Antworten: 15
    Letzter Beitrag: 05.11.2010, 08:31
  5. UDT als In_Out an Multiinstanz FB
    Von dirknico im Forum Simatic
    Antworten: 4
    Letzter Beitrag: 01.10.2009, 12:28

Stichworte

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •