Global-DB als Bitcontainer / Merkerersatz.

[rs-plc-aa]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

ich habe heute eine Beobachtung gemacht die mich ziemlich ins Grübeln bringt.

Ich habe ein Programm komplett neu strukturiert so daß alle mehr als ein mal benötigten Bausteine mit einer Schnittstelle versehen worden sind - also multiinstanzfähig.

Das was vorher Merkerbits übernahmen ist jetzt alles in DBs gewandert - d.h. jede Instanz hat zusätzlich einen Global-DB in dem alle Bits untergebracht sind und deren Zustände nur für die jeweilige Instanz zur verfügung stehen (sollten).

Ich schreibe deshalb in Klammern "sollten" weil jetzt mein Problem kommt:

(Nummern und Nämen nehme ich jetzt mal frei schnauze...)

Im FB 1 wird an OUT ein Bit #Anforderung gesetzt.

Das Bit #Anforderung wird beim Aufruf des FB 1 dem DB 100.DBX0.0 zugewiesen.

Jetzt wird anschließend FC 10 aufgerufen - diese hat an IN das Bit #Anforderung ebenfalls DB100.DBX0.0 zugewiesen bekommen.

Kurzum - ich möchte im FB 1 bestimmen ob im FC 10 etwas passiert oder nicht...

Jetzt habe ich aber folgendes Phaenomaen (korrekt?) daß im FB 1 das Bit an der Schnittstelle (Beobachtet im OB1) eine 1 führt allerdings wenn ich den DB100 beobachte nicht...
Genausowenig kommt an der FC 10 das Bit mit 1 an sondern immer mit 0

Verdacht 1: Es wird zurückgesetzt bevor FC 10 an der reihe ist -> möglich, aber nicht von mir

Verdacht 2: Wenn nicht von mir dann vielleicht von der CPU ?

Kann es sein daß wenn der selbe Speicherbereich in dem auch das Bit ist an einem anderen Baustein als IN_OUT deklariert ist - z.B. DB100.DBD0 - und wenn der andere Baustein diesen Bereich momentan nicht verwendet hat weil z.B.:
...

// Netzwerk 1
UN  #Ich_werde_benoetigt
BEB

... es möglich ist daß - warum auch immer der Bereich gelöscht wird ?

Oder muß hierfür (mehrfach verwendet) dann generell der IN_OUT Bereich für alle Deklarationen gewählt werden ?

Vorher war das so daß im FB 1 der Merker "Anforderung" gesetzt wurde und dieser dann in FC 10 auch immer noch da war - und es wurde teilweise auch das ganze Merker-DW anderweitig verarbeitet - z.B. Initialschritt - das komplette DW löschen = alle Bits gelöscht usw.

Was ist jetzt anders bzw. wo könnte der Hund begraben liegen ?

 

[volker]

antwort war flasch. gelöscht.

sollte gehen

 

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo RM,
dein Problem hört sich interessant an und ich habe da auch schon einen Verdacht ... Bevor ich da aber etwas sage, hätte ich schon gern ein paar mehr Info's zu deinem Programm - ich muss nämlich gestehen, dass ich durch deine Beschreibung - wenn auch sehr ausführlich - nicht so richtig durchgestiegen bin ...

Also : in dem Programm word im OB1 erst der FB1 und dann der FC10 aufgerufen ? Der FB1 generiert das Bit und der FC10 ist der einzige Interessent ? Wenn ja - was macht der FC10 ansonsten mit dem Bit ?

Bis dahin
Gruß
Ralf

 

[RaiKa]

Verwende doch mal im FB1 an Stelle von OUT den Typ INOUT.
Wenn bei OUT dem DB nicht permanent ein Wert zugewiesen wird, wird dem DB der Wert NULL übergeben.
Oder habe ich das Problem falsch verstanden?

Gruß
raika

 

[rs-plc-aa]

Hallo,
danke Volker - aber das kanns glaube ich nicht sein.

Der DB100 ist kein Instanzdatenbaustein.

Ein wenig ausführlicher:

Unter Instanzen meinte ich gewisse Programmteile die die selbe Struktur aber ganz unterschiedliche Zustände haben können.

Beispiel:

Maschine1 benötigt eine Skalierung, ein Hauptprogramm, eine Überwachung und sonst noch so´n Zeugs...

Maschine 2-4 aber auch...

Also habe ich das so strukturiert daß es nur eine Skalierung, ein Hauptprogramm usw. gibt.

Es werden dann am jeweiligen Baustein beim Aufruf (im Falle von FBs natürlich auch mir separatem DI) die Parameter für die jeweiligen Maschinen zugewiesen wie Messwerte Bits usw.

