PROFIBUS Umsetzer

Draco Malfoy

Level-1
Beiträge
1.168
Reaktionspunkte
82
Zuviel Werbung?
-> Hier kostenlos registrieren
Guten Morgen allesamt!

Folgende Fragestellung: Es gibt eine Anlage, wo derzeit mehrere Indramat Antriebe unter Profibus angesteuert werden.
Das SPS-Programm in der Anlagen CPU (S7-300) ist passwortgeschützt und lässt sich nicht so leicht editieren, ohne "spezielle Mittel" zumindest oder ohne die komplette Software neuzuschreiben.

Jetzt muss da ein schrittweiser Umstigeg auf Siemens Sinamics erfolgen, ohne weitere Änderungen. Gibt es jetzt prinzipiell eine Möglichkeit, bsplsw. eine PROFIBUS-fähige CPU einzusetzen, die als "PROFIBUS-Bosch" nachh "Profibus-SIEMENS" Umsetzer agiert ? Sprich, sich wie ein Indramat Slave gegenüber der übergelagerten Steuerung ausgibt, und als Siemens-Master gegenüber dem Antriebsverbund ? Wie hoch wäre der geschätzte Programmieraufwand für diese Lösung ?

Antriebsprotokoll ist in beiden Fällen ein herstellerspezifisches ProfiDRIVE.

Danke im Voraus,

Gruß Draco
 
Zuletzt bearbeitet:
Hallo,

zumindest in der HW-Konfig müsst ihr diese Rangier-CPU (CP) einbinden und die Antriebe als Teilnehmer entfernen. Wenn die Peripherieadressen am Block nacheinanderliegen und der Bereich nicht zu gross ist müsste mit Verlängerung der Reaktionszeit möglich sein.

André
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hi Draco,

ich habe ein Auto der Marke Renault Clio, weil ich sonst nix zu tun habe will ich das Steuergerät durch ein Neues vom 6er Golf ersetzen. Gibt es die Möglichkeit dass sich das Golf-Steuergerät als Renault-Steuergerät ausgibt?

Mag sein dass dein Vorhaben klappt und hier jemand eine patente Lösung parat hat. Mein Rat jedoch lautet, kauf dir gleich ein Golf das erspart dir jede Menge Arbeit und Ärger.

Was hat es eigentlich mit dem Passwortschutz auf sich? Betrifft das nur einzelne Bausteine oder die ganze CPU?

MfG Mäuseklavier
 
Hi Draco,
ich habe ein Auto der Marke Renault Clio, weil ich sonst nix zu tun habe will ich das Steuergerät durch ein Neues vom 6er Golf ersetzen. Gibt es die Möglichkeit dass sich das Golf-Steuergerät als Renault-Steuergerät ausgibt?
Mag sein dass dein Vorhaben klappt und hier jemand eine patente Lösung parat hat. Mein Rat jedoch lautet, kauf dir gleich ein Golf das erspart dir jede Menge Arbeit und Ärger.
Was hat es eigentlich mit dem Passwortschutz auf sich? Betrifft das nur einzelne Bausteine oder die ganze CPU?
MfG Mäuseklavier

In Deiner Logik hast Du eigentlich vollkommen recht, sehe ich genau so zumal eine weitere CPU zusätzlich Geld kostet. Die Sache ist nur die mit dem Passwortschutz. Der Anlagenhersteller ist Fa. ILLIG GmbH und die gibt das SPS-Programm leider nicht heraus. Soweit mir ersichtlich ist ist das gesamte Programm geschützt. Und das SPS-Programm für die gesamte Produktionsstraße neu zu schreiben ist sehr gewagt und nicht gerade trivial.
 
Das Problem mit dem Umsetzer ist, dass sich dieser als Indramat ausgeben müßte.
Die Identifizierung erfolgt über eine von der Profibus Nutzerorganisation vergebene Ident-Nr.
Ich kenne keine Funktion, um bei einer Siemens-CPU die Profibus Ident-Nr zu manipulieren.
Evtl. hast du mit Profibus-Karten für PC hier mehr Glück.

Gruß
Dieter
 
... gestaltet sich denn bei einem Siemens-Servo der Aufbau des Übertragungs-Blocks genauso, wie bei einem Indramat ? Ich bezweifle das mal stark. Von da her ist dieses Vorhaben in dem SPS-Programm selbst sicherlich umsetztbar (aber auch nicht "mal eben so") - aber an dem Regler selbst ...???

@TE:
Warum will dir denn der Lieferant nicht das Programm als Source zur Verfügung stellen ? ich halte das für sehr unprofessionell ... (ich kenne jetzt dazu allerdings nicht die rechtliche Grundlage - würde das aber mal durchleuchten (lassen))

