# Profibus DP Master Simulator



## FloNE (15 Oktober 2009)

Hallo,

ich schreibe im Moment meine Diplomarbeit in der es darum geht eine Profibusschnittstelle zu realisieren.
Es werden zwei Wege verfolgt, einmal der Weg mit einem Protokollkonverter von HMS und einmal über einen Single-Chip von Deutschmann (Unigate IC Profibus).
Ich benötige jetzt einen Master Simulator. Hierfür stehen Simulatoren von folgenden drei Firmen zur Auswahl:

- Bihl+Wiedemann
- HMS
- Deutschmann

Bihl+Wiedemann ist am günstigsten aber mein Betreuer meinte er würde die Hersteller nicht mischen wegen der Kompatibilität. Darin seh ich jetzt nicht das Problem, habe aber keine Erfahrung im Bezug auf Simulatoren.
Vielleicht hat ja einer von Euch schon mal damit gearbeitet und kann einen Empfehlen. Auch im Bezug auf die Bedienfreundlichkeit der Software.
Vielen Dank schon mal 

Grüße FloNE


----------



## Heiner05 (15 Oktober 2009)

Hallo FloNe,

die Simulatoren von Bihl, Deutschmann und HMS sind meines Wissens nach baugleich.
Ich würde Dir ein Bundle des HMS Anybus-IC für Profibus-DP und dem DP-Mastersimulator von HMS empfehlen.
Vorteil:
- im Bundle die günstigste Lösung von einem Anbieter
- beim Anybus-IC hast Du eine definierte Applikationsschnittstelle und keine weitere Arbeit auf dem IC. Beim Unigate IC hast Du 2 "Baustellen" zu berücksichtigen. Die Skript-Erstellung auf dem IC und dann noch Deine Applikation.

Ich wünsche Dir viel Glück für Deine Arbeit.

Gruß,

/Heiner05


----------



## FloNE (16 Oktober 2009)

Hallo Heiner05,

ich danke dir für deine schnelle Antwort.
Da hab ich wieder etwas Erfahrung bekommen, denn im Vorfeld hat sich keiner Gedanken drüber gemacht eventuell ein Bundel zu beschaffen. So wird mit dem IC von Deutschmann schon gearbeitet. 
Ich hatte schon die Vermutung das die Simulatoren ähnlich sein müssen, denn für eine genormte Feldbussschnittstelle kann die Funktion nicht so sehr unterschiedlich sein. Zumal ich festgestellt hab das HMS und Bihl die identische Software zum simulieren verwendet. 
Ich bin ganz froh solche Erfahrungen machen zu dürfen, besser jetzt als später 
Grüße


----------



## Marillo (9 November 2009)

Hallo FloNe,
mich würde mal interessieren was für ne Lösung du jetzt verfolgst bzw. umsetzen wirst bezüglich der Hardware. Wir scheinen da eine ähnliche Aufgabe zu haben ;-)
Bin mir da nämlich auch noch nicht so sicher wem ich von den genannten Firmen das Vertrauen schenken soll!
Klar eine Frage des Preises ist es auch, glaube aber nicht eine ganz so große. Denn wenn man bei der einen Lösung schneller zum Ziel kommt und da ein paar Euro mehr gelöhnt hat ist das wohl verschmerzbar. Kannst du absehen bei welcher Harware Lösung der Entwicklungsaufwand geringer ist ?? Also ich muss eine Feldbusssystem in einer "eigene" Elektronik mit µC realisieren, zunächst einmal Profibus.
Zur Zeit favorisiere ich Deutschmann UNIGATE IC serie. Weißt du wie bei der Anybus IC serie die Kommunikation (phy. Schnittstelle, Implementierung)zwischen dem Anybus IC und der evt. eignen Hardware aubläuft?
Bei Deutschmann hat man mit dem Scripting Tool offensichtlich da die "Narrenfreiheit".
Und...

Heiner05

was meinst du mit zwei Baustellen. Klar du musst dich bei Deutschmann mit dem Scripting beschäftigen, aber was hat es denn mit einer eigene Applikation auf sich. Korregiere mir bitte sofort aber kann ich mit einem Simulator(Master) auf einem PC nicht "alles" simulieren. Ich meine damit die gesamte Kommunikation. Ich muss doch "nur" dafür sorgen das auf der Feldbusseite alle der Profibus Spezifiaktion entsprechende Information einem möglichen Master bereit gestellt werden oder sehe ich das falsch.
Ich bin sehr dankbar für eure Erfahrungen.