Die Bits (was vorher Merker waren) habe ich nun für jede Maschine separat in DBs strukturiert - also vergleichbar mit MD0 für Maschine1, MD4 für M2 usw...

Nur daß der Vorteil der DBs eben der ist daß der symbolische Name in jedem DB gleich sein darf da sich die DBs untereinander nur noch mit ihrer Nummer unterscheiden (was in der Symboltabelle so nicht ginge...).

Somit stelle ich in den DBs bausteinweit für jede Maschine (in diesem Sinne also irgendwie auch Instanz) getrennt die Bits zur Verfügung die natürlich auch in verschiedenen Baustein interessant sind.

Das Problem ist nur daß es einmal ein Eingangs- ein anderes mal ein Ausgangs- und ebensogut ein Durchgangsparameter sein kann - je nach dem was in dem Baustein passiert...

Ich hoffe das ist so weit verständlich.

 

[rs-plc-aa]

Zuviel Werbung?
-> Hier kostenlos registrieren

Verwende doch mal im FB1 an Stelle von OUT den Typ INOUT.
Wenn bei OUT dem DB nicht permanent ein Wert zugewiesen wird, wird dem DB der Wert NULL übergeben.
Oder habe ich das Problem falsch verstanden?

Gruß
raika

Das war ja im Einganspost mein Verdacht 2...

Sorry ich habe meine vorherige Antwort geschrieben und deine erst danach bemerkt...

Wenn es so ist daß wenn "bei OUT dem DB nicht permanent ein Wert zugewiesen wird, dem DB der Wert NULL übergeben wird" -
dann würde ich natürlich gern wissen warum - oder zumindest woher du die Info hast ?

Das würde zumindest plausibel zu meinem Problem passen...

 

[volker]

bis auf die sache mit dem inout (was raika oben erwähnt hat) sehe ich eigentlich keine probs.

poste mal einen codeauszug

 

[RaiKa]

Eine lokale variable hat von Haus aus den Wert Null. Wenn du ihr nach dem Bausteinaufruf nichts zuweist, behält sie den Wert Null - oder einen rein zufällig anderen. Diesen gibst Du dann dem Datenbaustein.
Eine INOUT-Variable dagegen wird ja von Aufruf zu Aufruf gespeichert (durch dich selbst).
Oder Du verwendest im FB eine Variable vom Typ STATISCH, die wird dann im InstanzDB automatisch gespeichert und steht beim nächsten Aufruf des FB wieder mit dem gespeicherten Wert zur Verfügung.

Gruß
raika

 

[rs-plc-aa]

Zuviel Werbung?
-> Hier kostenlos registrieren

bis auf die sache mit dem inout (was raika oben erwähnt hat) sehe ich eigentlich keine probs.

Na wenn das keins ist !

Was möchtest du für Code sehen ?

In den FBs/FCs gibts nur Formaloperanden und der OB1 hat auf A4 Papier wahrscheinlich 20 Seiten... edit: (Nur AWL - kein KOP/FUP!)

Im OB1 werden an den Schnittstellen die tatsächlichen Operanden zugewiesen - und logische Fehler (z.B. FB1 OUT= DBX0.0 und FC10 IN= DBX0.1) hab ich schon gesucht wie verrückt - Fehlanzeige.

 

[Larry Laffer]

Hallo RS,
das war auch mein Verdacht.
Wenn der Symbolische Ausgang OUT deines FB's mit "S" und "R" und nicht mit "=" zugewiesen wird und in dem Baustein das betreffende Netzwerk entweder übersprungen oder das VKE kein "S" oder "R"v ermöglicht, dann ist OUT in irgendeinem Zustand (zufällig) - so jedenfalls meine Erfahrung mit dem Thema. Der Vorschlag von Raika würde das Problem umgehen, da du ja den alten Zustand wieder in den Baustein mit reinbringst ...

 

[Kai]

Wenn der Symbolische Ausgang OUT deines FB's mit "S" und "R" und nicht mit "=" zugewiesen wird und in dem Baustein das betreffende Netzwerk entweder übersprungen oder das VKE kein "S" oder "R"v ermöglicht, dann ist OUT in irgendeinem Zustand (zufällig) - so jedenfalls meine Erfahrung mit dem Thema.

Wir hatten schon einmal eine ähnliche Diskussion:

http://support.automation.siemens.c...cslib.csinfo&lang=de&objid=189227&caller=view

http://www.sps-forum.de/showthread.php?t=12193

Gruß Kai

 

[rs-plc-aa]

Zuviel Werbung?
-> Hier kostenlos registrieren

Sorry Raika - wir haben uns wieder "überschnitten"...

Das setze ich gleich mal so um - denn das ist ja genau das was ich benötige...

Der STAT ist mir auch bekannt und ich verwende ihn auch in der Skalierung z.B.

