# Softnet PB



## Larry Laffer (2 September 2007)

Hallo,
wir planen in den nächsten Tagen die Umrüstung eines vorhandenen Beschriftungs-Lasers, damit er via Profibus von der SPS her gesteuert werden kann.
Der Weg hierbei ist : CPU 317-2DP - CP5611 - Softnet Profibus.
Selber habe ich so etwas noch nicht gemacht. Gibt es da etwas besonderes zu beachten ?
Habe ich auf diesem Weg in etwa die gleichen Möglichkeiten wie zum Beispiel bei der Ansteuerung eines Servo-Reglers ?


----------



## MSB (2 September 2007)

Versteh ich jetzt irgendwie nicht,
also Steuerung ist eine 317-2DP, OK,
im PC des Beschrifungslasers ist dann der CP und der (Softnet =) OPC-Server?

Ganz einfach gesprochen, über diesen OPC-Server kannst du Daten von der Steuerung schreiben/lesen,
mehr zunächst mal nicht.

Mfg
Manuel


----------



## Larry Laffer (2 September 2007)

MSB schrieb:


> Versteh ich jetzt irgendwie nicht ...


 
Der Hintergrund meiner Frage war, dass ich bislang mit so etwas noch nicht gearbeitet habe / hatte und somit nicht so genau weiss, was mich da erwartet. Da ich aber ein Kontroll-Freak bin möchte ich gerne immer auf Augenhöhe mit meinem Problem sein ...


----------



## JesperMP (3 September 2007)

Ich nehme an, daß das Laser ein Slave zum 317 ist.
Der PC wird nur für das Ändern der Werten im Programm der 317 benutzt.
Dieses ist vollständig normal. Es sollte ziemlich einfach sein.

Nur eine Anmerkung: 
Warum 317-2DP + CP5611 + Sofnet PB?
Ein 317-2PNDP + Softnet IE würde der gleiche Preis sein.
Und du würdest dann getrennte netze für E/A (DP) und HMI (Ethernet) haben, was ein Vorteil ist, wenn du mich fragst.

edit:
Softnet IE LEAN sollte genügend sein.


----------



## Larry Laffer (4 September 2007)

...
tolle Wurst ...
Das hat NATÜRLICH alles wieder NICHT funktioniert ...
Angefangen mit der Doku zu dem Thema. Bis man da so herausgelesen hat, was man braucht sind schon mal schnell 2 Stunden in der Runde. Dan die Übertragung der Config zum Slave-CP. Geht nicht wegen gelben Ausrufezeichen. Es lässt sich aber auch nicht dazu aus, was jetzt nicht richtig ist. Irgend ein Versionsstand vermutlich. 
Wie bekomme ich heraus, welche Version der OPC-Server hat ? Die Nummer, die mir angibt hat nichts mit der Nummer zu tun, die ich in der Siemens-HW-Konfig eintragen kann.
Mein CP5611 ist vom Typ 1AA01. Meine Step7-Installation (aktuellster Stand) kennt aber nur 1AA00. Updaten kann man das auch nicht. Kann das auch 'ne Rolle spielen ?

Mal sehen, was ich für Antworten bekomme ... vor allen Dingen morgen von Siemens ...


----------



## JesperMP (4 September 2007)

> Dan die Übertragung der Config zum Slave-CP


?
Der CP5611 ist typisch ein Profibus Master. Muss dein CP5611 DP slave sein ?


> Geht nicht wegen gelben Ausrufezeichen. Es lässt sich aber auch nicht dazu aus, was jetzt nicht richtig ist. Irgend ein Versionsstand vermutlich.


Genau welche systemmeldungen ?


> Wie bekomme ich heraus, welche Version der OPC-Server hat ? Die Nummer, die mir angibt hat nichts mit der Nummer zu tun, die ich in der Siemens-HW-Konfig eintragen kann.


Genau was für Bestellnr hat dein softwarepaket ?


----------



## JesperMP (4 September 2007)

Es ist mir nicht klar wo der laser angeschlossen wird.
Als 'normaler' DP slave ?
Oder hat es irgendwie etwas zu tun mit den PC Station und CP5611 ? Ist der laser ein OPC client ?


----------



## Larry Laffer (5 September 2007)

