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

Seite 2 von 2 ErsteErste 12
Ergebnis 11 bis 15 von 15

Thema: Bereichslängen Fehler im Hochregallager

  1. #11
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.166
    Danke
    921
    Erhielt 3.286 Danke für 2.655 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Zitat Zitat von bike Beitrag anzeigen
    Wolltest du im Ernst die Bitadresse um 1 erhöhen?
    Du erhöhst doch schon vor dem SLD, warum noch das INC?
    Wahrscheinlich muß er auf eine Adresse ala DBX123.1 zugreifen. Das SLD 3 erzeugt eine Adresse p#byte.0

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  2. #12
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.166
    Danke
    921
    Erhielt 3.286 Danke für 2.655 Beiträge

    Standard

    Der Code ist etwas umständlich - doch dafür nachvollziehbar - programmiert. Der Code passt gut zu den vorhandenen Kommentaren. Sehr wahrscheinlich hat der Code unter Beachtung der real vorkommenden Variablen-Werte unter Classic sogar korrekt funktioniert. Ich vermute, daß der oder die ursprüngliche(n) Programmierer dieses Codes die kritisierten Operationen absichtlich so eingesetzt haben.

    Möglicherweise will der TE das Programm erweitern und arbeitet nun mit größeren Variablen-Werten (z.B. bei #LengthDB) für die der Code nicht gemacht ist oder TIA erzeugt einen "leicht" unterschiedlichen MC7-Code aus dem AWL. (Welche Ziel-CPU?)

    Ich vermute, zu Beginn dieser Codesequenz bzw. beim Aufruf des FB ist nicht der richtige DB geöffnet - eventuell eine "Neuerung" von TIA gegenüber Classic, welche möglicherweise vom "hidden" Code der Parameterversorgung beim Bausteinaufruf resultiert. (Vielleicht erlaubt der geöffnete DB auch keine absolut adressierten Zugriffe? Welche Ziel-CPU?)

    Man bräuchte die komplette AWL-Quelle dieses Bausteins, die Quelle des Baustein-Aufrufs, die Quelle des Sequence-DB und eine Aussage zu den real vorkommenden Variablen-Wertebereichen um qualifiziert die Fehlerursache zu benennen.

    Eigentlich ist mit dem Beitrag #2 vom Perfektionist bereits alles gesagt bzw. gefragt, was zum jetzigen Zeitpunkt gesagt werden kann. Wir sollten auf eine Antwort vom TE warten.

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  3. #13
    Registriert seit
    08.02.2007
    Ort
    A-2320
    Beiträge
    2.252
    Danke
    244
    Erhielt 332 Danke für 303 Beiträge

    Standard

    Zitat Zitat von PN/DP Beitrag anzeigen
    Deutsche Sprache - schwere Sprache.
    Ich verstehe borromeus' Anmerkungen genauso wie der Perfektionist und würde sie deshalb ebenfalls als falsch qualifizieren. Ich kann aber auch verstehen, wie borromeus es tatsächlich gemeint hat.

    So wäre es eindeutig gewesen:
    * L DBD schaut besser aus, der "L DBW" lädet nen 16Bit Adresspointer
    * +D schaut besser aus, der "+I" addiert nen 16Bit Wert

    Wobei "L DBD" statt "L DBW [#temp_Adr]" in dem Programm wahrscheinlich nicht korrekt wäre, weil DBD oder DBW richtet sich danach, auf was für eine Variable #temp_Adr zeigt. Da kann ich mir sehr gut vorstellen, daß diese Variable aus Speicherspar-Gründen eine Word- oder INT-Variable ist. Man muß schon sehr genau hinschauen, wo lediglich 16-Bit-Offsets berechnet werden und wo es tatsächlich Adressberechnungen sind, welche 32-Bit-Operationen erfordern.

    Was das INC betrifft - da scheint der Perfekte wohl an einer Wochenend-Amnesie gelitten zu haben borromeus hat natürlich recht mit seiner Anmerkung, daß INC eine 8-Bit-Operation ist.
    Allerdings führt das INC wohl nirgends zu einer Fehlberechnung. #T_CNT ist eine BYTE-Variable und "INC 1" direkt nach "SLD 3" funktioniert auch immer korrekt.

    Harald
    Danke für Deine wie immer sehr präzisen Ausführungen, der Sache mit der unglücklichen Formulierung stimme ich zu.

    Aber eines ist doch nicht so glasklar:

    zu:
    "Da kann ich mir sehr gut vorstellen, daß diese Variable aus Speicherspar-Gründen eine Word- oder INT-Variable ist. Man muß schon sehr genau hinschauen, wo lediglich 16-Bit-Offsets berechnet werden und wo es tatsächlich Adressberechnungen sind, welche 32-Bit-Operationen erfordern."

    Auch dann ist es m.E. zumindest nicht konsequent, weil wäre die #temp_Adr aus Speicherspargründen "WORD" wäre
    Code:
    L #LengthDB // load length of step sequence DB
     L 28 // offset of S_CNT
    -I
     SLD 3 // to pointer format
     T #temp_Adr // address of S_CNT
    das SLD3 auch durch ein SLW3 ersetzbar gewesen.
    Wie ich Eingangs schrieb, der Code schaut "fehleranfällig aus".

    Dass INC 1 nach SLD3 immer (in diesem Zusammenhang um das .1 bit zu erhalten) funktioniert, korrekt- da war ich wohl zu sehr mit dem 32 Bit Adresspointer "beschäftigt".

  4. #14
    Registriert seit
    22.06.2009
    Ort
    Sassnitz
    Beiträge
    11.166
    Danke
    921
    Erhielt 3.286 Danke für 2.655 Beiträge

    Standard

    Zitat Zitat von borromeus Beitrag anzeigen
    das SLD3 auch durch ein SLW3 ersetzbar gewesen.
    Vielleicht hat der/die Programmierer versucht, den Code auf kurzen Programmspeicherplatzbedarf zu "optimieren"? (daher z.B. die INC)
    SLW 3 braucht nicht weniger Bytes als SLD 3 --> Optimierung also nicht notwendig, man kann die korrekte Operation stehen lassen.

    Zitat Zitat von borromeus Beitrag anzeigen
    der Code schaut "fehleranfällig aus".

    Der Code hätte in einem Compiler mit Typprüfung keine Chance.

    Harald
    Es ist immer wieder überraschend, wie etwas plötzlich funktioniert, sobald man alles richtig macht.

    FAQ: Linkliste SIMATIC-Kommunikation über Ethernet

  5. #15
    Registriert seit
    08.02.2007
    Ort
    A-2320
    Beiträge
    2.252
    Danke
    244
    Erhielt 332 Danke für 303 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Viellicht meldet sich der TE ja wieder.

Ähnliche Themen

  1. Hochregallager: First first out in SCL
    Von mays im Forum Simatic
    Antworten: 8
    Letzter Beitrag: 12.10.2010, 18:38
  2. hochregallager ansatz
    Von erwin2010 im Forum Programmierstrategien
    Antworten: 4
    Letzter Beitrag: 13.08.2010, 13:23
  3. Verschiedene bereichslängen kopieren
    Von -Melanie- im Forum Simatic
    Antworten: 12
    Letzter Beitrag: 18.02.2010, 18:24
  4. Programm zur Lagerverwaltung (Hochregallager)
    Von maxi im Forum PC- und Netzwerktechnik
    Antworten: 14
    Letzter Beitrag: 31.01.2010, 15:00
  5. Hochregallager Modelle...
    Von Jochen Kühner im Forum Simatic
    Antworten: 15
    Letzter Beitrag: 10.10.2007, 21:37

Lesezeichen

Berechtigungen

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