Global-DB als Bitcontainer / Merkerersatz.

[rs-plc-aa]

Zuviel Werbung?
-> Hier kostenlos registrieren

antwort war flasch. gelöscht.

sollte gehen

@volker: Ich hab grade gesehen daß du den Beitrag editiert hast...

Erklär mal bitte wie du zu der Zuweisung von #fb_ausgang im OB1 kommst.

Mit vorangestellter Raute müsstest du das ja im OB1 TEMP (was anderes hat er ja nicht) abgelegt haben.

Was soll das bringen ? Ausserdem gibts mit deinem FB1 das Problem sowieso nicht da:

SET
= #fb_ausgang

bei jedem Aufruf passiert -> der OUT wird also immer erneuert (im Gegensatz zu meinem Fall wo das Bit im DB über die Aufrufe hinweg plötzlich seinen Zustand vergessen hat)

@all:

Nochmal nachgefragt:

Wie verhalten sich dann verknüpfte digitale (oder auch analoge) ausgänge wenn der OUT direkt der Peripherieadresse zugewiesen wird und in einem Durchlauf kein Schreibzugriff war ?

Fällt der Ausgang dann auch ab / verliert seinen Wert oder ist das dort anders ?

O.K. bei analogen Ausgängen sollte immer aktualisiert werden aber auch da kanns Ausnahmen geben wenn ich z.B. einem Stellventil während einer Standby-Phase einen Festwert zuweisen möchte und erst nach beendigung der Standby-Phase wieder ins Geschehen eingreife...

 

[Ralle]

FC - ein Out muß immer (jeden Zyklus) beschrieben werden, sonst ist er unbestimmt und kann sich ändern

FB - ein Out ist im zugehörigen Instanz-DB hinterlegt und muß nicht in jedem Durchlauf beschrieben werden, beim ersten FB-Aufruf ohne Zuweisung der Out bekommt der Out den Wert aus dem DB

 

[rs-plc-aa]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ok, ich glaube daß ich (mit eurer Hilfe) den Hund gefunden habe.

Der Umbau der Schnittstellen damit OUTs die nicht jedes mal aktualisiert werden zu IN_OUTs wurden hat leider nur einen Teilerfolg gebracht - ging aber auf jeden fall in die richtige Richtung.

Mein zusatz-Problem kann ich dafür jetzt ziemlich klar definieren:

Die Bits die an der IN_OUT definiert sind dienen zur Programmsteuerung bzw. zum Handshake einzelner, miteinander arbeitenden Bausteine (je nach Zustand im Baustein A wird B benötigt oder nicht...).

So weit so gut, klappt auch prinzipiell nur jetzt gibt es so was wie error-handlers die die gute Zustandsmaschine auch mal im Notfall aus Ihrer Kette rausreist und Sicherheit herstellt.

Da das an ziemlich vielen Stellen passieren kann hab ich - wenn alle Fehlerbehandlungen abgearbeitet sind ein Auffangbecken (IZ "Gesperrt") aus dem es dann erst wieder herausgeht wenn eine Reihe von Bedingungen erfüllt sind. Nach dem Entsperren sollte nun folgendes passieren: Initialisierung -> dazu gehört dann auch die ganze Batterie von Bits zurückzusetzen um wieder in einem definierten Grundzustand loszulegen.

Wie ich das jetzt sehe bleibt mir momentan nichts anderes übrig als mit lauter R-Befehlen Bit für Bit rückzusetzen weil die Bits keine Merker sind sondern über IN_OUT an einen DB gefesselt sind.

Versuche die ganzen Daten(doppel-)wörter mit NULL zu überschreiben gingen bis jetzt nicht da am Ende des FB der aktuelle Zustand der Bits (welche daduch ja unbeeinflusst bleiben) wieder in den DB zurückgegeben wird und quasi das löschen rückgängig macht. Dies belegt ein Test bei dem ich das Löschen testweise vor dem FB call im OB1 platzierte -> Ergebnis: löschen erfolgreich, DB-Bereich mit NULL an FB übergeben und mit NULL wieder rausgekommen (nur die Bits waren wieder gesetzt welche auch wirklich gerade aktiv waren - also alles gut).

Und jetzt ? Eigentlich halb so schlimm, andererseits eine Katastrophe.

Wenn ich die DB-Struktur in einen freien Merkeradressbereich gepackt hätte wäre es gegangen oder nicht ? Hier zweifle ich langsam auch schon da ich diese ja ebenfalls über IN_OUT "ankoppeln" müsste...

Ich glaube die Vorgehensweise selbst lässt das was ich will einfach nicht zu...

Da fällt mir aber gerade eine mögliche Lösung ein:

Wenn ich jetzt die komplette Struktur der DBs für eine Maschine in einen Merkeradressbereich "spiegele" und diesen dann starr für alle Instanzen fest in den Bausteinen dierkt adressiert (wie es seither ja funktionierte) verankere dann muss ich halt am Beginn der Maschine bevor der erste Baustein davon aufgerufen wird die DB Inhalte als Blöcke in den Merkerbereich kopieren und nach dem letzten Baustein (vor dem ersten der nächsten Maschine) in die DBs für den nächsten Zyklus zurücksichern usw...

Mag vielleicht auch umständlich sein aber da wäre ich jetzt sicher daß es so funktioniert. Hat eben den Nachteil daß bei Änderungen beide Listen abgeglichen werden müssen (DBs und Merker).

 

[rs-plc-aa]

Hallo, da das Problem ja nun bekannt ist ist es einfacher über Lösungen nachzudenken...

Eine weitere hätte ich so grob als Gedanke gefasst weiß aber noch nicht ob es funktionieren würde.