Hier werden alle Peripheriewerte normiert und im DI eingebettet - auf diese kann ich dann von überall aus zugreifen.

Das mit den Bits ist aber ja anders da sie keinem speziellen Baustein sondern einer übergreifenden Sturktur (Maschine1,2,...) zugeordnet sind - daher ein global-DB für jede Struktur...

Ausserdem generiere ich die global-DBs mit Excel 100mal schneller als im DB-Editor

Ich werde das mal umsetzen und das Ergebnis hier posten...

Oh ich sehe gerade es sind noch mehr Antworten eingetroffen...
Diese untermauern das eigentlich nur noch.

Riesen Dank an alle !

 

[Ralle]

Der STAT ist mir auch bekannt und ich verwende ihn auch in der Skalierung z.B.

Hier werden alle Peripheriewerte normiert und im DI eingebettet - auf diese kann ich dann von überall aus zugreifen.

Die Frage ist mal abseits von deinem Problem.
Meinst du im Instanz-DB mit DI und greifst du dann mit anderen FB/FC auf diesen fremden Instanz-DB zu? Dann ist dir sicher klar, daß kaum jemand anderes als du später in der Lage sein wird, herauszufinden, wo welche Daten wirklich manipuliert werden.

Daten, die von anderen Programmteilen benötigt werden sollten immer in einem globalen DB landen, das ist, vor allem nach 2 Jahren, wesentlich übersichtlicher.

 

[zotos]

Die Frage ist mal abseits von deinem Problem.
Meinst du im Instanz-DB mit DI und greifst du dann mit anderen FB/FC auf diesen fremden Instanz-DB zu? Dann ist dir sicher klar, daß kaum jemand anderes als du später in der Lage sein wird, herauszufinden, wo welche Daten wirklich manipuliert werden.

100% ACK

Sowas ist ganz dolle böser scheiß!

 

[rs-plc-aa]

Zuviel Werbung?
-> Hier kostenlos registrieren

Das mit dem Instanz-DB und dem darauf zugreifen ist ja auch nicht die Regel - und nur lesende Zugriffe.

Was spricht dagegen wenn ein FB "Skalierung" heißt und einen dementsprechenden STAT-Bereich hat die skalierten Werte dort zu lassen und die anderen Bausteine die z.B. nur eine Temperatur daraus benötigen sich diese dort abholen ?

Sonst wäre ja das Gegenteil der fall - ich nehme statt einem FB eine FC und speichere bei jedem Durchlauf die OUT (=skalierten Werte) in einem globalen DB -> da kann man´s ja auch so machen da bei jedem Durchlauf jeder Ausgang neu geschrieben wird (hab´s jetzt ja schon kapiert).

Ich kann ja die jeweiligen Instanz-DBs nach Ihrem Inhalt benennen z.B. Messwerte_M1, M2...

Das ist doch genauso übersichtlich oder ?
Oder ist das so was wie ein "ungeschriebenes Gesetz" ?


Eine Zusatzfrage zu diesem Thema hätte ich aber da dann noch:

F: Was passiert mit den IN-Parametern wenn diese in jenem Durchlauf nicht verwendet werden ?

Die Antwort liegt zwar auf der Hand aber wenn jemand noch den ACK-Button drücken würde wäre ich 100% sicher.

A: Auf die Daten wird nur lesend zugegriffen, eine ungewollte Manipulation ist unter KEINEN Umständen möglich! - richtig?

Nur so... falls es doch die berühmte Ausnahme der Regel geben sollte bitte Bescheid geben

 

[zotos]

Das mit dem Instanz-DB und dem darauf zugreifen ist ja auch nicht die Regel - und nur lesende Zugriffe.

Was spricht dagegen wenn ein FB "Skalierung" heißt und einen dementsprechenden STAT-Bereich hat die skalierten Werte dort zu lassen und die anderen Bausteine die z.B. nur eine Temperatur daraus benötigen sich diese dort abholen ?

Sonst wäre ja das Gegenteil der fall - ich nehme statt einem FB eine FC und speichere bei jedem Durchlauf die OUT (=skalierten Werte) in einem globalen DB -> da kann man´s ja auch so machen da bei jedem Durchlauf jeder Ausgang neu geschrieben wird (hab´s jetzt ja schon kapiert).

Ich kann ja die jeweiligen Instanz-DBs nach Ihrem Inhalt benennen z.B. Messwerte_M1, M2...

Das ist doch genauso übersichtlich oder ?
Oder ist das so was wie ein "ungeschriebenes Gesetz" ?


Eine Zusatzfrage zu diesem Thema hätte ich aber da dann noch:

F: Was passiert mit den IN-Parametern wenn diese in jenem Durchlauf nicht verwendet werden ?

Die Antwort liegt zwar auf der Hand aber wenn jemand noch den ACK-Button drücken würde wäre ich 100% sicher.

A: Auf die Daten wird nur lesend zugegriffen, eine ungewollte Manipulation ist unter KEINEN Umständen möglich! - richtig?

Nur so... falls es doch die berühmte Ausnahme der Regel geben sollte bitte Bescheid geben

Also im Unterschied zu einer Function hat ein Functionblock lokalen (->private) statischen Variablen. Bei Funktionen ist darauf zu achten das man die Schnittstellen immer klar und sauber hält. So wie ich das nun lese sparst Du aus irgendeinem Grund an OUT Variablen (warum?).
Ein ein Querzugrif auf lokale Variablen ist schlechter Programmierstil.

 

[Onkel Dagobert]

Hallo rs-plc-aa,

..Was spricht dagegen wenn ein FB "Skalierung" heißt und einen dementsprechenden STAT-Bereich hat die skalierten Werte dort zu lassen und die anderen Bausteine die z.B. nur eine Temperatur daraus benötigen sich diese dort abholen ?..

Wenn der FB z.Bsp. als Multiinstanz verwendet wird, seine Instanzdaten also in einem übergeordneten DI stehen, können sich die Adressen der Instanzdaten bei Änderungen verschieben. Falls dann die absolute Adressierung Vorrang hat, wird's kritisch. Die "querlesenden" Bausteine bekommen dann falsche Werte. So etwas darf man ganz einfach nicht machen!

Zu deinem Problem. Schreibe doch mal in den OB1 nach jedem Bausteinaufruf:

U DB 100.DBX0.0
= #TEMP // temp. bit oder Merker

um zu prüfen, nach welchem Baustein das Bit zurückgesetzt ist. So kannst du die Fehlerstelle erst mal eingrenzen. Ich vermute, die Ursache liegt hier woanders, nicht bei OUT oder IN_OUT.


Gruß, Onkel

 

[rs-plc-aa]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ein ein Querzugrif auf lokale Variablen ist schlechter Programmierstil.

Das war die Frage ob es so etwas wie ein ungeschriebenes Gesetz ist...

Denn von der Funktionalität her ist es ja das selbe.

Ich schrieb auch dass ich das nicht generell so mache daher habe ich ein Beispiel genannt...

Wie gesagt ich hatte mir jetzt nichts schlimmes dabei gedacht die Messwerte einer Instanz in dessen IDB bereitzustellen da dieser IDB den selben Symbolischen Namen bekommen kann wie es der GDB auch bekommen würde. (auf die Auffindbarkeit bezogen)

Oder habe ich einen weiteren Nachteil noch gar nicht erkannt ?

BTW:
Könnte noch jemand den ACK-Button zu meiner Frage bzgl. den IN-Parametern drücken ?

 

[Onkel Dagobert]

F: Was passiert mit den IN-Parametern wenn diese in jenem Durchlauf nicht verwendet werden ?
A: Die Antwort liegt zwar auf der Hand aber wenn jemand noch den ACK-Button drücken würde wäre ich 100% sicher.
<ACK>

F: Auf die Daten wird nur lesend zugegriffen, eine ungewollte Manipulation ist unter KEINEN Umständen möglich!
A: - richtig? - Die Daten werden beim Lesen nicht verändert.
<ACK>

 

[rs-plc-aa]

Wenn der FB z.Bsp. als Multiinstanz verwendet wird, seine Instanzdaten also in einem übergeordneten DI stehen, können sich die Adressen der Instanzdaten bei Änderungen verschieben. Falls dann die absolute Adressierung Vorrang hat, wird's kritisch. Die "querlesenden" Bausteine bekommen dann falsche Werte. So etwas darf man ganz einfach nicht machen!

Ja Ja - wer ist da nicht schon mal drübergestolpert ?



Hierzu gibt es wohl auch keine Einstellung die die "richtige" ist...

Das was ich bisher darüber gelesen habe reicht zumindest nicht aus um mich endlich mal für eine festzulegen.

Zu deinem Problem. Schreibe doch mal in den OB1 nach jedem Bausteinaufruf:

U DB 100.DBX0.0
= #TEMP // temp. bit oder Merker

Das wird dann der nächste Schritt sein -> wobei ich hoffe daß dieser dann nicht mehr benötigt wird...

Das mit der IN_OUT Geschichte passt zumindest so gut zu meiner Problematik da es sich um Bits handelt die nicht in jedem Durchlauf angefasst werden (eine art Schrittkette in AWL) - da sollte der Zustand bis zur nächsten Behandlung natürlich bestand haben und nicht einfach gelöscht werden.