Profibus DP-Slave Kommunikation in C
Von Jörg S., Marc H. und Johannes F.
Geschrieben für MSP430F2252. Getestet an Siemens S7 mit 19,200 und
93,750kBit/s.
Basis war Reengineering der Kommunikation eines DP/DP Kopplers mit einer
S7 und vor allen das Profibus Handbuch von Prof. Max Felser (ein
Dankeschön an dieser Stelle).
Die Entwicklung begann mit kompletter Ahnungslosigkeit vom Profibus. Von
daher ist der Code ständig verändert und erweitert worden und somit
nicht unbedingt ein Ingenieurs-Glanzstück ;)
Der DP-Slave ist soweit Profibus konform das normale I/O Daten gesendet
und empfangen werden können, da der Fokus auf diesem Aspekt lag.
habe gleich ein paar fragen dazu!
1. wie stark ist der uC ausgelastet (flash und performance) > gehts noch
schneller / ist noch platz für andere applikationen?
2. warum dieser uC (habt ihr einen komerziellen / universitären
Hintergrund)?
3. wie habt ihr die parametresierung der s7 gemacht?
4. was für treiber habt ihr genommen und wie habt ihr die
abschlusswiderstände dimensioniert?
5. was für eine applikation habt ihr hiermit realisiert?
6. habt ihr schon bugs gefunden?
danke
tbd
>1. wie stark ist der uC ausgelastet (flash und performance) > gehts noch>schneller / ist noch platz für andere applikationen?
Er muss halt alles empfangen was los ist und erst dann auswerten ob es
wirklich für ihn ist. Da empfangen und senden interruptgesteuert ist,
hat der µC viel Zeit was anderes zu machen. Im speziellen Fall wird noch
ein 2x16 Zeichen Display mit 4 Tasten, IR Empfänger und Temp.Sensor
(TSic) "nebenbei" behandelt.
Der MSP läuft auf 8Mhz und hat 16kB FLASH und 512B RAM. Der Profibus
verbraucht glaub ich um die 2kB FLASH und wohl um die 130B RAM. Wobei
der RAM Verbrauch fast zu 100% aus den Ein- und Ausgangsregistern und
dem UART Buffer besteht.
Kommunikation geht sicherlich noch schneller, hab ich aber noch nicht
getestet da die aktuelle Geschwindigkeit erst mal ausreichend ist.
>2. warum dieser uC (habt ihr einen komerziellen / universitären>Hintergrund)?
Ich habe vor allem beruflich mit dem MSP430 zu tun, hab aber auch schon
vorher damit privat gearbeitet. Von daher kam nur der MSP in Frage :)
Das Projekt ist privat.
>3. wie habt ihr die parametresierung der s7 gemacht?
Über den Part kann ich wenig sagen, da kennen sich die anderen zwei
"Mitstreiter" aus. Es muss halt ne GSD Datei für den Slave angelegt
werden mit der man die Grundparameter festlegt.
>4. was für treiber habt ihr genommen und wie habt ihr die>abschlusswiderstände dimensioniert?
RS485 Transceiver ist der MAX3485. Abschlusswiderstand ist 120Ohm
vorgesehen. Halt Standard RS485...
>5. was für eine applikation habt ihr hiermit realisiert?
Hausautomation. Ich denke da wird es dann noch ne komplette
Projektvorstellung geben, die Entwicklung ist aber noch nicht wirklich
abgeschlossen.
>6. habt ihr schon bugs gefunden?
Das einzige was mir einfällt ist die MS1/2 Kommunikation. Wenn sowas
mitläuft geht nix mehr, das wird wohl die nächste Erweiterung sein die
rein kommt.
Auf Seite 23 der von dir benannten Datei von Max Felser
(http://www.profibus.felser.ch/technik/PROFIBUS_Technik.pdf) ist
beschrieben, das die Terminierung im Stecker realisiert wird.
Aber sonst finde ich es wirklich interessant! Die einzige realisierung
auf einem uC die ich kenne ist diese:
http://www.htw-dresden.de/fe/labor/mikror/projects/pb_slave/
Diese ist jedoch leider auf ASM geschrieben...
Habt ihr eine Testhardware gebaut oder könnt ihr eine Applikation damit
als Demo zeigen?
>das die Terminierung im Stecker realisiert wird
Wenn man so einen Profibus Stecker nutzt... Muss man ja nicht.
>Habt ihr eine Testhardware gebaut oder könnt ihr eine Applikation damit>als Demo zeigen?
Im Anhnag mal die "SPS-Remote" Einheit. Damit soll man dann in jedem
Zimmer die Heizung, Rolladen, Wecker usw. steuern. Funktioniert so weit
schon im Testaufbau.
>Handelt es sich um DPV0(zyklisch), DPV1(azyklisch), DPV2(isochron)?
DPV0
Im Anhang die nächste Stufe, die SPS-AudioControl zur umschaltung von
Audio Signalen für die Deckenbeschallung der Räume. Ansonsten gibt's
dann noch die Dimmersteuerung. Da hab ich aber gerade kein Bild von.
Hallo Joerg,
starke Sache - zwei Fragen hätte ich:
1. hast Du es auch an einer S7-300 getestet?
2. Wie sieht Dein physikalisches Interface aus?
Gruss Otto
>1. hast Du es auch an einer S7-300 getestet?
Wenn ich mich nicht täusche wird das an einer S7-315 CPU betrieben. Was
anderes wäre nicht ohne weiteres zur Hand.
>2. Wie sieht Dein physikalisches Interface aus?
Also Profibus ist RS485 wenn du das meinst? A, B von Profibus an den
MAX3485 Transceiver und dann halt auf den UART vom MSP430.
Hallo Jörg,
> Dann wäre es ja nichts besonderes, oder? ;)
ja - schon - aber "nur die halbe Lösung", denn die Adapter gibt es als
USB oder RS232 auf Profibus und die kosten schon ein paat Euro.
Es ist halt gut zu wissen, dass Du es wirklich mit selbstgestrickter HW
realisieren konntest......
oft sind es dann die "kleinen Gemeinheiten", weshalb es nicht läuft....
;-)
Gruss Otto
Wenn du jetzt noch eine Demo-Software hättest... ach wäre das schön ;)
Ne jetzt mal ganz im ernst! Ich finde es wirklich prima was ihr da auf
die beine gestellt habt!!!
Aber gerade im bereich Hausautomatisierung denke ich das es andere
Schnittstellen (CAN/CANopen) gibt die sich im gegensatz zu propritären
systemen etabliert haben. Das soll euch um gottes willen nicht davon
abhalten weiter zu machen! So ein ASIC für Profibus ist nämlich super
teuer.
Hallo Jörg,
prima Projekt. Ja, die GSD-Datei wäre schon ziemlich interessant. Und
vor allem auch, welche E/A-Konfiguration damit abgedeckt wird.
Vielleicht könntest Du ja bspw. die GSD-Datei von Eurer "SPS-Remote"
Einheit senden und dazu, welche E/A's ansprechbar sind (evtl. auch einen
Schaltplan).
Joline
>welche E/A's ansprechbar sind
Wie meinst du das? Die E/As werden halt für Sachen wie Raumtemperatur,
Aussentemperatur, Solltemperatur (Heizung), Weckzeit Wochentag, Weckzeit
Samstag, Weckzeit Sonntag, Rolladen Steuerung, SPS Uhrzeit und sowas
"misbraucht". Physikalische I/Os werden zumindest bei der SPS-Remote
nicht gesetzt.
Marc will dann noch genauer was zu der GSD Datei schreiben.
damit des keine diskusionen gibt, ja die "Ident_Number" ist eine vom
großen S. wir haben diese gsd nur als muster genommen. da es sich um
kein kommerzielles projet handelt, sondern nur einen privaten test, gibt
es damit auch keine probleme.
>>welche E/A's ansprechbar sind>Wie meinst du das? Die E/As werden halt für Sachen wie Raumtemperatur,>Aussentemperatur, Solltemperatur (Heizung), Weckzeit Wochentag, Weckzeit>Samstag, Weckzeit Sonntag, Rolladen Steuerung, SPS Uhrzeit und sowas>"misbraucht". Physikalische I/Os werden zumindest bei der SPS-Remote>nicht gesetzt.
Naja, auf dem Bild sind u.a. 4 Taster zu sehen. Da könnte man ja auf die
Idee kommen, dass das Eingänge sind, die an die SPS weitergeleitet
werden...
Danke für die GSD Datei. Aus der Konfiguration kann ich sehen, dass da
32 Byte als Ein- und als Ausgang ausgetauscht werden können (im Beispiel
12..46). Wie kann man nun Daten vom Slave an die SPS senden? Also ich
meine, ich möchte z.B. Daten senden, die man dann auf EW14 in der SPS
empfängt? Oder umgedreht, wenn man auf den Ausgang AW16 einen Wert
schreibt, wie kann man den im Slave empfangen? Kommt da immer ein
Bytehaufen mit der Länge 32 an, den man selbt auseinander nehmen
muss/kann?
Joline
>Naja, auf dem Bild sind u.a. 4 Taster zu sehen. Da könnte man ja auf die>Idee kommen, dass das Eingänge sind, die an die SPS weitergeleitet>werden...
Die Tasten sind nur für die Menü-Steuerung vom Gerät, die SPS bekommt
davon nichts mit.
>Kommt da immer ein Bytehaufen mit der Länge 32 an, den man selbt>auseinander nehmen muss/kann?
Genau das, ja.
Noch eine Frage zur Hardware:
Da ist am UART des Controllers nur ein RS485-Baustein angeschlossen und
dieser hängt dann direkt am Profibus, richtig?
Joline
>Da ist am UART des Controllers nur ein RS485-Baustein angeschlossen und>dieser hängt dann direkt am Profibus, richtig?
Genau, alles Standard RS485 Technik.
>gibt es zu Eurem Projekt auch eine zusammenfassende Dokumentation />Website?
Nö :) Gibt aber noch einen kleinen "Schwesterthread" im SPS-Forum:
http://www.sps-forum.de/showthread.php?t=15510
Wie gesagt ist das Projekt ja auch noch nicht abgeschlossen. Von daher
werden ich auch (vorerst) keine Schaltpläne o.ä. einstellen. Fragen zur
Hardware dürfen aber natürlich gestellt werden.
Hallo Jörg,
mensch, deine Schalter-Einbauten find ich Klasse.
Wärst Du bereit hierzu die Schaltpläne & Board (insb. Dimension-Layer),
sowie Befestigungsmöglichkeiten offen zu legen?
Fänd ich super. Ich bin grad dabei einen Unterputz-Einsatz aufzubauen;
Funktionsmöglichkeit soll sein: Temperatur, LCD, Dimmer, 1xSchaltkontakt
(für nächste Steckdose), BUS-Anschluß.
Ich danke Dir sehr
>Wärst Du bereit hierzu die Schaltpläne & Board (insb. Dimension-Layer),>sowie Befestigungsmöglichkeiten offen zu legen?
Das mit den Schaltplänen hatte ich ja schon gesagt.
Bezüglich Befestigungsmöglichkeiten dürfte sich das Problem stellen das
wir Tragringe von HEWI bzw. Berker verwendet haben die ich bei uns in
der Firma aus dem Schrott geholt habe und die man wohl sonst nicht im
freien Handel bekommt. Alternative wäre evt. der Tragring 12700 von
Gira. Dafür müsste man das Layout aber ändern, von daher würden meine
Dimensions wohl nicht sonderlich helfen.
>es gibt noch gira tragring AMP steckbar 019100 ca.3€>oder einfach eine normale steckdose für 2€ und den rest in den müll ;-)
Da muss man dann aber erst mal schnitzen bis man was brauchbares hat.
Hier mal die Rückseite der SPS-Remote.
Wie man sehen kann bietet dieser Tragring schön viel Platz für
rückseitige Bauteile.
Links der RS485 Transceiver, mittig der MSP430 mit 8MHz Resonator, unten
der 8-polige JTAG Stecker, mittig der 6-polige RS485 Stecker (VCC, 2xA,
2xB, GND), rechts 3,3V Spannungsregler.
>wie kann bei Euch die Slave-Adresse eingestellt werden?
Bei der SPS-Remote wird sie per Menü eingestellt und in's Flash
gespeichert.
Bei der AudioControl und dem Dimmer hat die Steuereinheit dann
Dip-Schalter.
Bei Profibus muss beachtet werden das die Adresse nicht größer als 127
werden darf!
>Wird die Adresse dezimal oder hexadezimal erwartet?
Wo ist der der Unterschied? :) Hex oder Dez. ist ja nur ne
unterschiedliche Darstellung.
hi jörg, im sps-forum hat mir einer geschrieben des es mit mikropascal
und pic controller fertige kommunikationbausteine gibt, geschrieben in
pascal für RS485 LCD anzeigen serielle schnittstellen und so. kannst ja
mal schaun ob man davon etwas übernehmen kannnnnnn.
Im Anhang der aktuelle Stand.
Da einige Fragen zur Implementierung aufgetaucht sind, hier mal die
etwas genauere Beschreibung des Code:
Globale Variablen:
char uart_buffer[MAX_BUFFER_SIZE];
Der UART Daten Buffer in den alle Daten die ankommen gespeichert werden.
unsigned int uart_byte_cnt;
Zähler für die Anzahl der Bytes die in uart_buffer[] eingelesen wurden.
unsigned int uart_transmit_cnt;
Zähler für die Anzahl der Bytes die bereits gesendet wurden. Ist nur
wichtig wenn man die Interrupt Sende-Funktion benutzt.
unsigned char profibus_status;
Aktueller Status der Profibus Schnittstelle.
unsigned char slave_addr;
Wie der Name schon sagt.
unsigned char master_addr;
Könnte man wahrscheinlich auch weg machen, da wird eh immer nur die
source_add reinkopiert.
unsigned char group;
Bisher auch unnötig da nicht benutzt.
unsigned char data_out_register[OUTPUT_DATA_SIZE];
Hier die Daten reinkopieren die zur SPS sollen (Daten Slave -> SPS).
unsigned char data_in_register [INPUT_DATA_SIZE];
Hier kommen die Daten der SPS rein (Daten SPS -> Slave).
unsigned char Input_Data_size;
Anzahl der Bytes die die SPS senden will.
unsigned char Output_Data_size;
Anzahl der Bytes die die SPS vom Slave erwartet.
Das Konzept der Input- und Output_Data_size muss evt. überdacht werden
da die SPS wohl Modulabhängig auch mehrere "Blöcke" Ein-und
Ausgangsdaten senden kann. Da wird aktuell dran geforscht.
unsigned char Vendor_Data_size;
Unbenutzt
Was ist nötig um das ganze zum laufen zu bekommen?
Zur Initialisierung benötigt der Slave erst mal eine Adresse. Sollte
zwischen 1 und 126 liegen. Im Code kommt sie von der Funktion
read_slave_addr();
Dann muss man die Zeitsteuerung rein bekommen. Im Code mit Timer A
erledigt (unten mehr dazu). Grundsätzlich mal die Zeit Tsyn abwarten
(Zeit ohne UART Kommunikation) und dann alles an Daten einlesen und
profibus_RX() aufrufen. Die Funktion erledigt eigentlich alles
automatisch.
Wichtige Stelle ist diese:
1
// Daten von Master einlesen
2
for(cnt=0;cnt<INPUT_DATA_SIZE;cnt++)
3
{
4
data_in_register[cnt]=uart_buffer[cnt+7];
5
}
6
7
// Daten fuer Master in Buffer schreiben
8
for(cnt=0;cnt<OUTPUT_DATA_SIZE;cnt++)
9
{
10
uart_buffer[cnt+7]=data_out_register[cnt];
11
}
Sollte selbsterklärend sein, oder? SPS Daten einlesen, Slave Daten raus.
Die Funktion profibus_send_CMD() macht alles selber, nur die Funktion
profibus_TX() muss wieder an eure Hardware angepasst werden. Einfach die
Anzahl length Bytes von *data auf den RS485 schicken, fertig.
Hardware abhängig ist also nur die UART Empfangs- und Sendefunktion so
wie die Zeitsteurung. Die Auswertung der Daten sollte auf jedem
Controller laufen. Für einen einfachen Taster oder Schalter/Relais Slave
kommt man auch komplett ohne Interrupts aus.
Ein Wort zur Zeit-Steuerung:
1) WAIT_SYN: Warten auf Tsyn (Gewisse Zeit ohne UART Kommunikation).
2) Wenn Tsyn erreicht ist auf WAIT_DATA schalten
3) In der Zeit WAIT_DATA alles an UART Daten einlesen und auf GET_DATA
gehen
4) GET_DATA hat ein Timeout. Wenn eine gewisse Zeit keine weiteren Daten
über UART rein kommen wird profibus_RX() aufgerufen um die Daten
auszuwerten
5) Beim senden wird auf SEND_DATA geschaltet
6) Sind alle Daten rausgeschickt, gehen wir wieder auf WAIT_SYN und das
Spiel beginnt von vorn.
wirklich?
Ich kann mir zwar vorstellen, was sie bewirken sollen. Aber da erfolgt
ja keine Zuweisung und wie ein Funktionsaufruf sieht das auch nicht aus.
Ich würde ja noch verstehen, wenn diese Flags (?) irgendwie gesetzt
werden (z.B. =1 oder =true)...
Thomas
P.S. Ich kenne mich nicht so mit dem MSP430 aus...
>OK, dann passt die Quelle nicht ganz zum Header. ;o)
Stimmt, mein Fehler. Gibt seit gestern aber eh wieder ne neue Version :)
Werde ich im laufe der Woche reinstellen.
Hallo Jörg,
ich bin gerade dabei, den Code auf einen AVR anzupassen und bin schon
ziemlich weit. Einzig die praktische Prüfung steht noch aus. ;o)
Vielleicht sollten wir uns mal unterhalten, wie man den Code
hardwareunabhängig macht und so auf verschiedener Hardware nutzen kann.
Gruß,
Jörg
Bin an einer Implementierung für AVR interessiert, hätte auch die nötige
Hardware (315-2DP) neben mir am Schreibtisch stehen. Müsste nur den AVR
daran anschliessen, bzw. den RS485 Bus anbinden.
>Vielleicht sollten wir uns mal unterhalten, wie man den Code>hardwareunabhängig macht und so auf verschiedener Hardware nutzen kann.
Na ja, der Hauptteil (profibus_RX) ist ja schon unabhängig. Was stellst
du dir da noch vor?
>Na ja, der Hauptteil (profibus_RX) ist ja schon unabhängig. Was stellst>du dir da noch vor?
Ich habe die gesamte UART-Kommunikation und alles, was damit zu tun hat,
ausgelagert. Auch gibt es die Timerfunktion nicht mehr. Das ist bei mir
eine Funktion profibus_Statusmachine() und diese wird dann extern in
einem Timer aufgerufen. So was meine ich.
Ich denke, man kann die Logik sehr schön von allen hardwarenahen Dingen
trennen. Somit hätte man dann eine profibus.c/.h, die in verschiedenen
Projekten verwendet werden kann und einfach nur Funktionen bereitstellt,
die von extern aufgerufen werden können.
Jörg
P.S. Ich möchte im Moment nur den geänderten Code hier nicht posten,
da der völlig ungetestet ist (Er lässt sich nur fehlerfrei kompilieren
;o) ).
Logische Auslagerungen könnte man natürlich machen, all zu viele
Änderungen werden ich (zumindest beim aktuellen Projekt) vermutlich aber
nicht machen können. Muss jetzt schon darauf achten das die
Funktionsaufrufe bzw. Interrupts nicht zu lange dauern.
Aber am besten warten wir mal ab bis du fertig bist und reden dann
weiter über das Thema :)
> Gibt seit gestern aber eh wieder ne neue Version :)
Kannst Du sie hier bitte reinstellen. Dann kann ich meine modifizierte
Variante anpassen. Die könnte ich Dir dann bspw. auch zumailen, damit
man ab dann evtl. eine gemeinsame Basis hat.
Jörg
War die letzten Tage etwas kränklich, von daher hat es noch nicht
geklappt. Ich denke mal heute abend oder morgen stell ich die neue
Version rein.... Hauptänderung waren aber eh nur Interrupt Geschichten.
Für AVR Umbastler wohl nicht sooo interessant.
So, die aktuelle Version.
Änderungen:
- RX Interrupt optimiert.
- Slave Adresse wird vor Checksummenberechnung überprüft
- TX Interrupt wartet nicht mehr bis letztes Byte gesendet wurde
- Umschaltung von TX auf RX (RS485 Transceiver) jetzt per Timer
(PROFIBUS_SEND_DATA)
- Timer Interrupt Stop Timer für die Zeit der Verarbeitung
- Interrupt nesting im Timer Interrupt möglich
Alle Änderungen verringern die Verarbeitungszeit für die Profibus
Schnittstelle und geben anderen Applikationen mehr und schnelleren
Zugriff auf die CPU.
Hallo Jörg,
unterstützt auch das DPV0 die erweiterte Diagnose des Typs "device
related" - "Status Model" - "Status Message" ?
Wenn ja wie ??
Danke im Vorraus.
Gruß,
Viviane
Dann kann man mehr oder weniger beliebig viele Gerätebezogene Diagnose
Bytes senden. Was die einzelnen Bits bedeuten muss in der GSD Datei
beschrieben werden.
Hallo Jörg,
ich bin gerade am testen mit einem experimentellen Aufbau.
Nun weiß ich aber nicht so recht, wie denn die Peripherie initialisiert
werden muß (Basic Clock Modul, TimerA, UART, Interrupts) ?
Vielen Dank im Vorraus.
Gruß Tino
Hallo Jörg,
wäre es eventuell möglich, dass Du mal den SPS - Code (auch wenn
offtoppic) hier posten könntest, mit dem Du die gesamte Kommunikatin
über den Profibus machst. Die Parametrierung ist mir klar.
Geht sich um den AWL Part (Receive-Signal - Datenbank auslesen -
weiterverarbeiten und wie die Daten dann von der Datenbank aus weiter
verarbeitet werden.
Gruß
@SPS:
Den AWL-Code für die Profibus-Kommunikation kann ich gern bei passender
Gelegenheit mal rauskopieren und hier posten. Ich denke allerdings
nicht, dass der wirklich weiter hilft, da er auf die speziellen
Anforderungen zugeschnitten ist, und unzählige andere FCs aufruft, die
z.B. für die Normierung, IR-Code-Verarbeitung, usw. zuständig sind.
Prinzipiell besteht so ein SPS-Remote für die SPS aus 35Byte E/A. Diese
Daten werden in jedem Zyklus aus einem DB auf die Ausgangsbytes
kopiert...
Kannst Du evtl. deine Frage bzgl. des SPS-Programms ein wenig
konkretisieren. Vieleicht lässt sich so besser helfen.
Gruß Marc
@mhedder:
ich habe folgendes Problem, ich arbeite derzeit mit einer Vipa 313-CPU
mit RS485 Schnittstelle. Es gibt einige viele tolle Beispiele, aber
alle, die ich bisher gesehen habe, waren so der Art, ich schick ein paar
Zeichen zur SPS, die schickt die dann wieder zurück oder schreibt die in
eine DB. Okay, das hab ich auch schon selbst realisiert.
Was mich derzeit aber interessiert, ist eher folgender Fall:
- ich schicke Daten an die SPS
- Daten werden in einer DB abgelegt - okay bis hier ist alles klar
- danach sollen sie ja so ganz toll ausgewertet werden. nur genau beim
Auswerten hab ich das Problem.
Zugriff auf einzelne Elemente aus einer Datenbank ist da auch nicht das
Problem, aber bei der Fehlerbehandlung und der Aufbau der Schleifen
hakts bei mir. Ich bau mir da meistens irgendwie eine Endlosschleife
oder so... .
Daher würde mich der Code mal interessieren, mit dem ihr die Daten
auswertet, um vielleicht so auf meine Probleme aufmerksam zu werden.
Gruß
Mit DB meinst Du wohl "Datenbank". Bei unserem Projekt, wird die
gesammte Datenhaltung in "Datenbausteinen" direkt in der SPS gemacht.
Bei deinem Problem kann ich Dir da nicht wirklich weiterhelfen...
Mir scheint, Du solltest Dich erstmal richtig in die Materie
SPS-Programmierung einlesen.
Für SPS-Spezifische fragen ist folgendes Forum im Übrigen eine gute
Adresse:
http://www.sps-forum.de
Gruß Marc
@mhedder:
sorry, aber ich weiß schon, wovon ich da rede und ich hab mich auch mehr
als genug belesen ... .
Also, das alle Daten in Datenbausteinen [DB]vorgehalten werden, ist mir
klar.
Also nochmal:
- Daten werden vom PC via RS485 an die SPS geschickt
- SPS speichert die gesendeten Daten in einer "Empfangs"DB
- Auslösen eines Interrupts, oder setzen eines Merkers - Daten vorhanden
- danach folgt ein Algorithmus, der eben die empfangen Daten auswerten
soll
- ich weiß, dass ich folgende Daten anschl. habe:
- ID des Senders
- ID des Empfängers
- Datenblock
Wie wertet ihr diesen Datenblock in der o.g. DB aus?
Dazu fehlt mir einfach mal ein Beispiel da ich daran meistens ziemliche
Probleme bekomme.
Gruß
Hallo,
irgendwie verstehe ich Dein Problem nicht wirklich. Also, Du hast die
Daten in einem DB in der SPS stehen. Dann ist es doch ein Leichtes auf
die Daten mit einem neuen FC oder FB zuzugreifen und die Daten
auszuwerten...?
z.B.:
u db1.dbx3.0
= a 0.0 // Wenn Bit 3.0 in DB1 gleich eins, dann A 0.0 High
Wir reden aber immer von Datenbausteinen, oder?
Einmal schreibst Du
"Also, das alle Daten in Datenbausteinen [DB]vorgehalten werden, ist mir
klar."
und ein anderes Mal
"SPS speichert die gesendeten Daten in einer "Empfangs"DB"
Gruß Marc
Hi,
ich möchte auch einen MSP verwenden um den SPC4 anzusteuern. Hast du die
Funktionalität für den Zugriff auf die 10 Addressbits selbst
programmiert oder hast du hierfür eine Bibliothek ? Ist dein MSP430F2252
für die anbindung eines externen Datenbusses besonders geeignet (Adress
und Datenbus) ?
Gruß
Michael
Da hast du was falsch verstanden. Wir machen ALLES mit dem MSP. Ein SPC4
o.ä. ist nicht notwendig. Nur ein RS485 Baustein :)
Funktioniert also mit allen MSPs (oder anderen Controllern) die eine
UART Schnittstelle haben. Der MSP430F2252 ist im prinzip schon etwas
oversized. Für einfache I/O Sachen geht auch was kleineres.
In den nächsten Tagen wird es übrigens noch ein kleines Update der SW
geben.
Die neue Version...
Änderungen:
- Mit defines werden jetzt die diversen Arrays automatisch angelegt und
initialisiert.
- Zwei neue Arrays: Vendor_Data[] und Diag_Data[]
- Neues Flag: diagnose_status
- read_slave_addr() in get_Address() umbenannt
Über "diagnose_status = TRUE" werden Diagnose Daten automatisch
übertragen.
Der Datentausch wird durch die defines "automatisiert". Wenn keine Daten
gesendet, sondern nur empfangen werden, wird automatisch nur noch eine
Kurzquittung anstatt SD2 Kommando gesendet.
Mal eine Frage eines nur bedingt mit der Materie vertrauten:
Das Ganze funktioniert doch nur so lange prima, wie allen Nodes die
Geschwindigkeit des MSP, bzw. der geringeren Busgeschwindigkeit
ausreicht (?) oder kann man so einen low-speed-Slave auch zusammen mit
anderen Full-Speed-Slaves in einem 12 MBit Netz einsetzen ?
Stefan
Hallo Joerg-S an Co
Super arbeit geleistet. Da habe ich ein par Fragen dazu.
1º
Könnten Sie mir sagen auf wieviele ms der interrupt eingestellt ist?
2º Ist es möglich der code mit der function main() uploaden, es wäre
nähmlich sehr hilfreich.
Alberto (Spain)
>Könnten Sie mir sagen auf wieviele ms der interrupt eingestellt ist?
Timer A?
Das ist variable, je nachdem in welchem Zustand der Profibus gerade ist.
Relevanter Code:
> Ist es möglich der code mit der function main() uploaden, es wäre> nähmlich sehr hilfreich.
Das das sonderlich hilfreich ist, glaube ich nicht :)
Gibt es konkrete Fragen?
>In dem fall 5.33 sind das 5.33 ms?
Nein, das ist die Anzahl der Takte des Timer A für ein Bit.
Timer A = 500kHz -> 2µs/Takt
Profibus = 93750 Baud -> 10,66µs/Bit
10,66µs/2µs = 5,33 Takte/Bit
Hier war mal die rede von einer Version für einen AVR, ist darraus was
geworden?
Welche maximale Profibus Baudrate wäre denn mit einem MSP430F2252
möglich?
>Welche maximale Profibus Baudrate wäre denn mit einem MSP430F2252>möglich?
Wenn Marc noch ne 2. SPS auftreiben kann, wollte ich ein Versuch mit
500k und 1,5M starten.
500k sollte sicherlich noch gehen, 1,5M würde schon ausserhalb der Spec
vom 2252 liegen, es gibt aber MSPs der F2xxer Serie die das laut
Datenblatt noch können.
Allgegenwärtig schrieb:
> Interessant wäre eine Portierung auch auf einen ARM ala STM32 oder LPC2
Auf meinem Schreibtisch liegt schon ne Platine mit ARM Cortex M3
(LPC1768) :)
Jain, hat mit einem Sample angefangen, den 1768 hab ich aber normal
gekauft ;)
Wird aber noch etwas dauern bis da Profibus läuft. Bis jetzt blinkt nur
ne LED, als nächstes kommt erst mal ein Display dran, danach dann
UART...
Jörg S. schrieb:
> Wenn Marc noch ne 2. SPS auftreiben kann, wollte ich ein Versuch mit> 500k und 1,5M starten.> 500k sollte sicherlich noch gehen, 1,5M würde schon ausserhalb der Spec> vom 2252 liegen, es gibt aber MSPs der F2xxer Serie die das laut> Datenblatt noch können.
wo bekomme Ich dennam besten die MSP Microcontroller?
Bei welchem würden denn laut Datenblatt 1,5 gehen, hab mal gestöbert,
aber Ich finde bei allen die gleiche Uart Frequenz!
>wo bekomme Ich denn am besten die MSP Microcontroller?
HBE (www.hbe-shop.de) hat eigentlich alle im Programm.
>Bei welchem würden denn laut Datenblatt 1,5 gehen, hab mal gestöbert,>aber Ich finde bei allen die gleiche Uart Frequenz!
Die F21x2 gehen z.B. bis 2MHz BitClk.
Hab eben mal schnell mein Projekt total abgespeckt. Es kommen 2,3 kByte
Flash und 150 Byte RAM raus (bei MSP430 / Code Optimierung "low").
Beim Profibus könnte man aber noch einiges raus werfen (z.B. SAP 62 ->
DSAP 62) und dadurch noch etlichen Speicher sparen.
Wenn man also nur ein paar Byte direkt von einem Port auslesen oder
setzen will, könnte man es mit eisernem Willen vielleicht schon mit 2
kByte Flash und 128 Byte RAM schaffen. Wäre hart an der Grenze, aber
wohl noch im Bereich des möglichen.
Hallo Joerg,
sieht wirklich Klasse aus was du da machst.
Habe auch eine SPS im Keller hängen zur Haussteuerung.
Wäre sehr an dem 6-fach Dimmer interessiert.
Würdest du die Daten herausgeben (Source-Code, Layout etc.) ?
Ich benutze Eagle. Sieht auch sehr nach Eagle aus.
noeppkes ...
Beschreibung von dem ganzen Kram ist schon in Arbeit.
Evt. könnte ich am Wochenende die Homepage soweit fertig machen das
schon ein paar Schaltpläne usw. mit drin sind...
Und ja, es ist mit Eagle gemacht :)
So, hier findet sich jetzt die Schaltungsbeschreibung, Schaltplan und
das Eagle Projekt:
http://www.see-solutions.de/projekte/projekte.htm (2007_02)
Weiss noch nicht genau wie das dann mit der Beschreibung der SPS Seite
werden soll. Evt. gibt es dann mal eine separate Homepage für die ganze
Sache...
Hallo Jörg,
Als eine PROFIBUS slave sollte es unter beliebige master (SPS oder
anders) arbeiten.
Ich versuche diese mit ein AVR AtMega16 zu machen. Es springt doch eine
meldung herüber und die nächste wird dann im Profibus_RX bearbeitet!?
Also jede zweite meldung ist verloren.
Dann muss immer als 3 oder so in master als Retry Count angegeben. Dann
wird die fehler behebt bei die nächste (retry) meldung.
Ich hat die Timer_ISR unter case PROFIBUS_GET_DATA ein kurzes ein/aus
mit der RS485 treiber gemacht (7,5us). Dann kann ich es in ProfiTrace2
oscilloscope als ein "blip" sehen. Und wenn eine meldung bearbeitet sind
wird die nächste es nicht. Aber immer die meldung danach.
Hast du mit ProfiTrace oder ähnliches überprüft dass deine slave keine
meldungen übersehen?
Hurra Propeller!! Nun laüft es.
Und es springt keine meldungen herüber. Dass war meine fehler wenn zum
AVR umschreiben.
In SAP_CHK_CFG sollte du erst diese kode einsetzen:
1
Output_Data_size=0;
2
Input_Data_size=0;
Danach alle "=" mit "+=" ersätzen. Dann wird es mehrere module
akzeptieren. Wenn du in konfigurator 10 byte input angibt als ein modul
8byte und ein modul 2byte, dann bekommst du nur 2 byte! Mit diese
korrektur kannst du mehrere module korrekt einsetzen. Und diese slave
will sich zum master konfiguration anpassen, nicht nur wie üblich
überprüfen.
Es lüft nun mit 187.5Kbit/s und Tsdr 42Tbit. Wird mit ProfiTrace2
ausgemessen.
Mit 2 kleine änderungen ist auch Set Slave Address OK.
Wie geht es dann mit ihre hausautomations projekt Jörg?
Hallo Einar,
ich würde auch gerne mal mit meinem Atmega16 und Profibus
herumexperimentieren. Könntest Du vielleicht den Code deiner Portierung
zum AVR zur Verfügung stellen?
Dann muss ich das Rad nicht neu erfinden.
Danke im Voraus
Kilian
Einar S. schrieb:> In SAP_CHK_CFG sollte du erst diese kode einsetzen:>
1
>Output_Data_size=0;
2
>Input_Data_size=0;
3
>
Das wird ja schon in der init_Profibus() gemacht.
Einar S. schrieb:> Danach alle "=" mit "+=" ersätzen. Dann wird es mehrere module> akzeptieren. Wenn du in konfigurator 10 byte input angibt als ein modul> 8byte und ein modul 2byte, dann bekommst du nur 2 byte! Mit diese> korrektur kannst du mehrere module korrekt einsetzen.
Das mit den Modulen ist bekannt. Hab ich weiter oben schon erwähnt. Für
Konfigurationen mit mehreren Modulen sind die auskommentierten Arrays
Input_Data_size_Module[INPUT_MODULE_CNT]
und
Output_Data_size_Module[OUTPUT_MODULE_CNT]
vorgesehen. Da hab ich aber noch nicht weiter dran gearbeitet. Das mit
+= ist natürlich erst mal eine einfache Lösung :)
Einar S. schrieb:
>Wie geht es dann mit ihre hausautomations projekt Jörg?
Grundätzlich läuft's. Ein paar kleine Probleme und Änderungen müssen
noch bearbeitet werden :)
Ich muss es doch erst ein bisschen durchsehen, so bitte geduld Kilian.
Und nur wenn Jörg gibt sein OK.
@Jörg: Ist es OK wenn ich die modifizierte kode auch für andere zu
verfügung stellt? Es is ja nahezu 100% deine arbeit.
KiliPet schrieb:> Dann muss ich das Rad nicht neu erfinden.
Hier isses.
Das rundlauf diese rad konnte besser sein. ;-)
Bei mir geht es ziemlich gut, aber es ist bekannte fehler darin.
Für meine erste projekt LEDlicht steuerung/dimmer ist es scon gut genug.
Verbesserungen will ich trotzdem machen.
Einar S. schrieb:> Hier isses.> Das rundlauf diese rad konnte besser sein. ;-)>> Bei mir geht es ziemlich gut, aber es ist bekannte fehler darin.>> Für meine erste projekt LEDlicht steuerung/dimmer ist es scon gut genug.> Verbesserungen will ich trotzdem machen.
Kann man auch einen Schaltplan zu deinem entwurf bekommen?
Ich habe die PROFIBUS treibern von eine slave modul ausgeschlachtet.
Meistens ist die alle gleich. Und in das buch "The New Rapid Way to
Profibus DP" (Manfred Popp) ist auch shaltplan zu finden.
Oder 75176 datenblatt suchen.
Einar S. schrieb:> Ich habe die PROFIBUS treibern von eine slave modul ausgeschlachtet.>> Meistens ist die alle gleich. Und in das buch "The New Rapid Way to> Profibus DP" (Manfred Popp) ist auch shaltplan zu finden.>> Oder 75176 datenblatt suchen.
Hab leider dieses Buch nicht...
Und in dem Datenblatt finde Ich kein Schaltplan mit AVR...
geht auch ein Max3485 als PB Treiber??
Jochen Kühner schrieb:> Und in dem Datenblatt finde Ich kein Schaltplan mit AVR...
Findet du auch nicht in buch.
Diese kannst du in Profibus.c lesen:
"Pins used: USART RX / TX, Portd:2 controls TX enable."
Besser kann ich nicht tun. Ich habe selber keine schaltplan.
Diese DP-slave ist keine DIY DP-slave.
Es ist auch keine komplette DP-Slave, aber eine basis für DP funktionen
herumzuspielen. Man sollte PROFIBUS und AVR ziemlich gut verstehen um
von hier weiter zu kommen. (Gilt mindestens für meine AVR anpassung. Wie
es mit Jörg's MSP430 ist, weiss ich nicht.)
Hello. i try the code profibus.c and the profibus.h that u gave but when
i run apper this:
error: `FALSE' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:51:
error: (Each undeclared identifier is reported only once
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:51:
error: for each function it appears in.)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:91:
error: `TACTL' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:91:
error: `MC1' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:91:
error: `TASSEL1' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:91:
error: `ID_3' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:92:
error: `TAR' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:93:
error: `TACCR0' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c: At
top level:
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:101
: error: function name not found in vector #pragma
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c: In
function `USCIAB0RX_ISR':
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:105
: error: `UCA0RXBUF' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:123
: error: `TAR' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c: In
function `profibus_RX':
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:146
: error: `FALSE' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:166
: error: `TRUE' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:269
: error: `LED_ERROR_AN' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:271
: error: `LED_ERROR_AUS' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:367
: warning: comparison is always false due to limited range of data type
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c: In
function `profibus_TX':
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:712
: error: `RS485_TX_EN' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:714
: error: `TACCR0' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:720
: error: `IFG2' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:720
: error: `UCA0TXIFG' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:721
: error: `IE2' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:721
: error: `UCA0TXIE' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c: In
function `addmatch':
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:752
: error: `FALSE' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:754
: error: `TRUE' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c: At
top level:
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:760
: error: function name not found in vector #pragma
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c: In
function `USCIAB0TX_ISR':
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:766
: error: `UCA0TXBUF' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:769
: error: `IE2' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:769
: error: `UCA0TXIE' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:772
: error: `TAR' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c: At
top level:
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:777
: error: function name not found in vector #pragma
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c: In
function `TIMERA0_ISR':
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:783
: error: `TACTL' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:783
: error: `MC1' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:789
: error: `TACCR0' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:813
: error: `RS485_RX_EN' undeclared (first use in this function)
Projecto\Firmware\Firware\SPC3_app_example\Profibus_Final\profibus.c:825
: error: `TAR' undeclared (first use in this function)
Why apper that? can u help me? please
>Why apper that? can u help me? please
What Compiler are you using?
It looks like you do not include the Header Files for the MSP430
specific Defines.
Other Defines like "LED_ERROR_AN" or "RS485_TX_EN" are Defines for some
Port-Pin Switching. They have to be created by you.
Has the "SPC3" Name to do anything with your Project? Because this
Source Code isn't for any Profibus-ASIC like the SPC!
In eigener Sache:
Das Profibus Handbuch von Max Felser habe ich mal auf meine Homepage
gestellt, da es ja nicht mehr im web verfügbar ist:
http://www.see-solutions.de/sonstiges/sonstiges.htm#Profibus_Handbuch
In den nächsten Woche gibt's auch wieder ein kleines Update. Da ist das
dann mit den Modulen für die I/O Datengröße besser gelöst.
Soares schrieb:> Im using mplap. I trying to developing a module with VPC3+S using the> SPI interface. Can you help me ?please
Sorry, i don't know nothing about mplap and nothing about the VPC3 Chip.
Summary:
This Project implements a Profibus Client ONLY WITH SOFTWARE to a MSP430
Microcontroller. There is no need for a special Profibus Chip, because
this things are done within the Software on the µC!
On the Hardware-Side, you need a µC with UART and a RS485 Transceiver
Chip, that's all :)
Neue Version.
Änderungen:
diagnose_status wird nicht mehr als Flag benutzt, sondern jetzt direkt
als Status Byte 1 in der Diagnose verwendet. Daher Umbenennung in
diagnose_status_1.
Der Ablauf der Diagnose wurde ebenfalls überarbeitet, da ein Bug dazu
führte das die falsche Anzahl der Diagnose Bytes gesendet wurde.
Die Software benutzt zur Zeit die Gerätebezogene Diagnose. Die weiteren
zwei Diagnosemöglichkeiten wurden noch nicht getestet.
Das Define DIAGNOSE wurde in DATA_HIGH unbenannt, um konform zur Felser
Dokumentation zu sein.
Hinweis zum Ablauf: Wenn man Diagnosedaten überträgt, löscht die SPS den
Diagnosestatus erst wenn bei gesetztem Diagnosebit (diagnose_status_1 &
EXT_DIAG_) leere Diagnosedaten übertragen wurden. Löscht man EXT_DIAG_
zusammen mit den Diagnosedaten, so erkennt die SPS den gelöschten
Diagnose Status nicht.
Beim "Parameter Request" ist die Bezeichnung User Parameter richtiger.
Daher wird das Define VENDOR_DATA_SIZE umbenannt in USER_PARA_SIZE.
Achtung: Der Name VENDOR_DATA_SIZE wird weiterhin verwendet (Bei Config
Request).
Wie bereits angekündigt wird die Input/Output Datengröße neu ermittelt.
Dazu wird ein neues, 2-Dimensionales, Array Module_Data_size[][]
verwendet.
Die SPS kann nicht nur eine einzige Eingangs- und Ausgangsgröße
festlegen, sondern auch verschiedene Module. Vor allem beim "speziellem
Format" spielt das eine Rolle.
Mit MODULE_CNT wird die Anzahl der Module festgelegt. In den zwei Byte
pro Modul im Array wird die Anzahl der Eingangs- und Ausgangsbytes
gespeichert.
Bei einem Fehler wird automatisch das entsprechende Flag (CFG_FAULT_) in
der Diagnose gesetzt.
Der gesamte Abschnitt "Check Config Request" wurde diesbezüglich
überarbeitet.
Einar S. schrieb:> KiliPet schrieb:>> Dann muss ich das Rad nicht neu erfinden.>> Hier isses.> Das rundlauf diese rad konnte besser sein. ;-)>> Bei mir geht es ziemlich gut, aber es ist bekannte fehler darin.>> Für meine erste projekt LEDlicht steuerung/dimmer ist es scon gut genug.> Verbesserungen will ich trotzdem machen.
Ich habe nun auch meine Profibus Platine fertig, habe jedoch statts
einem 12mHz Quarz ein 16MHz quarz verwendet.
Sehe Ich das richtig, das Ich in der profibus.h die F_CPU auf 16000000
anpassen muss, und noch die DELAY_TBIT auf 85 erhöhen, das wars dann
schon??
Und wenn Ichs mit 1,5 Mbit testen will, muss Ich dann auch nur die
DELAY_TBIT anpassen (um faktor 8 verkleinern?)
Ok, Ich hab gesehen, Ich muss auch noch die werte bei
#define UART_BAUD_187500 anpassen.
Aber wie kommt man bei 12MHz Quarz auf 7 für #define UART_BAUD_187500
7
(Wert fürs Register UBBRL)
Wenn Ich da die Formeln aus dem Microcontroller Wiki nehm, kommt bei mir
bei 12MHz 3 raus!
Die beiden vorherigen Fragen haben sich soweit erledigt, habe jetzt auch
ein 12MHz Quarz eingelötet, da sonst für die Teilerberechnungen ja
unschöne Werte rauskommen. Wenns mit dem 12MHz mal läuft werd Ich ja
sehen ob Ich das 16MHz noch brauche oder nicht.
Hab nur das Problem Ich kriegs nicht zum laufen. Hab mir mal einen
Blinker ins Hauptprogramm eingebaut, der geht, aber sonst läufts nicht.
In profibus_RX hab Ich mal einen meiner Ausgänge angesteuert, da läufts
anscheinend rein, aber dann springt er im select zum case default.
Und wenn Ich das ganze ein paar minuten laufen lasse, dann hängt
plötzlich der PD2 Ausgang (also das Umschalten von Recieve auf Send),
und dann geht der ganze Profibus nicht mehr (da auch TX die ganze Zeit
bei 5V ist!)
Hab mal meinen Plan angehängt, viel. ist ja auch da noch was falsch!
Mfg.
Mit 16MHz muss du 500Kbit/s läufen. Und dann wird die PROFIBUS timing
ein problem. Mindestens mit die heutige erkennung von ende der
einkommende meldung. Es wird erkannt als die antwort ausgehen sollte.
Ihr plan ist OK. Ich habe galvanische trennung zwischen MCU und RS485.
Aber wenn deine testbus nur am labortisch ist sollte das kein problem
sein.
Die steuerungsaufgaben sollte in doit() sein. Und es sollte nimmer die
interrupt blockieren.
Ich habe nun ein 12Mhz eingelötet, zur Problemanalyse. Auch die
Busgeschwindigkeit habe Ich auf 187500 eingestellt. Der Profibus
funktioniert also noch nicht.
Ich habe zur Kontrolle mal die empfangen daten ins Eeprom geschrieben,
aber im uart_buffer[0] steht nie ein SD1, SD2, SD3 oder SD4. Es wird
dort immer in den default case gesprungen. d.h. ich empfange daten, aber
nicht die richtigen.
Hast du da noch irgendwelche Ideen?
Was für einen Optokoppler hast du denn drin, bzw würdest du empfehlen?
Danke schonmals.
Hast du die quellcode wie es ist versucht? Bei mir läuft es gut.
Erst die originalcode nützen. Wenn es läuft ist deine hardware in
ordnung.
Von störungen weghalten und es sollte ausser galvanische trennung OK
sein.
Hast du die fuse für externe quarz einprogrammiert? Wenn nicht lauft es
etwa 8MHz von die interne PLL. Und wenn du eine neue ATmega kriegst ist
diese fuse nicht für externe quarz programmiert.
Ich Idiot!
Es war das vertauschen von A und B!
Danke schon mal an Einar und Jörg für die Hilfe.
Hab jetzt noch sporadisch Busausfälle, hast du das auch Einar?
Werd mal morgen mit dem Profibusanalyser drangehen, um zu sehen ob er im
nicht gestörten Zustand schon oft in die Telegrammwiederholung kommt.
Als nächstes werd Ich dann noch versuchen AutoBau Erkennung zu
implementieren. Müsste doch möglich sein, wenn man einen Zähler bei den
empfangen falschen Telegrammen einbaut, so das wenn dieser zu groß wird,
man die Baudrate ändert, bis es funktioniert?
Einar S. schrieb:> Von störungen weghalten und es sollte ausser galvanische trennung OK> sein.
Ist den eine Galvanische Trennung bei PB-Vorschrift? Machst du in deinen
PB Platinen eine galvaische Trennung Jörg?
Noch Infos:
Wenn Ich das RetryLimit hochsetze, bekommt die CPU die Störung nicht
mehr mit. Muss morgen mal mit dem Busanalyser sehen, ob der Slave gar
nicht Antwortet, oder was falsches schickt...
Und schon wieder Ich.
@Eimar:
Sollte in deinem AVR Projekt nicht auch unsigned char data_in_register
[INPUT_DATA_SIZE]; volatile sein?
Wenn es gedacht Ist die Verabreitung in doit zu machen, gehts bei mir
ohne nicht!
Und nochmals Ich:
Ich hab jetzt das Retry_Limit auf 5, und da läuft es eigendlich stabil.
Doch wenn ich dann z.B. den baugruppenzustand in Step7 aufmache, und
somit mein Schnittstellenadapter ein Haufen Informationen vom Bus zieht,
habe Ich einen Busausfall von meinem Teilnehmer. werd das auch mal
morgen weiter Analysieren, aber viel. hat ja da schon jemand eine Idee!
Jochen Kuehner schrieb:> Machst du in deinen PB Platinen eine galvaische Trennung Jörg?
Nein.
> Doch wenn ich dann z.B. den baugruppenzustand in Step7 aufmache, und> somit mein Schnittstellenadapter ein Haufen Informationen vom Bus zieht,> habe Ich einen Busausfall von meinem Teilnehmer.
Das Verhalten kenne ich bei der MSP Software als damals noch der Buffer
-Überlauf durch zu viele Eingangsdaten noch nicht abgefangen wurde.
Jörg S. schrieb:> -Überlauf durch zu viele Eingangsdaten noch nicht abgefangen wurde.
Das ist aber in dem AVR Code von Eimar schon drinn...
Um erstmal HW Probleme auszuschließen, was macht Ihr denn mit dem
Schirm?
So....
hab jetzt was Rausgefunden. Sowie es aussieht braucht der Teilnehmer zu
lange wenn Ich große Telegramme auf dem Bus Verschicke.
Ich bin ja schon bei Normal laufenden Bus bei einer Min-SDT von 49.
Hab die max sdt deshalb mal hochgesetzt, dann geht die CPU auch nicht
mehr in Stop, doch es kommt immer noch zu einer Telgrammwiederholung, da
selbst nach über 279 Bitzeiten noch keine Antwort kam.
Hab mal einen Screenshot vom telegramlog angehäüngt, und hab mal auf die
Telegrammwiederholung getriggert. Im normalen Betrieb tritt keine
wiederholung auf. Was mich aber wundert ist, das nach dem längeren FDL
request, welcher wahrscheinlich die Probleme verursacht, erst mal 2
normale telegramme vom teilnehmer kamen, und erst danach das mit der
wiederholung passiert ist!
Einer Ne Idee?
Achso, noch Infos: ID SPS=2 , ID AVR=1
Spalte 1 - TeleNr
Spalte 2 - zeitstempel
Spalte 3 - Adressen
Spalte 4 - Protokoll
Spalte 5 - Primitive
Spalte 6 - Dienst
Spalte 7 - Daten
Habs jetzt auch noch im normalen Betrieb geschafft.
Wenn das Global_Control Telegramm kommt, kann der AVR nicht auf die
Statusanfrage danach gleich Antworten.
Denke das ist aber, da der AVR das Global Control noch verarbeiten muss,
und daher noch nicht auf das neue Telegramm reagieren kann! Kann das
sein?
Jörg S. schrieb:> Bei Global Control muss er ja nichts machen, noch nicht mal antworten.> Von daher sollte er da ja schon sehr schnell durch sein...
keine Ahnung warums dann passiert.
Hast du denn den Bus bei dir ohne ausfälle (Telegrammwiederholungen) am
laufen? Irgend eine Idee was das sonst verursachen könnte?
Vielleicht ist ist Zeit Tsyn nach Global Control noch nicht abgelaufen.
Hast du ein Speicheroszi? Dann könnte man sich mal an einem Portpin
ausgeben lassen wann er wieder bereit ist und schauen ob vorher schon
Daten reinkommen.
Hallo Jörg S.
ich habe mit Interesse Ihr Projekt und die Kommentare dazu studiert.
Könnten Sie mich diesbezüglich bitte per E-Mail kontaktieren?
mfG
Michael
Hallo,
ich verfolge diesen Beitrag nun schon eine ganze Weile. Ich wollte diese
DP-Ablaufsteuerung auf einen AVR, am besten AtmegaXY ummünzen. Jetzt
gibts da kleinere Probleme beim Anpassen der Interrupts und des Timers.
Hat jemand vllt. eine funktionierende Anpassung an einen atmega32 oder
ähnlich... nur mal zum rein schauen und draus lernen :-)
vielen Dank schon mal
Grüße Daniel
Ja, für ATmega16. Bitte mein post von Datum: 07.05.2010 14:44 lesen. Da
ist die quellkode dabei.
Vielleicht kannst du nicht diese als "gast" sehen?
ATmega32 ist soweit ich weiss dieselbe MCU mit mehr Flash & RAM.
Einar
Vielen Dank für die schnelle Antwort, ja die AtmegaXY sind so ziemlich
gleich, vor allem was Register angeht... werde den Code die Tage mal
testen..
man muss ja manchmal auch noch arbeiten nebenher :-)
@Zachter (Gast): Leider nicht. Ich bekommt nur ein fehlermeldung:
--------------
Error
Code: ER_NFF_102420110918
Possible reasons for that:
* you have a mistake in the link
* The file was deleted in case of a abuse report.
* The file was deleted by the uploader.
--------------
@Daniel: Wie geht es? Atmega32 sollte ohne änderungen spielen.
BTW: Was ich eigentlich brauche sind ein paar Slaves mit 1,5Mbit für
meinen Hausbus. Dafür ist aber jeder ASIC viel zu teuer...
Eine lösung hab ich bisher leider nicht.
Hi,
ich arbeite gerade daran meine steuerung für motoren als Profibus slave
zu erweitere.
Die Daten werden dann praktisch aus meiner Steuerung an eine S7 gesendet
und von dort aus an ein PLS.
Ich verwende einen ARM Cortex und habe eine Möglichkeit gesucht,
praktisch einen Profibus DP Slave Code zu finden und somit die
funktionialität in meine MCU zu integrieren als bspw. ein Profichip
Modul zu kaufen.
Meint ihr das ist mit eurem Code möglich?
Ich muss ca. 80Byte an daten an die S7 senden.
Viele Grüße
Steffen
Ist es ein hobbyprojekt? Dann versuchen sie es. Es ist möglich.
Aber wenn es ein kommerzielles produkt ist, dann nein! überhaupt nicht!
Diese code hat elementen die nie durch eine PROFIBUS certification
kommt.
http://www.profibus.com/community/test-labs/
Dann sollte du ein chiplösung oder modullösung suchen. Profichip ist
einer von diese, es gibt mehrere. Ich rate sie mit eine PICC zu sprechen
wenn dies eine kommerzielle produkt ist.
MvG
Einar
cell85 schrieb:> Meint ihr das ist mit eurem Code möglich?
Der Code stellt ein Profbus Slave dar. Geht also :)
> Diese code hat elementen die nie durch eine PROFIBUS certification> kommt.
Ausserdem hab ich komerzielle Nutzung untersagt ;)
Wenn man noch einiges an Zeit reinsteckt kann auch was zertifizierbares
raus kommen. Aber im aktuellen Zustand ist der Code natürlich nicht 100%
Profibus konform. Wie auch auch schon im Ursprungspost steht.
ja mir reicht eigentlich die Info aus, das es möglich ist einen
soft-pb-dp in meine mcu zu integrieren. Ich würde versuchen einen
konformen stack zu benutzen (kaufen/selbst coden) oder eine geeignete
Chiplösung zu finden.
Dear Jörg S
Thanks alot for your reply.
I want to use this system with PLC siemens CPU314C-2DP,and I need a GSD
file,
do u have a correct GSD file for this system?
Best Regards
Dear Jörg S
I hope that you are fine .
I have a question : Do you know ,how I can connect with PLC siemens.
Do you have a function that I can use this for communication with PLC
and MCU .
thanks alot
If you want to know how to include a Profibus Device into the SPS
Programm, that are Basics of the SPS Programming. And i'am not familiar
with that. My Part in this Projekt was only the programming of the
Firmware for MSP430 µC.
Hello Joerg,
I appreciate your hardwork in developing profibus slave in uC.
Would you please guide me how can I modify this code to view/recive
32bit(4byte) data from master.
I just want simple DP slave implementation and Slave will receive 4byte
data from master every second.
Regards,
Azher
Hi,
Is it possible to get the source code somewhere? I would like to take a
look at it to determine the complexity of a Profibus slave and possibly
port it to an ARM Cortex M4.
Best regards,
Janne
Hallo Leute,
Ich stieß auf diesen Thread bei der Suche nach Informationen über die
Implementierung von PROFIBUS.
Ich denke, ich werde eine Anpassung im programmierbaren Logik machen.
Aber dafür, brauche ich eine Aufzeichnung der Austausch zwischen Master
und Slave.
Und im Moment, habe ich keine Zugang zu einem SPS.
Könnte jemand mir das bieten?
Vielen Dank im Voraus.
MfG,
Thoma
Hallo Jörg,
Ja, ich suche ein Kommunikations-Mitschnitt (Ich kannte diesen Begriff
nicht, Deutsch ist nicht meine Muttersprache).
Hast du so etwas auf dein Festplatte?
Thoma
Hallo Jörg,
Ein Kommunikations-Mitschnitt wird mir erlauben, eine zeitgesteuerte
Prüfstand erstellen.
Dann frage ich einfach diese Forumsteilnehmer.
Vielen Dank für deine Hilfe.
Thoma
Dear,
I am Sony from Indonesia.
@ Jörg, I really appreciate for your hardwork. I also have hardwork to
understanding the german language in this forum :D
@ Einar, How to implement your program to AVR with PA as 8bit output and
PB as 8bit input like layout that attached by Jochen Kuehner?
I actually not familiar wit C language, but I will start to learn. I has
been try to compile the code with AVR Studio-4 without error and made
challenge for me.
Gruß
Sony
Hi Jörg,
I'm building an embedded solution to do profibus and i was wondering why
you didn't use a specific ASIC chip like the VPC3+C or SPC3 for more
easier develloping.
I'd like to also know which part of your Source Code is doing the job of
the ASIC chip.
Excuse me i don't speak dutch.
Thanks,
Romain
Hi Romain,
this post is seven years old. We do not even know whether the author is
reading yet. Please contact the creator of the solution with a PM or
open a new topic.
greeting
deathfun
Hi deathfun,
I'm aware that it's an old topic but last message is only 1 year old so
maybe with luck Jörg is still active ?
But thanks for the advice, i'm gonna PM him :-)
Best regards,
Romain
Yes I am not dead ;)
A ASIC is expensive and not easy to get. And so it was much easier to
start with a normal RS485 Chip. The first test to analyze what is going
on on the Bus where very good, with the documentation we could decode
all of the commands.
The profibus.c is doing the job.
Hi Jörg,
cool to see you are here :)
Okay for the Asic you are right but for my embedded solution, the cost
of the Asic isn't expensive so I'll surely use it.
When i said:
"I'd like to also know which part of your Source Code is doing the job
of
the ASIC chip."
I wanted to mean which part of your code is only doing the job of the
Asic ? I'm new with Profibus and i know that in software level, we need
implement de FDL , the user app and the DP-slave stack. Does your code
is doing the three of them in a same .c ?
Thanks,
Romain
I don't know exactly what the ASIC is doing :) But i would say that all
of the things you mentioned is in the profibus.c
But (mentioned above) this implementation is not a complete
implementation! We wanted to send and receive Bytes for a S7 home
Automation Project. And for this little Project it works fine.
Ok thank you,
I have a new question now,
I just found something strange for me in your source code :
"
// Slave Adresse holen
slave_addr = get_Address();
"
I understand that you want to get the address of the slave but i don't
find where this fuction "get_Address()" is defined ?
Thanks
Romain
Other suggestions would be to read it from EEPROM or hard code it.
In that case you would have to set it in EEPROM using any method of your
choice.
One of them might be the PROFIBUS function Set Slave Address. If using
this, a "virgin" slave should default to address 126. This strategy is
useful when you cannot access your hardware because it is potted or in
other cases where switches are not an option.
Hard coding it is really only sensible when you want to postpone your
decision during development.
Einar
Hi Jorg and Einar,
I have ported Einars softbus(based on Jorg's work)to Basom-avr running
on a ATMEGA1284p.
For testing, its connected to a DeltaV system and a couple of bytes are
configured as input and output.
This is working ok, but when I reset(or power cycles) the 1284 the
communication goes down and are not restored
until I dissables/enables the DP port on the system side.
Is this also the case with yours tests?
I also tried to implement the latest version from Jorg, but have some
problem understanding
the "else" witch I marked >>>>>??
------------------------------------------------------------------------
-
if (Vendor_Data_size != 0)
{
// Auswerten
}
// Bei Fehler -> CFG_FAULT_ in Diagnose senden
#if (VENDOR_DATA_SIZE > 0)
if (Module_cnt > MODULE_CNT || Vendor_Data_size !=
VENDOR_DATA_SIZE)
diagnose_status_1 |= CFG_FAULT_;
#else
if (Module_cnt > MODULE_CNT)
diagnose_status_1 |= CFG_FAULT_;
#endif
>>>>>?? else
diagnose_status_1 &= ~(STATION_NOT_READY_ + CFG_FAULT_);
// Kurzquittung
profibus_send_CMD(SC, 0, SAP_OFFSET, &uart_buffer[0], 0);
break;
------------------------------------------------------------------------
---
I'm not an C expert som I thoght that:
if (Vendor_Data_size != 0)
{
// Auswerten
}
the if will end here.
So I cant understand the marked else.
Could you explain?
Regards
Andes L.
Did you check if that is caused by this slave, the DeltaV master or your
master configuration.
That would not be my master of choice to test a "newborn" slave, as it
has a few peculiarities itself.
So I suggest you first try with another slave to make sure that it is
really your slave that causes this. I don't say that you encountered a
bug in your master, but that it may be a feature that is not exactly
announced on page 1 in the manual. ;-) Like what is the behaviour when a
slave disappear? Maybe you need to handle that fault in some way (in the
master).
Look for what behaviour it will have to different abnormal timings from
the slave. I am a bit surprised that you can actually do this in Bascom!
I thought that was a language of convenience more than speed?
If I remember correctly The DeltaV master and configurator are actually
branded in components, so may not have gotten full focus from the
producer.
Einar
Hi Einar,
I’ve been working with DeltaV the last 15+ years and believe me it deals
with Profibus DP quit well
The slave I’m making is just for fun as a hobby and I test it in a lab
of course.
Other slaves as motor starters ,etc are also connected and behave as
expected when powered off/on.
They resume communication after a short period after this power cycle.
The GSD file I’m using is the one that you shared in AVRSoftBus.zip.
Could it be that the GSD needs modification in order to handle the power
off/on event?
@Jorg: Could you try to explain me the diagnose_status_1 handling with
the “else” that confusing me?
Anders L. schrieb:> Could it be that the GSD needs modification in order to handle the power> off/on event?
The slave does not "see" the .GSD file, so the only thing to think about
is if the GSD does tell the master that some timing (or other factor)is
outside what the slave actually can handle.
Since your program is assumed to be quite different than mine, as you
used another (slower?) language. What I did was to observe with
ProfiTrace and squeeze the timing until the slave could not keep up.
Then I relaxed it somewhat. And this at the higher baudrate(s). At low
baudrate the slave is just sitting there twiddling its thumbs anyway.
If I remember right, the timing that needed to be pushed up a bit is max
Tsdr.
There is much room for improvement. If this was something I would use
for several of my projects, I would process incoming messages in
parallel with them arriving. So that when the last byte of a message
arrive the response packet is ready to be shoved out the UART. You would
not know there was a microcontroller doing it all behind the scenes. :-)
Check with your bus analyzer what the master does when the slave is
lost. Does it continue issuing data exchange messages, or does it issue
diagnostic requests? Disregard the FDL status request to the slave.
That's just the master looking for a mate ;-)
Anders L. schrieb:> I'm not an C expert som I thoght that:> if (Vendor_Data_size != 0)> {> // Auswerten> }> the if will end here.> So I cant understand the marked else.> Could you explain?
Right, the if ends there.
The else is the else from the if Part here:
Habe da noch eine Frage.
Gibt es hier von einen Port für einen ARM Cortex M.
Ich wollte für ein Projekt einen M0 als RS485 (Profibus) Datenlieferant
einbauen und dieser Code wäre da was passendes.
Schade das es nichts neues gibt, ist an sich ein wirklich gutes Stück
Software. Ich werde versuchen die Software einzusetzen!
Bitte Michael nimm mir es nicht Übel aber Phyton ist nicht gerade das
was ich für so was nehmen würde.
Aber in Prinzip ist es so was ähnliches was ich bauen will.
Ein M0 der sich um den Profibus kümmert so wie ein SPC3 und ein
Hauptsystem das das darüber liegende Protokoll macht. Wobei mir dann
egal wäre in welcher Sprache das Protokoll abgearbeitet wird, ist ab da
sowieso nichts wildes mehr. Aber mein M0 (dein AVR) sollte schon etwas
mehr machen.
VG, Peter
I started with my project this week and i saw that i need a CPU with a
12mBit UART.
Now i'm locking for a solution.
May be some one else had a M0 solution without the 12Mbit.
je suis un etudiant en master technologie de l'informtion et de
communication alors mon sujet du memoire fin d'etude est sur le profibus
dans les reseaux indestruels sans fil alors je veut implémenté ca avec
n'importe quelle simulateur ns2 ou bien ns3 pas de probleme ...alors
aidez moi svp
merci d'anvance
i am a student on master information and communication technology soo my
memory of is about profibus in wireless indistruel networks soo
I want an implementation of this protocole with ns2 or ns3 anything ....
so help me pleasee
thank you in advance
Dear mr. Jörg S!
Many thanks for such an excellent implementation of the Profibus DP
software slave. With minor changes, on the Cortex-M0 I achieved a stable
exchange rate of 3Mb / sec. Thanks again for such a wonderful job!
Best Regards, Michael.
Michael schrieb:> Dear mr. Jörg S!> Many thanks for such an excellent implementation of the Profibus DP> software slave. With minor changes, on the Cortex-M0 I achieved a stable> exchange rate of 3Mb / sec. Thanks again for such a wonderful job!> Best Regards, Michael.
Hallo Michael, könntest du den Code teilen?
Hello,
I changed code from project AVRSoftBus for atXmega32A4U. It's run on
48Mhz. I tested both speed 187500 and 1M5, everything work. In
profibus.h need change UART_BAUD and DELAY_TBIT. I used USART D0. I
believe this code is usable for someone.
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten