Blick unter den Rock...

[Borsti]

Zuviel Werbung?
-> Hier kostenlos registrieren

Moin...

Komischer Titel, aber er trifft es glaub ich ganz gut. Und zwar geht es um folgendes:

Mich interessiert es jetzt schon seit längerem, wie es unter der Plastik Abdeckung einer S7 (300er, oder 400er, egal...) aussieht.
Ja klar, ich könnte jetzt den dicken Schraubenzieher ansetzen und schon wüsste ich es, aber daß würde mir nichts bringen.
Mich interessiert vielmehr, wie der Prozessor aufgebaut ist. Auf welcher Architektur der Prozessor basiert (Harvard, v. Neumann, reine Akkumulator Architektur, oder doch Stack Architektur, oder gar Register Architektur, etc), wie die Datenpfade aussehen, wie die ALUs arbeiten, usw...
Desweiteren, wieviele DMA Kanäle es gibt, MMUs, DMA Kanäle, Bus Interfaces, etc...
Halt alles was auf der Platine drauf ist und wie es zusammen spielt.
Vielleicht hat jemand sowas, oder sogar noch die Instruction Set Tabelle, mit OpCode, etc.

Ich hab jetzt schon öfters was gesucht, aber nichts gefunden was mit Klarheit verschafft.

Wäre schön, wenn jemand mir da etwas Licht ins Dunkel bringen könnte.

MfG
Borsti

 

[Question_mark]

???

Hallo,

dicken Schraubenzieher ansetzen und schon wüsste ich es, aber daß würde mir nichts bringen.

Muss ich das jetzt verstehen ??? Dann nimm doch den Schraubendreher und schaue einfach nach...

Gruß

Question_mark

 

[Zottel]

Zuviel Werbung?
-> Hier kostenlos registrieren

Nimm den Schraubenzieher und guck!
Irgendwo im Web habe ich mal gefunden,was für Prozessoren drauf sind. Habe es aber vergessen.
Früher hieß es, auf den S5 sei ein spezieller Koprozessor, für die Bitbefehle, wenn ich nicht irre. Macht auch Sinn.

Je nach Prozessor wurde mehr oder weniger große Anteile des MC7 codes zur Laufzeit interpretiert. Andere beim Laden in nativen Maschinecode übersetzt.

MMUs sind eher sinnlos. Sie lohnen sich nur für Multitasking-Anwendungen, wo jedem Anwenderprogramm gleiche oder ähnliche logische Adressen "vorgegaukelt" werden. Die Wiederverwendung gleicher Adressen pro Anwenderprogramm erleichtert das Auslagern auf Platte und die Benutzung gemeinsamer Bibliotheken (.ddl, .so).

Die Opcodes zum AWL waren bei der S5 noch im Handbuch abgedruckt. Im wesentlichen sind sie in die S7 übernommen worden. Zusätzliche Opcodes gibt es für REAL, Pointer-Operationen, erweiterte Adressbereiche und Lokalvariablen.

Mit den Testprogrammen von Libnodave kannst du Bausteine auslesen und pro Baustein wird der Maschinencode in einem File gespeichert. Du kannst AWL schreiben, in die SPS laden, auslesen und anschließend den Maschinencode in einem Hex-Editor ermitteln. Mit Geduld kommst du so an den ganzen Befehlssatz.

Er unterscheidet sich von bekannten Mikroprozessoren durch einge Eigenheiten:
- Es gibt mehrere Ladebefehle für Konstanten mit identischen Binärmustern. Die sind der CPU egal, Binärmuster in den Akku, aber Step7 kann beim Auslesen aus der CPU entscheiden, ob es "L L#3f80000" oder "L 1.0" , real oder dint ist.
- Es gibt zusätzliche Bytes vor einem Unterprogrammaufruf, die Informationen zum Typ der Parameter enthalten. Das sieht ungefähr so aus:
L #Parameter1
T LWx
L #Parameter2
T LWx+2 (oder -2?)
SPA zumCall
Code zur Beschreibung von Parameter1
Code zur Beschreibung von Parameter2
zumCall:CALL FCx

