- Beiträge
- 15.416
- Reaktionspunkte
- 4.044
-> Hier kostenlos registrieren
So was kann man dann wohl höchstens in Serienmaschinen einsetzen, die lange Zeit programmiert und getestet werden, im Sondermaschinenbau völlig inakzeptabel.
CoDeSys V3
- Ersteller junkie
- Erstellt am
-> Hier kostenlos registrieren
Wenn ich DAS lese
Was würde die Crowd sagen, wenn das bei BIG S so wäre - komisch - bei 3S wird sowass augenscheinlich eher akzepiert.
Frank
Daher heißt es ja 3S.
Bedeutet mindestens dritte Potenz höhere Übertragungsgeschwindigkeit.
Du bist von BigS einfach versaut (oder soll ich schreiben "verwöhnt?)
bike
-> Hier kostenlos registrieren
Welche Version setzt du aktuell ein? Was zählst du zur Downloadzeit dazu, und was ist dann ein grosses Projekt?
Wir testen zu jeder Release die Performance mit ausgesuchten, besonders grossen Projekten. Der Test-PC ist dabei ein verhältnismässig veraltetes Teil, also kein Dual-Core oder sowas.
Für unser grösstes Projekt (ziemlich Visu-lastig) kommen dabei Übersetzungszeiten von etwa 5 Minuten raus und Downloadzeiten von 25 Sekunden bei 10 MB generiertem Code (Zielhardware ist hier auch die RTE). Ein Projekt aus dem Maschinenbau zum Vergleich: 1,6 MB Code ohne Visu, 1 Min Übersetzungszeit, 15 Sekunden Download.
Es stimmt nach wie vor, dass die V23 schneller war, aber im Vergleich zum Wettbewerb sind das keine schlechten Werte. Und wir arbeiten natürlich weiter an Verbesserungen.
IBFS
Level-1
- Beiträge
- 4.068
- Reaktionspunkte
- 893
Du hast da nicht wirklich eine Wahlmöglichkeit.
Es hängt einzig und allein von der Hardware (Target) ab,
welche Codesys-Version du verwenden mußt.
Diese Trennung gibt es sogar zwischen V2.2 und V2.3.
Es gibt Steuerungköpfe in Altprojekten, die kann man
nur mit V2.2 ansprechen.
Bei WAGO z.B. ist außer der 6xx - Steuerung noch alles V2.3
Also schaue dir die Hardware vorher genau an.
Frank
-> Hier kostenlos registrieren
Danke für die Info...
tja, dann bleibt mein problem bestehen bis ich die baugruppen kenn.
ich werd mich dann vielleicht nochmal melden ^^
tja, dann bleibt mein problem bestehen bis ich die baugruppen kenn.
ich werd mich dann vielleicht nochmal melden ^^
In einer Testumgebung interessieren mich die Zeiten nicht, aber im Feld.
Und da ist BigS leider? noch ziemlich am schnellsten und, was wichtig ist, haben die Features, die das Leben als Entwickler leichter machen.
Man kann immer schlechtere finden, doch für uns ist die Messlatte die Besten.
bike
Was soll denn im "Feld" anders sein? Wenn du einen Download über Ethernet machst, dann ist das ein Download über Ethernet und ob das im Büro oder in der Halle stattfindet, sollte vergleichsweise wurscht sein.
Wenn du einen Download über CanOpen machst, wirds langsamer werden, den kann ich aber auch im Büro durchführen.
Wie lange brauchst du denn bei einem Siemens Projekt um 10 MB Code zu generieren? Was ist denn die Messlatte? Ich versuch ja gerade ein bisschen
Objektivität in die Debatte zu bringen.
Ich denke nicht, dass wir irgendeinen Vergleich zu scheuen brauchen.
Auch was die Funktionalität angeht.
Bernhard
IBFS
Level-1
- Beiträge
- 4.068
- Reaktionspunkte
- 893
-> Hier kostenlos registrieren
Die Frage stellt sich garnicht! Man macht eine Änderung ... Läde NUR den geänderten Baustein (ggf. plus IDB) in die Steuerung ... 10 Sekunden - fertig.
Diese ewige Komplettgenerierungsläufe ist genau das, was ich an solchen System nicht leiden kann.
Außerdem weiß man vor einer Änderung praktisch nie, ob das Programm nachher noch DELTA-Ladefähig ist.
Frank
OK, das ist eine andere Diskussion. Wenn nur ein einzelner Baustein geändert wird, gehts auch bei CoDeSys schneller, aber nicht so schnell wie bei Siemens, das ist so.
Die Delta-Ladefähigkeit verlierst du bei CoDeSys genau in zwei Fällen:
1. Änderungen in der Steuerungskonfiguration
2. Änderungen in der Taskkonfiguration.
Ausserdem wird der Code ohne dein Zutun immer inkrementell generiert. Beim normalen Arbeiten wird es daher eher schneller gehen.
Für vergleichbare Zahlen muss ich aber ein komplettes Übersetzen und einen kompletten Download messen.
Die Delta-Ladefähigkeit verlierst du bei CoDeSys genau in zwei Fällen:
1. Änderungen in der Steuerungskonfiguration
2. Änderungen in der Taskkonfiguration.
Ausserdem wird der Code ohne dein Zutun immer inkrementell generiert. Beim normalen Arbeiten wird es daher eher schneller gehen.
Für vergleichbare Zahlen muss ich aber ein komplettes Übersetzen und einen kompletten Download messen.
Der Unterschied ist schlicht und einfach, dass ich im Büro mir einen Kaffee hole und in der Halle steht der Kunde hinter mir.
Ich brauche keine 10MB Code bei Siemens und auch nicht generieren, da mit dem Speichern übersetzt wird.
Ich finde diese Vergleiche der oder der ist schneller und besser ansich doof.
Doch ist die Funktionalität von Codesys oder Twincat noch? nicht so weit bei BigS. Wobei ich Siemens an vielen Stellen echt Scheiße finde.
Doch bei Siemens wird konventionell die Schwachstellen bearbeitet und nicht ein völlig anderes Produkt, das vielleicht viel kann, auf den Weg gebracht, sondern es wird auf das vorherige aufgebaut.
Es stellt sich nach meiner Meinung die Frage, ob es nicht sinnvoller ist, das bestehende zu verbessern und nicht etwas völlig neues anderes nachzuschieben.
bike
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
-> Hier kostenlos registrieren
Beim Speichern wird übersetzt? Redest du hier von AWL? Du möchtest doch jetzt nicht ernsthaft AWL mit einer objektorientierten Hochsprache vergleichen oder?
Bezüglich Übersetzungsdauer kannst du dir ja mal die aktuelle Oscat-Bibliothek herunterladen und komplett übersetzen. Da ist Däumchendrehen angesagt. Und das sind ca. 300 kB Code inklusive Siemens-Bibliotheksbausteinen.
Ich vergleiche PLC Programmierung mit PLC Programmierung.
Und wie es in der Praxis an der Maschine ist.
Wenn du mir sagst, codesys ist Hochsprache und keine Entwicklungsumgebung für PLC Programme, dann okay.
Mir ist doch völlig egal wie das genannt wird, es muss funktionieren.
bike
- Beiträge
- 9.189
- Reaktionspunkte
- 2.936
Aber das Hauptfeature in V3 ist eben die Möglichkeit objektorientiert zu programmieren. Die vorherigen Versionen funktionieren doch.
Und Codesys V3 beinhaltet schon so viele neue Sprachelemente, dass man schon von einer eigenen Sprache sprechen kann wie ich meine. Leider konnte ich die V3 selber noch nicht benutzen. Ich finde den Weg den Codesys einschlägt aber grundsätzlich richtig, in die SPS-Programmierung auch die Erkenntnisse aus der anderen Programmierwelt einfließen zu lassen.
Sicher gibt es außer der Sprache selber noch viele andere Funktionen die ein SPS-Programmierer braucht um eine Anlage zu betreiben. Hier hat durchaus Siemens noch die Nase vorne.
Wenn man aber die Neuerungen von Codesys V3 und Siemens TIA vergleicht, sieht man worauf die Hersteller setzen: Siemens setzt mit TIA eher auf den programmierenden Elektriker (Drag&Drop, schöne Bildchen, möglichst viel zusammenklicken), für Codesys V3 wird man eher Begeisterung bei reinen Programmierern finden.
Wenn sich irgendwann herausstellen sollte dass objektiorientierung für die SPS-Welt nichts ist - dann soll es meinetwegen so sein. AWL ist aber garantiert nicht der Weisheit letzter Schluss.
-> Hier kostenlos registrieren
Da geh ich mit dir völlig konform.
Jedoch ist es immer noch so, dass wir für unsere Kunden entwickeln.
Und es sind eben Elektriker, die die Anlagen betreuen dürfen/müssen.
Und zu TIA verkneif ich mir einen Kommentar. *ROFL*
Doch eines ist auch klar, je mehr Zeilen ein Programm hat, um so größer ist die Wahrscheinlichkeit, dass Fehler vorhanden sind.
Und wenn der PC zu hause abschmiert ist das die eine Seite, doch wenn beim Werkzeugwechsel ein Neustart erfolgen muss, dann wird es teuer,
In einem Programm in FUP/KOP kann die Logik besser darstellen und man Fehler besser finden.
Und wer schon Fanuc Ladder programmiert hat, der genießt AWL
bike
Halllo Thomas,
ich habe auf der Hannover Messe den gleichen Eindruck wie Du bekommen.
Das TIA-Portal ist aus meiner Sicht für Instandhalter gemacht und soll mit seinem tollen Äußeren dem Endscheider in der Fabrik vermitteln, dass damit jeder von der Straße Maschinen/Anlagen Programmieren kann.
Ist wahrscheinlich auch der letzte Trumpf von Siemens, dass viele Maschinen und Anlagen Betreiber voll auf Siemens setzen.
Was den Stand der Technik angeht, wo hat Siemens denn noch die Nase vorn?
Gruß
dummy
MSB
Level-3
- Beiträge
- 7.193
- Reaktionspunkte
- 1.652
Ich sach mal so, im realen Handling, insbesondere wenn die Maschine mal ein paar Jährchen alt ist,
sind klassische Programmiersprachen als Siemens-AWL/KOP/FUP oder auch Sachen wie Mitsubishi AWL/KOP etc.
mit einigem Abstand am besten wartbar ... weit vor jedem beliebigen IEC System welches mir bisher begegnet wäre.
Ich persönlich sehe beide Seiten, weil ich mich auch auf beiden Seiten rumtreibe ...
Als Programmierer liebe ich die Features die mir Codesys bietet (meistens jedenfalls),
als Dienstleister der auch Software-Instandhaltung für div. Industriebetriebe macht,
liebe ich die vergleichsweise durchschaubare Programmierweise, die ich in Siemens-Steuerungen vorfinde,
insbesondere die Tatsache auch notfalls mal etwas in einem AG-Abzug nachzuvollziehen ist absolut großartig.
Aus der Sicht als Instandhalter ist es auch absolut tötlich, wenn man nicht vorhersagen kann,
ob das Projekt welches man gerade vor sich hat, auch tatsächlich dem in der Maschine entspricht,
auch hier haben die etwas betagten Systeme die Nase meilenweit vorne.
Mfg
Manuel
-> Hier kostenlos registrieren
Siemens hat zum Beispiel bei CNC und PLS die Nase weit vorn.
Anlagen in Fernost und Stillstand, was nun? Siemens habe ich in 24Stunden vor Ort und der Kunde kann produzieren. Das ist ein entscheidender Vorteil.
Dieser Aussage kann ich zu 100% zustimmen.
Wenn ich heute irgend eine IEC Programmentwicklungsumgebung habe, wer sagt, dass ich das in 10 Jahren die Programme noch warten kann?
S5 Programme aus den achtziger Jahren letztes Jahrhundert kann ich heute noch ändern und dem Kunden helfen, weiter zu produzieren.
Bei dieser ganzen Diskussion fällt mir auf, dass nicht der Kunde und dessen Bedürfnisse im Vordergrund stehen.
bike
Hallo Bike,
ja z.B. die 840D ist ne schöne Steuerung, da sind wir mal einer Meinung.
Ansonsten kann ich Dir nicht folgen.
Die Bedürfnisse des Kunden sind doch Produzieren und damit Geld verdienen.
Ich hab noch keinen Kunden gesehen, der mit Programmierung sein Geld verdient und wenn er zur Instandhaltung in das Programm schauen muss ist vorher schon was schief gelaufen.
Bei irgendwelchen exotischen Sondermaschinen mag es vielleicht Sinn ergeben. Ansonsten sollte der Maschinen- und Anlagenbauer mal seine Hausaufgaben machen.
Gruß
dummy
MSB
Level-3
- Beiträge
- 7.193
- Reaktionspunkte
- 1.652
Richtig, das ganze aber 15-20 Jahre lang, wenn man sich mal vor Augen führt welch beträchtliche Zahl an
Ur-Ur-Ur-Alt S5en 150W, S3 und Co noch draußen rumschwirrt, sogar noch länger.
Mit jedem Teil welches in der Zeit verreckt steigt die Wahrscheinlichkeit das man an der Software was ändern muss,
oder selbige auf irgendwas portieren muss.
Mfg
Manuel