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

Ergebnis 1 bis 8 von 8

Thema: [ Newbie ] Symboltabelle, Datenbaustein und Rezepturassisten

  1. #1
    Anonymous Gast

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hallo;

    Ich setze im Moment ein kleines Projekt mit einer S7-200 mit Step 7-Mirco/Win um. Drei Dinge die ich gerne tun würde werden mir aber untersagt:

    1) Einzelne Bits in der Symboltabelle mit einem symbolischen Namen versehen.

    2) Einem DWORT eine indirekte Adresse im Datenbaustein zuweisen.

    3) Im Rezepturasisstenten BitVariable in den Rezeopten auch wirklich als Bits speichern lassen. Der Assistent lässt mich zwar BitVariable anlegen speichert dann aber immer ein ganzes Byte.

    Hat das einen besonderen Grund warum obige Funktionalität nicht bereitgestellt wird? Wenn das nämlich wirklich nicht unterstützt wirt, so sind das eklatante Versäumnisse, die die jeweiligen Konzepte mehr ooder minder unbrauchbar machen. Dann brauche ich auch andere Variable nicht mit symbolischen Namen versehen, bzw. bei eine so ineffizienten Speicherausnutzung (Speichermodul hat ja nur 64K) brauche ich keinen Rezepturassistenten. Da programmier ich das lieber allein. Ach ich vergass: Geht ja auch nicht. Gibt ja keine Funktion zu schreiben und lesen in den Speicherbaustein. Die werden ja erst über den Assistenten erzeugt

    Oder hab ich da was übersehen?
    Zitieren Zitieren Gelöst: [ Newbie ] Symboltabelle, Datenbaustein und Rezepturassisten  

  2. "Das ist alles leider keine Alternative für mich, da der Kunde für den ich das programmiere sehr enge preisliche Vorstellungen hat. Der will nachher mehrere Dutzend der Steuerungen im Monat verbauen. Da machen 100 EUR - 200 EUR Aufpreis eine Menge aus.Eine 256k EPROM ist einfach wesentlich teurer. Und auch eine S-300 Modell würde preislich noch mal was draufschlagen. Ursprünglich solte ja auch als OP das OP77A, was nach Siemens Angaben softwarekompatibel zum OP77B sein soll, eingesetzt werden. Es ist nicht kompatibel. Beim OP77A fehlen diverse Funktionen in WinCC, die für das OP77B vorhanden sind. Da zum Entwickeln das OP77B zur Verfügung gestellt wurde lief das ganze nacher nicht mehr auf der A-Variante. Um das Projekt nicht umschreiben zu müssen nehmen wir jetzt das OP77B. Resultat: 80 EUR Aufpreis zum A Modell der eigentlich gar nicht nötig wäre.

    Ich hab halt inzwischen einen echt dicken Hals wegen der Geschichte. Die Hardware reicht von der Leistung doppelt und dreifach. Die IDE's WinCC und Micro/Win stellen einem jedoch nur einen relativ geringen Teil der möglichen Leistung zur Verfügung. Vollkommen grundlos. Warum kann MicroWin nicht aufs ERPROM direkt zugreifen? Der Rezepturassistent generiert doch Funktionen die genau das können. Warum gibt es beim OP77B die Funktion "SetzeBitInVariable" beim OP77A aber nur "SetzeBit"? Klar: Letzteres lässt sich sehr einfach umgehen. Aber die Frage beleibt: Warum wird es dem Entwickler künstlich schwer gemacht. Ich wetter ja eigentlich auch nicht so sehr gegen MicroWin. Mit AWL kann man schon sehr viele tolle Dinge machen. Da ist es halt nur der Rezepturassist. Aber WinCC ist nur KlickiBunti und ein Griff ins ... gewesen. Da sind die Möglichkeiten extrem arg gesetzt. Da hab ich mir nur zwei Dinge gewünscht: Eine Routine zum Setzen eines Pixels und eine zum Abfragen eines beliebigen (also nicht nur f-Tasten) Tastendrucks. Hätte vollkommen gereicht. Alles andere ist eh kam zu gebrauchen, Eines aus vielen Beispielen:

    Das OP77A hat ein Display mit 164x60. Das ist recht knapp bemessen aber mehr als ausreichend. Wie kommt man bei Siemes auf die Idee die als einzig mögliche Schriftart eine mit TTF mit Serifen (WinCCflexible) anzubieten? Die kleinste leserliche Pixelschriftart hat 5x5 Pixel pro Buchstabe. Bei 60 Zeilen kriegt man da gut leserlich so um die 10 Zeilen hin. Mit WinCCFlexible aber nur 5, da unter 8pt die WinCCflexible nicht gut lesbar ist. Warum ist das so? Der Bootloader vom OP77 verwendet doch auch eine serifenlose Schriftart.

    O.k. wie gesagt: Hab schon zu viele graue Haare bekekommen."


  3. #2
    Anonymous Gast

    Standard

    1) Einzelne Bits in der Symboltabelle mit einem symbolischen Namen versehen.

    ANTW: V-Breich nicht. Eingänge/Ausgänge/Merker möglich.

    2) Einem DWORT eine indirekte Adresse im Datenbaustein zuweisen.

    ANTW: nicht direkt als Pointer übergebbar, aber als Wert. (auch bei S7-300 nicht möglich).
    In einem kurzem Programm die Pointer Adresse auslesen und Wert aufschreiben. Alle CPUen gleich. Bits nicht indirekt möglich, minimum ist Byte Auflösung.
    Speicherkennung analog zu ANY-Pointer S7-300 z.b Eingänge 16#81 -> z.b. EB0 = 16#81000000 EB1= 16#81000001

    3) Im Rezepturasisstenten BitVariable in den Rezeopten auch wirklich als Bits speichern lassen. Der Assistent lässt mich zwar BitVariable anlegen speichert dann aber immer ein ganzes Byte.

    ANTW: jede Variable nimmt eigenen Speicher (auch Zeit/Datum stempel)
    Wenn zusammenhängend möglich wäre, muss user explizit trennen wenn aufeinanderfolgende Bits nicht funktionsmässig zusammengehören.

    Abhilfe: Bits per Programm zu einem Byte zusammenführen (kopieren)
    z.b.
    U M0.0 =V0.0
    U E2.0 = V0.1 usw.

  4. #3
    Anonymous Gast

    Standard

    Zitat Zitat von Anonymous
    1) Einzelne Bits in der Symboltabelle mit einem symbolischen Namen versehen.

    ANTW: V-Breich nicht. Eingänge/Ausgänge/Merker möglich.
    Ah ja. Danke Siemens. Brauche natürlich einen Symbolischen Namen für ein Bit im Variablenspeicher.

    2) Einem DWORT eine indirekte Adresse im Datenbaustein zuweisen.

    ANTW: nicht direkt als Pointer übergebbar, aber als Wert. (auch bei S7-300 nicht möglich).
    In einem kurzem Programm die Pointer Adresse auslesen und Wert aufschreiben. Alle CPUen gleich. Bits nicht indirekt möglich, minimum ist Byte Auflösung.
    Speicherkennung analog zu ANY-Pointer S7-300 z.b Eingänge 16#81 -> z.b. EB0 = 16#81000000 EB1= 16#81000001
    Hm, also auch wenn alle CPUs gleich adressieren denke ich das das schlechter Programmierstil ist die Adressen auszulesen. Hab mir jetzt damit beholfen den Pointer im Datenbaustein erst einmal auf 0 zu setzen und in einem initialisiere Unterprogramm, dass nur im ersten Steuerungszyklus aufgerufen wird, die indirekte Adresse zuzuweisen.

    3) Im Rezepturasisstenten BitVariable in den Rezeopten auch wirklich als Bits speichern lassen. Der Assistent lässt mich zwar BitVariable anlegen speichert dann aber immer ein ganzes Byte.

    ANTW: jede Variable nimmt eigenen Speicher (auch Zeit/Datum stempel)
    Wenn zusammenhängend möglich wäre, muss user explizit trennen wenn aufeinanderfolgende Bits nicht funktionsmässig zusammengehören.

    Abhilfe: Bits per Programm zu einem Byte zusammenführen (kopieren)
    z.b.
    U M0.0 =V0.0
    U E2.0 = V0.1 usw.
    Jep, hab die Bits letztendlich zusammengefasst.

    Aber letztendlich find ich den Rezepturassistenten für'n ... . Mit dem hab ich wesentlich mehr Probleme, als das er mir helfen würde. Zum einen arbeitet der extrem ineffizient wenn der keine einzelnen Bits unterstützt und zu anderen ist der viel zu unflexibel. In meiner Anwendung benötige z.B. nicht einfach eine Anzahl n Variable für ein Rezept, sondern ich habe m Blöcke mit jeweils n Variablen. Insgesamt also n*m Variable in einer Größenordnung von ca 500 Variablen, die ich im Rezepturassistenten alle einzeln angeben müsste. Vollkommen schwachsinnig. Ein Block ist bei mir also jetzt ein Rezeptureintrag. Die Steuerung setzt diese Rezepte, die ja eigentlich nur einem Block meines gewünschten GesamtRezeptes ausmachen nach dem laden aus dem Rezepturspeicher im Hauptspeicher zusammen und umgekehrt. Wie gesagt vollkommen blödsinnig. Was mir einfach gereicht hätte wäre wenn ich den BMB Befehl auf dem Rezepturspeicher (Modulspeicher) ausführen könnte, d.h. ganz einfach nur Bytes im Speicher hin und herschieben. Aber nein sowohl das OP77 als auch die S7 200 haben eine absolut schwachsinnige Rezepturverwaltung, die wirklich nur auf einen extrem kleinen Anwendungsbereich einsetzbar ist. Irgendwie werd ich das Gefühl nicht los, dass Siemens einem da bewusst Steine in den Weg legt, damit man ja teurere Geräte kauft, die dan etwas komfortabler zu programmieren sind.

    Entschuldigt meinen Unmut, aber das ist wirklich zum Haare ausreissen wie diese Softwareprodukte WinCC und Micro/Win die mir eigentlich helfen sollten alles nur extrem verkomplizieren.

  5. #4
    Anonymous Gast

    Standard

    Zu Punkt 2) bereits erwähnt dass dieses auch bei S7-300 nicht direkt möglich ist
    Es bleibt nur das vorherige auslesen oder erstellen zur Laufzeit, wobei du Sie ja im DB bereits vorbelegen wolltest

    Zu 3)
    Im Rezepurassistenten definiert man die Struktur nur einmalig für Rezepte mit gleichen Aufbau und gibt unter "Rezeptaktionen" die Anzahl dieser an.
    Ich gehe bei deiner Beschreibung mit den Blöcke davon aus, dass dieses bei dir zutrifft.

    Ein BMB ist nicht möglich da die Rezepte im externen Eprom gespeichert/gelesen werden und dieses asynchron zum laufenden Programm ausgeführt werden.
    Bei S7-300 ist auch kein direkter Zugriff über SFC20 oder Lade/Transferier möglich sonder nur indirekt über ein/auslesend der 80er SFCs.

    Alternativ kannst du dir ein Unterprogramm schreiben mit gleicher Übergabeschnittstelle welches du einen Pointer aus dem V-Bereich zusätzlich mitgiebst und damit den vorhandenen V-Bereich nutzt.
    Falls du aber ein grosses Programm hast bzw. ein 300er Programm in eine 200er quetschen willst, wird der Bereich wahrscheinlich schon anderweitig genutzt.

  6. #5
    Anonymous Gast

    Standard

    Zu Punkt 2) bereits erwähnt dass dieses auch bei S7-300 nicht direkt möglich ist
    Es bleibt nur das vorherige auslesen oder erstellen zur Laufzeit, wobei du Sie ja im DB bereits vorbelegen wolltest

    Zu 3)
    Im Rezepurassistenten definiert man die Struktur nur einmalig für Rezepte mit gleichen Aufbau und gibt unter "Rezeptaktionen" die Anzahl dieser an.
    Ich gehe bei deiner Beschreibung mit den Blöcke davon aus, dass dieses bei dir zutrifft.

    Ein BMB ist nicht möglich da die Rezepte im externen Eprom gespeichert/gelesen werden und dieses asynchron zum laufenden Programm ausgeführt werden.
    Bei S7-300 ist auch kein direkter Zugriff über SFC20 oder Lade/Transferier möglich sonder nur indirekt über ein/auslesend der 80er SFCs.

    Alternativ kannst du dir ein Unterprogramm schreiben mit gleicher Übergabeschnittstelle welches du einen Pointer aus dem V-Bereich zusätzlich mitgiebst und damit den vorhandenen V-Bereich nutzt.
    Falls du aber ein grosses Programm hast bzw. ein 300er Programm in eine 200er quetschen willst, wird der Bereich wahrscheinlich schon anderweitig genutzt.

  7. #6
    Anonymous Gast

    Standard

    Zitat Zitat von Anonymous
    Zu Punkt 2) bereits erwähnt dass dieses auch bei S7-300 nicht direkt möglich ist
    Es bleibt nur das vorherige auslesen oder erstellen zur Laufzeit, wobei du Sie ja im DB bereits vorbelegen wolltest
    Das hatte ich schon richtig verstanden. Finde es eben nur schlechten Programmierstil, da man sich hardwarebhängig macht.Niemand kann garantieren, dass auch alle zukünfitgen Siemens Steuerungen die gleiche Adressierung verwenden werden. Das über eine init-Funktion zu machen halte ich deshalb für wesentlich sauberer programmiert.

    Zu 3)
    Im Rezepurassistenten definiert man die Struktur nur einmalig für Rezepte mit gleichen Aufbau und gibt unter "Rezeptaktionen" die Anzahl dieser an.
    Ich gehe bei deiner Beschreibung mit den Blöcke davon aus, dass dieses bei dir zutrifft.
    Nein es trifft eben nicht zu. Ich habe pro Rezept mehrere hundert Variable die ich speichern muss. Die im Rezepturassistenten per Hand anlegen zu müssen ist einfach nur blödsinnig. Der zweite und eigentlich noch wichtigere Punkt aber ist: Ein Rezept besteht bei mir aus einer unbestimmten Anzahl Blöcken, Ich habe keine Rezepte mit fixer Größe. Die Größe variiert von Rezept zu Rezept. Das eine besteht aus 5 Blöcken a 14 Variablen und das andere aus 32 Blöcken a 14 Variablen. Ich würde den Repzepturspeicher also gerne dynamisch verwalten. Das ist vor allem deshalb auch notwendig, da der Speicher ja nur 64k groß ist und da auch noch die Datenprotokolle drin gespeichert werden. Alles in allem reichen 64k dicke. Allerdings nicht, wenn der Rezepturassistent so verschwenderisch mit dem Speicher haushaltet.

    Die Rezepturverwaltung kann man, so wie sie implementiert in WinCC bzw. Micro/Win implementiert ist nur für extrem kleine Projekte (z.B. Fruchtsaftmischanlage) nutzen. Also immer nur dann wenn man nur sehr wenige Variable im Rezept hat. Was mache ich den aber wenn ich z.B. den RaumPfad eines Roboterarms als Rezept speichern möchte? Für jede Position x, y, z einen Double anlegen und dann im Rezepturasistenten x1, y1, y2, ... x1024, y1024, z1024 anlegen?

    Ein BMB ist nicht möglich da die Rezepte im externen Eprom gespeichert/gelesen werden und dieses asynchron zum laufenden Programm ausgeführt werden.
    Bei S7-300 ist auch kein direkter Zugriff über SFC20 oder Lade/Transferier möglich sonder nur indirekt über ein/auslesend der 80er SFCs.
    Die Asynchronität beim Schreiben und Lesen des EPROM ist doch wohl das geringste Problem. Da setzt die Steuerung irgendwo ein Flag wenn sie fertig gelesen bzw. geschrieben hat und das fragt man einfach ab. Das Prob weshalb ich den Rezepturassistenten als "dämlich" bezeichne ist, dass das Teil so ineffizient mit dem Speicher haushaltet und das sich nicht alle Anwendungsfälle damit erschlagen lassen. Die Arbeit die sich Siemens gemacht hat das Teil entwickeln zu lassen hätten sie sie sparen können und einfach nur einen Lese und Schreibzugriff aufs EPROM realisieren sollen. Ich denke mal das es den auch gibt, Nur der Compiler blockt den eben ab. Schliesslich müssen auch die vom Rezeoturassistenten generierten Funktionen irgendwie ins EPROM schreiben und davon lesen. Der Inhalt dieser Funktionen wird natürlich von Micro/Win versteckt. Man könnte ja auf die Idee kommen sich das durchzulesen und die Zugriffe selbst zu machen, Und das ist der Knackpunkt. Da wird ein dickes Softwaremodul wie der Rezepturassistent entwickelt, der meiner Meinung nach nur wenig Nutzen hat, und man wird auch noch gezwungen das Teil zu benutzen. Keine Chance eine Rezepturverwaltung mit dem EPROM ohne den Assistenten aufzubauen.

    Alternativ kannst du dir ein Unterprogramm schreiben mit gleicher Übergabeschnittstelle welches du einen Pointer aus dem V-Bereich zusätzlich mitgiebst und damit den vorhandenen V-Bereich nutzt.
    Falls du aber ein grosses Programm hast bzw. ein 300er Programm in eine 200er quetschen willst, wird der Bereich wahrscheinlich schon anderweitig genutzt.
    Du meinst den V-Bereich als Rezepturspeicher benutzen? Daran hatte ich auch gedacht. Klappt aber nicht, da mein Kunde natürlich gerne die Mobilität des EPROM nutzen möchte, d.h. er nimmt das EPROM auch mal aus einer Maschine raus und packt es in eine zweite um dort die Rezepte nutzen zu können. Ausserdem ist schon wie du es gesagt hast der Variablenspeicher natürlich sehr klein.


    Entschuldigt bitte noch eimal meinen Unmut. Ich kenne mich ja mit SPS ja noch nicht so gut aus. Komme eigentlich aus der C++ und Java Welt. Ich hab früher aber auch intensiv Assembler programmiert. Solche Designfehler wie den aufgezwungenen Rezepturassistenten hab ich bisher noch nicht erlebt. Wie gesagt: Wenn man den wenigstens umgehen könnte.

  8. #7
    Anonymous Gast

    Standard

    Für deine dynamischen Variablentabellen ist der Rezepturassistent völlig ungeeignet.

    Du hast recht, man sollte die Möglichkeit bekommen selber auf des externe Eeprom zu schreiben (und es per Programm zu verwalten).

    Als Lösung könnte ich im Moment nur zu einem 256kB Modul raten, falls dieses für deine Daten ausreicht.

    Ansonsten hätte ich dir dafür eine S7-300C (Kompakt-CPU) empfohlen.
    Preislich in etwa bei einer CPU226 angesiedelt und du kannst max. eine 4MB MMC (Siemens MMC keine normale) stecken.

    Dann kannst du den restlichen Speicherbereich der Karte für deine Daten nutzen, max 16kB pro DB (bei grösseren CPU 64kB).

    Dort gibt es die Möglichkeit Datenbausteine oder teile zur Laufzeit zu lesen/schreiben und auch zu erstellen/löschen.

  9. #8
    Anonymous Gast

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Das ist alles leider keine Alternative für mich, da der Kunde für den ich das programmiere sehr enge preisliche Vorstellungen hat. Der will nachher mehrere Dutzend der Steuerungen im Monat verbauen. Da machen 100 EUR - 200 EUR Aufpreis eine Menge aus.Eine 256k EPROM ist einfach wesentlich teurer. Und auch eine S-300 Modell würde preislich noch mal was draufschlagen. Ursprünglich solte ja auch als OP das OP77A, was nach Siemens Angaben softwarekompatibel zum OP77B sein soll, eingesetzt werden. Es ist nicht kompatibel. Beim OP77A fehlen diverse Funktionen in WinCC, die für das OP77B vorhanden sind. Da zum Entwickeln das OP77B zur Verfügung gestellt wurde lief das ganze nacher nicht mehr auf der A-Variante. Um das Projekt nicht umschreiben zu müssen nehmen wir jetzt das OP77B. Resultat: 80 EUR Aufpreis zum A Modell der eigentlich gar nicht nötig wäre.

    Ich hab halt inzwischen einen echt dicken Hals wegen der Geschichte. Die Hardware reicht von der Leistung doppelt und dreifach. Die IDE's WinCC und Micro/Win stellen einem jedoch nur einen relativ geringen Teil der möglichen Leistung zur Verfügung. Vollkommen grundlos. Warum kann MicroWin nicht aufs ERPROM direkt zugreifen? Der Rezepturassistent generiert doch Funktionen die genau das können. Warum gibt es beim OP77B die Funktion "SetzeBitInVariable" beim OP77A aber nur "SetzeBit"? Klar: Letzteres lässt sich sehr einfach umgehen. Aber die Frage beleibt: Warum wird es dem Entwickler künstlich schwer gemacht. Ich wetter ja eigentlich auch nicht so sehr gegen MicroWin. Mit AWL kann man schon sehr viele tolle Dinge machen. Da ist es halt nur der Rezepturassist. Aber WinCC ist nur KlickiBunti und ein Griff ins ... gewesen. Da sind die Möglichkeiten extrem arg gesetzt. Da hab ich mir nur zwei Dinge gewünscht: Eine Routine zum Setzen eines Pixels und eine zum Abfragen eines beliebigen (also nicht nur f-Tasten) Tastendrucks. Hätte vollkommen gereicht. Alles andere ist eh kam zu gebrauchen, Eines aus vielen Beispielen:

    Das OP77A hat ein Display mit 164x60. Das ist recht knapp bemessen aber mehr als ausreichend. Wie kommt man bei Siemes auf die Idee die als einzig mögliche Schriftart eine mit TTF mit Serifen (WinCCflexible) anzubieten? Die kleinste leserliche Pixelschriftart hat 5x5 Pixel pro Buchstabe. Bei 60 Zeilen kriegt man da gut leserlich so um die 10 Zeilen hin. Mit WinCCFlexible aber nur 5, da unter 8pt die WinCCflexible nicht gut lesbar ist. Warum ist das so? Der Bootloader vom OP77 verwendet doch auch eine serifenlose Schriftart.

    O.k. wie gesagt: Hab schon zu viele graue Haare bekekommen.

Ähnliche Themen

  1. Newbie Problem mit Umwandlung
    Von senior65 im Forum Simatic
    Antworten: 5
    Letzter Beitrag: 06.02.2009, 06:41
  2. Newbie und Hausaufgabenforum ?
    Von Waelder im Forum Stammtisch
    Antworten: 7
    Letzter Beitrag: 09.07.2008, 23:29
  3. NEWBIE: SPS und Haustechnik
    Von leonie im Forum Simatic
    Antworten: 24
    Letzter Beitrag: 08.04.2008, 16:48
  4. Antworten: 17
    Letzter Beitrag: 18.06.2007, 22:10
  5. Symboltabelle in einen Datenbaustein generiern
    Von bluside im Forum Simatic
    Antworten: 7
    Letzter Beitrag: 16.09.2006, 20:25

Lesezeichen

Berechtigungen

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