Einen Teil davon kannst du sehen, wenn du einen FC programmierst, den im OB1 aufrufst, den aufgerufenen FC löschst und dann den OB1 wieder darstellen läßt. Weil der aufgerufene FC fehlt, gelingt die Rückdarstellung nicht und du kannst ein bischen "unter die Haube" gucken.

Eine andere Sache ist, Bausteine im laufenden Programm auszutauschen. Bei der S5 ließ sich leicht nachvollziehen, daß die Anfangsadressen aller gültigen Bausteine in einer Tabelle stehen. Beim Überschreiben eines PB wird der neue in freien Speicher geladen. Vor Beginn des nächsten Zyklus wird die Adresse aktualisiert. Der alte bleibt da, bis du "Speicher komprimieren" aufrufst. Durch manipulieren der Tabelle kannst du ihn auch wieder aktivieren.

Alle diese Informationen sind aus der Erinnerung und können im Detail fehlerhaft sein.

 

[Longbow]

Hallo,

Es reicht nicht eine CPU aufzuschrauben, da es sehr unterschiedliche Plattformen gibt:

S7-300 CPUs kleiner oder gleich CPU 315 2DP :
Basieren auf C165 Prozessor (16 Bit Prozessor)
S7-300 CPU 315 PN/DP, 317:
Basieren auf Tricore (32 Bit Prozessor)
315 PN/DP wird gegenüber der 317 eingebremst und
von den Zeiten nicht korrekt im Handbuch beschrieben (ist schneller als im Handbuch)
S7-300 CPU 319:
MIPS 64 Bit CPU (als Basis, CPU kommt vom PMC)
+ Tricore

S7-400: Die älteren hatten einen MC7-ASIC + x86-Prozessor
(386 oder 486)
Die neueren haben auch MC7-ASIC + Tricore
Bei den ganz neuen weiß ich es nicht.

SPEED7: SPEED7 MC7 ASIC (Prozessor) + ARM


Die ganzen "großen" CPUs haben alle mehr als einen Prozessor und auch MMUs
(damit lassen sich bestimmte Probleme in eine SPS deutlich angenehmer lösen ;-) )

In den SPSen mit ASIC sind noch zahlreiche "Goodies" drin!
Ist aber eigentlich nur wichtig, wenn man vorhat so was selber zu machen ;-)
Übrigens: Opcode Tabelle hat ca. 1400 Einträge

Gruß

 

[Ralle]

S7-300 CPU 319:
MIPS 64 Bit CPU (als Basis, CPU kommt vom PMC)
+ Tricore

Ah, deshalb hat die so einen riesigen Kühlkörper drin und wiegt 12 Kilo ! Das muß schon was weggeschaufelt werden, an Heizenergie.

PS:

315 PN/DP wird eingebremst und
von den Zeiten nicht korrekt im Handbuch beschrieben

???

 

[Longbow]

Zuviel Werbung?
-> Hier kostenlos registrieren

PS:


???

Danke!

Ich habe meinen anderen Beitrag noch geändert, da er missverständlich war:
Die 315-2PN/DP ist eine abgespeckte 317 PN/DP und ist nicht mit der
315 2DP "verwandt". Die CPU ist schneller als im Handbuch angegeben.

 

[Borsti]

Na, dass ist doch schonmal was. Danke an euch alle...

MMUs sind eher sinnlos. Sie lohnen sich nur für Multitasking-Anwendungen, wo jedem Anwenderprogramm gleiche oder ähnliche logische Adressen "vorgegaukelt" werden.

Genau darum geht es ja...

Zur Grundidee die ich habe:
Es geht darum, ob man einer S7 Multitasking beibringen kann. Und zwar soll eine normale CPU, zusätzlich noch die Arbeit, etwa einer C240 übernehmen.
Achs Regelung und Kontrolle. Und das ganze dann mit Kinematik Modulen versehen. Steuerung von Mehr-Achs Robotern, komplett aus einer Steuerung, die auf dieselben Datenbereiche, E/A´s, Merker, etc. zugreifen kann.
Alles frei programmierbar, vlt. nach IEC 61131-3, oder wie Adept Steuerungen... Die ganze Softwareimplementierung im Simatic Manager reingepackt.
Das ganze dann noch am besten in der 300er Serie...

