Suche etwas seltsame SPS

Zuviel Werbung?
-> Hier kostenlos registrieren
Betriebselektriker und Hochsprachen

Hallo,

wir als betriebsnah arbeitende Fachkräfte haben grundsätzlich nichts gegen Hochsprachen, exotische, unkommentierte oder gesperrte Programme.

Ausser: Am Wäldchestag bzw. am Rosenmontag je nach Standort des Programmierers erscheint eine Meldung wie:
FatalError0815, please call 01234/56789.
Spätestens dann entschliesst man sich zu außergewöhnlichen Massnahmen.
 
Du kannst dir CoDeSys auch bei einem der zahlreichen Partner herunterladen.
Bei Microinnovation heisst das Kind dann MXPro und ist ohne Registrierung (allerdings nur Demo) verwendbar.

@Zotos
Siemens SCL ist immer noch grottenschlecht.
Vor allem, wenn mann noch nicht mit Siemens zu tun hatte und von einer guten Plattform wie CoDeSys wechseln muss. Wenn man gewöhnt ist, solche Späße wie Arrays aus Funktionsbausteinen zu bilden (Funktioniert in CoDeSys wunderbar) und plötzlich mit Datenbausteinen zu kämpfen hat, fällt man mehr als einmal gehörig auf die Nase.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
...
Schöne Verallgemeinerung.
Meine Verallgemeinerung sieht dann so aus: Die meisten die Siemens in den Himmel heben haben einfach keine Erfahrung mit anderen Systemen ;o)

Ich denke das wenn man von der Hochsprachen Programmierung (wie der Fragesteller) zur SPS kommt ist Siemens eben nicht gerade komfortabel.
Man frägt sich recht schnell warum man immer alles selbst Absolutenadressen zuordnen muss und nicht einfach global und lokale Variablen verwenden kann?
Warum muss man jeder Funktion auch noch eine Nummer geben wenn man doch schon einen eindeutigen Namen vergeben hat?
Warum kann ich von einem FB nicht einfach eine Instanz bilden und muss statt dessen mit Instanz DBs arbeiten?
Warum ist SCL so schlecht implementiert (vielleicht hat sich da ja was geändert) und man das sooo.. umständlich über Quellen erzeugen muss?
Warum kostet die Entwicklungsumgebung gleich über 2k€?

Sicher: Siemens ist komplizierter als andere Systeme (kenne aber sonst auch nur Fanuc, bzw. Grundkenntnisse von Heidenhain und Mitsubishi). Aber ich habe ein System, das sehr offen ist, mit dem ich viele Möglichkeiten habe, auch gut strukturiert und dokumentiert Programme zu erstellen (Fanuc kennt keine Kommentare und nur wenige Zeichen Symbolik, nur um ein Beispiel zu nennen), und vor allen Dingen habe ich jede Menge qualifiziertes Personal, das mit dem System vertraut ist. Aber die können (fast) alle keine Hochsprache... Ich hab' mit PC-basierten Systemen auf Hochsprache noch keine guten Erfahrungen gemacht, selbst wenn sie zweifelsohne Vorteile haben.
Egal. Ist so 'ne Frage wie "Äpfel oder Birnen" oder "Wurst oder Käse"...

Gruß, Tobias
 
Zuletzt bearbeitet:
Also SCL ist sicher schlechter als CoDeSys, da es eben kompatibel zu den ganzen Siemens Altlasten wie DB's, Merkern etc. sein muss, bzw. Siemens es nicht besser hingekriegt hat oder wollte. Aber besser als gar keine Hochsprache in der S7.

Warum deutsche 'Fachkräfte' nicht in der Lage sind SCL zu verstehen, ist mir auch nicht klar. Von Graph möchte ich da ja gar nicht reden, obwohl man dort sofort nach Aufruf des entsprechenden FB's sieht warum eine Anlage steht.

Ich arbeite seit Version 1.0 auch mit VB, aber die ereignisgesteuerte Windows-Welt hat mit der Echtzeit-Welt der SPS nichts gemein. VB für HMI ist sehr gut, aber allein vom Debugging kann man beide überhaupt nicht vergleichen.

Ich programmiere auch nur für Sondermaschienen und selbst dort ist in 80% der Fälle Siemens Pflicht. Und grossen Kunde von z.B. Beckhoff zu überzeugen, habe ich mittlerweile aufgegeben.
 
Also SCL ist sicher schlechter als CoDeSys, da es eben kompatibel zu den ganzen Siemens Altlasten wie DB's, Merkern etc. sein muss, bzw. Siemens es nicht besser hingekriegt hat oder wollte. Aber besser als gar keine Hochsprache in der S7.