JesperMP schrieb:


> ?
> Der CP5611 ist typisch ein Profibus Master. Muss dein CP5611 DP slave sein ?
> Genau welche systemmeldungen ?
> Genau was für Bestellnr hat dein softwarepaket ?


 
Hallo Jesper,
danke für dein Interesse.
Ich habe die Simatic Net PC-Software Edition 2006
Best.Nr. 6GK1704-5SW64-3AA00
Der Hersteller des Lasers hat sich einen PB-Slave gewünscht. Ich wüßte im Augenblick auch nicht, was dem entgegen steht. Übertragen will ich via PB Steuerbefehle, die Auswahl des Beschriftungs-Layouts und einen Beschriftungs-Inhalt.

Ich habe auch noch mal ein paar Screenshots zusammengestellt. Daraus läßt sich bezüglich Meldungen und Aufbau schon viel erkennen ...


----------



## Larry Laffer (5 September 2007)

... und noch ein paar Bilderchen ...


----------



## Ralle (5 September 2007)

Hallo Larry, ich hab sowas mal gehabt, aber irgendwie ganz anders gelöst. Ich hab mal ein Bild davon gemacht. Ist schon einige Jährchen her.

Ich habe dann eine *.xdb (rechte Maustaste auf PC-Station, dann "Objekteigenschaften/Konfiguration") und eine *.ldb (Doppelclick auf CP5613 in PC-Station, Reiter "Betriebsart") Datei erzeugen lassen, eine davon kann man dann bei der Konfiguration der PC-Station (Einrichten der CP5613 auf dem PC) angeben, da steht der gesamte Netzaufbau drin. Danach konnte ich per OPC-Server die eingerichteten Verbindungen (Applikation) nutzen. Du hast zwar eine andere CP, aber ich denke, der Vorgang ist da identisch.


----------



## JesperMP (5 September 2007)

OK, jetzt weiss ich was passiert und warum du den fehlermeldung bekommst !
Den fehlermeldung bedeutet das es keine verbindung gibt zwisschen den PC mit STEP7 und den "PC Station". 
"R0/S125" ist softbus ("R0") und index 125 ("S125").
Hast du den Stationenkonfigurator auf den "PC-CAB-Laser" PC eingerichtet ?
Ist den "PC-CAB-Laser" PC denselbe als dein programmier PC ?

Dein software ist korrekt für Softnet DP Slave.


----------



## JesperMP (5 September 2007)

@Ralle.
Was du vorschlägst ist ein S7-verbindung zwischen 2 DP master.
Larry will sein Laser als DP slave verbinden.


----------



## Larry Laffer (5 September 2007)

@Ralle:
deinen Vorschlag konnte ich leider nicht umsetzen. Die beiden Dateien waren schon da, aber die *.ldb-Datei läßt sich nicht manuell auf den LASER-PC aufspielen.

@Jesper:
Ich habe den Stations-Konfigurator eingerichtet.
Der LASER-PC ist nicht identisch mit dem Programmier-PC von dem die Screenshots kommen.
Eine Verbindung zum LASER-PC existiert. Er wird als Busteilnehmer (auch namentlich) erkannt - siehe Bild "übertragen_1.jpg".

Danke auf jeden Fall schon einmal für die Reaktion. Ich stehe hier echt ein bißchen auf dem Schlauch.
Von der An- und Einbindung der Komponenten habe ich mich glatt um 15 Jahre in der Zeit zurück versetzt gefühlt. Ich hatte eigentlich nicht damit gerechnet, dass das ein Problem darstellen würde (vor 15 - 20 Jahren schon , aber heute ?)


----------



## JesperMP (5 September 2007)

Hallo Larry.

Wenn du die Konfiguration "entfernt" laden möchtest, dann ist es wichtig, daß der Name im STEP7/NCM Projekt genau der selbe wie der Name des PC im Windows Workgroup ist.
Also, in Windows System manager muss den name "PC-CAP-Laser" sein.
Eigentlich ist diese name nicht 100% gestattet, da sonderzeichen wie "bindestrich" problematisch sind.
edit: Ich weiss das es bei Ethernet so funktioniert. Ob es überhaupt geht bei Profibus bin ich nicht sicher.