Gruß

Steff


----------



## FloNE (10 November 2009)

Hallo Steff,

ich habe hier ein Unigate IC liegen, mit Entwicklungsboard und einem Master Simulator von Bihl + Wiedemann.
Die Anbindung des IC's erfolgt über die UART Schnittstelle. Im Moment betreibe ich das Entwicklungsboard allerdings noch ohne eigene Hardware. Hab es über RS 232 mit dem PC verbunden. Bei interesse kann ich aber über Erfahrungen berichten die ich mit eigener Hardware gemacht habe. 

Im Script werden mit einem Befehl die Daten von der RS 232 Schnittstelle gelesen und gespeichert. Mittels einem zweiten Befehl, können diese dann auf den Bus geschrieben werden. Mehr Einfluss hat man auf die Übertragung nicht. Was dazwischen mit den Daten passiert kann man aber selber bestimmten. Verechnen, Schleifen, Verzweigungen, alles was das Herz begehrt. Mit hilfe zahlreicher Beispiele, der Dokumentation und der Hilfe sind die Befehle schnell zu verstehen, sodass man damit arbeiten kann.

Da ich zwischendrin an einer anderen Baustelle beschäftigt war, bin ich jetzt erst dabei mich mit der Schieberegister Schnittstelle zu beschäftigen und kann dazu leider noch nix sagen. So wie ich das Script aber einschätz sollte das kein großes Problem darstellen.

Zum Anybus IC kann ich leider auch nur das wiedergeben was auf der Homepage dazu steht.

Ich hätte Interesse daran zu erfahren welche Lösung du dann verfolgst. Solltest du den Anybus IC nehmen würde ich mich über Erfahrungen freuen. Im anderen Fall könnte ich mir einen Erfahrungsaustausch vorstellen. :s12:

Grüße FloNE


----------



## Marillo (10 November 2009)

Hallo FloNE,
einen weiteren Erfahrungsaustausch in der Sache wär super. Also habe mich jetzt auch zunächst für deutschmann entschieden, allerdings als komplettlösung d.h. das master simulation tool ist auch mit dabei. dies alles zunächst für profibus. dies alles hat folgenden grund. wie haben hier in unserer hardware "schon" ein selbst entwickeltes Protokoll/Telegramm laufen das an der uart an unserem controller (8951) bereitgestellt wird. dieses ist auch recht simpel und soll nicht verändert werden. nun hat man ja anscheinend "alle" möglichkeiten mit dem protocol developer von deutschmann. ich hoffe mal das klappt damit und man kann mit dem vorhanden befehlsvorrat unser format ohne große stoplersteine verarbeiten.

bei hms und der anybus ic variante, so habe ich das jedenfalls verstanden, schreiben die das protokoll schon vor (RTU) und somit müßte ich unser eigenes protokoll umschreiben (ist ja auch mehr aufwand). 

wie sind denn die von dir gewonnenen erkenntnisse über profibus dp bzw. hast du schon ne vorstellung von den "diensten" die laut profibus spezifikation (DPV0) von einem slave einem möglichen master bereit gestellt werden müssen?? 

gruß


----------



## FloNE (10 November 2009)

Muß denn euer Gerät das Protokoll ausführen wenn es über Profibus kommuniziert? Denn für das Unigate IC reichen auch nur die Daten. Wär einfacher.

Bei dem Gerät an dem ich mitarbeite wird es einen Softwareschalter geben, ob es ein Protokoll über RS 485 ausführt, oder aber die Daten an den IC weiterleitet, da beide Varianten für verschiedene Situationen gewünscht werden ohne das es zu aufwendig wird.

Zu beachten ist auch, dass das Script etwas langsamer Arbeitet als zb reiner C-Code. Deshalb stößt man bei einem aufwendigen Script schnell an die Zeitgrenzen, wenn solche vorhanden sind. 

Ich verfolge ja noch die Lösung mit dem Anybus Communicator von HMS. Der arbeitet auch mit Modbus RTU, es ist aber möglich eigene Protokolle zu definieren. Was natürlich mit etwas aufwand verbunden ist, aber ganz gut funktioniert.