Mir gehts halt grundsätzlich darum, ob sowas mit der vorhandenen HW möglich ist. Die nächste Frage wäre natürlich, wieviel Aufwand ist das ganze, etc.

Ich denk einfach mal ins blaue hinein, so entstehen manchmal ganz gute Ideen...

 

[Zottel]

Was willst du: Multitasking mit den Mitteln von Step7 AWL betreiben?

Oder ein eigenes Betriebssystem draufpacken? Ich schätze, bevor du alle nötigen Informationen hast, kannst du besser gleich neue Hardware entwerfen.
Die Siemens Hardware ist ja auch nicht wirklich billig.
Dann lieber RT-Linux auf ne X-Box spielen und dafür eine Soft-SPS und Achssteuerung entwerfen...
Oder Beckhoff nehmen...

 

[Borsti]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ähm... Nein...
Quasi so, als ob parallel zu den ganz normalen Sachen, die in der SPS ablaufen, noch ein (oder mehrere) andere Prozesse ablaufen.
Also nicht alle Tasks in AWL, oder sowas...
Ich dachte da an sowas wie einen dritten Ordner, zusätzlich zu dem Baustein und Quellen Ordner...
Und ja, dafür brauch man ein neues (verändertes) Betriebssystem. Aber das beste Betriebssystem bringt einem ja nix, wenn die Hardware nicht damit klar kommt. Daher meine Frage zum Innenleben...
Und warum ich jetzt nicht auf bereits vorhandene Systeme (Beckhoff, Elau, etc.) zurück greifen wollte erklärt sich einfach dadurch, dass sonst die Schaltschränke umgebaut werden müssten, da in den meisten schon eine S7 (oder 95U) verbaut ist.

Wie gesagt, ich spiel einfach mal mit ein paar Ideen herum...

 

[Zottel]

Ähm... Nein...
Quasi so, als ob parallel zu den ganz normalen Sachen, die in der SPS ablaufen, noch ein (oder mehrere) andere Prozesse ablaufen.

(Quasi-)Parallel laufende Prozesse kannst su innerhalb von Step7 mit Zeit-OBs und Alarm-OBs realisieren.
Es ist auch möglich, den Inhalt des OB1 "Hauptprogramm" in einen FC zu verlagern und diesen FC aus einem neuen OB1 nur in jedem 2., 3. Zyklus oder wie du willst aufzurufen und in den anderen Zyklen andere FCs.

Also nicht alle Tasks in AWL, oder sowas...

Die können auch in ST oder FUP oder KOP programmiert sein. Aber letztlich ist AWL so was wie der kleinste gemeinsame Nenner für alles, was in MC7 programmiert ist. Ob MC7 nun Maschinensprache oder "P-Code" (Code einer simulierten Maschine) ist, hängt davon ab, welche Hardware verbaut wurde.
Aber ohne die Firmware zu ersetzen, kommst du nicht "tiefer".

Ich dachte da an sowas wie einen dritten Ordner, zusätzlich zu dem Baustein und Quellen Ordner...

Die Ordner sind ja nur eine Organisationsform innerhalb von Step7.
Alles, was in Quellen steht, hat eine Entsprechung in "Bausteine". Umgekehrt nicht. Step7 lädt MC7 in die CPU. Ob diese es beim download in nativen Code des Prozessors übersetzt, interpretiert oder wirklich ausführen kann, ist ihr überlassen.

Und ja, dafür brauch man ein neues (verändertes) Betriebssystem. Aber das beste Betriebssystem bringt einem ja nix, wenn die Hardware nicht damit klar kommt. Daher meine Frage zum Innenleben...

Um "tiefer" zu kommen, ja. Nehmen wir an, du hast eine modifizierte Firmware, die eine Task- Umschaltung zwischen einer hochpriosierten Achssteuerung und dem "normalen" S7-, MC7-, Programm bewirken würde.
Jetzt hast du folgende Probleme:
- Dein Programm für die Achssteuerung ist wahrscheinlich nicht MC7 sondern nativer Prozessorcode, um schneller zu sein. Wenn nicht, wäre es nicht schneller und du könntest es gleich in S7 AWL schreiben.
- Damit gibst du das auf, warum viele Kunden Siemens verlangen: Breite Wissensbasis.
- Auch wenn es nur für deine vorhandene CPU taugen muß, weißt du nicht, ob die Ersatz-CPU die du morgen kaufst, nicht völlig anders aufgebaut ist (z.B. mit einem10x schnelleren Prozessor und völlig anderem Maschinencode und MC7-Interpreter). Normale Programme laufen weiter, aber du fängst von vorne an.