Wenn es nicht klappt, denn gibts es ein einfachere weg.
Zuerst alles in NetPro kompilieren.
Dann die *.xdb Datei im "XDBs" Ordner im STEP7 Projektordner finden. Kopier diese Datei zum Laser PC und benutzen den "Import station.." Funktion in Station Konfigurator. Wenn gefragt, den .xdb Datei auswählen.


----------



## Larry Laffer (5 September 2007)

Hallo Jesper,
meinst du mit Namen den Namen, den ich im Stations-Konfigurator vergeben habe ?
Der ist unterschiedlich, das stimmt. Werde ich gleich mal ausprobieren. Das wäre natürlich ein "dicker Hund", wenn es daran liegt ...

Ich melde mich gleich dazu ...


----------



## Ralle (5 September 2007)

JesperMP schrieb:


> @Ralle.
> Was du vorschlägst ist ein S7-verbindung zwischen 2 DP master.
> Larry will sein Laser als DP slave verbinden.



Hm, in der Hardwarekonfig der CP5613 ist aber kein Haken bei "Master" sonder bei "kein DP". Das ist die Standardeinstellung und das läuft auch so.

@Larry

Die Dateien hab ich auch per Diskette übertragen, nicht von Step7 aus!


----------



## JesperMP (5 September 2007)

Wenn man sich vertan haben kann man diese Name im Stationen Konfigurator manuell ändern.

Wenn das Name in Windows Systemsteuerung richtig eingestellt ist, wird es automatisch davon ins Stationen Konfigurator übernommen wenn ein übertragung von NetPro durchgefürt wird.


----------



## JesperMP (5 September 2007)

Ralle schrieb:


> Hm, in der Hardwarekonfig der CP5613 ist aber kein Haken bei "Master" sonder bei "kein DP". Das ist die Standardeinstellung und das läuft auch so.


"kein DP" bedeutet das der CP5613 keine DP slaves steuert, und es auch selber nicht ein DP slave ist. Larry will sein Laser als DP slave betrieben.


----------



## Larry Laffer (5 September 2007)

Hallo Jesper,
leider kein Erfolg.
Ich habe den Stationsnamen dahin geändert, dass er keine Sonder-Zeichen etc mehr enthält ("CAB_Laser"). So heißt es auch in meinem Step7-Projekt. Der Remote-Zugriff meldet nach wie vor den selben Fehler.
Nun habe ich versucht die Stations-Daten zu importieren. Daraufhin erhielt ich die Meldung "Beim Importieren der Projektierungsdaten sind Fehler aufgetreten". Das deckt sich mit meinem Ursprungs-Verdacht. Habe ich im Step7-Projekt irgend etwas falsch eingestellt ? Welchen Einfluß haben die SW-Versions-Nummern, die ich in der Hardware-Konfig finde aber sonst nirgendwo ? Ich weiß nicht, welche Version mein OPC-Server etc. hat. Welche Rolle spielt es, dass meine Karte eine "1AA01" ist, ich aber in der Konfiguration "1AA00" eingetragen habe, weil man etwas anderes nirgendwo wegbekommt ?


----------



## Larry Laffer (5 September 2007)

JesperMP schrieb:


> "kein DP" bedeutet das der CP5613 keine DP slaves steuert, und es auch selber nicht ein DP slave ist. Larry will sein Laser als DP slave betrieben.


 
Betrifft mich das ...?


----------



## Ralle (5 September 2007)

Das betraf meine Konfiguration, die ich dir vorgeschlagen hatte. Immerhin, kannst du es ja mal damit probieren.


----------



## JesperMP (5 September 2007)

Hallo Larry.

Ich habe auch nur 1AA00 in meiner HW catalog. Ich glaube das es keine rolle spielt, da Siemens HW im normal fall kompatibel zur vorige versionen ist. Ein projekt mit 1AA00 sollte funktionieren auf ein 1AA01.

Dein Simatic Net software ist v6.4 (6GK1704-5SW64-3AA00). Dies ist den letzten stand.
Eigentlich sollte es auch keine rolle spielen weil Simatic Net rückwärtskompatibel ist.

Wenn du versucht zu importieren, wenn es streikt geh zu den Diagnostics wähler und seh warum es nicht will.
Im normal fall gibt es genauere eklärung.


