Softnet PB

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.
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... 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
 
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?
 
... 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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Problem: Zweikern

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.
 
... 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
 
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...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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...
 
ich habe es eben in der boot.ini disabled (Option /ONECPU)...
das hat den Vorteil, daß man nicht Windows neu installieren muß (laut Siemens muß das, wenn man wieder auf Multi zurück will, wobei sie den Multi-CPU-Treiber meinten, der gegen den Uni-CPU-Treiber ausgetauscht werden müßte, der aber IMHO wahrscheinlich auch mit dem Ausschalten im BIOS installiert wird).

Die boot.ini-Option läuft dann dagegen wohl weiterhin mit dem Multi-CPU-Treiber, nur daß der dann die zweite CPU (oder Kern) brach liegen läßt.

Mit Single-Core funktioniert es dann ohne Änderungen an Test-Programm oder sonstiger Konfiguration.

Es ist für mich damit endgültig erwiesen, daß es am Multi-Core liegen muß.
 
@Larry

Ich hol das nochmals hoch, da ich heute auch die Ehre hatte eine CP5611 als Slave einzubinden. Ich wollte 16 Byte E/A nutzen, habe in voller Hybris gemeint, konsistent wär ja nicht schlecht. Da lief aber gar nichts, die OPC-Scout hat keine Quelle gefunden. Erst nachdem ich "Byte" und als Konsistenz "Einheit" gewählt habe, konnte ich mit dem OPC-Scout die E/A finden und auslesen. Es funktionierte auch nicht "Word" und als Konsistenz "Einheit"! Weiterhin hat die CP (Ich glaube, es war schon die neue A2) sich geweigert irgendwas zu tun, wenn ich den OPC-Server FW V6.4 in der Hardwarkonfig ausgewählt habe, V6.3 lief dann. Bei bestimmten Änderungen muß man die XDB-Datei per Stick zum PC tragen :roll: , danach kann man kleinere Änderungen direkt vom PG aus in den PC einspielen.

Alles in Allem, nicht funktioniert auf Anhieb :twisted: , geduldiges Ausprobieren ist angesagt. Die Karte war leider schon verbaut, die Software auf dem PC installiert. Keine Ahnung, wie man an Informationen über benötigte Firmwareversionen gelangen kann, der OPC-Scout schweigt sich jedenfalls zu dem Thema aus. Dieses Gefrickel bei den Siemens-PC Geschichten geht mir langsam echt auf den Keks, X Firmware- und Softwareversionen, die eine will mit jener nicht, die andere nicht mit der nächsten, das nervt.

Also Leute mein Rat, schön ruhig bleiben und ALLES durchprobieren.
 
@Ralle:
Die CP5611 kann nur Byte-Konsistenz.
Ich hatte allerdings beim Einsatz des OPC-Servers (den ich nach Vorschlag von Jesper zunächst zum Testen am Start hatte) kein Problem auf die deklarierten Datenbereiche zuzugreifen ...
Kann ich dir bei der Angelegenheit jetzt noch irgendwie behilflich sein ...?

Gruß
LL
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@Ralle:
Die CP5611 kann nur Byte-Konsistenz.
Ich hatte allerdings beim Einsatz des OPC-Servers (den ich nach Vorschlag von Jesper zunächst zum Testen am Start hatte) kein Problem auf die deklarierten Datenbereiche zuzugreifen ...
Kann ich dir bei der Angelegenheit jetzt noch irgendwie behilflich sein ...?

Gruß
LL

Nein, es läuft nun, das war nur nochmal eine Zusammenfassung, für alle, die auch mal an diesem Problem hängen. Da die CP5611 in einem Fremdrechner saß, hatte ich erstmal keine Doku zur Hand. Du hattest anscheinend einen neueren OPC-Server, da ja bei dir die Version 6.4 funktionierte. Trotzdem vielen Dank :p.
 
Zurück
Oben