Warum deutsche 'Fachkräfte' nicht in der Lage sind SCL zu verstehen, ist mir auch nicht klar. Von Graph möchte ich da ja gar nicht reden, obwohl man dort sofort nach Aufruf des entsprechenden FB's sieht warum eine Anlage steht.
...

100% Ack.

Damit antwortest Du gleichzeitig auf verschiedene Threads.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Parallax,

wenn du eine Alternative suchst, waere Beckhoff eine interessante Alternative. Diese Steuerung waere in der Lage autonom zu arbeiten, und kann aber auch mit OPC-Server mit VB verbunden werden. Preismaessig liegt sie eindeutig unter der S7 und ist meines Erachtens maechtiger wie Siemens SPS.
Allerdings ist das Hilfesystem von Beckhoff sehr gewoehungsbeduerftig unnd meines Erachtens nach teilweise recht chaotisch. Als zweite Quelle fuer die Steuerung steht Codesys zur Verfuegung. Beide bauen sie auf den indentischen Compiler der IEC-Sprache auf.
schau dich mal bei www.beckhoff.com um

mfg
 
Hi da dies allerdings den Sondermaschinenbau betrifft und dort häufig Aufgaben auftreten die regelmäßige Erweiterungen betreffen würde ich dies lieber über einen IndustriePC erledigen, und zweitens will ich so wenig wie möglich Siemens verwenden.
Also wenn das So ist, wäre wohl B&R die erste wahl für Dich.

Die Haussprache von B&R ist das sog. B&R Automation Basic, welches sich sehr an Visual basic anlehnt (halt ohne Objektorientierung).

Als Industrie-PCs kommen PanelPC 700 (zusammengebaut) oder APC620 (PC mit extra Display) in Frage. Dabei hast Du die Wahl zwischen 2 SPS-Laufzeitumgebungen
- AR010: diese läuft parallel zu Windows XP (besser gesagt: Windows XP läuft in der Restzeit der Soft-SPS); für diesen fall hat aber B&R keine eigene Visu-Software, Du müsstest auf zenOn oder so ausweichen
- AR106: auf dem PC läuft kein Windows - der PC ist dann im Prinzip wie eine SPS, die komplette Rechnerleistung steht für SPS-Aufgaben + Visu zur Verfügung (wobei die Visu WYSIWYG-programmiert wird)

Die Variante AR106 ist besonders interessant, wenn Du kein Windows auf dem PC brauchst - als Display kann beim APC620 ein Standard DVI-Monitor oder ein Automation Panel verwendet werden.

schau einfach mal auf www.br-automation.co.at nach.


mfg
maxl
 
Zuviel Werbung?
-> Hier kostenlos registrieren
über Meinungen und Ansichten

Sehe ich nicht so. Da man doch für die B&R AR010 geschichte ja B&R IPCs braucht. Bei CoDeSys und Beckhoff kannst Du die IPCs nehmen die Du eh schon einsetzt also auch bestehende Anlagen aufrüsten.
Mhm, hatte nicht gelesen, dass hier bereits eine wilde Diskussion um ICPs, SCL, Siemens, Beckhoff, CoDeSys usw. am laufen war.
Mein Beitrag stellt meine Meinung dar, wobei ja Meinung immer was subjektives ist. Objektiv betrachtet kenne ich weder TwinCat noch CoDeSys, aber dafür B&R sehr gut. B&R ist meine Empfehlung für diese Anwendung (wg. Basic), mag sein dass die Formuliereung
maxl schrieb:
Also wenn das So ist, wäre wohl B&R die erste wahl für Dich.
ungünstig gewählt war.

Bin der Meinung, dass IPC und Soft-SPS immer zusammengehören sollten (als TwinCat + Beckhoff-PC, AR010 + B&R-PC, WinLC + Siemens-PC usw.). Bin auch der Meinung dass der B&R APC620 derzeit einer der besten IPCs am Markt ist. Bin zudem noch der Meinung, dass PCs in einer Industrieanlage soweit möglich vermieden werden sollen, und schon gar keine Soft-PLCs darauf laufen sollen. Mag sein, dass dies "altmodische" Ansichten sind, aber es ist meine Meinung.

mfg
Maxl

PS: außerdem ist B&R eine österreichische Firma :)
 
Programmiersprachen

