TIA Problem mit UDT inout und Multiinstanz

[dodi110480]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Alle,

ich habe schon überall verzweifelt nach meinem Problem gesucht, bin aber nicht so wirklich fündig geworden.

Ich habe mir kleine FBs gebaut, die zb. einen G120c ansteuern und diverse Störungen erzeugen wenn der Umrichter n Problem hat. Am FB ist unter anderem ein inout PLC-Datentyp, der in einem DB steht. Dieser wird dann von der HMI benutzt um im Einrichtbetrieb den Motor (Um den Motorbaustein geht es egtl. nicht, dieser funktioniert schon lange) zu steuern. Unter anderem ist da eine Variable drin die den Sollwert vorgibt.

Ich baue mir nun aus solchen kleinen FB (Motor, Zylinderbewegung.... usw) einen großen FB der ein Anlagenteil dar stellt. Diese kann man prima von Projekt zu Projekt wiederverwenden.

Das Problem ist nun das wenn ich in der HMI denn Sollwert ändere, dieser manchmal nicht übernommen wird und wieder zurückspringt. Wenn ich mir das ganze am PC betrachte und da die Variable ansteuere funktioniert es immer...

Ich habe schon alles möglich probiert.... zykluszeit der hmi variable.... kommunikationslast...

Hat jemand ähnliche Erfahrungen oder weiß jemand vielleicht sogar eine Lösung?

Danke schonmal

Gruß

Dominik

 

[dodi110480]

achso... nochwas... in_out deswegen weil ich den Sollwert intern im Motor FB begrenze.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du hast wahrscheinlich eine S7-400, oder eine neuere S7-300 bei der du die priorisierte BuB-Kommunikation aktiviert hast. Bei diesen werden die Kommunikationsdaten auch mitten im Zyklus in die internen Datenstrukturen eingebunden. Wenn die Daten nun gerade in dem Moment eintreffen in dem der Baustein auf den In-Out Daten arbeitet, werden diese beim Verlassen des Bausteins wieder überschrieben. Das Phänomen tritt umso häufiger zu Tage, desto größer die Zeit die in dem Fb im Verhältnis zur Gesamtzykluszeit verbracht wird (großer Baustein, kleines Restprogramm). Behandeln sollte man es aber so als ob es immer da wäre.

 

[dodi110480]

Hi Thomas, danke für die Antwort.... es sind 1200er und 1500er bei der 300er gehts nämlich. ...so etwas Ähnliches habe ich vermutet kann man das irgendwo abstellen? :sad:

 

[Thomas_v2.1]

Bei der 300er hieß das "priorisierte BuB-Kommunikation", war aber in Voreinstellung deaktiviert. Bei der 1200/1500 scheint es so eine Option nicht zu geben. Dann musst du wohl dein Programm so schreiben dass es damit umgehen kann.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das Thema gab es vor einem Jahr schonmal:
http://www.sps-forum.de/simatic/68319-s7-1500-hmi-kommunikation-zykluskontrollpunkt.html

Wie man das bei einer 1500 lösen kann weiß ich aber momentan auch nicht.

 

[HelleBarde]

Hi all

bei der 300 bin ich über sowas noch nicht gestolpert, aber bei der 400 oft. Bei der 1200 vielleicht schon, und bei der 1518 sicher aber nicht so oft wie bei der 400. Je schneller die AS desto mehr Probleme bekommt man.

Ich habe mir deswegen angwöhnt keine direkten Schreibzugriffe der Visu in Variablen des Prozesses zu machen. So lästig es am Anfang sein mag, es spart auf die Dauer Zeit und Nerven für BuB einen (oder mehrere) eigenständige DB zu machen.
Also über die Visualisierung schreibe ich in den HMI-DB und am Zyklusbeginn übertrage ich Daten in den Prozess.
Das müssen nicht alle immer sein, sondern die, die im aktuellen Zustand des Prozesses von Wichtigkeit sind.

Durch diese Entkopplung entfallen die Probleme mit Ablaufebenen und Konsistenz.

Sollte man mehr als 480 Bytes am Stück übertragen müssen, dann klappt das nicht. Irgendwo bei 460 oder so ist eine Grenze, jenseits dieser werden mehrere Pakete übertragen. Zwischen diesen Paketen kann die CPU (und die 400 macht das ausgiebig) bereits wieder auf die erst halb geschriebenen Daten zugreifen. Das macht in 99 von 100 Fällen keinen Ärger, aber einmal die Woche sieht der Prozess Daten aus zwei (oder mehr) zu übertragenden Runden. An solchen Fehlern kann man verzweifeln.