----------



## JesperMP (5 September 2007)

Larry Laffer schrieb:


> Betrifft mich das ...?


["kein DP"]Nein.


----------



## Larry Laffer (5 September 2007)

So ....
komisches Spiel.
Den CP habe ich jetzt konfiguriert bekommen. Vorgehensweise: In der Konfiguration OPC-Server V6.4 eingetragen. Dann erstellte XDB-Datei manuell (per Stick und Station importieren) auf den CP gespielt. Dann Hardware-Konfig auf die CPU übertragen und auf einmal kann ich jetzt auch die Hardware-Konfig über den PB auf den CP übertragen. Immerhin, soweit so gut.

Nun möchte ich gerne eine Verbindung anlegen, damit ich vielleicht doch noch eine Kommunikation bekomme. Das klappt aber nicht. Die Fehlermeldung generell "Es kann keine Verbindung zu der gewählten Station angelegt werden)   ?????

Wie auch immer. Ich möchte mich auf jeden Fall schon einmal für deine Geduld bedanken, Jesper. Arbeitest du bei Siemens ?


----------



## Larry Laffer (5 September 2007)

...
ach ja,
hatte ich schon vergessen :  Ich habe immer noch einen Busfehler obwohl meiner Meinung nach alles OK ist ...


----------



## JesperMP (5 September 2007)

Larry Laffer schrieb:


> Nun möchte ich gerne eine Verbindung anlegen, damit ich vielleicht doch noch eine Kommunikation bekomme. Das klappt aber nicht. Die Fehlermeldung generell "Es kann keine Verbindung zu der gewählten Station angelegt werden) ?????


Also, willst du eine zusätzliches verbindung anliegen. Wie ein S7-verbindung, oder ?
Das problem kann sein das du vielleicht den häkschen "Test, Commisioning, Routing and Configured connections" unter Operating Mode deaktiviert hast.



Larry Laffer schrieb:


> Arbeitest du bei Siemens ?


Nöh. Ich arbeite (oder "kämpfe") MIT Siemens.


----------



## JesperMP (5 September 2007)

Larry Laffer schrieb:


> ...
> ach ja,
> hatte ich schon vergessen : Ich habe immer noch einen Busfehler obwohl meiner Meinung nach alles OK ist ...


Also, dein S7 master meldet BF ?
Vielleicht ist den grund dafür das den OPC client (den Laser) nicht den OPC server zyklisch anspricht.
Bei Profibus DP muss die E/A daten immer aktualisiert werden.

edit:
Versuch mit den OPC Scout test client, ob alles funktioniert.
Wenn du alle E/A daten im OPC scout liesst, verschwindet den BF.


----------



## Larry Laffer (5 September 2007)

Hallo Jesper,
brauche ich die Verbindung gar nicht ?
Wenn ja, wie erreiche ich jetzt einen Datenaustausch (-Busfehler -).
Irgend etwas scheint ja immer noich nicht zu stimmen ...


----------



## JesperMP (5 September 2007)

Larry Laffer schrieb:


> brauche ich die Verbindung gar nicht ?


Nein. Die DP slave verbindung ist speziell damit das die daten alle E/A daten sind. Alles ist jetzt fertig konfiguriert ohne zusätsliche S7-verbindungen.



Larry Laffer schrieb:


> Wenn ja, wie erreiche ich jetzt einen Datenaustausch (-Busfehler -).
> Irgend etwas scheint ja immer noich nicht zu stimmen ...


Probier den OPC scout.

edit: Kann sein das man den BF nicht "austrixen" kann mit den OPC scout.
Die eingänge werden zyklisch gelesen, aber wie kann man die ausgänge zyklisch ansteuern ?


----------



## Larry Laffer (5 September 2007)

Stimmt, du hast recht. Mit dem OPC-Scout läuft es dann.
Wenn ich das richtig verstanden habe, dann übernimmt dieser temporär die Funktion, die eigentlich die LASER-Software übernehmen sollte, stimmts ?


----------



## JesperMP (5 September 2007)

Ja, den OPC scout ist ein einfache OPC client, nur für testen.
Der Laser muß auch ein OPC client sein.