Gruß
Larry
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... gestaltet sich denn bei einem Siemens-Servo der Aufbau des Übertragungs-Blocks genauso, wie bei einem Indramat ?
Nein, natürlich nicht. Das eine ist wie gesagt Bosch ProfiDRIVE und das andere ist Siemens-ProfiDRIVE.
Von da her ist dieses Vorhaben in dem SPS-Programm selbst sicherlich umsetztbar (aber auch nicht "mal eben so")
Da werden sicherlich einige Tage Programmierarbeit von nöten sein. Vorausgesetzt, man hat den Quell-Code.

Warum will dir denn der Lieferant nicht das Programm als Source zur Verfügung stellen ? ich halte das für sehr unprofessionell ...
Naja, des ist ja nicht der Lieferant sondern der Maschinenhersteller. Ich vertrete hingegen ein anderweitiges Unternehmen für Steuerungsbau und stehe somit als "konkurrenz" da.
Vielleicht kennst Du Leute die besseren Zugang zu der besagten Firma hätten ?
 
Naja, des ist ja nicht der Lieferant sondern der Maschinenhersteller. Ich vertrete hingegen ein anderweitiges Unternehmen für Steuerungsbau und stehe somit als "konkurrenz" da.
Vielleicht kennst Du Leute die besseren Zugang zu der besagten Firma hätten ?

Ähh ... dann sollte der, der die Maschine/Anlage erworben hat sich vielleicht mal deswegen mit dem Hersteller in Verbindung setzen ...
Ich kann mir wirklich nicht vorstellen, dass du/ihr nur mit dem AG-Abzug eine wirkliche Chance habt.
Ach ja , ich kenne die Fa. Illig nicht auch zumindestens nicht wissentlich Leute, die das tun.

Gruß
Larry
 
Ich kann mir wirklich nicht vorstellen, dass du/ihr nur mit dem AG-Abzug eine wirkliche Chance habt.
Da habe ich ehrlich gesagt auch so meine Zweifel, hm. Habe die MMC Karte mittlerweile auslesen können, die enthält 121 Programmbausteine, jeder so 1km lang und natürlich ohne jegliche Kommentare.
Könnte ich eventuell innerhalb der CPU geschickt einen Baustein anlegen, der eine Protokollwandlung vollführt ?
Oder bzw. wie identifiziere ich zuverlässig alle Module die mit den Indramats kommunizieren ?
 
Zuviel Werbung?
-> Hier kostenlos registrieren
... bzw. wie identifiziere ich zuverlässig alle Module die mit den Indramats kommunizieren ?

Ich würde nach der HW-Konfig und den darin verwendeten Perepherie-Adressen vorgehen.
Wenn du dann noch über IndraWorks den Regler ausliesst hast du ja die Definition des Daten-Austausches.
Jetzt ist dann die Frage, wie der Programmersteller damit weiter umgegangen ist - da habe ich schon "tolle" Sachen gesehen.
Was macht denn die Maschine ? Einfache Positionier-Aufgaben ? In dem Fall würde ja sehr wahrscheinlich nur ein Positions-Sollwert, der irgendwo herkommt, zum Servo geschickt und die Steuerbits gehandelt. Da läßt sich mit etwas tüfteln sicherlich etwas machen und man könnte dann diese Werte und Bits einfach mal (vielleicht zuerst versuchsweise) zu dem "neuen" Regler schicken - diese Informationen anders aufzubereiten wenn man erst mal weiß, wie sie definiert sind, sollte nicht das Problem sein.
Das Projekt hingegen ist hinterher nicht mehr wirklich für jemanden sinnvoll zu verwenden ...

Gruß
Larry
 
Ich würde nach der HW-Konfig und den darin verwendeten Perepherie-Adressen vorgehen.
Wenn du dann noch über IndraWorks den Regler ausliesst hast du ja die Definition des Daten-Austausches.
Jetzt ist dann die Frage, wie der Programmersteller damit weiter umgegangen ist - da habe ich schon "tolle" Sachen gesehen.
Was macht denn die Maschine ? Einfache Positionier-Aufgaben ? In dem Fall würde ja sehr wahrscheinlich nur ein Positions-Sollwert, der irgendwo herkommt, zum Servo geschickt und die Steuerbits gehandelt. Da läßt sich mit etwas tüfteln sicherlich etwas machen und man könnte dann diese Werte und Bits einfach mal (vielleicht zuerst versuchsweise) zu dem "neuen" Regler schicken - diese Informationen anders aufzubereiten wenn man erst mal weiß, wie sie definiert sind, sollte nicht das Problem sein.
Das Projekt hingegen ist hinterher nicht mehr wirklich für jemanden sinnvoll zu verwenden ...

Gruß
Larry