Hi,
es bilden sich immer wilde Diskussionen in dem Bereich. Meine Meinung, und zwar absolut erprobt: mit TwinCat bzw. CoDeSys oder Siemens
SCL/Graph/AWL kann man tolle und sichere Anlagen bauen, da sind
für alle Implementierungsfragen irgenwelche Lösungen da. Darüber hinaus,
falls man was zusätzlich mit PC machen möchte, wäre VB + LibNoDave z.B.
die Alternative, kann man seeehr viel machen.
Bezüglich Meinungen "PC als Steuerung":
"PCs haben da nicht zu suchen" ist konservativ und alt. Ich setzte viele
PCs ein, seit Jahren, und sauber projektierte und programmierte Anlagen
laufen störungsfrei über lange Zeiten. Die heutige Lösungen betreffend
Disaster Recovery sind auch sehr gut, wenn man von den PCs Images
macht, sind die Systeme auch bei HD Crashs sehr schnell wiederhergestellt. Die Windows Systeme kan man abspecken, alles unnötige raus, so laufen die NT(Win 2000 und XP) Systeme sehr stabil.
Nochmals: meine Aussagen sind reale Erfahrungswerte, alles o.g. ist schon
gemacht und getestet, z.T. mehrmals.

Gruss: Vladi
 
Wir haben hier Beckhoff seit 3 Jahren auf einem PC laufen und es läuft. Und die Entwicklungsumgebung kostet nix. Dazu kommt, dass mit Ethercat ein Bus angeboten ist, der extrem schnell ist und die Möglichkeit besteht einen Profibusmaster/-slave als Klemme zu betreiben. Zykluszeiten von 1ms sind überhaupt kein Problem. Mittlerweile macht Beckhoff Werbung mit 100us Zykluszeiten. Da Beckhoff seine Software auf CoDeSys basiert, bekommt man alles inkl. Selbst die Visualisierung ist einfach zu implementieren und das ohne Code.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Gibts dazu auch noch ein link?

Google sagt nichts zu "C-for-Step7".