Ich bin froh, daß du es am laufen hast, mindestens vom PLC zum OPC server.


----------



## Larry Laffer (5 September 2007)

Und ich bin über deine Hilfe froh ...!    
Ohne die hätte ich mich noch ein paar Wochen damit herumschlagen können und hätte den ganzen Kram hinterher warscheinlich vor Wut in Stücke gehauen.
So aber haben wir jetzt für die Nachwelt noch einen schönen Thread gebaut. Vielleicht hat ja der Eine oder Andere auch noch mal so ein Problem ...

Also nochmals ... Danke !


----------



## Larry Laffer (4 Oktober 2007)

Ich muss das Thema noch einmal aufgreifen und nach vorne holen.

Im Augenblick stehe ich vor dem Problem, dass die Verbindung SPS - CP5611 unter Zuhilfenahme des OPC-Scout wunderbar funktioniert, nicht aber mit der Anwendersoftware meines LASER-Herstellers.

*Weiß jemand, welche Einträge in einem C++-Programm für den Befehl "DPS_Open" benötigt werden - hierbei wichtig die Beziehung zum Netpro.*
*Ich kann den CP zwar initialisieren, bekomme aber keinen Handle für einen bestehenden Kontakt zurück ...*

Das Problem brennt schon ein bißchen ...


----------



## Larry Laffer (5 Oktober 2007)

*der Tag danach ...*

da ich einfach mal annehme, dass es vielleicht noch einmal jemanden geben wird, der dieses Problem vielleicht auch hat - hier die Lösung eines *sehr* langen Arbeitstages :

