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

Seite 5 von 6 ErsteErste ... 3456 LetzteLetzte
Ergebnis 41 bis 50 von 55

Thema: Softnet PB

  1. #41
    Registriert seit
    29.01.2008
    Beiträge
    10
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    ja, deswegen schrieb ich:

    > Config-Bytes z.B.: 0x17, 0x27 d.h. je 8 Bytes rein und raus.

    die Bytes werden letztlich aus einem String (der im Prinzip aus einer Einstellungs-Datenbank oder Ini-Datei kommt) extrahiert (z.B. sscanf) und dann in die Config-Bytes reingeschrieben.

    Diese Bytes sind IMHO korrekt konfiguriert, da der Slave im Master mit denselben Bytes konfiguriert ist (0x17, 0x27) und die Verbindung aufgebaut wird und auch grundsätzlich funktioniert. Mit falschen Config-Bytes (und ebenso z.B. User-Parameter-Bytes) würde die Verbindung gar nicht erst zustande kommen (das habe ich auch ausprobiert). Man kann außerdem im Hilscher-Master die eingestellte Konfiguration des Slaves mit der tatsächlichen vergleichen und sieht dort auch genau diese Bytes sowie ein OK dazu.

    Unsere GSD-Datei enthält einige Module die in Zweier-Potenzen gestaffelt sind, so daß man sich damit beliebige Längen zusammenstellen kann.
    Wir verwenden aber im Test bisher nur die Bytes 0x11, 0x17, 0x21, 0x27 (also unidirektional, der Gedanke war, daß es bei diesen keine gemeinsamen Puffer geben sollte, im Gegensatz dazu vermuten wir bei den bidirektionalen z.B. 0x31 und 0x37 daß da derselbe Puffer verwendet werden könnte. Bei Hilscher ist es mit den uni- und bidirektionalen Modulen jedenfalls so.

    Bei Hilscher sieht das übrigens so aus:

    Code:
      bool Kommun_Hilscher::
    COM_send()
      {
      int iError =
        DevExchangeIO(
          mDevice,
          0, mOutputDataLength, mOutputData,
          0, 0, 0,
          mWriteTimeout
          );
    
      if(IsError(iError, "DevExchangeIO/write"))
        {
        COM_close();
        return false;
        }
    
      return true;
      }
    Code:
      bool Kommun_Hilscher::
    COM_receive()
      {
      int iError =
        DevExchangeIO(
          mDevice,
          0, 0, 0,
          0, mInputDataLength, mInputData,
          mReadTimeout
          );
    
      if(IsError(iError, "DevExchangeIO/read"))
        {
        COM_close();
        return false;
        }
    
      return true;
      }
    D.h. hier wird read und write nicht getrennt aufgerufen, aber die Puffer jeweils auf Null gesetzt, man könnte aber auch beide Puffer gleichzeitig austauschen. Deswegen vermute ich jetzt, daß bei Siemens DPS_get_output und DPS_set_input vielleicht immer zusammen benutzt werden müssen, wobei *ich* dann als Library-Entwickler dann nicht zwei getrennte Routinen anbieten würde.

    Ich muß dazusagen, daß ich zwar Software-Profi bin (seit bald 30 Jahren, wir haben übrigens ein ganz ähnliches Geburtsdatum), aber nicht gerade ein Profibus-Spezialist (hier im Forum wird mich wahrscheinlich jeder in die Tasche stecken oder gar auslachen )

    Bei Hilscher und deren Konfigurationstool war und ist das alles für mich recht logisch und intuitiv, bei Siemens habe ich jetzt eher das umgekehrte Erlebnis.

  2. #42
    Registriert seit
    29.01.2008
    Beiträge
    10
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Standard

    eine weitere Info:

    Wir haben jetzt statt des Hilscher-Masters einen weiteren Siemens-PC mit CP5611 als Master mit OPC konfiguriert, so daß jetzt der OPC-Scout als Programm zum Einsatz kommt.

    Auch hier zeigt sich dasselbe Verhalten.
    Es ist folglich nicht auf den Hilscher-Master zurückzuführen.

  3. #43
    Avatar von Larry Laffer
    Larry Laffer ist offline Super-Moderator
    Themenstarter
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.708
    Danke
    398
    Erhielt 2.397 Danke für 1.997 Beiträge

    Standard

    ... ich habe mir deine ganzen Beiträge jetzt noch einmal durchgelesen und dabei bemerkt, dass ich anscheinend ein paar Dinge einfach überlesen habe.

    Zum Thema:
    Ich stecke in der C-Programmierung nicht wirklich drin. Trotzdem sind ein paar Dinge hängen geblieben. Vielleicht hilft dir das weiter. Ich beschreibe vielleicht einfach unsere Anwendung und wie sie realisiert worden ist.
    Ich habe einen Binären Koppelbereich in beide Richtungen mit der Größe 2 Byte. Dann übertrage ich 2 seperate Strings (in Wirklichkeit ARRAY_OF_Byte). Der erste ist 24 Zeichen lange und der zweite 40 Zeichen. So ist es in der GSD-Datei deklariert ... Im C++-Programm werden in einem Rutsch (und ich vermute sogar ständig) 66 Bytes gelesen und 2 Bytes geschrieben (in einem Abwasch). Das ist vielleicht der markante Unterschied zu deinem Programm. Ich könnte mir durchaus vorstellen, dass wenn du die Schnittstelle nicht entsprechend bedienst, dass es dann vielleicht zu der Reflektion kommt (Buffer-Überlauf). Ist aber nur so eine Idee. Wenn wir so nicht weiterkommen (ich erwarte dein Feedback), dann werde ich gerne Kontakt zu dem Laser-Programmierer aufnehmen und diese Sache hinterfragen. Das könnte dann aber nächste Woche werden - aber immerhin (ich weiß nicht wie schnell der da reagiert).
    Nochmal zum Programm im Laser-PC. Wenn ich da nicht total falsch liege, dann fragt der "Andere" seine Schnittstelle auch dann ab, wenn definitiv nichts von mir gekommen ist. Ob und wie darauf reagiert wird ist bei uns über die BOOL-Ebene gesteuert. Das Empfangsprogramm auf dem Laser-PC stellt den Inhalt des Empfangspuffers auf dem Bildschirm dar. Eine übertragene Zeichenkette wird hier "sofort" auf der Gegenseite angezeigt - also keine sichtbare Übertragungs-Verzögerung.

    Vielleicht habe ich dir ein wenig helfen können. Wenn nicht, dann weiß ich nur noch den genannten Weg, der aber (für mich) kein Problem darstellt ...

    Gruß
    LL

  4. #44
    Registriert seit
    29.01.2008
    Beiträge
    10
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Standard

    das hilft mir insoweit, als dass ich jetzt weiß, dass bei Euch regelmäßig gesendet UND empfangen wird (das erwähntest Du auch schon in einer vorherigen Antwort).

    Interessant wäre noch in welchem Takt die Daten bei Eurem Projekt größenordnungsmäßig ausgetauscht wurden, 10ms, 100ms, ...?

    Das ist ein wesentlicher Unterschied zu unserer Anwendung.

    Bei uns wird zeitweise viel übertragen und dann wird wieder länger gewartet.

    Es geht da um Bauteile (z.B. Motoren) auf einem Transportband, die meistens eine geringe Taktzahl haben (meistens so 20 bis 60 Sekunden).

    Da Eure Anwendung sowieso zyklisch arbeitet, wird es nichts bringen den Programmierer zu fragen. Ich werde mich wohl lieber mal an Siemens wenden...

    Ich denke, ich werde es jetzt erstmal so lösen, dass ich beim Pollen (get_output) immer auch die Ausgabe-Daten (set_input) setze, da es ja bei DP wohl nichts schaden kann.

    Könnte sich denn die SPS daran verschlucken?

  5. #45
    Avatar von Larry Laffer
    Larry Laffer ist offline Super-Moderator
    Themenstarter
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.708
    Danke
    398
    Erhielt 2.397 Danke für 1.997 Beiträge

    Standard

    ... so unterschiedlich ist die Anwendung (glaube ich) nicht. Bei mir ist es der Beschriftungstext und das Layout für ein produziertes Bauteil. Der Takt der Bauteile ist hier ca. 5 s. In dem Takt schicke ich dann auch die Beschriftungs-Info an den Laser (von der SPS aus).

    Ich glaube nicht, dass sich die SPS verschluckt. Du überschreibst (nach meiner Meinung) nur den letzten Wert im zugewiesenen Puffer (PEW xyz ?).

    Siemens fragen ist bestimmt nicht schlecht - hat mir ja auch geholfen - kostet halt nur ein wenig Zeit. Dafür viel Erfolg und berichte bitte von deinem Ergebnis.

    Gruß
    LL

  6. Folgender Benutzer sagt Danke zu Larry Laffer für den nützlichen Beitrag:

    hg42 (30.01.2008)

  7. #46
    Registriert seit
    29.01.2008
    Beiträge
    10
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Standard

    die Ursache für mein Problem ist offenbar, daß die beiden SIMATIC-Panel-PCs vom Typ 677B mit Core 2 Duo Prozessoren ausgestattet sind und die auf dem Motherboard verbaute sogenannte CP5611-kompatible Profibus-Schnittstelle wohl nicht für Mehrkern und Multiprozessoren geeignet ist. Das sind bisher Vermutungen, genaueres erfahre ich noch von Siemens.

    Jedenfalls funktioniert das Ganze mit einfache Einzel-Kern-Celerons und ansonsten gleichen Konfigurationen und Programmen.
    Zitieren Zitieren Problem: Zweikern  

  8. #47
    Avatar von Larry Laffer
    Larry Laffer ist offline Super-Moderator
    Themenstarter
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.708
    Danke
    398
    Erhielt 2.397 Danke für 1.997 Beiträge

    Standard

    ... wo du das jetzt schreibst ...

    Bei unserem Laser-PC (in dem der CP5611 sitzt) haben wir den Dual-Core-Modus im Bios ausgeschaltet. Aktiviert hatte ich auch Schwierigkeiten, weill die Kommunikation nach einiger Zeit abstürzte. Man konnte es zwar neu starten, aber irgendwann gab es dann wieder einen Fehler und damit einen Programm-Abbruch. Seit dem de-Aktivieren ist der Fehler nicht wieder aufgetreten ...

    Gruß
    LL

  9. #48
    Registriert seit
    29.01.2008
    Beiträge
    10
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Standard

    wobei es eine neuere Variante der CP5611 geben soll, die mit Multiprozessoren klar kommt (nennt sich CP5611A2), es sieht also so aus, als wäre es ein Hardwareproblem. Dummerweise kann man bei unserem Panel-PC den Baustein nicht umbauen, weil er auf dem Motherboard sitzt...

  10. #49
    Registriert seit
    29.01.2008
    Beiträge
    10
    Danke
    1
    Erhielt 0 Danke für 0 Beiträge

    Standard

    Eben hat sich ein anderer Siemens-Mitarbeiter auf eine andere Anfrage zur Slave-API gemeldet und er ist nun der Meinung, dass die auf dem Motherboard verbaute Profibusschnittstelle Multicore-fähig sein sollte...es wird also weiter geforscht...

  11. #50
    Avatar von Larry Laffer
    Larry Laffer ist offline Super-Moderator
    Themenstarter
    Registriert seit
    22.03.2007
    Ort
    Detmold (im Lipperland)
    Beiträge
    11.708
    Danke
    398
    Erhielt 2.397 Danke für 1.997 Beiträge

    Standard


    Zuviel Werbung?
    -> Hier kostenlos registrieren
    Hast du denn die Dual-Core-Geschichte im BIOS mal disabled ?

Ähnliche Themen

  1. S7 Softnet benötigt?
    Von Sesssko im Forum HMI
    Antworten: 7
    Letzter Beitrag: 01.09.2010, 20:42
  2. SIMATIC Softnet-S7
    Von Skippy1988 im Forum Simatic
    Antworten: 10
    Letzter Beitrag: 18.03.2009, 07:25
  3. Softnet-S7
    Von Ray-Banton im Forum Hochsprachen - OPC
    Antworten: 3
    Letzter Beitrag: 17.09.2008, 15:09
  4. Softnet PN-IO Linux
    Von ain im Forum Simatic
    Antworten: 0
    Letzter Beitrag: 03.06.2008, 15:46
  5. Simatic Softnet-DP-Slave
    Von ronnie.b im Forum Hochsprachen - OPC
    Antworten: 4
    Letzter Beitrag: 12.04.2007, 12:07

Lesezeichen

Berechtigungen

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