Okey, verstehe die Vorgehensweise. Also die Maschine ist eine Verpackungsmaschine (Tiefziehen) und die Servos sind reine Positionierer bloß mit Lageregelung, d.h. Schleppabstandüberwachung etc.
Jetzt hat die noch ne HMI, welche auch "Intelligenz" wie z.B. Kundenprogramme beinhaltet. Dabei werden die Ist-Werte der Servos in einem bestimmten Screen direkt in Motorunits angezeigt. Frage ist, ob hier die Kommunikation immer über den Busmaster (also die S7) läuft oder die HMI auch direkt Daten von Slaves erhält. Wenn zweiteres, müsste man auch noch das HMI Programm umbauen.

Die Regler hatte ich schon mit dem DriveTop16 Tool von Bosch mal ausgelesen gehabt, dort werden einige spezielle Bytes mit sinnbehafteten Werten im Steuerwort übergeben und einige im Statuswort zurückgemeldet. Nichts schlimmes eigentlich.
 
Also die Maschine ist eine Verpackungsmaschine (Tiefziehen) und die Servos sind reine Positionierer bloß mit Lageregelung, d.h. Schleppabstandüberwachung etc.
Das ist doch schon mal gut - dann wird wahrscheinlich nur die Zielpos. (und ggf. die Geschwindigkeit) und die Steuerbits übergeben - das ersiehst du aber aus dem Regler (Führungskommunikation)

Jetzt hat die noch ne HMI, welche auch "Intelligenz" wie z.B. Kundenprogramme beinhaltet. Dabei werden die Ist-Werte der Servos in einem bestimmten Screen direkt in Motorunits angezeigt. Frage ist, ob hier die Kommunikation immer über den Busmaster (also die S7) läuft oder die HMI auch direkt Daten von Slaves erhält. Wenn zweiteres, müsste man auch noch das HMI Programm umbauen.
Ich könnte mir hier vorstellen (so würde ich es machen), dass die Visu die Zielpositionen, ggf. Produktbezogen unterschiedlich, verwaltet und in die SPS überspielt.
Die Istpositionen werden nur der Anzeige dienen.
Beides wird normalerweise nicht von dem Slave sondern (eher wahrscheinlich) aus einen Koppel-DB in der SPS geholt/reingespielt.

Die Regler hatte ich schon mit dem DriveTop16 Tool von Bosch mal ausgelesen gehabt, dort werden einige spezielle Bytes mit sinnbehafteten Werten im Steuerwort übergeben und einige im Statuswort zurückgemeldet. Nichts schlimmes eigentlich.
Das genannte Tool kenne ich nicht, du solltest hier mal (wie schon oben geschrieben) einen Blick auf die Führungskommunikation werfen.

Gruß
Larry
 
das ersiehst du aber aus dem Regler (Führungskommunikation)
Okay, dann werde ich da nochmal genauer in den Regler reingucken.
Laut Datenblatt müssen bei der angewählten Betriebsart jedoch mindestens folgende Prozessdaten übergeben werden (plus einige Daten die zusätzlich anwenderspezifisch angewählt werden können und Steuerbits):
- Feedrate-Override;
- Positionier-Ruck;
- Zielposition;
- Positionier-Geschwindigkeit;
- Positionier-Beschleunigung;
- Positionier-Verzögerung;
Beides wird normalerweise nicht von dem Slave sondern (eher wahrscheinlich) aus einen Koppel-DB in der SPS geholt/reingespielt.
Würde mir auch sinnvoll erscheinen. Bleibt nur, diesen Koppel-Baustein zu identifizieren und zu back-engineeren.
Die Istpositionen werden nur der Anzeige dienen.
Denke, die SPS überwacht eventuell noch die relative Lage des Vorstreckstempels gegenüber den Werkzeugträgern und verhindert eine Crashfahrt.
Mal ne Frage, denkst Du es wäre widerrechtlich wenn ich das unkommentierte SPS-Programm hier auslege ? Eventuell hat jemand Lust da reinzugucken.
Ist das eine RDKP72g von Illig ?
Nicht sehr weit entfernt. Es ist eine RDK-80.
 
Zuletzt bearbeitet:
Ich halte diesen Umstieg für reichlich schwachsinnig, wenn man die Software nicht zur Verfügung hat. Ein AG-Abzug könnte ebenfalls z.Teil nutzlos sein, wenn die Bausteine in SCL erstellt wurden kommt auch i.d.R. ganz schöner Spagetti-Code zum Vorschein und ist auch keine reiner AWL-Code, also schwierig zu handhaben. Ich kenne ja die Gründe nicht, die der Maschinenbesitzer hat, aber so lange es Indramt und Ersatzteile gibt, sehe ich keinen wirtschaftlichen Sinn in einem Umstieg, es sei denn, man will die Maschinen nachbauen... Ein Umprogrammieren auf Sinamics wird auf jeden Fall schwierig und nicht in 3 Tagen zu machen sein.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mal blöd gefragt:
Was macht es für einen Sinn an einer bestehenden Serienmaschine Indramat-Antriebe gegen Siemens zu tauschen?