Zu den Diensten von Profibus hab ich in den zahlreichen Büchern die ich in der Bibliothek ausgeliehen habe was gelesen. Bis jetzt hab ich sie aber noch nicht selber gebraucht, da die Kommunikation in einem Chip auf dem IC von Deutschmann integriert ist. Sobald du die Daten die gesendet werden sollen freigibst liegt es nicht mehr in deiner Hand wie sie über den Bus übertragen werden. 

Buch Empfehlungen kann ich dir geben wenn du das möchtest 

Grüße


----------



## Marillo (11 November 2009)

Hallo,
dann gib mir mal ne buchempfehlung für profibus bitte!
Danke

gruß


----------



## Marillo (11 November 2009)

Hi ich nochmal,
jetzt was inhaltliches ;-). Also in unsere Hardware, da handelt es sich im wesentlichen um netzteile. da werden signale von einem möglichen Master (SPS, PC) bei bedarf gefordert. das können sein, istwerte, gerätespezifische daten. es können auch daten von einem master gesendet werden wie z.b. stellwerte(sollwerte) wie spannung, strom, leistung etc. ein funktionsgenerator ist auch integriert der wenn er in betrieb ist permanent signale sendet. du siehst, kommunikation auf dem bus könnte durchaus groß sein. all diese signale werden in unserem µC aufbereitet und an der uart schnittstelle in einem bestimmten, eigenen telegrammtyp bereit gestellt. die baudrate steht "auch" zu 99% fest, da mit dieser eine fehlerfreie übertragung sichergestellt werden kann. die performance also die geschwindigkeit der datenübertragung spielt primär nicht so die rolle.


----------



## FloNE (12 November 2009)

Sorry war leider etwas beschäftigt. Kriegst mal schnell die Bücher, morgen hab ich etwas mehr zeit. 

- Profibus DP von Manfred Popp, Hüthig Verlag
- Profibus von Klaus Bender, Hanser Fachbuchverlag
- Bussysteme in der Automatisierungs- und Prozesstechnik von Gerhard Schnell, Vieweg Verlag

Die find ich persönlich recht gut und haben mir geholfen.

Hier noch ein Link: http://www.profibus.felser.ch/


----------



## Marillo (19 November 2009)

Moin FloNe,

still alive??

und hast Zeit für dein Projekt gehabt und neue Erkenntnisse gewonnen?

Also seid gestern ist bei mir endlich die Hard- und Software eingetroffen, sodaß ich endlich richtig loslegen kann. Und da hab ich auch schon ein paar fragen. Vielleicht kannst du mir helfen?!
Wir haben ja das Master Simulationstool auch von Deutschmann geordert. Ich bin hier quasi bei den ersten Schritten. Ich habe vor eine komplette Simulation (soweit dies geht) aufzubauen d.h. Evaluationkit mit UNIGATE IC auf der einen Seite und PC mit installierten Mastersimulation (Profibus) auf der anderen Seite. Jetzt hat das EVA Board ja nicht nur eine DEBUG Schnittstelle - streng genommen sogar zwei (USB Variante) (zunächst nutze ich die mit Phoenix bzw DSUB Anschluß) Hiermit kann ich für das geschrieben Scripts im Protocol Developer testen) richtig??
Sondern auch noch eine Applikations Schnittstelle (hier auch wieder strenggenommen zwei - USB Variante). Ich möchte auch hier zunächst die Schnittstelle mit Phoenix und DSUB Anschluß nutzen. Der "Nachteil" ist wohl das ich für diese Konfiguration(en) 3 serielle DSUB Anschlüße an dem PC brauch (inkl. der Schnittstelle der Master Simulation) 
RICHTIG???
Wie gesagt korregiere mich wenn ich falsch liege. Aber nur so kann ich auch das Tool WINGATE (auch von DEUTSCHMANN) nutzen und ein beliebiges fertiges und zuvor compiliertes Script in das UNIGATE IC rüber spielen (Stichwort: Konfigurationmodus auf EVA Board) und dann laufen (RUN Betriebsmodus) lassen, oder?

Und jetzt noch was wichtiges! Wofür ist eigentliche die/eine Applikationsschnittstelle. Dient sie zur Simulation einer kundenseitigen Hardware. Und kann ich die dann mit beispielsweise einem RS232 Monitor Programm wie es Deutschmann auch mitliefert, simulieren??


Jetzt ist doch was viel geworden ;-)

Gruß


----------



## FloNE (19 November 2009)

Guten Morgen,

ja ich lebe noch  Ist grad alles irgendwie ... komisch ^^

Wir konzentrieren uns gerade auf den Protokollkonverter weil der im ersten Schritt genutzt werden soll. Die Tage wird hoffentlich das eigentliche Gerät soweit fertig das man damit arbeiten kann. Es stehen dann Messungen an ob die Zeit eingehalten werden kann die vorgegeben ist. 

Meine erste Frage an dich, benutzt du das EVA Kit so wie du es erwähnst oder das Developerkit? Ich für meinen Teil benutze das Developerkit. Weiß leider nicht wie groß die unterschiede sind.

Deiner Beschreibung nach klingt das aber ähnlich.

Also das Developerkit hat einen USB Anschluss, der zwei COM Schnittstellen am PC Darstellt. Eine der beiden ist zum Debuggen über den Protokollkonverter, die andere für den RS 232 Monitor über den Daten empfangen und gesendet werden können. In dieser Variante werden eine COM Schnittstelle über DSUB für den Master Simulator und eine USB Schnittstelle für den Debugger und die Applikationsschnittstelle benötigt. 

Möchtest du zum Debuggen und für die Applikation die DSUB Stecker verwenden benötigst du drei entsprechende Schnittstellen am PC. Ich habe leider nur USB an meinem PC und muß deshalb RS232/USB Umsetzer verwenden. Nicht schön aber funktioniert 

Um ein Script mit Wingate einzuspielen wirst du eine der beiden COM Schnittstellen spendieren müssen, sobald das Script aber im IC ist benötigst du diese nicht mehr. So kannst du dann das Script im Betrieb nicht debuggen. Dazu mußt du das Script über den Protocol Developer im Debug Modus starten. Das Script läuft dann auf dem IC auch zusammen mit dem Simulator, aber du kannst es wie gewohnt Debuggen. 

Die Frage mit der Applikationsschnittstelle habe ich indirekt schon beantwortet  Damit kannst du den RS 232 Monitor der mitgeliefert ist verwenden oder aber auch eine eigene Hardware über RS 232/422/485 anschließen. Zweiteres hab ich noch nicht gemacht, da ich mich bis jetzt nur mit der Script programmierung beschäftigt habe und noch keine eigene Hardware verwendet hab. Wie gesagt im Moment steht der Protokollkonverter im Vordergrund. 

Ich hoff ich konnt dir helfen und glänze nicht wieder so lang mit Abwesenheit :s12:


----------



## Marillo (19 November 2009)

Servus,
jo habe mich die ganze Zeit verschrieben. Ich meine natürlich das Developerboard. (das EVA taugt ja nix ;-))


----------



## FloNE (19 November 2009)

Naja obs taugt oder nicht ist wohl Ansichtssache  Aber dann passt das ja was ich als Antwort verfasst hab


----------



## Marillo (19 November 2009)

Danke erstmal wie den Gedankenaustausch,

a soweit so gut. Habe jetzt erstmal die USB Schnittstelle (DEBUG und Applikation) genutzt und den Master Simulator an einer reellen COM dran (COM1) weil ich von den ITlern noch auf zwei zusätzliche COM´s warten muss. Auf der einen Seite habe ich jetzt den RS232 Monitor der Applikationsschnittstelle zugeordnet und dem Protocol Developer die DEBUG Schnittstelle. Jetzt möchte ich parallel das Profibus Master Tool starten (wie gesagt an COM1). Hier muss ich unter Options->Module noch einige dinge einstellen. Hier tue ich mich schwer welche Profibusadresse (Profibus Slave ID) eingestellt werden muss. Welche GSD Datei ich brauche ist soweit ist soweit klar. Wie spielt die Einstellung Modulename hier mit. Ich glaube zunächst muss das was hier eingetragen wird von der GSD Datei unterstützt werden.Aber was hat es sonst noch damit aufsich.
Jedenfall bekomme ich von Developerkit immer einen Busfehler angezeigt (rote LED) an der Schnittstellen.
Hier noch die Meldung vom STATE Fenster in der Master Simu.

RESET Profibus DP
CHANGE MODULE
  module: Close Slave
  module: select module
  module: store new module in registry
  ERROR: select new module


----------



## Marillo (19 November 2009)

Aso,