Man bindet einfach die dem Softnet beigefügte Datei "DPSLib.DLL" und die zugehöhigen Header-Files in das C++-Programm ein. Diese finden sich nach erfolgter Softnet-Installation im Verzeichnis "C:\Programme\Siemens\Simatic.Net\DP\" und Unterzeichnissen.
Interessanterweise findet man die DLL auch bei ProTool-Runtime und bei WinCC-Flexible Runtime.
Mit Hilfe dieser Datei erstellt man einen eigenständigen DP-Slave. Der OPC-Quatsch und die diversen Zusatzprogramme, die mit der Simatic.Net-Installation noch so auf den entsprechenden Rechner aufgepackt werden, werden ALLE NICHT BENÖTIGT. Was man letztendlich wirklich brauch ist eine GSD_Datei, die man sich selber noch zusammenbasteln muss. Eine richtige Vorlage dazu habe ich bisher noch nicht gefunden, aber da gibt es ja noch den Thread von Flummy33 (http://www.sps-forum.de/showthread.php?t=14824), die einem da etwas weiterhelfen kann.
Jedenfalls bin ich dann so zum Ziel gekommen.
Auf den richtigen Dreh hat mich darüber hinaus ein freundlicher Mitarbeiter bei der Siemens-Hotline gebracht, denn in der Doku vom Softnet haben weder der Systemprogrammierer von der Laser-Firma noch ich irgendetwas für uns brauchbares gefunden. Aber das ist ja fürt Siemens nicht untypisch - Willkommen im 21. Jahrhundert.

Falls nach diesem Geschreibsel für jemanden noch Fragen offen sind, so stehe ich gerne mit Rat zur Verfügung. Alles habe ich bestimmt noch nicht geschrieben.


----------



## JesperMP (5 Oktober 2007)

Larry Laffer schrieb:
			
		

> [..]denn in der Doku vom Softnet haben weder der Systemprogrammierer von der Laser-Firma noch ich irgendetwas für uns brauchbares gefunden. Aber das ist ja fürt Siemens nicht untypisch - Willkommen im 21. Jahrhundert.


Ich denke, daß es viele Sachen gibt wovon man Siemens kritisieren kann, aber manchmal ist es zu einfach Siemens gerade zu tadeln, selbst wenn sie absolut nicht zu tadeln sind.

OPC ist ein offenes (nicht Siemens spezifik) standard. 
Man soll sich nicht mit Siemens in Verbindung treten, um Informationen zu erhalten, wie man einen OPC Klienten bildet. Diese information erhaltet man bei http://www.opcfoundation.org/ , oder http://www.opcconnect.com/ (woüber ich dich früher informiert habe).

Die fehler ist, daß du und der Laser Programmierer nicht ihrer Heimarbeit zur rechten Zeit getan hat (!).
Wie ich es verstehe, erwartete ihr, daß der Programmierer mit nullwissen über OPC, seine Arbeit innerhalb einem Tag beenden sollte !?

Warum fingst du am Anfang mit dem OPC Weg an?


----------



## Larry Laffer (5 Oktober 2007)

JesperMP schrieb:


> Warum fingst du am Anfang mit dem OPC Weg an?


 
Hallo Jesper,
das Problem war, dass *ICH* am Anfang nicht so genau wusste, wohin es gehen würde und wie ...

Zum Thema OPC-Handling in C++ hatte ich unter dem genannten Link nichts brauchbares finden können - ist aber auch nicht so ganz mein Gebiet.

Der Programmierer der Laser-Firma hatte von Anfang an einen PB-Slave im Sinn. Dazu hatten wir auch Doku gefunden. Allerdings nichts, was sich zum Siemens-Projekt in Einklang bringen ließ.
Immerhin - den Hinweis mit der GSD-Datei kam von der Siemens-Hotline.



> Ich denke, daß es viele Sachen gibt wovon man Siemens kritisieren kann, aber manchmal ist es zu einfach Siemens gerade zu tadeln, selbst wenn sie absolut nicht zu tadeln sind.


 
Da hast du bestimmt Recht. Allerdings was das Thema Doku, Beispiele, Infos angeht so ist das bei Siemens schon immer ein Problem gewesen und wird es auch bestimmt in 100 Jahren noch sein. Es gibt viele Firmen, die keine brauchbare zu ihren Produkten Doku erstellen können, aber ich denke bei allen denen ist Siemens schon ein Spitzenreiter.

Trotzdem war deine Hilfe in diesem Projekt für mich sehr wertvoll, den ohne die wäre ich gestern sicher nicht an den Punkt gekommen.

Gruß
LL


----------



## hg42 (29 Januar 2008)

Larry Laffer schrieb:


> da ich einfach mal annehme, dass es vielleicht noch einmal jemanden geben wird, der dieses Problem vielleicht auch hat - hier die Lösung eines *sehr* langen Arbeitstages :
> 
> Man bindet einfach die dem Softnet beigefügte Datei "DPSLib.DLL" und die zugehöhigen Header-Files in das C++-Programm ein. Diese finden sich nach erfolgter Softnet-Installation im Verzeichnis "C:\Programme\Siemens\Simatic.Net\DP\" und Unterzeichnissen.



Da ich im Moment dabei bin, eine CP5611 in unser Projekt einzubinden, würde mich interessieren, wie Euer Slave-Quellcode an einer bestimmten Stelle aussieht.

DPS_open/start und DPS_stop/close sind klar und auch der Datentransfer funktioniert, aber wir haben  einen Effekt, den wir uns nicht erklären können. Bei häufigem Pollen mit DPS_get_output werden nämlich irgendwann (je häufiger desto schneller) die empfangenen Daten wieder zur SPS zurückübertragen... Die verwendeten Puffer werden aber nicht gemeinsam verwendet.

Vielleicht könnst Du Larry (das kommt aus dem Spiel?) zu mir mal einen Kontakt aufbauen, da Du keine Kontaktdaten eingetragen hast? (sonst hätte ich hierfür vermutlich auch einen anderen Thread gestartet)


----------



## Larry Laffer (30 Januar 2008)

Hallo hg42,
leider kann ich dir bei deinem Problem nicht wirklich weiterhelfen. Das C++ Programm stammt ja nicht von mir. Vielleicht aber trotzdem soviel :
Ich übertrage bei meinem Fall regelmaßig Strings an die CP5611 und frage zyklisch den Status ab bzw. übertrage Steuerbefehle. Dabei gibt es kein Problem. Den Fall eines Daten-reflektierens habe ich auch nicht beobachtet. Das heißt für mich, dass in deinem C++ Script irgendwas nicht astrein ist. Vielleicht stellst du das mal hier ein (ein bißchen kann ich mich noch daran erinnern, wie es bei uns war) oder du hast mal ein besonderes Augenmerk auf die der GSD-Datei entsprechenden Deklarationen (Die Definition des IO-Bereichs in der GSD-Datei muss ja 1:1 mit der Zuweisung in dem Script übereinstimmen).

Soviel erstmal als Anfang. Ansonsten müssen wir da warscheinlich konkreter werden ...

Larry Laffer stammt aus dem gleichnamigen Spiel (ich fand den Namen Klasse, habe das Spiel aber nie gespielt ...)

Gruß
LL


----------



## hg42 (30 Januar 2008)

wie gesagt funktioniert es im Prinzip, d.h. die Kommunikation findet statt, nur daß nach z.B. 5 sek. auf einmal in unserem Hilscher-CIF50-PB-Master (genauer im E/A-Monitor des Konfigurations-Programms Sycon von HIlscher) die Output-Daten wieder den Eingang überschreiben.

Da ich die Komplexität des eigentlichen Applikationsprogrammes aus dem Test heraushalten wollte habe ich auch ein Test-Programm auf einem etwas niedrigeren Level geschrieben.

Unser Test-Slave sieht im Prinzip so aus:

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

Baudrate: 1M5

MaxBuffer ist mit 255 vorbesetzt.

Öffnen der Schnittstelle:


```
DPS_open(mDeviceName,
                        &mDeviceHandle,
                        DPS_SM_SIMPLE,
                        mStationAddressInt,
                        0,
                        mPNOIdentNumber,
                        0,
                        &mInitData,
                        NULL,
                        mBaudrateIndex,
                        &mErrorDesc);
...
DPS_start(mDeviceHandle, &mErrorDesc);
...
while(iTimeElapsed.Time() * 1000 < mOpenTimeout)
   {
   if(DP_OK == DPS_get_output(mDeviceHandle, mInputData,
                            mInputDataLength, &mErrorDesc))
    {
    mConnected = true;
    memset(mInputData, 0x55, mInputDataLength);  // zum Test vorbesetzt
    break;
    }
 delay(100);
 }
...
```
dann gibt es eine send- und eine receive-Funktion:


```
bool Siemens_DP_Slave::
send()
  {
  mErrorDesc.error_code = 0;
  if(IsError(DPS_set_input(mDeviceHandle,
                     mOutputData, mOutputDataLength, &mErrorDesc))
    {
    close();
    return false;
    }

  return true;
  }
```


```
bool Siemens_DP_Slave::
receive()
  {
  uint8 iBuffer[MaxBuffer];
  memcpy(iBuffer, mInputData, MaxBuffer);

  mErrorDesc.error_code = 0;
  if(IsError(DPS_get_output(mDeviceHandle,
                      mInputData, mInputDataLength, &mErrorDesc))
    {
    close();
    return false;
    }

  #if Use_SendAfterReceive
  DPS_set_input(mDeviceHandle,
     mOutputData, mOutputDataLength, &mErrorDesc);  // hack???
  #endif

  #if Use_TestReplaceByte
  iBuffer[2] = 8;
  mInputData[2] = 8;
  #endif

  if(memcmp(mInputData, iBuffer, MaxBuffer))
    return true;

  return false;
  }
```
und dann wird es so benutzt:


```
int
main(int argc, char** argv)
  {
  Siemens_DP_Slave iIO;

  memset(iIO.mOutputData, 7, 255);

  if(!iIO.open())
    exit(1);

  int i = 0;
  int n = 0;

  while(true)
    {
    iIO.receive();
    if(! (++n % 30000))
      {
      memset(iIO.mOutputData, i = (i+1)%255, iIO.mOutputDataLength);
      iIO.send();
      }
    //printf("."); fflush(stdout);
    }

  return 0;
  }
```
"Input" und "Output" beziehen sich dabei übrigens auf die Sicht des Slaves, da die Nomenklatur sich nach der Applikation richtet, wo das Profibus-Modul nur eines von vielen Kommuikationsmodulen ist.

Wir linken entweder direkt die dpslib.lib oder laden die DPSLSTD.DLL dynamisch, mit demselben Ergebnis.

Zum Test haben wir verschiedenes ausprobiert, u.a. folgendes:

Wenn ich bei receive das #if Use_TestReplaceByte einkompiliere, dann wird ein Byte im empfangenen InputBuffer ersetzt. Würden nun im Test-Programm die InputDaten irgendwie wieder rausgeschickt, dann müßten die geänderten Daten beim Master auftauchen. Dem ist aber nicht so. Es werden die Daten kopiert, die der Master geschickt hat. Deswegen bin ich schon fast geneigt, zu denken, daß der Master die Kopie selbst macht...

Klammere ich das send allgemein aus, dann wird allerdings auch nichts kopiert.

Es gibt eine zeitliche Abhängigkeit von der Geschwindigkeit des Pollens (d.h. des Aufrufs von receive) in der Art daß die Zeit bis zur Kopie sinkt, wenn man häufiger pollt. Bei receive alle 10ms sind es z.B. 5sek, wobei es durchaus schwankt (etwa 4sek bis 10sek), polle ich wie hier im Beispiel sehr schnell kommt die Kopie in unter einer Sekunde, so daß man in Sycon die richtigen Daten kaum noch zu Gesicht bekommt.

Kompiliere ich #if Use_SendAfterReceive ein, dann funktioniert das Ganze anscheinend, ich bin mir aber nicht sicher, daß dann nicht ab und zu kurzzeitig doch die Kopie beim Master ansteht.

Ich frage mich, ob es vielleicht so gedacht sein könnte, daß man beim receive auch immer senden muß.

In der Doku zur DPSLIB steht ausreichendes über die Öffnen und Schließen der Schnittstelle. Zur Kombination DPS_get_output und DPS_set_input schweigt sich die Doku aber aus, es gibt nur ein Beispiel zu DPS_get_output.

Obige Frage läßt sich jedenfalls damit nicht klären. Eher würde ich das so lesen, daß man die beiden Funktionen beliebig gemischt verwenden kann.

Interessant wäre für mich jetzt vor allem, ob bei Eurem Projekt DPS_get_output und DPS_set_input immer regelmäßig aufeinander folgen.

Bei üblichen Gegebenheiten merkt man das Problem allerdings wie beschrieben erst, wenn man längere Zeit (also im Sekunden-Bereich) vom Slave aus keine Daten rausschickt.


----------



## Larry Laffer (30 Januar 2008)

Hallo hg42,
ich entdecke in deinem Script bekannte Elemente. Etwas vermisse ich aber :
Wie und wo hast du die Kopplung zur GSD-Datei realisiert ?
Dieselbe beinhaltet z.B. :
	
	



```
Module = "Daten-Kopplung" 0x31 , 0x2F,0x2F,0x27 , 0x2F,0x27
EndModule
```
Diese Zuordnung vermisse ich bei dir. Das obige Beispiel besagt :
0x31 = Input und Output  2 Bytes
0x2F = Output  16 Bytes
0x27 = Output  8 Bytes

Mehr als 16 Bytes lassen sich in einem Block nicht deklarieren ...
Input und Output sind hier aus Sicht der SPS.
Diese Definition muss bei der Initialisierung (ich glaube InitData) mit übergeben werden.

Gruß
LL


----------



## hg42 (30 Januar 2008)

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:


```
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;
  }
```


```
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.


----------



## hg42 (30 Januar 2008)

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.


----------



## Larry Laffer (30 Januar 2008)

... 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


----------



## hg42 (30 Januar 2008)

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?


----------



## Larry Laffer (30 Januar 2008)

... 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


----------



## hg42 (6 Februar 2008)

*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.


----------



## Larry Laffer (6 Februar 2008)

... 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


----------



## hg42 (6 Februar 2008)

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...


----------



## hg42 (6 Februar 2008)

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...


----------



## Larry Laffer (6 Februar 2008)

Hast du denn die Dual-Core-Geschichte im BIOS mal disabled ?


----------



## hg42 (6 Februar 2008)

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ß.


----------



## hg42 (5 März 2008)

Siemens hat anhand meiner Beschreibungen und Sourcen alles nachvollziehen können und will im April korrigierte Treiber liefern.


----------



## Ralle (1 April 2008)

@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.


----------



## Larry Laffer (2 April 2008)

@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


----------



## Ralle (2 April 2008)

Larry Laffer schrieb:


> @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 ...?
> ...



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  .


----------