Und warum ich jetzt nicht auf bereits vorhandene Systeme (Beckhoff, Elau, etc.) zurück greifen wollte erklärt sich einfach dadurch, dass sonst die Schaltschränke umgebaut werden müssten, da in den meisten schon eine S7 (oder 95U) verbaut ist.

Ja, und diese Schränke funktionieren wohl irgendwie, sonst stünden sie da (hoffentlich) nicht mehr. Die Achsen, die du vielleicht parallel steuern willst, werden auch da sein. Sag mir wie sie jetzt gesteuert werden, dann können wir darüber nachdenken, ob es Möglichkeiten gibt, mit einer unterlagerten Achssteuerung etwas zu optimieren/beschleunigen/etc.

 

[Maxl]

Und warum ich jetzt nicht auf bereits vorhandene Systeme (Beckhoff, Elau, etc.) zurück greifen wollte erklärt sich einfach dadurch, dass sonst die Schaltschränke umgebaut werden müssten, da in den meisten schon eine S7 (oder 95U) verbaut ist.

Also meiner Ansicht nach ist es nicht sinnvoll, hier selbst was zu basteln (Zottel hat recht!), spätestens wenn sich die Hardwarebasis ändert fängst Du bei 0 an.

Dein Argument, dass die Schaltschränke umgebaut werden müssen, ist insofern nicht haltbar, da sich die 300er-Baugruppen problemlos per IM153 und Profibus auch an Steuerungen von anderen Herstellern anbinden lassen.


Wenn Du Achsregelungen in diese Systeme reinpflanzen willst, ist meiner Meinung nach die beste Lösung, auf fertige Systeme zu setzen, welche die von Dir geforderte offene Speicherarchitektur bieten. Was Beckhoff & Elau hier können, kann ich von meinem Standpunkt nicht beurteilen, da wir noch keine davon eingesetzt haben.

Bei solchen Anwendungsfällen kommen bei uns Steuerungen von B&R mit der ARNC0-Erweiterung zum Einsatz. Bei ARNC0 handelt es sich um eine Soft-CNC, welche als hochpriorer Task auf der PLC läuft. Funktionen wie normale Achsregelung, Kurvenscheiben & CNC-Programme sind hier kein Problem. Ich verwende ARNC0 derzeit auch dazu, um auf der PLC die Lagesollwerte für eine Achse selbst zu generieren und diese anschließend (im 2ms-Takt) auf den Lageregler der Achse zu schreiben. Für komplexe Kinematiken (wie z.B. ein 6 Achs Roboter) gibts Librarys.

Über die Rechenleistung braucht man sich hier nicht Gedanken zu machen, da durch die Bank Pentium oder Celeron CPUs > 100MHz zum Einsatz kommen (bei meinem Projekt ist es ein Pentium M mit 1,4 GHz). Programmiert wird das ganze in Basic, ST oder C (natürlich kannst Du auch AWL verwenden, wenn Du willst)


Ich gehe mal davon aus, dass die Architekturen von Beckhoff usw. ähnlich aufgebaut sind.


mfg
Maxl

 

[Zottel]

Zuviel Werbung?
-> Hier kostenlos registrieren

...Ich verwende ARNC0 derzeit auch dazu, um auf der PLC die Lagesollwerte für eine Achse selbst zu generieren und diese anschließend (im 2ms-Takt) auf den Lageregler der Achse zu schreiben. Für komplexe Kinematiken (wie z.B. ein 6 Achs Roboter) gibts Librarys.

Über die Rechenleistung braucht man sich hier nicht Gedanken zu machen, da durch die Bank Pentium oder Celeron CPUs > 100MHz zum Einsatz kommen (bei meinem Projekt ist es ein Pentium M mit 1,4 GHz). Maxl