Durch spezielle "HMI-Koppel-DB" hat man jetzt die Möglichkeit an zwei Stellen eine Sequenznummer zu hinterlegen. Also ganz am Anfang des großen Paketes und ganz am Ende, die gleiche Zahl. Bevor man die Daten in den Prozess übernimmt vergleicht man die beiden Sequenznummern. Sind sie ungleich, dann wartet man in diesem Zyklus, kopiert nix und lässt die Daten links liegen. Wenn sie gleich sind, dann kann man die Daten verwenden.

Nächster Trick: Man merkt sich die Sequenznummer an einer dritten Stelle. Aber erst nach dem die Daten in den Prozess übernommen wurden. Im nächsten Zyklus kann man damit herausfinden ob überhaupt neues von VISU rein gekommen ist. Wen nix neues reingekommen ist, braucht auch nix kopiert werden.

JA, ich gebe zu, das klingt alles umständlich. ABER so bekommt man eine robuste Kommunikation die ohne Artefakte friedlich tut was sie soll. Das spart Nerven.

'n schön' Tach auch
HB

 

[Larry Laffer]

... so baut sich halt jeder seine Hintertürchen um die Defizite der Visu-Kommunikation umgehen zu können ... 8)

Im Falle des Vorschlages von HB muss ich allerdings sagen, dass ich das für den umgekehrten Weg (SPS -> Visu) schon ausprobiert habe und dabei habe feststellen müssen dass auch das kein Garant für Datenkonsistenz ist - kann klappen - muss aber nicht ...

Ob das allerdings dem TE hilft ...
In denke, dass das Vernünftigste (auch nach meiner Erfahrung) ist, es so zu machen, wie von Thomas vorgeschlagen. "Einfach" den Baustein so ändern, dass die Daten in ihn nur eingelesen, nicht aber von ihm auch wieder zurück geschrieben werden ...

Gruß
Larry

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sein Problem ist aber nicht die Datenkonsistenz, sondern dass die HMI-Daten auch mitten im OB1-Zyklus in den SPS-Daten landen, und der Verwendung dieser Variable als In-Out-Parameter an einem FB. Die Real-Variable mit ihren 4 Bytes landet immer konsistent im Speicher.

Eine Lösung wäre den Sollwert vom HMI auf Änderung zu überwachen, und ihn nur bei Änderung auf die Variable der er als In-Out-Parameter verwendet zu schreiben.

 

[HelleBarde]

Hi Thomas

klar hat Dodi kein Problem mit der konsistenz, aber er hat eines mit der Nebenläufigkeit. Beiden Problemen kann man entkommen wenn man die Visu nicht direkt in den Prozess -- in Dodis Fall den Instanz-DB -- schreiben lässt.

'n schön' Tach auch
HB

 

[Larry Laffer]

@HB:
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

 

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das hier hört sich erst mal nicht gut an.
Die meisten unserer Standard-FBs verwenden UDTs die via SFC20 rein und wieder rauskopiert werden.

Da kann ich mich ja auf was gefasst machen... :-|

 

[Thomas_v2.1]

klar hat Dodi kein Problem mit der konsistenz, aber er hat eines mit der Nebenläufigkeit. Beiden Problemen kann man entkommen wenn man die Visu nicht direkt in den Prozess -- in Dodis Fall den Instanz-DB -- schreiben lässt.

Wenn er auf den Instanz-DB schreiben würde hätte er das Problem überhaupt nicht, denn es entsteht erst durch die Parameterübergabe. Bei den ganzen PCS7-Bausteinen geschieht der HMI-Zugriff direkt auf die Instanz-DBs. Da diese immer auf einer S7-400 laufen, müssen diese mit diesem asynchronen Zugriff umgehen können. Und das können sie auch.

 

[Larry Laffer]

@Ronin:
Das machen alle meine Standard-Bausteine auch. Es ist halt eine Frage, wie du damit umgehst. Eigentlich kann es doch gar nicht sein, dass dein Baustein UND die Visu den gleichen Datenpunkt verändern wollen - und wenn doch dann muß man es halt organisieren ...

Gruß
Larry

 