Was du übrigends bei deinem Vorhaben nicht ausser acht lassen darfst, ist ein geändertes zeitliches Verhalten.
Je nach Komplexität des Werkstücks / Werkzeuges können Ziehvorgänge da recht ekelhaft sein.
Die Istposition des Tisches löst meist weitere Aktionen aus (Werkzeug-Steuerung, Blasensteuerung, Kühlung, ...)
Bevor du die Antriebe tauscht, nimm auf jedenfall ein Weg-Zeit-Diagramm der Achsen auf.
Werkzeug- und Blasensteuerung sind zeitkritisch.
Also wenn dein Kunde nicht gerade simple Jogurt-Becher macht, schau dir genau an, was an Achsen noch alles hängt.

Gruß
Dieter
 
Ein AG-Abzug könnte ebenfalls z.Teil nutzlos sein, wenn die Bausteine in SCL erstellt wurden kommt auch i.d.R. ganz schöner Spagetti-Code zum Vorschein und ist auch keine reiner AWL-Code, also schwierig zu handhaben.

Die Tisch-Steuerung mit ihren ganzen Optionen, Zeiten, Positionen ist mit selbst voll kommentiert komplex.
Ich kenn die aktuellen Illigs nicht, aber bei unseren Kiefel- und Comi-Anlagen steckt da einiges drin.

Gruß
Dieter
 
Mal blöd gefragt:
Was macht es für einen Sinn an einer bestehenden Serienmaschine Indramat-Antriebe gegen Siemens zu tauschen?
Da gibt es verschiedene Gründe.
Zum einen ist SINAMICS ein laufendes Produkt was nicht abgeschafft ist und wo es noch vernünftigen Support gibt. Zum Anderen, habe ich bei SIEMENS die Möglichkeit beliebige Antriebe und auch beliebige Geber einzusetzen, es ist ein offenes Systhem im Gegensatz zu den Indramats wo nix außer Rexroth Produkten dran kann. Zum Anderen, kann SINAMICS noch sehr viel mehr, wie z.B. bis zu 6 Achsen mit einer CU320 steuern, und da dort wahrscheinlich noch ne Packstation hinzukommt, liegt es doch auf der Hand gleich auf eine zukunftsweisende Technologie umzusteigen ?

Dann hat der Kunde noch 2 "kaputte" Antriebe in der 5k Größenordnung liegen, deren einziges Problem ein defekter Geber ist. Neue Geber kann man da aber nicht dranbauen, weil das dann keine Indramat Antriebe mehr wären, und dann verweigern die Servocontroller den Betrieb. Und mit SIEMENS kann er die problemlos einsetzen, muss nur einen Geber dranbauen und ein entsprechendes SMC Modul für weniger als 200€ kaufen. Sind doch erst mal Gründe genug...
Also wenn dein Kunde nicht gerade simple Jogurt-Becher macht, schau dir genau an, was an Achsen noch alles hängt.
Der produziert sehr spezielle Sachen, aber keine komplizierten. Recht simpel eigentlich. Was natürlich nicht heißt, daß das Produkt sich nicht mal ändern könnte. Aber die Maschine hat nur drei zentrale Achsen: Obertisch, vorstreckstempel und Untertisch.
Andere Frage, wieso sollte sich das zeitliche Verhalten ändern ?? Wir haben doch einen definierten Verfahrweg und eine definierte Obergrenze für die Verfahrgeschwindigkeit sowie Verfahrbeschleunigung. Plus dazu, ein definiertes Antriebsverhalten beim Positionieren, was durch die entsprechenden Regelkurven gegeben ist. Woher soll denn hier die Diskrepanz kommen ? Die SINAMICS Technologie ist doch sicherlich nicht weniger echtzeitfähig wie die ECODRIVEs ?

Außerdem haben wir ein unfreiwilliges Experiment mal gemacht: Ich habe mal bei der Obergrenze für Bipolabeschleunigung und Bip.-Geschwindigskeit im ECODRIVE eine Null dahinter vergessen gehabt, mit der Folge daß der Obertisch deutlich langsamer gefahren war. Aber es gab keine schlimme Problematik, nur die Taktzeit ist runtergegangen. Die anderen Achsen haben gewartet bis der Tisch seine Soll-Positionen angenommen hat und sind dann nachgezogen.
 
Zuletzt bearbeitet:
Zurück
Oben