Man darf schon mal darüber nachdenken, daß 2ms (Takt) für 2,8 Millionen Takte (nicht Instruktionen) eines 1,4 GHz Prozessors reichen. Was macht er da bloß? Transparente Fenster in Vista anzeigen? True-Type-Schriften aufs schönste rendern, indem er nur teils vom Kurvenzug touchierten Orten auf dem Bildschirm Grauwerte zuordnet? Wen interessiert das im Automatisierungsumfeld?
Bringt man ihn dazu, schnelle Peripherie vorausgesetzt, genauso detailliert eine Form zu fräsen, dann würde es vielleicht einen Nacharbeitsgang ersparen.

 

[Maxl]

Man darf schon mal darüber nachdenken, daß 2ms (Takt) für 2,8 Millionen Takte (nicht Instruktionen) eines 1,4 GHz Prozessors reichen. Was macht er da bloß? Transparente Fenster in Vista anzeigen? True-Type-Schriften aufs schönste rendern, indem er nur teils vom Kurvenzug touchierten Orten auf dem Bildschirm Grauwerte zuordnet? Wen interessiert das im Automatisierungsumfeld?

Diese Frage ist berechtigt! In diesem Fall hast Du Lösung auch gleich parat!

Bringt man ihn dazu, schnelle Peripherie vorausgesetzt, genauso detailliert eine Form zu fräsen, dann würde es vielleicht einen Nacharbeitsgang ersparen.

Naja, ein bisschen mehr darfs schon sein . In meinem Fall sinds nur 28 Achsen (davon 2 CNC-Kanäle á 5 Achsen mit dynamischer Transformation) und eine kleine Visu. Idle-Time zw. 70 und 85%. Kein Windows!
Nacharbeitsgang wird zwar keiner ersetzt, allerdings 3-4 Handarbeitsplätze (wobei über den tieferen Sinn dann in Gewerkschaftsforen diskutiert werden darf)

Wir wollten einfach nur die gleiche Hardware einsetzen, die wir auch für die 6-Achs Roboter verwenden. Hier muss die Steuerung zwar nur 19 Achsen rechnen, allerdings sind die Transformationen etwas komplexer (die Idle-Time beträgt dann nur 50-70%).


mfg
Maxl

 

[Borsti]

(Quasi-)Parallel laufende Prozesse kannst su innerhalb von Step7 mit Zeit-OBs und Alarm-OBs realisieren.
Es ist auch möglich, den Inhalt des OB1 "Hauptprogramm" in einen FC zu verlagern und diesen FC aus einem neuen OB1 nur in jedem 2., 3. Zyklus oder wie du willst aufzurufen und in den anderen Zyklen andere FCs.

Gut, kann man machen.
Nehmen wir mal an, man hätte 2 Programm Teile, einen der die normalen SPS aufgaben übernimmt und einen, der die Achsen steuert. Dann hab ich ja, während der SPS Zyklus läuft, eine komplette Zykluszeit in der die Achsen quasi nicht überwacht werden, also die Position, die Geschwindigkeiten, etc.
Denke bei niedrigen Geschwindigkeiten/hohen Übersetzungen vom Getriebe sollte das nicht so das Problem sein. Wäre die Frage, für welche Genauigkeit und Geschwindigkeit man sowas braucht, bzw. wie lange der normale SPS Zyklus ist.

Die können auch in ST oder FUP oder KOP programmiert sein. Aber letztlich ist AWL so was wie der kleinste gemeinsame Nenner für alles, was in MC7 programmiert ist. Ob MC7 nun Maschinensprache oder "P-Code" (Code einer simulierten Maschine) ist, hängt davon ab, welche Hardware verbaut wurde.

Wohl war. Bleibt die Frage, was man alles mit dem AWL Code treiben kann, bzw. wo die Grenzen sind. Natürlich auf die Kinematik bezogen...

Die Ordner sind ja nur eine Organisationsform innerhalb von Step7.
Alles, was in Quellen steht, hat eine Entsprechung in "Bausteine".

Hab ich ja nur geschrieben, um meine Vorstellung der Organisation im S-Manager zu verdeutlichen...