hab vergessen zu sagen das ich ein Beispiel script rein gespielt (jetzt über den Protocol Developer im DEBUG Modus) habe. Das heißt Testmode_ICs_No_Bus.dss wobei ich die Funktionen BusStart und Wait(Bus_Active) aktiviert habe - die wahren vorher auskommentiert.
In diesem Script wird eine serielle Schnittstelle konfiguriert mit set befehlen (Baudrate, databits, startbits und parity) . glaube das dies die schnittstelle für die APP ist, richtig??
Vielleicht fehlt dem die Parameter con der BUS Seite?!


----------



## FloNE (19 November 2009)

Das waren auch meine ersten Schritte 

An der Slave Adresse hab ich mir fast die Zähne ausgebissen. Im Wingate kannst du sehen welche Slave Adresse im Moment vergeben ist. War bei mir 127, könnte bei dir auch so sein. Kannst sie da auch ändern. Nach dem ich dann aber das Beispiel Script ausgeführt hatte war sie wieder auf 127 zurückgestellt. 

Hab dann auch nicht mehr das Programm von Deutschman für den Master Simulator verwendet. Das war mir unsympathisch. Hab das von Bihl + Wiedemann genommen. Kannst du hier bekommen und sollte auch mit dem von Deutschmann funktionieren, da das Deutschmann Tool auch mit dem Simulator von Bihl + Wiedemann geht. 

http://www.bihl-wiedemann.de/deutsch/down/downldsw.htm#simulator

Ich hab das Script Profibus_IC_Basisboard.dss verwendet. Hier war das Problem, dass er an dem Befehl wo er auf den Bus wartet 

Wait ( Bus_Active ) ;

hängen geblieben ist. Hab dann in einem anderen Script folgenden Befehl gefunden und verwendet:

var L_0xE0         : Long ;         moveconst ( L_0xE0, 0xE0);

:LoopBusState;
 Get ( ReadBusState , L_BusState ) ;
 if L_BusState less L_0xE0 then :LoopBusState;

Hier wird der Status des Bus abgefragt und wenn der den Wert 0xE0 erreicht befindet sich der Bus im Data Exchange Modus. Leider find ich die Quelle grad nicht auf die schnelle, aber ich such sie noch, würd mich selber interessieren wo das stand.
Auf jedenfall hat das dann funktioniert. Auch wurde dann nicht mehr die Slave Adresse verstellt.

Die konfiguartion der RS Schnittstelle hab ich von Hand gemacht. 

Set ( Baudrate , 9600 ) ;
Set ( Databits , 8 ) ;
Set ( Startbits , 1 ) ;
Set ( Parity , none ) ;

Hab gern im Detail was da passiert und vertrau vorgefertigtem nicht immer. 

EDIT: Seh grad das du deine RS Schnittstelle auch so konfigurierst wie ich ^^


----------



## Marillo (9 April 2010)

*Hallo again*

Servus,
auch wenn der letzte Post schon etwas zurückliegt stelle ich mal auf Verdacht eine Bestandmeldung bezüglich des PROFIBUS Projekts.
Also habe "mittlerweile" ein ablauffähiges Programm über den Protocol Developer für einen zyklischen Datenaustausch mit einem Feldgerät geschrieben. Dies alles funktioniert aber nur solange wie ich die von Deutschmann mitgelieferte GSD Datei benutze. Bei einer syntaktisch richtig geschrieben anderen GSD Datei funktioniert mein Programm nicht mehr d.h. der Initialisierungmechanismus meldet einen Fehler. Zwangsläüfig kommt es zu keinem DATA EXCHANGE.
Zur Hard und Software. Zum Einsatz kommt wie schon gesagt der Protocol Developer von Deutschmann in Verbindung mit einem UNIGATE IC. Als Mastersimulation benutze ich wahlweise entweder das Tool für PROFIBUS von Deutschmann oder das von Bihl und Wiedemann, die jeweils über einen Dongle (ich nutze denn DPV1 Typ). Letzteres ist komfortabler. Stichwort: Konfigurator der Module aus GSD Datei für Master. Dieser Mechanismus ist meiner Meinung nach auch notwendig denn sobald man eine Kommunikation über mehrere Datenbereiche und Datenbreiten ausführen möchte kommt man über die Auswahl mehrerer Module nicht umrum.
FloNe, wenn du das ließt:
Wie ist der Stand bei dir, ist dein Projekt abgeschlossen?
Also ich denke ich werde noch was brauche da ich auch den azyklsichen Verkehr implemtieren möchte/muss.

Gruß


----------