[dodi110480]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo, erstmal danke an alle.
Also, wenn ich direkt in den Instanz DB schreibe dann macht das Ganze Konzept mit FBs und vererbung und Schnick Schnack doch gar keinen Sinn mehr, oder?
Ich würde mir gerne Bausteine schaffen, die Aufgaben erledigen und wenn die mal gehen dann ... egal, rein damit. Das ganze möchte ich dann quasi zu einem großen Anlagenteil zusammenstecken... z.b. Hat jeder von den kleinen FBs ein Betriebsbereit, Grundstellung, und sämtliche Fehler. Diese Signale intern im großen FB verknüpft ergeben mir dann EIN Betriebsbereit des Anlagenteils. Das Ganze funktioniert alles wunderbar ... ich hab sogar die Automatik mit reingequetscht. Nachteil: Der FB wird etwas.... groß.
Das Einzige was mich jetzt nervt ist das die Schnittstelle am großen FB (IN_OUT Variable) nicht mehr zuverlässig mit der HMI funktioniert.
Das geht soweit, dass ich jetzt mal nur einen IN_OUT am großen FB erzeugt habe der überhaupt nicht innendrinn verknüpft ist und Dieser verhält sich ebenfalls so.... ach Kacke... :-?

Gruß,
Dominik

 

[dodi110480]

Nochwas: Wenn ich im TIA Online gehe und die Brille aufsetze kann ich die IN_OUT Variablen wunderbar steueren.... KEINE Probleme...
Wieso haben die die Kommunikation zur HMI nicht genauSO gemacht?.... arrrrrg.
.....ich glaub, ich trink heute Eins...oder Zwei.

P.S. ich wollte es halt mal Objekt orrientiert versuchen.... :-/

Gruß und schönes Wochenende

 

[Larry Laffer]

Eigentlich kann es doch gar nicht sein, dass dein Baustein UND die Visu den gleichen Datenpunkt verändern wollen - und wenn doch dann muß man es halt organisieren ...

Hallo,
so etwas Ähnliches mache ich auch : ein Sammel-FB, der von alle seinen Stationen die Status-Signale einsammelt und daraus Sammelbits erschafft. Dazu gehört u.A. auch so etwas wie Betriebsart.
Ich habe dafür einen Bereich, wo den Stationen Signale aus dem Sammel-FB zur Verfügung gestellt werden und einen anderen Bereich, wo die Stationen dem Sammel-FB Signale zur Verfügung stellen.
Wie du siehst habe ich die Richtungen streng getrennt.
Es gibt aber sicherlich noch andere Wege das Problem zu umgehen.
Deinen Objekt-Gedanken solltest du deshalb jedenfalls nicht verwerfen. Das, was du vorhast, läßt sich m.E. durchaus umsetzen ...

Gruß
Larry

 

[dodi110480]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo, hab das Problem jetzt mehr oder weniger "gelöst". Ich lese vor dem FB die INOUT Variablen in temporäre Variablen ein und benutze die temporären am FB. Jetzt kommts, bitte nicht schlagen. ich schreibe die temporären mittels 1sekündiger Flanke wieder zurück.
Gruß Dominik


Gesendet von meinem iPhone mit Tapatalk

 

[Ralle]

Hallo, hab das Problem jetzt mehr oder weniger "gelöst". Ich lese vor dem FB die INOUT Variablen in temporäre Variablen ein und benutze die temporären am FB. Jetzt kommts, bitte nicht schlagen. ich schreibe die temporären mittels 1sekündiger Flanke wieder zurück.
Gruß Dominik


Gesendet von meinem iPhone mit Tapatalk

Aber ich glaube, damit beseitigst du das Problem nicht komplett, du verringerst nur die Häufigkeit eines "Zurückspringens", weil du nur noch alle 1 Sekunde und nicht alle paar Millisekunden schreibst.
Wenn es nicht stört, dass es alle paar Wochen doch mal passiert ist das ja auch ganz ok.

 

[dodi110480]

Hallo, da hast du natürlich recht aber die Anlage muss am Dienstag raus und wir haben im Moment soviel zu tun das wir neue Sachen nicht im Büro testen können sondern am Objekt selbst. Das ist zwar eher suboptimal aber ich habe mir vorgenommen beim Umstieg auf TIA endlich mal in Richtung ObjektOrientiert zugehen.
Der Vorteil ist, dass wenn mir was besseres einfällt können wir die Anlage updaten (FB raus, FB rein) weil unsere Monteure öfter mal bei diesem Kunden sind.
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.

Gruß
Dominik