Die Firma FAT (http://www.fathaco.com/) setzt das ein. Ich war selber völlig baff, dass das geht.
Wir machen Handel von und Service an Werkzeugmaschinen und bieten auch seit kurzem Handling an Werkzeugmaschinen zusammen mit einem Partner aus der Automatisierung an- und da muss man halt an die SPS ran. Muss man bei manchen Herstellern sowieso :???:
Und da ist bei Hochsprachen halt nicht so viel zu machen... Lustig wird's, wenn das Ding schon beim Kunden stehen sollte...

Der Link von deltalogic sieht ganz gut aus, ich denke, dass ich das, was mir da über den Weg gelaufen ist.

Gruß, Tobias
 
Zuletzt bearbeitet:
...
Und da ist bei Hochsprachen halt nicht so viel zu machen...
...

Also wenn Siemens es mal endlich gebacken bekommen würde SCl ordentlich zu implementieren wäre das schon mal ein Riesen Schritt.

Ich persönlich kann auf C als SPS-Sprache sehr gut verzichten.
 
Also wenn Siemens es mal endlich gebacken bekommen würde SCl ordentlich zu implementieren wäre das schon mal ein Riesen Schritt.
Ich setze SCL in der Regel nur zum datenschaufeln (wenn UDTs oder Arrays im Spiel sind) oder für komplexe Mathematische Funktionen ein - der Rest lässt sich auch anders lösen.

Ich persönlich kann auf C als SPS-Sprache sehr gut verzichten.
B&R zum Beispiel unterstützt C von vornherein. Es wird aber nicht als SPS-Programmiersprache propagiert (obwohl das auch geht), sondern hauptsächlich dafür, dass fertige Berechnungsalgoritmen, die als C-Code existieren, einfach in ein SPS-Programm eingebunden werden können.
Es ist z.B. sehr angenehm, wenn man etwas in MathLab durchsimuliert, daraus dann ein C-Programm generieren lässt und dieses einfach ins B&R Studio importiert.

Ansonsten bin ich auch der Meinung, dass C was für den IT-Bereich ist, nicht für SPS-Programmierung.

vladi schrieb:
"PCs haben da nicht zu suchen" ist konservativ und alt. Ich setzte viele PCs ein, seit Jahren, und sauber projektierte und programmierte Anlagen laufen störungsfrei über lange Zeiten. Die heutige Lösungen betreffend Disaster Recovery sind auch sehr gut, wenn man von den PCs Images macht, sind die Systeme auch bei HD Crashs sehr schnell wiederhergestellt. Die Windows Systeme kan man abspecken, alles unnötige raus, so laufen die NT(Win 2000 und XP) Systeme sehr stabil.
Nochmals: meine Aussagen sind reale Erfahrungswerte, alles o.g. ist schon
gemacht und getestet, z.T. mehrmals.
Ich sage lediglich, dass sie soweit wie möglich vermieden werden sollten, nicht dass die da nichts zu suchen haben! Bei meinem derzeitigen Projekt ist ein PC mit WinCCflex Runtime im Einsatz - Ich nutze aber im wesentlichen nur 2 Dinge:
- Historische Trends mit Archiven (ist auf MP zu langsam)
- Proxy-Betrieb von MoviTools: PC dient als Gateway von Ethernet auf Profibus.
Bei Anbindungen an Datenbanken, BDE-Systeme oder Bilderkennungen sind PCs klar die richtige Wahl; aber reine Visu-PCs sind einfach unterfordert und für das was sie leisten müssen, einfach zu teuer.

mfg
Maxl
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich setze SCL in der Regel nur zum datenschaufeln (wenn UDTs oder Arrays im Spiel sind) oder für komplexe Mathematische Funktionen ein - der Rest lässt sich auch anders lösen.
...
Also ich erinnere mich ja nur schwach an Step7 und SCL. Aber musste man da nicht über SCL-Quellen das ganze einbauen und die Online Betrachtung war sehr mühselig.
Also selbst wenn man es nur für wenige aber komplexe Aufgaben einsetzt sollte es leicht zu handeln sein.
Ich selbst würde ja ein Gemisch von FUP/ST(SCL)/AS(Graph7) bevorzugen immer der Aufgabe angemessen auf AWL verzichte ich.

B&R zum Beispiel unterstützt C von vornherein. Es wird aber nicht als SPS-Programmiersprache propagiert (obwohl das auch geht), sondern hauptsächlich dafür, dass fertige Berechnungsalgoritmen, die als C-Code existieren, einfach in ein SPS-Programm eingebunden werden können.
Es ist z.B. sehr angenehm, wenn man etwas in MathLab durchsimuliert, daraus dann ein C-Programm generieren lässt und dieses einfach ins B&R Studio importiert.
...
Ok, überzeugt für den beschriebenen Fall macht es wirklich Sinn. Vorhandene C-Sourcen als gekapselte Funktion. Man muss das Rad ja nicht neu erfinden. Wobei eine Umsetzung von einfachen C Programmen nach ST(SCL) keine schlimme Sache ist.

Ich sage lediglich, dass sie soweit wie möglich vermieden werden sollten, nicht dass die da nichts zu suchen haben!
...
Bei Anbindungen an Datenbanken, BDE-Systeme oder Bilderkennungen sind PCs klar die richtige Wahl; aber reine Visu-PCs sind einfach unterfordert und für das was sie leisten müssen, einfach zu teuer.
...

Ich weiß das Thema hatten wir schon x-mal. Aber der PC als SPS ist Praxis erprobt und kommt hauptsächlich auf den Kunden an ob der das will oder nicht.
Sobald wir einen PC als Visu brauche nutze wir den auch als SPS. Allerdings kommt das wohl auch daher das wir immer jede Menge an Daten speichern müssen und eine sehr aufwendige Visu einsetzen die eine komfortable Fehlersuche ermöglicht.
Die Anbindung ab das Leitsystem läuft völlig getrennt von der SPS ebene da die SPS die Ergebnisdaten direkt auf den PC Speichert und das Leitsystem sich die Daten dort abholen kann das macht es den Admins leicht.
Ganz zuschweigen von der Leistungsfähigkeit es Systems Zykluszeiten von 1ms und das nicht gerade bei kleinen Programmen. Meist nützt die SPS ohne Visu und die Visu taugt ohne SPS nichts dann kann das auch eine Komponente sein.
 
Für Maschinen bei denen jeder Cent zählt, kann evtl. auch das eine Alternative sein:

http://www.linuxcnc.org/

Es geht um das Projekt EMC, welches die Grundlage für die Steuerung von CNC-Maschinen liefert. Angesichts das MS jetzt nur noch Vista liefert und Vista in erster Linie für Konsumenten mit Multimediaanwendungen gebaut wurde, gehen auch die guten Zeiten für Beckhoff und Co. dem Ende entgegen. Ich bin jedenfalls gespannt, was denn als Ersatz für XP kommen wird.
 
Angesichts das MS jetzt nur noch Vista liefert und Vista in erster Linie für Konsumenten mit Multimediaanwendungen gebaut wurde, gehen auch die guten Zeiten für Beckhoff und Co. dem Ende entgegen. Ich bin jedenfalls gespannt, was denn als Ersatz für XP kommen wird.

Für die Industrie gibt es die "Emebdded"-Versionen, die kannste dir ohne Muiltimedia-Schnickschnack zusammenstellen. XP wird es noch lange Zeit geben, denke ich, denn von der Technik her ist Vista nix wirklich neues, was der Industrie nutzen könnte:
http://www.microsoft.com/windows/embedded/de-de/plan_faq.mspx

Ansonsten nimmt man Windows CE:
http://www.pc-control.net/pdf/012007/pcc0107_embedded_d.pdf
CE ist ein Echtzeitbetriebssystem mit offen gelegtem Quellcode und kostet in der Grundversion pro Lizens unter 20 Dollar:
http://www.microsoft.com/windows/embedded/de-de/license.mspx
 
Zuletzt bearbeitet:
Zurück
Oben