Softnet PB

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.
 
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 ?
 
...
ach ja,
hatte ich schon vergessen : Ich habe immer noch einen Busfehler obwohl meiner Meinung nach alles OK ist ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.

Arbeitest du bei Siemens ?
Nöh. Ich arbeite (oder "kämpfe") MIT Siemens.
 
...
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.
 
Zuletzt bearbeitet:
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 ...
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.

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 ?
 
Zuletzt bearbeitet:
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 ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Und ich bin über deine Hilfe froh ...! :D :D :D
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 !
 
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 ...
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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?
 
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
 
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)
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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:

Code:
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:

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

  return true;
  }
Code:
   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:

Code:
  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.
 
Zuletzt bearbeitet:
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. :
Code:
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


 
Zurück
Oben