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

Seite 2 von 3 ErsteErste 123 LetzteLetzte
Ergebnis 11 bis 20 von 30

Thema: Global-DB als Bitcontainer / Merkerersatz.

  1. #11
    Registriert seit
    30.03.2005
    Beiträge
    2.096
    Danke
    0
    Erhielt 673 Danke für 541 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von Larry Laffer Beitrag anzeigen
    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.co...27&caller=view

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

    Gruß Kai

  2. #12
    Avatar von rs-plc-aa
    rs-plc-aa ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    07.11.2004
    Beiträge
    697
    Danke
    69
    Erhielt 64 Danke für 48 Beiträge

    Standard

    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 !
    RS (rs-plc-aa)
    ______________________________________________
    Morgen ist Heute Gestern...
    ______________________________________________
    Installierst du noch - oder Arbeitest du schon ?
    ______________________________________________

  3. #13
    Registriert seit
    27.05.2004
    Ort
    Thüringen/Berlin
    Beiträge
    12.227
    Danke
    534
    Erhielt 2.698 Danke für 1.950 Beiträge

    Standard

    Zitat Zitat von rs-plc-aa Beitrag anzeigen
    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.
    Gruß
    Ralle

    ... there\'re 10 kinds of people ... those who understand binaries and those who don\'t …
    and the third kinds of people … those who love TIA-Portal

  4. Folgender Benutzer sagt Danke zu Ralle für den nützlichen Beitrag:

    zotos (29.03.2007)

  5. #14
    Registriert seit
    07.03.2004
    Beiträge
    4.369
    Danke
    946
    Erhielt 1.158 Danke für 831 Beiträge

    Standard

    Zitat Zitat von Ralle Beitrag anzeigen
    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ß!
    If you open your Mind too much, your Brain will fall out.

  6. #15
    Avatar von rs-plc-aa
    rs-plc-aa ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    07.11.2004
    Beiträge
    697
    Danke
    69
    Erhielt 64 Danke für 48 Beiträge

    Standard

    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
    RS (rs-plc-aa)
    ______________________________________________
    Morgen ist Heute Gestern...
    ______________________________________________
    Installierst du noch - oder Arbeitest du schon ?
    ______________________________________________

  7. #16
    Registriert seit
    07.03.2004
    Beiträge
    4.369
    Danke
    946
    Erhielt 1.158 Danke für 831 Beiträge

    Standard

    Zitat Zitat von rs-plc-aa Beitrag anzeigen
    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.
    If you open your Mind too much, your Brain will fall out.

  8. #17
    Registriert seit
    06.10.2003
    Beiträge
    3.414
    Danke
    451
    Erhielt 506 Danke für 408 Beiträge

    Standard

    Hallo rs-plc-aa,

    Zitat Zitat von rs-plc-aa Beitrag anzeigen
    ..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
    Es gibt viel mehr Leute, die freiwillig aufgeben, als solche, die echt scheitern.
    Henry Ford

  9. #18
    Avatar von rs-plc-aa
    rs-plc-aa ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    07.11.2004
    Beiträge
    697
    Danke
    69
    Erhielt 64 Danke für 48 Beiträge

    Standard

    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 ?
    RS (rs-plc-aa)
    ______________________________________________
    Morgen ist Heute Gestern...
    ______________________________________________
    Installierst du noch - oder Arbeitest du schon ?
    ______________________________________________

  10. #19
    Registriert seit
    06.10.2003
    Beiträge
    3.414
    Danke
    451
    Erhielt 506 Danke für 408 Beiträge

    Standard

    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>
    Es gibt viel mehr Leute, die freiwillig aufgeben, als solche, die echt scheitern.
    Henry Ford

  11. Folgender Benutzer sagt Danke zu Onkel Dagobert für den nützlichen Beitrag:

    rs-plc-aa (29.03.2007)

  12. #20
    Avatar von rs-plc-aa
    rs-plc-aa ist offline Erfahrener Benutzer
    Themenstarter
    Registriert seit
    07.11.2004
    Beiträge
    697
    Danke
    69
    Erhielt 64 Danke für 48 Beiträge

    Standard


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

    OperandenVorrang.png

    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.
    RS (rs-plc-aa)
    ______________________________________________
    Morgen ist Heute Gestern...
    ______________________________________________
    Installierst du noch - oder Arbeitest du schon ?
    ______________________________________________

Ähnliche Themen

  1. global db Anfangswert->Aktualwert??
    Von beavis im Forum Simatic
    Antworten: 2
    Letzter Beitrag: 11.02.2010, 13:10
  2. Global Drive Oszilloskopfunktion
    Von _loki_ im Forum Antriebstechnik
    Antworten: 2
    Letzter Beitrag: 18.09.2009, 13:20
  3. Darstellungsart in Global-DB's
    Von Diesla im Forum Simatic
    Antworten: 3
    Letzter Beitrag: 12.04.2009, 09:55
  4. Global und Instanz DBs ?
    Von Insane im Forum Simatic
    Antworten: 22
    Letzter Beitrag: 07.01.2009, 13:27
  5. Global-DB vs. Instanz-DB
    Von b0den im Forum Simatic
    Antworten: 4
    Letzter Beitrag: 16.06.2008, 13:17

Lesezeichen

Berechtigungen

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