Ist es möglich ein ARRAY of BOOL anzulegen, dort die Struktur der Bits reinsetzen und dann die Bits innerhalb des Arrays einzeln aber auch Teile des Arrays gesamt anzusprechen ?

Da ich noch nichts mit Arrays zu tun hatte bräuchte ich da ein wenig Hilfe.

Ansonsten bleibt nichts anderes (aus meiner Sicht jetzt zumindest) als die Variante mit den Merkern die ich zuvor nannte.

Hier kann ich ja sowohl die Bits als auch bis zu DWs davon ansprechen, und die Änderungen werden sofort wirksam (wenn sie nicht in der Schnittstelle liegen sondern direkt adressiert sind).

Hat jemand einen Tip zu den Arrays ? - Würde das gehen ?

 

[Larry Laffer]

Hallo,
ich habe dein Problem sporadisch immer mal so mit-verfolgt ...
Wenn ich es richtig verstanden habe, dann resultiert dein Problem daraus, dass du sowohl ein Datenwort wie auch ein (oder mehere) Bits daraus als IN_OUT Pararmeter deines FB's verwendest.
Das gibt die Steuerung (wie auch jedes andere Programmiersystem (Hochsprache o.ä.)) nicht her. In der Praxis solltest du ja auch nicht mit zwei wiedersprüchlichen Befehlsgebern arbeiten. Eine Alternative, die ich sehe ist, dass du das Datenwort und deine Bitmaske zusammen-ODERst.
Das geht aber nur, wenn du mit zwei verschiedenen Variablen arbeitest, womit du wieder beim Kern der Sache bist ...

Ein ARRAY of BOOL ist nur eine andere Darstellungsform der gleichen Thematik. Du verwendest immer noch die gleichen Variablen, nennst sie bloss anders ...

Gruß ...

 

[rs-plc-aa]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ja gut ok...

Ich habe ja jetzt verschiedene Ansätze, die zwar keine Wunschlösung sind aber vielleicht in Kombination für den jeweiligen Fall in Frage kommen.

Jetzt muß ich halt genau abwägen wann + wo ich was einsetze...

Das Ergebnis folgt...

@Larry Laffer: eine Ausnahme gibt es schon -> direkte Adressierung !

Wenn ich z.B.:

SET
S M0.0
S M0.3
...
 
L 0
T MW0
...
U M0.0 // Ist False und nicht True !

 

[Larry Laffer]

Da hast du recht. Ich bezog meine Antwort aber auf das aktuelle Problem mit den IN_OUT's (Übergabe-Parametern) ...

 

[rs-plc-aa]

Hey Larry, das war auch nicht besserwisserisch gemeint sondern entspricht dem wie meine Bausteine vorher arbeiteten und jetzt habe ich eben das Los gezogen und muss alles Umbauen daß sie fit für einen Mehfachstart sind - > alles einfach nur in die Schnittstellen zu verteilen reichte eben doch nicht (wie man sieht) weil sich manches ganz anders verhält als man erwartet. Das ist ja auch die Kernaussage des Threads "Global-DB als Bitcontainer / Merkerersatz"...

Es fing ja an mit den OUTs die plötzlich weg waren wenn sie nicht jedes mal neu beschrieben werden, und dann die IN_OUTs die zwar einem DB zugeordnet sein können aber wenn sie nicht explizit im Baustein geändert werden wirkt sich die indirekte Änderung des DBs im Bautein nicht mal zur Laufzeit des Bausteins aus...

Dabei wäre es doch so einfach: es feht IMHO nur ein Befehl der das ermöglichen würde: -->> "Aktualisieren" oder auch F5 genannt...

Wenn ich jetzt im Code den DB mit NULL überschreibe und direkt danach die IN_OUT Schnittstelle neu einlesen könnte, dann wären ab dem Zeitpunkt alle betroffen Bits genullt.

Nein statt dessen wird am Ende des Bausteins das Abbild in den DB zurückgeschrieben und alles ist versemmelt.

Klar ist das meine Schuld - das weiß man doch daß das nicht geht - > denkste, woher denn wenn im Handbuch das nicht so ausdrücklich steht, und selbst Siemens das nachträglich in einen FAQ gesetzt hat (und die kommen ja auch erst raus wenn eine gewisse Menge gleicher Anfragen aufgelaufen sind...)

Also in diesem Sinne, frohes Programmieren noch !

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
habe ich auch nicht besserwisserisch verstanden ...

Ich kann deinen Ansatz beim Programmieren gut verstehen. Auch ich schlage mich sehr oft mit Optimierungen und -Ideen herum. Oftmals ist es so, dass nicht die erste Idee zum Erfolg führt.

Grüße und weiterhin viel Erfolg ...

 

[rs-plc-aa]

Grüße und weiterhin viel Erfolg ...

Danke dir, kann ich brauchen !

Ich glaube ich werde es jetzt so machen daß ich die Schnittstelle in logische Gruppen aufteile (wenn es nicht glatt aufgeht eben dummys dazwischen) und lösche das auf die DI-Adresse bezogen.

Der riesen Nachteil ist halt der daß wenn die Schnittstelle geändert wird sich das Ganze wieder verschiebt und die Verknüpfungen angepasst werden müssen.

Aber so lange das nicht der Fall ist sollte es so wenigstens funktionieren, und später kann ich das ja noch mal aufgreifen.

Es würde auch gehen die DBs in den Lokaldaten zwischenzuspeichern - da will ich es aber nicht auf den Versuch ankommen lassen daß der Speicher überläuft wenn mal ne kleinere CPU für nur eine Instanz verwendet werden sollte (sind derzeit 384 Bits) - und der Code müsste komplett geändert werden - so sind es nur wenige Stellen...