Jetzt hast du folgende Probleme:
- Dein Programm für die Achssteuerung ist wahrscheinlich nicht MC7 sondern nativer Prozessorcode, um schneller zu sein. Wenn nicht, wäre es nicht schneller und du könntest es gleich in S7 AWL schreiben.
- Damit gibst du das auf, warum viele Kunden Siemens verlangen: Breite Wissensbasis.
- Auch wenn es nur für deine vorhandene CPU taugen muß, weißt du nicht, ob die Ersatz-CPU die du morgen kaufst, nicht völlig anders aufgebaut ist (z.B. mit einem10x schnelleren Prozessor und völlig anderem Maschinencode und MC7-Interpreter). Normale Programme laufen weiter, aber du fängst von vorne an.

Gute Argumente. Hab ich noch gar nicht so genau drüber nachgedacht.

Ja, und diese Schränke funktionieren wohl irgendwie, sonst stünden sie da (hoffentlich) nicht mehr. Die Achsen, die du vielleicht parallel steuern willst, werden auch da sein. Sag mir wie sie jetzt gesteuert werden, dann können wir darüber nachdenken, ob es Möglichkeiten gibt, mit einer unterlagerten Achssteuerung etwas zu optimieren/beschleunigen/etc.

ZZ Ist ne Simatic S5/7 verbaut, in zusammenarbeit mit Adept Steuerungen. Aber Adept nervt ein bisschen, weil ihr Support und ihre Nachlieferungsphilosophie für die Füße ist.

Dein Argument, dass die Schaltschränke umgebaut werden müssen, ist insofern nicht haltbar, da sich die 300er-Baugruppen problemlos per IM153 und Profibus auch an Steuerungen von anderen Herstellern anbinden lassen.

So ist es ja zZ auch, aber ich würde ganz gerne von der Bit schaufelei weg kommen. Mit so mein Hauptbeweggrund, warum ich diesen Thread eröffnet habe.

Aber man munkelt ja, dass sich hier ab und an die Spione, einer gewissen Firma herumtreiben. Vielleicht kann man ihnen ja eine kleine Anregung geben...

 

[Maxl]

Zuviel Werbung?
-> Hier kostenlos registrieren

So ist es ja zZ auch, aber ich würde ganz gerne von der Bit schaufelei weg kommen. Mit so mein Hauptbeweggrund, warum ich diesen Thread eröffnet habe.

Dachte dabei eigentlich nicht an Bitschaufelei von S7 zu anderer Steuerung, sondern: S7 weg, IOs direkt per Profibus an die neue Steuerung anbinden (und dort als IOs verwenden) - aus ner 300er wird dann quasi ne ET200M.
Profibus Master sollte es heute für jede Steuerung geben (AB, Beckhoff, B&R um nur einige zu nennen)

ZZ Ist ne Simatic S5/7 verbaut, in zusammenarbeit mit Adept Steuerungen. Aber Adept nervt ein bisschen, weil ihr Support und ihre Nachlieferungsphilosophie für die Füße ist.

Ich kenne Adept nicht. Kann aus Deinem Beitrag auch nicht ganz herauslesen, ob hier zusätzlich eine S7-CPU im Einsatz ist, oder die IOs bereits als ET200M betrieben werden.

Bin mir nicht so ganz sicher, ob Du mit S7-Hardware und MC7-Code wirklich ordentlich an Dein Ziel kommen kannst, da die S7-CPUs so ziemlich die langsamsten Steuerungen am Markt sind. Für Achsregelung und komplexe Kinematiken wohl kaum tauglich.
Für mich stellt sich alleine schon die Frage, wie Du Istwerte von den Achsen einlesen willst bzw. wie Du ordentliche Sollwerte auf diese rausbringst. Die Frage, wie das ganze System taktsynchron gestaltet werden soll, stelle ich gar nicht.

Dass Siemens Spione hier auf eine Idee gebracht werden halte ich für sehr unwahrscheinlich. Für solche Anwendungen will Siemens ihre T-CPUs, FM-Baugruppen, Simotion-CPUs und die Sinumerik verkaufen - und natürlich die dazupassenden Antriebe.
Ich kann hier wiederholt nur empfehlen, auf alternative Branchengrößen zu setzen - allen voran B&R und Beckhoff. Deren Steuerungen sind wesentlich schneller und die Steuerungs- und Buskonzepte sind von vornherein auf Antriebszwecke abgestimmt. Von einer langsfristigen, umkomplizierten Ersatzteilversorgung kann man hier ebenfalls ausgehen.


mfg
Maxl

 

[Borsti]

Dachte dabei eigentlich nicht an Bitschaufelei von S7 zu anderer Steuerung, sondern: S7 weg, IOs direkt per Profibus an die neue Steuerung anbinden (und dort als IOs verwenden) - aus ner 300er wird dann quasi ne ET200M.
Profibus Master sollte es heute für jede Steuerung geben (AB, Beckhoff, B&R um nur einige zu nennen)

Ist ganz klar ne gute Lösung. Eine andere Steuerung, die die S7 und die Adept Steuerung ersetzt. Nur der Haken wird sein, dass sich keiner bei uns mit B&R, Beckhoff, etc. auskennt´. Und 250 Leute auf Schulungen für ein neues System schicken kostet ja auch ein bisschen. Da die meisten bei uns die Siemens Le(e/h)rgänge schon haben und auch in Adept relativ fit sind, liegt der Wunsch nahe, mit bekannten Teilen zu arbeiten.

Ich kenne Adept nicht. Kann aus Deinem Beitrag auch nicht ganz herauslesen, ob hier zusätzlich eine S7-CPU im Einsatz ist, oder die IOs bereits als ET200M betrieben werden.

Ja, es ist eine Siemens Steuerung in Zusammenarbeit mit einer Adept Steuerung verbaut. Bei den ganz alten Systemen wird die Kommunikation zwischen beiden Steuerungen noch über Kupfer gelöst. Bei den neueren Steuerungen sind es S7 die über DeviceNet mit dem Adept sprechen.

Bin mir nicht so ganz sicher, ob Du mit S7-Hardware und MC7-Code wirklich ordentlich an Dein Ziel kommen kannst, da die S7-CPUs so ziemlich die langsamsten Steuerungen am Markt sind. Für Achsregelung und komplexe Kinematiken wohl kaum tauglich.
Für mich stellt sich alleine schon die Frage, wie Du Istwerte von den Achsen einlesen willst bzw. wie Du ordentliche Sollwerte auf diese rausbringst. Die Frage, wie das ganze System taktsynchron gestaltet werden soll, stelle ich gar nicht.

Da bin ich ja auch am Überlegen, ob es mit der S7 HW/SW überhaupt möglich ist. Daher wollte ich ja mehr über die S7 erfahren.
Zu den Ist/Soll-Werten. Nehmen wir als Beispiel an, man hat Rexroth Regler, die via ProfiBus an der S7 hängen. Den kann ich ja über den Bus die Sollposition, Geschwindigkeit, etc. übergeben. Der Regler macht dann ja alles selbstständig. Zumindest ist das ja bei Linearen Bewegungen so. Bei Kinematik müsste man ihm dann halt während der Bewegung neue Zielpositionen, Geschwindigkeiten, Beschleunigungen, etc. übergeben. Dazu brauch man aber eine Steuerung die eine flotte Zykluszeit hat (wenn man das ganze auf mehrere Zyklen aufteilt, wie Zottel es angesprochen hatte), damit ich mit der Istposition neu arbeiten kann.
Wie sieht es denn mit der Vipa Speed7 aus?
Meines Wissens nach ist diese ja um einges flotter als die S7...

Ich kann hier wiederholt nur empfehlen, auf alternative Branchengrößen zu setzen - allen voran B&R und Beckhoff. Deren Steuerungen sind wesentlich schneller und die Steuerungs- und Buskonzepte sind von vornherein auf Antriebszwecke abgestimmt. Von einer langsfristigen, umkomplizierten Ersatzteilversorgung kann man hier ebenfalls ausgehen.

Da müsste man sich mal ein paar Verkäufer von diesen Firmen ins Haus holen. Allerdings hat man es dann mit Verkäufern zu tun und bei denen lautet die Standartantwort "Unsere Steuerung kann alles, ist die beste und schnellste, die einfachste und die Bedienungsfreundlichste." Diese Sprüche kennt man ja... Und wenn ich hier jetzt die Frage stelle, was ihr am besten findet, wird sicherlich wieder eine Art Grundsatz Diskussion ausbrechen. Ich sag nur Little/Big Endian...

 

[MSB]

Also wenn du dich elektronisch wirklich in der Lage siehst, die Hardwarebasis einer S7 zu ändern,
und für deine Bedürfnisse anzupassen, dann ist die Einarbeitung in Beckhoff/BR/ egal wen,
doch sicherlich ein Klacks.

Was musst du hier eigentlich bewegen?
Wie wärs z.B. von Siemens mit 315/317T, wenns denn Siemens sein muss,
mit der Möglichkeit für Kurvenscheiben etc. sollte hier doch auch schon sehr viel möglich sein.

Ansonsten gibt es da von vielen Herstellern spezielle Motion/CNC-Komponenten.

Was hast du für Anforderungen, hast du mehr oder weniger einfache Festpositionen,
oder musst du über Kamerasystemen o.ä. den Roboter erst positionieren?

Mfg
Manuel

 

[TobiasA]

Zuviel Werbung?
-> Hier kostenlos registrieren

Was macht ihr eigentlich überhaupt für Anwendungen? Das würde mich nämlich auch mal stark interessieren... Für Zerspanung würde sich ja die Sinumerik anbieten (wenn man bei Siemens bleiben will), sonst hat Beckhoff (wie ich finde) ein sehr interessantes Programm, was sich zum Beispiel bei Fensterbaumaschinen weit verbreitet hat.
Wenn du nur Positionieren willst, gibt es ja Anbieter satt, die intelligente Frequenzumrichter im Angebot haben, denen du über Profibus nur die Position, Geschwindigkeit etc. weitergibst.

Für Zerspanung jenseits der Werkzeugmaschine habe ich bislang über Beckhoff sehr gute Äusserungen gehört.

Mich würde mal interessieren, was ihr so für Anwendungen habt. Ich bin bisher im Bereich der Werkzeugmaschinen unterwegs (Siemens Sinumerik, Heidenhain, Fanuc).

Gruß, Tobias

 

[Borsti]

Ach so, ja das sollte man schon erwähnen...

Die Hauptanwendungen sind Roboter, mit Linear Ketten.
Ich sag einfach mal, daß eine durchschnittliche Maschine 2 Knickarm Roboter (je 2 Achsen), eine Kettendoppelzug (2 Achsen) und 2 lineare Bänder mit Servos hat.

Also, im Schnitt 8 Achen +- 4. So in etwa siehts aus. Die linearen Antriebe sind kein Problem, ganz normale Servo Steuerung. Der Doppelzug ist auch kein Ding. Wo es problematisch wird, ist halt die Kinematik der Knickarme.

Also wenn du dich elektronisch wirklich in der Lage siehst, die Hardwarebasis einer S7 zu ändern,
und für deine Bedürfnisse anzupassen, dann ist die Einarbeitung in Beckhoff/BR/ egal wen,
doch sicherlich ein Klacks.

Nein, ich will ja die Hardware nicht ändern. Ich wollte halt nur die Möglichkeiten ausloten, die man mit der vorhandenen Hardware hat...

 

[Longbow]

Frage:

An eine Änderung der Firmware einer SPS würde ich gar nicht erst denken,
dort steckt RICHTIG VIEL Arbeit, Test und Optimierung drin!


Frage: Wie sind die Achsen an die SPS angeschlossen (Profibus, Profinet, oder an 24V I/Os + Zähler oder SSI) und welche Updaterate
wäre Wünschenswert (z.B. alle 500µs oder alle 2ms)?

Ach so, ja das sollte man schon erwähnen...

Also, im Schnitt 8 Achen +- 4. So in etwa siehts aus. Die linearen Antriebe sind kein Problem, ganz normale Servo Steuerung. Der Doppelzug ist auch kein Ding. Wo es problematisch wird, ist halt die Kinematik der Knickarme.