Mit STEP 7 Brötchen verdienen

Hi,

slebstständig ist immer gut. Hast Du auch potentielle Auftraggeber?
Rosa

Das Programmieren der S5 und auch der S7 beherrschen jede Menge Leute.
Es gehört zum Beispiel bei Energieelektronikern zur Ausbildung. Außerdem
jagt das Arbeitsamt jeden 2. zu einem STEP 7-Lehrgang.

Setze Merker 64.0
ODER NICHT

;-)

MfG Paul

Frank B. schrieb:

> Auch werden Produktionsanlagen gerne am Wochenende oder in den
> Werksferien, zwischen Weihnachten und Neujahr um- oder aufgebaut.
> Da ist Fernseher reparieren schon angenehmer :-)

Das hatte ich bei der Telekom aber auch im Großanlagengeschäft. 
TK-Anlagen bei Geschäftskunden konnten nur komplett in Stillstandsphasen 
umgebaut werden. Wenn es nicht ging, mußten die Anlagen auch vollständig 
parallel aufgebaut werden. Wurde aber alles korrekt bezahlt, Samstags- 
und Sonntagsüberstunden und Nachtzuschläge. Kein Problem.

Würde mich eher auf deinem Fachgebiet selbständig machen an deiner 
Stelle...

Das ist doch Unsinn, Fernseher werden durchaus noch repariert. Das wird 
auch noch eine Weile so bleiben, durch den Kostendruck der Hersteller 
gehen die nämlich immer schneller kaputt... ;-)

Paul Baumann schrieb:
> Das Programmieren der S5 und auch der S7 beherrschen jede Menge Leute.
> Es gehört zum Beispiel bei Energieelektronikern zur Ausbildung. Außerdem
> jagt das Arbeitsamt jeden 2. zu einem STEP 7-Lehrgang.
>
> Setze Merker 64.0
> ODER NICHT
>
> ;-)
>
> MfG Paul

so sehen diese programme dann aber meist auch...

(beendet mit kalten schauern über noch einen vermurksten s5-s7 
programmierer)

Michael S. schrieb:
> beim Blödmarkt beschäftigt

Der Blödmarkt verdient aber auch nichts an der Reparatur. Dem ist es 
lieber, du kaufst bei ihm einen neuen Fernseher. Ich hatte letztes Jahr 
meinen 4 Jahre alten Flachbild-TV in einer kleinen Werkstatt und die 
Reparatur war finanziell auf jeden Fall eine Alternative zum Neukauf.

@ TO: Bedenke immer, dass du kein Ingenieur bist oder sonst irgend eine 
HS / FHS besucht hast. Das wird nämlich bei Freelancer meist 
vorausgesetzt. Die Firmen holen oftmals auch eher die Leute, die die 
komplette Anlage gebaut und die SPS beim Bau eingerichtet haben. Die 
brauchen keine /kaum Einarbeitung.

Mein Tipp: Lass es...

Zuckerle schrob:
>Zwischen mir und einem der vom Arbeitsamt aufn Kurs geschickt wird sind
>Welten.

Pass auf Du...
Ich verpasse Dir gleich einen Wischimpuls, der alle Deine Merker rück-
setzt!

;-)

MfG Paul

Hallo Steppi,

ich bin im Bereich Automatisierungstechnik unterwegs. Ich kann Dir 
sagen, daß ich weiß daß viele Leute denken SPS programmieren wäre setze 
Merker so und so ....blablabla

Wer in dem Bereich mal gearbeitet hat weis definitiv daß das viel mehr 
ist. Letztlich ist z.B. AWL nichts anderes als Assembler, darüberhinaus 
werden auch hier die Hochsprachen immer wichtiger.

Mit einem buch oder einem Arbeitsamtskurs schaust du dann in einer 
richtigen Firma wie die Sau ins Uhrwerk, das kann ich dir versprechen.

Nehmen wir nur mal das Beispiel Antriebe...da gehört schon mehr dazu und 
schwupps siehst du dich mitten in der Regelungstechnik.

Wer hier immer so tut, daß jeder Elektriker SPS programmieren könnte nur 
weil er weis was ein UND oder ODER ist, hat von diesem Geschäft 
definitiv keine Ahnung.

Mit einem Schnellkursus erreichst du da auf alle Fälle gar nichts.

@Hans-Heinrich

Wo bzw. wie hast Du das Programmieren von SPS erlernt? Das würde mich
brennend interessieren. Ich will Dich nicht provozieren, bitte verstehe
meine Frage nicht so.

Es steht außer Frage, daß man das "Fein"-Programmieren daran am Besten 
am lebenden Objekt lernt, nur- man muß von Irgendjemandem die Grundlagen
beigebracht bekommen.

Ich weiß von einem Kurs des Arbeitsamtes, der ein halbes Jahr andauerte
und von Siemens-Ausbildern geleitet wurde. Da war Alles bunt gemischt
vertreten, was vorher irgendwie eine Elektroausbildung genossen hatte.

(Ingenieure, Techniker, Meister, Facharbeiter bunt durcheinander)

Dabei stellte sich heraus, daß die Facharbeiter am Liebsten im 
Kontaktplan
(KOP) programmierten, weil sie ihre Schaltung nur im Kopf um 90 Grad
drehten und eingeben konnten.

MfG Paul

Hallo Hans-Heinrich,

das SPS programmieren habe ich "gelernt" an der Technikerschule im 
Studium zum Elektroingenieur. Darüber hinaus habe ich bei zwei Firmen 
gearbeitet, die nichts anderes machen. Also Projektingenieur für 
Automatisierungstechnik.

Zum Thema KOP: Das ist ohnehin der (wenns nicht speziell anders geforder 
ist) üblichste Weg (auch international). Trotzdem setzen sich z.B. SCL 
immer mehr durch und eines Tages werden wohl FUP, KOP, AWL dadurch 
verdrängt. Wenn du aber z.B. B&R nimmst, kannst du da auch wunderbar in 
C programmieren. Hängt halt auch immer von Vorgaben des Kunden ab. Wie 
ich schon gesagt habe...SPS ist nicht nur einfach das programmieren 
einer trivialen Logik. Schau dir nur mal die ganzen BUS Geschichten an. 
Es gibt immer welche, die das ganze so "konfigurieren" daß man zum 
Schluß das ganze einfach "ansprechen" kann, wenn aber das so nicht 
gewollt ist und jemand von dir verlangt wirklich mit send und receive zu 
programmieren trennt sich die Spreu vom Weizen. Letztendlich reden wir 
halt doch einfach von Mikrocontrollerprogrammierung.

O.T.
>Wenn du aber z.B. B&R nimmst, kannst du da auch wunderbar in
>C programmieren.

C und wunderbar? Das Einzige, wofür ich C verwende, ist der Laufwerks-
buchstabe der 1.Festplatte in meinem Rechner.
;-))

MfG Paul

Also Sorry,

aber bezüglich C werd ich jetzt sicherlich nicht ablästern. Wer damit 
nicht zurecht kommt sind eben genau die, die lieber ein paar UND und 
ODER nehmen und dann möglichst grafisch zusammenschalten. Wenn wir von C 
sprechen sprechen wir eben vom Programmieren.

Sag ich doch

Zum Thema STEP 7:

Warum sollte man eine firmenspezifische Programmiersprache lernen, wenn 
es seit Jahren eine internationale Norm (IEC 61131-3) gibt, die von den 
meisten anderen Unternehmen in der Branche (z.B. Beckhoff, Wago, ABB, 
Bosch, Festo etc.) eingehalten wird und somit wesentlich flexibler ist?

STEP 7 ist meines Wissens nach nur in Deutschland wirklich bekannt und 
verbreitet.

Das Ganze ist doch ein reines Marketinginstrument, um die Kunden für 
immer an eigene Automatisierungsprodukte zu binden.

Mich wundert es, dass das praktisch keinen hier interessiert.

MfG

>Wenn du aber z.B. B&R nimmst, ..

Ja, die haben aber noch einiges zutun mit der SW, nicht mit der HW.


>Mich wundert es, dass das praktisch keinen hier interessiert.

Meine Rede.

Sascha schrob:
>KOP ist tot

Na, mach Dir mal keinen KOPP um den KOP. ;-)
In der o.g. IEC61131-3 ist auch der KOP noch gleichrangig vertreten.

@Hans Heinrich

Es gibt die Möglichkeit mittels ST (Strukturierter Text) zu 
programmieren.
Das ist eine "ordentliche" Sprache, die eher wie ein Pascal-Quelltext
aussieht und im Gegensatz zu "C" nicht alle verfügbaren Sonderzeichen
als Operatoren benutzt.

MfG Paul

>Wer in dem Bereich mal gearbeitet hat weis definitiv daß das viel mehr
>ist. Letztlich ist z.B. AWL nichts anderes als Assembler, darüberhinaus
>werden auch hier die Hochsprachen immer wichtiger.

Na zwischen Assembler und AWL liegen aber noch Welten. AWL ist stark 
vereinfachte Assemblerprogrammierung, wo die wirklich koplizierten Dinge 
und Fallen weggelassen wurden. FUP, KOP, AWL wurden geschaffen, damit 
Hinz und Kunz völlig plattgormunabhängig in kurzer Zeit programmieren 
kann. Man kann damit Personal mit geringerer Quali als einen Ingenieur 
oder Informatiker einstellen.

In den meisten Großbetrieben gibt es spezielle festangestellte Leute, 
die für die Steuerungen verantwortlich sind. Dort kommt man als 
Freelancer kaum rein. Und SPS-Programmierer gibt's auch wie Sand am 
Meer. Ich würde es sein lassen. Ohne das Nennen bisheriger Kunden hast 
Du sowieso keine Chance, einen Auftrag zu bekommen.

Globi schrieb:
> Das ist doch Unsinn, Fernseher werden durchaus noch repariert. Das wird
> auch noch eine Weile so bleiben, durch den Kostendruck der Hersteller
> gehen die nämlich immer schneller kaputt... ;-)

Meine Beobachtung ist, dass man da ganz gut fahren müsste, wenn man in 
einem Geschäft angestellt ist das auch Neugeräte verkauft. Dann testet 
man nur, ob alle Kabel sitzen, irgendwas wackelt oder verstellt ist...
Und dann zuckt man mit den Schultern, sagt dass da nix zu machen ist, 
man sich lieber ein neues Gerät kaufen sollte, und verweist freundlich 
auf den Verkäufer.

Der hat dann schon viele Informationen um den Kunden einzuwickeln, und 
der fühlt sich auch ein bisschen schuldig, weil er so viel Umstände 
gemacht hat...

:)

>Letztlich ist z.B. AWL nichts anderes als Assembler,
Totaler Quarsch!
Versuch mal mit AWL einen uC in Assembler zu programmieren!
20 verschiedene Adressierungsarten?

>FUP, KOP, AWL wurden geschaffen, damit Hinz und Kunz völlig
>plattformunabhängig in kurzer Zeit programmieren kann.
Stimmt. Kommt von dem Steuerungsbau mit Schützkontakten her.

Es gibt einige SPSen, die man auch mit C,C++ oder anderen Hochsprachen 
progr kann. (Auch kann man bei verschiedenden ASM (aber das ist nicht 
AWL!!) einbinden.)

Ich habe ja auch nicht geschrieben, daß AWL das gleich ist wie Assembler 
sondern verwendete noch das hier duchaus wichtige Wort letztlich.

Die SPS ist letztlich auch nihts anderes als ein uC und für genau diesen 
ist AWL eben das Pendant zur Assemblerprogrammierung. Geschichten wie 
Stack und sonstiges spielen ja auch eine Rolle bei SPS. Wie gesagt, wer 
noch keine größeren und komplizierten SPS Projekte gesehen hat, meint 
immer wieder reden nur von UND und ODER. Zu KOP und FUP mußich auch 
sagen, daß es für Hinz und Kunz entwickelt wurde. Oder man vergleiche 
mal z.B. wie simpel es ist ein Analogsignal auszuwerten...da muß man 
sicher nicht studiert haben...sieht bei einem "echten" uC also ohne den 
ganzen rießigen Step7 Aufbau ganz anders aus.

Ich würde mich auch auf keinen Fall hier selbstständig machen aus den 
gleichen Gründen wie schon genannt aber mach dir auch mal über deine 
Verantwortung hier Gedanken. Wenn da was passiert, dann kannst du dich 
einglasen lassen.

>Die SPS ist letztlich auch nihts anderes als ein uC und für genau diesen
>ist AWL eben das Pendant zur Assemblerprogrammierung.

Die SPS ist ein µC (z. B. C167 von Siemens) mit angebauter Peripherie. 
Die Entwicklungsingenieure haben in Assembler und C eine Metasprache 
(AWL) entwickelt, die den Anwender von bestimmten Internas entbindet 
(Programmiermodell, Addressierungsarten, Adressdistanzen, Betriebsarten 
des Controllers, Pipelineeffekten, Atomics). Für die meisten 
Standardanwendungen wurde dann noch der KOP (USA) und der FUP 
entwickelt. Das alles, um die Programmierung wiederkehrender Probleme 
fehlerfreier, plattformunabhängig, von Personal mit niedrigerer 
Qualifikation ausführen lassen zu können. Es handelt sich also um einen 
problementschärften Mikrocontroller mit entschärfter (vereinfachter) 
Programmiersprache.

>Die SPS ist ein µC (z. B. C167 von Siemens)
Ja, verschiedene SPSen (Siemens oder auch andere) hatten C667, oder auch 
'51er drin.
Aber (wie geschrieben) der uC arbeitet im Verborgenen, wie bei vielen 
anderen Geräten auch.
Und aussen erscheint nur das, was der SPS-Geräte-Entwickler vorgesehen 
hat. Sonst nichts. An den ASM des uCs kommt der Anwender (jedenfalls bei 
den meisten Geräten) definitiv nicht heran (soll er wohl auch nicht, 
denn dort gibt es ua CPU-Register und 100e SFR's).

>Es handelt sich also um einen problementschärften Mikrocontroller mit
>entschärfter (vereinfachter) Programmiersprache.
Seltsam ausgedrückt.

>Aber (wie geschrieben) der uC arbeitet im Verborgenen, wie bei vielen
>anderen Geräten auch.

Nichts anderes habe ich geschrieben.

>>Es handelt sich also um einen problementschärften Mikrocontroller mit
>>entschärfter (vereinfachter) Programmiersprache.
>Seltsam ausgedrückt.

Oder ganz krass: Ein µC für dummies.

Ich würde nicht sagen ein uC für Dummies, sondern ein streng 
durchstandartisierter uC bei dem eben die Fallstricke der Internas 
weitestgehend durch den "Aufbau" eliminiert wurden.

Im Prinzip meinen wir alle das gleiche :)

PS: Mit "Aufbau" meine ich Step7

Sagen wir ein Mikrocontroller light (von der Programmierung her, nicht 
von der Leistungsfähigkeit)

So könnte man es bezeichnen.

Übrigens in der C167 von Infenion :)

>Ich würde nicht sagen ein uC für Dummies, sondern ein streng
>durchstandartisierter uC bei dem eben die Fallstricke der Internas
>weitestgehend durch den "Aufbau" eliminiert wurden.
Nein.
Es ist KEIN uC! (auch wenn der im verborgenen drin ist. Eine 
Waschmachine ist auch kein uC, auch wenn dort einer drin ist. Und auch 
eine Waschmachine kann man "programmieren".)

Sorry, aber das ist Blödsinn oder hast du in deiner Waschmaschine schon 
mal einen Zeiger programmiert ?

Hallo,

PCS7 ist voll im Trend und Anspruchsvoll! TIA ist das Schlagwort!

1. Integrierte F-Technik. Haben noch nicht all zu viele Hersteller.
2. SFC = Schrittkette.
3. WinCC / Dynamische Bilder, Skripte Wahlweise in C oder VBA.
4. Windows Netzwerkumgebung
5. usw, usw


Allerdings würde ich nicht das Risiko auf mich nehmen und eine
Fremde Anlage betreuen. Wenn die CPU stehen bleibt können da schon
einige Tausend Euro Schadensersatz fällig werden. Trotz Standard,
jede Anlage ist anders. Aber man verdient gut!


Viel Erfolg und Gruß

>Sorry, aber das ist Blödsinn oder hast du in deiner Waschmaschine schon
>mal einen Zeiger programmiert ?
Das "programmieren" stand in Anführungszeichen. Genau wie das 
"programmieren" in "Assembler" bei einer SPS.
Oder hast du bei deiner SPS (gehe mal davon aus, dass du die nicht 
selbst gebaut hast) schon mal mit Mikroprozessor-Registern oder -SFRs 
programmiert?

Hans Heinrich schrieb:
> Ich würde nicht sagen ein uC für Dummies, sondern ein streng
> durchstandartisierter uC bei dem eben die Fallstricke der Internas
> weitestgehend durch den "Aufbau" eliminiert wurden.
>
> Im Prinzip meinen wir alle das gleiche :)

Genau, es ist eine standardisierte Schnittstelle zur Maschinenperipherie 
und zugleich eine fertige Lösung (Software, Hardware) für 
Automatisierungsaufgaben. Man könnte ja theoretisch wirklich einen µC 
oder ähnliches nehmen, was zu viel mehr Entwicklungsarbeit und später zu 
Problemen bei der Wartung führt (Steuerung geht nicht-> Entwickler hat 
gekündigt-> wer machts?, Chinese vor Ort bekommt keine Ersatzteile). Man 
kann schnell einfache Probleme damit lösen (paar Verknpüfungen setzen 
kann jeder gute FA), jeder versteht die Programme (und die großen 
Hersteller haben in jedem Land Vertretungen). Deswegen hat die SPS wohl 
den Ruf nicht anspruchsvoll zu sein. Wenns ans Eingemachte geht 
(Regelungstechnik, zeitkritsche Anwendungen) sollte man doch 
entsprechenden Background haben. Damit machen gewisse Leute Geld. Die, 
die vom AA oder sonstwem geschult werden können einfachere Steuerungen 
realisieren oder ggf. mal ins Programm schauen fürs Troubleshooting. 
Ausnahmen bestätigen natürlich die Regel. Aber ohne Diplom oder 
vielleicht einen Techniker-Abschluss ist der Zugang zu komplexen 
Aufgaben versperrt.

Dietrich schrieb:
> STEP 7 ist meines Wissens nach nur in Deutschland wirklich bekannt und
> verbreitet.

Dafür, daß es nur in Deutschland verbreitet ist, bin ich aber in den 
letzten 10 Jahren ziemlich viel herumgekommen auf der Welt :-)

>Aber ohne Diplom oder
>vielleicht einen Techniker-Abschluss ist der Zugang zu komplexen
>Aufgaben versperrt.


Richtig! Nur der Professor kennt den Prozessor.
;-)
Guck Dir mal das an:
http://www.sps-edv-schulungen.de/sps-techniker.html

Da bekommst Du alles, was Du brauchst gelehrt. Ich denke schon, daß man 
in
6 Wochen Vollzeit genügend beigebracht bekommt, auch als Meister oder
Facharbeiter. Die Welt besteht nicht nur aus Ingenieuren, Technikern und
Tölpeln. Ich habe es erlebt, daß ausschließlich Facharbeiter eine ganze
Fertigungsstraße für Betonelemente selbst konstruiert, gebaut und die 
Pro-
gramme für mehrere, die Anlage steuernde S7 geschrieben haben. Da hat
Keiner um Hilfe nach Ingenieuren und Technikern geschrien...

MfG Paul

Dietrich schrieb:
> Mich wundert es, dass das praktisch keinen hier interessiert.

Das könnte daran liegen:
Insgesamt wurden Anfang des Jahres deutschlandweit 401 Maschinenbauer, 
Steuerungsbauer und Ingenieurbüros zu ihrem Kaufverhalten und ihren 
zukünftigen Technologiewünschen im Bereich der SPS-Systeme und 
Industrie-PC befragt...Hier lag Siemens mit über 99 % sowohl in der 2001 
als auch in der 2005 durchgeführten Studie an Platz 1, gefolgt von 
Moeller und Rockwell.

Ach ja, für die Quellenfanatiker:
http://www.vipa.de/de/aktuelles/news-detail/article/marktstudie-zu-sps-und-ipc/

Paul Baumann schrieb:
> Die Welt besteht nicht nur aus Ingenieuren, Technikern und
> Tölpeln. Ich habe es erlebt, daß ausschließlich Facharbeiter eine ganze
> Fertigungsstraße für Betonelemente selbst konstruiert, gebaut und die
> Pro-
> gramme für mehrere, die Anlage steuernde S7 geschrieben haben. Da hat
> Keiner um Hilfe nach Ingenieuren und Technikern geschrien...

Ich meinte das so: Ein Fernsehmonteur macht eine Schulung und danach 
bewirbter sich als Freelancer für SPS Programmierung (auf die 
Ausgangsfrage bezogen).
Ich wollte auf keinen Fall eine wer-ist-besser-Diskussion anfangen. Ich 
kenne aber persönlich Fälle die absolute SPS-Cracks sind, aber auf den 
Arbeitsmarkt bei den Firmen keinen Fuß in die Tür bekommen (als 
Programmierer) und deswegen gehen die nochmal zur Schule.

Wer auch nur ein wenig Ahnung von der Steuerungsprogrammierung hat und 
sich die Inhalte des oben genannten Links ansieht,

http://www.sps-edv-schulungen.de/sps-techniker.html

wird nichts weiter als ein müdes Lächeln für einen solchen Kurs übrig 
haben...

billy schrieb:
> Wer auch nur ein wenig Ahnung von der Steuerungsprogrammierung hat und
> sich die Inhalte des oben genannten Links ansieht,
>
> http://www.sps-edv-schulungen.de/sps-techniker.html
>
> wird nichts weiter als ein müdes Lächeln für einen solchen Kurs übrig
> haben...

Habe es mir mal durchgelesen. In dem Kurs wird vermittelt, was überhaupt 
zur SPS(-Programmierung) dazugehört und wie ein Programm strukturiert 
wird.  Kein Wort zu Regelungstechnik, Bussystemen u.ä...
Also wie gesagt, nur mit dem Kurs, sind schon einfache Programme 
(Ampelsteuerung o.ä.) möglich. Oder anders ausgedrückt: Derjenige 
Kursabsolvent fängt bei Firma xy an mit der Aufgabe: Entwickeln sie eine 
Steuerung/Regelung für ... mit Anbindung an ... .

Es ist so:

Die hinter den S7-Systemen stehende Logik ist prinzipiell einfach. 
Allerdings verlagert sich die S7-Programmierung immer weiter vom 
einfachen Ersatz von Relais durch eine SPS in Richtung aufwendiger 
Antriebstechnik, HMI/GUI, Datenaustausch mit übergeordneten Servern, 
z.B. zur Qualitätssicherung etc. Wer da noch mit KOP arbeiten will, muss 
Masochist sein. Das nur so als Einwurf.

Programmierung von Steuerungstechnik ist, wie gesagt, heute viel mehr 
als nur die Programmierung einfacher logischer Verknüpfungen. Bei vielen 
Anlagen gibt es eine recht aufwendige und komplizierte Infrastruktur.

Zweitens gibt es das Problem der Haftung. Ich bin im Automotivebereich 
tätig, deshalb ist für mich eine gute (und sehr teure) 
Betriebshaftpflichtversicherung ein Muss.

Drittens gibt es das Problem der Auftragsumfänge. Nicht selten kosten 
die Anlagen bzw. Maschinen mehrere Millionen Euro, und der projektierte 
Terminplan ist unter allen Umständen einzuhalten, da sonst hohe 
Vertragsstrafen drohen. Gerade das Automotiveumfeld ist da recht 
kritisch, da bei einem Produktneuanlauf doch sehr viele Firmen beteiligt 
sind, und gelegentlich deutlicher Terminstress vor dem Produktionsstart 
entsteht.

Zuletzt ein Tipp: ich habe schon viele Leute kennen gelernt, die 
behauptet haben, SPS-Programmierung wäre doch einfach, das hätte man 
"schon in der Schule alles gemacht". Häufig ist das einfach die in Mode 
gekommene totale Selbstüberschützung der jüngeren Generationen. Nach 
einigen Monaten Einarbeitung sieht man dann schnell, ob jemand Fuß 
gefasst hat und ihm zuzutrauen ist, das Thema zu beherrschen, oder ob er 
immer in der zweiten Reihe wursteln wird, weil er einfach von der 
Komplexität der Anforderungen überfordert ist.
Ich kenne nur Leute, die entweder die ersten Projekte erfolgreich 
durchgezogen haben und dann auch fortwährend problemlos an weitere 
Aufträge gekommen bzw. als Angestellte in diesem Bereich geblieben sind, 
und solche, die sofort gescheitert sind und festgestellt haben, dass 
Ihnen das Thema nicht liegt.

Alles in allem ist das Arbeitsumfeld Automatisierungstechnik allerdings, 
und ich denke, das kann ich nach über 13 Jahren Tätigkeit in diesem 
Bereich einschätzen, eher undankbar. Wie gesagt: durch immer weiter 
steigende Auftragsumfänge und Komplexität, sehr enge Terminvorgaben, 
große Mengen an Leuten und Firmen in diesem Umfeld, wodurch die Preise, 
vor allem seit der Krise 2009/2010 ziemlich eingebrochen sind, häufige 
Reisetätigkeit, Haftung, und nicht zuletzt durch enormen 
Weiterbildungsdruck, kann man sich schon angenehmere Tätigkeiten 
vorstellen.

Dem Beitrag von High Performer ist wirklich nichts mehr hinzuzufügen. 
Insbesondere der letzte Absatz ist nichts als einfach nur wahr und macht 
diesen Job deshalb irgendwo auch so unattraktiv

Du hast Recht, die Funktionen werden bei mir im OB32 im 1Sek-Takt
abgearbeitet. Aber trotz der fast 1.000 POs = Prozessobjekte
beträgt die Zykluszeit bei den aktuellen 417F/H min. 32ms
max. 370ms und aktuell 170..180ms (Die Werte habe ich so in Einnerung)
zu dem laufen auch viele Funktionen mit 10ms Abtastung. Es ist schon 
fast Wahnsinn wie schnell die Modernen CPUs sind. Einfache Addition nur 
1us.


Schöne Grüße

>>Autor: Dietrich (Gast)
>>Datum: 07.09.2011 20:41
>>
>>Zum Thema STEP 7:
>>
>>Warum sollte man eine firmenspezifische Programmiersprache lernen, wenn
>>es seit Jahren eine internationale Norm (IEC 61131-3) gibt, die von den
>>meisten anderen Unternehmen in der Branche (z.B. Beckhoff, Wago, ABB,
>>Bosch, Festo etc.) eingehalten wird und somit wesentlich flexibler ist?

und was bitte bringt der standart IEC61131-3?????
meine wenn ich ne software genau gemäss dieser norm schreibe, wird sie 
trotzdem nicht 1:1 von eienr sps eines herstellers auf die einen anderen 
portierbar sein (naja vielleicht ein ganz primitives programm...)
weiter ist IEC61131-3 (NOCH) nicht objektorientiert, was in naher 
zukunft zwar kommen wird (beckhof wird den standart setzen)...

schlussendlich muss man programmieren können... ob jetzt step7, beckhof, 
etc...

Richtig, IEC 61131/3 ist eigentlich nur ein Pseudo-Standard, weil die 
Portierung wenn überhaupt nur mit viel Glück funktioniert. Das hat man 
wohl den Platzhirschen wie Siemens zu verdanken.

> (beckhof wird den standart setzen)...

Nicht Beckhoff, 3S wird das tun.

>Es ist schon fast Wahnsinn wie schnell die Modernen CPUs sind.
>Einfache Addition nur 1us.
Soll wohl ein Witz sein.
Selbst ein rel einfacher uC macht das in 10..20 ns.

MCUA schrieb:
>>Es ist schon fast Wahnsinn wie schnell die Modernen CPUs sind.
>>Einfache Addition nur 1us.
> Soll wohl ein Witz sein.
> Selbst ein rel einfacher uC macht das in 10..20 ns.


Aber wir reden hier von SIemens ;-)

Haha

Sorry, mein Fehler. Richtig sind 75ns!

MCUA schrieb:
>>Es ist schon fast Wahnsinn wie schnell die Modernen CPUs sind.
>>Einfache Addition nur 1us.
> Soll wohl ein Witz sein.
> Selbst ein rel einfacher uC macht das in 10..20 ns.

Bitte nicht eine Birne mit einem Apfelbaum vergleichen!

Die Komplexität einer Fertigungsanlage ist als Außenstehender kaum 
vorstellbar!
Sonst 100% agree den Beitrag von High Performer.

>Die Komplexität einer Fertigungsanlage ist als Außenstehender kaum
>vorstellbar!
Pauschalisiertes Geplapper.
Eher passt die "Komplexität" einer Fertigungsanlage, wenn richtig 
programmiert, in einen GANZ KLEINEN uC (oder in einen Schrank voller 
Schütze) hinein.
Und solange weder in Assembler noch mit einer richtigen 
Programmiersprache gearbeitet wird, kann von Komplexität eigentlich 
keine Rede sein.

MCUA schrieb:
>>Die Komplexität einer Fertigungsanlage ist als Außenstehender kaum
>>vorstellbar!
> Pauschalisiertes Geplapper.
> Eher passt die "Komplexität" einer Fertigungsanlage, wenn richtig
> programmiert, in einen GANZ KLEINEN uC (oder in einen Schrank voller
> Schütze) hinein.
> Und solange weder in Assembler noch mit einer richtigen
> Programmiersprache gearbeitet wird, kann von Komplexität eigentlich
> keine Rede sein.

Ich habe bisher noch keinen "GANZ KLEINEN uC" gesehen der eine heutige 
Fertigungsanlage verwaltet. Bei einzelnen Applikationen wie z.B. die 
Regelung einer Kleberheizung oder die Auswertung in der 
Qualitätskontrolle sind mit einem "GANZ KLEINEN uC" in Assembler zu 
realisieren, da gebe ich dir Recht!

Ich will aber dein Programm sehen in deinem "GANZ KLEINEN uC", welches 
i.d.R. mehrer Roboter als Slave-Teilnehmer, verschiedene Antriebe, 
verschiedene HMI, verschidenste Applikationen (wie schon genannt), 
hunderte dezentrale EAs, personelle Sicherheit nach der MRL und nahezu 
100%ige Diagnose mit ensprechender maschineller Sicherheit 
(netzunabhägig wie Profinet, Interbus etc.) verwaltet.

Anschließend kannst du es ja nochmals mit einem Schrank voller Schütze 
aufbauen. Vergiss aber bitte den Uplink zur Warte nicht, sonst werden 
die Krawattenträger sehr ungemütlich, wenn sie keine Bilder mehr 
geliefert bekommen!

>Pauschalisiertes Geplapper.
>Eher passt die "Komplexität" einer Fertigungsanlage, wenn richtig
>programmiert, in einen GANZ KLEINEN uC (oder in einen Schrank voller
>Schütze) hinein.

Also das ist so pauschal jedenfalls dann nicht korrekt, wenn man auch 
die eingesetzte Peripherie betrachtet. Bereits einfache Servoantriebe, 
Industrieroboer, Kamerasysteme oder auch Bediengeräte benötigen jedes 
Gerät für sich bereits ausreichend Rechenleistung, die mit "einem GANZ 
KLEINEN uC" nicht mehr zu machen ist.

Die Komplexität einer Anwendung hängt außerdem ja sicher nicht in erster 
Linie vom "Footprint" ab, sondern von der Anwendungsart. 
Selbstverständlich können z.B. bereits in einem einfachen 
Cortex-M3-Controller durchaus komplexe Abläufe programmiert werden. Man 
schaue sich nur mal den internen Aufbau an. Hier kann bereits die 
Umsetzung mit dem Ziel, Echtzeitverhalten auf der einen und ergonomische 
Kommunikation mit dem Anwender, eine gewisse Herausforderung darstellen.

Bei der Steuerungstechnik sieht das ähnlich aus. So ist meiner Ansicht 
nach z.B. die Basisinbetriebnahme komplexer Fertigungsmaschinen auf 
840D-Basis nicht gerade trivial, und es gehört schon ein klein wenig 
Know How dazu.
Die Komplexität in der Steuerungstechnik rührt auch in den meisten 
Fällen nicht von der Komplexität der Einzelkomponenten her, sondern vom 
Umfang des "Gesamtkunstwerks". Der Softwareentwickler muss dabei häufig 
interdisziplinäre Bereiche beherrschen, z.B. Sicherheitstechnik, 
Ergonomie, Algorithmen und Datenstrukturen, Regelungstechnik, dann soll 
er noch Kameras, Roboter, Scanner, Servoantriebe, Schraub- und 
Messsysteme etc. programmieren bzw. parametrieren. In größeren Firmen 
gibt es dafür Fachabteilungen, aber das ist eher nicht die Regel.
Der kleine "Pferdefuß" bei aktuellen Steuerungen ist auch die zyklische 
Ausführung des Programms, die die Programmierer dazu zwingt, bestimmte 
Programmteile anders zu implementieren, als es ein Informatiker 
vielleicht in seinem PC-Programm tun würde.

Allerdings muss ich auch zugestehen, dass Softwareentwickler in der 
Steuerungstechnik oft wenig elegante Programme schreiben, um es mal 
vorsichtig auszudrücken. Über die Ursachen möchte ich hier nicht 
spekulieren, um nicht den Zorn bestimmter Berufsgruppen auf mich zu 
ziehen ;-)

So wie es in C++ z.B. nicht unbedingt sinnvoll ist, in seinem Quelltext 
zu zeigen, wie perfekt man die syntaktischen und semantischen Details 
der Sprache beherrscht (z.B. durch trickreiche Ausnutzung der 
Operatorprioritäten), so ist das auch in der Steuerungsprogrammierung 
nicht sinnvoll.

Hallo,

ich glaub Ihr habt nicht verstanden was MCUA euch sagen will.

Er hat selbst noch nie in einer Linie gestanden und will euch nur sagen 
daß er TROTZDEM der einzige ist, der weis wie der Hase läuft und alle 
außer Ihm sowieso blöd sind. So einfach ist das.

Warum antwortet man eigentlich auf solche Unterirdischen Beiträge.

>>>Die Komplexität einer Fertigungsanlage ist als Außenstehender kaum
>>>vorstellbar!
>> Pauschalisiertes Geplapper.
>> Eher passt die "Komplexität" einer Fertigungsanlage, wenn richtig
>> programmiert, in einen GANZ KLEINEN uC (oder in einen Schrank voller
>> Schütze) hinein.
>> Und solange weder in Assembler noch mit einer richtigen
>> Programmiersprache gearbeitet wird, kann von Komplexität eigentlich
>> keine Rede sein.

>Ich habe bisher noch keinen "GANZ KLEINEN uC" gesehen der eine heutige
>Fertigungsanlage verwaltet. Bei einzelnen Applikationen wie z.B. die
>Regelung einer Kleberheizung oder die Auswertung in der
>Qualitätskontrolle sind mit einem "GANZ KLEINEN uC" in Assembler zu
>realisieren, da gebe ich dir Recht!
Und der macht das schneller als eine SPS, in SPS-Sprache geschrieben.


>Ich will aber dein Programm sehen in deinem "GANZ KLEINEN uC", welches
>i.d.R. mehrer Roboter als Slave-Teilnehmer, verschiedene Antriebe,
>verschiedene HMI, verschidenste Applikationen (wie schon genannt),
>hunderte dezentrale EAs, personelle Sicherheit nach der MRL und nahezu
>100%ige Diagnose mit ensprechender maschineller Sicherheit
>(netzunabhägig wie Profinet, Interbus etc.) verwaltet.

>Anschließend kannst du es ja nochmals mit einem Schrank voller Schütze
>aufbauen. Vergiss aber bitte den Uplink zur Warte nicht, sonst werden
>die Krawattenträger sehr ungemütlich, wenn sie keine Bilder mehr
>geliefert bekommen!

Die angesprochenen Roboter oder Slave-Teilnehmer, verschiedene Antriebe, 
usw nimmt der SPS-"Programmierer" nur in Betrieb oder parametriert 
diese, er baut sie aber nicht. Mit dem Innenleben dieser 
Geräte/Module/Teile oder "Uplink zur Warte" hat der SPS-"Programmierer" 
nicht die Bohne zu tun.

Deshalb auch :
>Die Entwicklungsingenieure haben in Assembler und C eine Metasprache
>(AWL) entwickelt, die den Anwender von bestimmten Internas entbindet
>(Programmiermodell, Addressierungsarten, Adressdistanzen, Betriebsarten
>des Controllers, Pipelineeffekten, Atomics).

----------------------------------------------------------------------

>Der Softwareentwickler muss dabei häufig
>interdisziplinäre Bereiche beherrschen, z.B. Sicherheitstechnik,
>Ergonomie, Algorithmen und Datenstrukturen, Regelungstechnik, dann soll
>er noch Kameras, Roboter, Scanner, Servoantriebe, Schraub- und
>Messsysteme etc. programmieren bzw. parametrieren.
Kameras, Roboter, Scanner, Servoantriebe, Schraub- und Messsysteme ???
parametrieren,ja. (selbst gesagt)

-----------------------------------------------------------

>ich glaub Ihr habt nicht verstanden was MCUA euch sagen will.
Ich sagte, dass SPS-"Programmierung" nicht im Geringsten bis auf 
Hardware-Ebene von Mikroprozessoren oder elektron. Bauteilen runter 
geht. (Das ist Tatsache, und Andere sagten das auch, mit Begründung)
Den Rest haben sich einige selbst dazu gedichtet.

-----------------------------------------------------------

>Er hat selbst noch nie in einer Linie gestanden und will euch nur sagen
>daß er TROTZDEM der einzige ist, der weis wie der Hase läuft und alle
>außer Ihm sowieso blöd sind. So einfach ist das.
Was soll dieser Schwachsinn? Ich habe an SPS-Linien schon gearbeitet 
(geplant, gebaut, gewartet) da wusstest du wahrscheinlich nichtmal, dass 
es sowas gibt.
Aber eins ist total sicher: Du hast im Leben noch keinen uC von innen 
gesehen, sonst hättest du diesen Schwachsinn
>Letztlich ist z.B. AWL nichts anderes als Assembler,
hier nicht gschrieben!

Deshalb auch :
>>>Es handelt sich also um einen problementschärften Mikrocontroller mit
>>>entschärfter (vereinfachter) Programmiersprache.
>>Seltsam ausgedrückt.
>Oder ganz krass: Ein µC für dummies.

Sicherlich sind die Chips heutzutage leistungsfähig genug, um auch große 
Fertigungsstrecken ansteuern zu können. ABER Bastellösungen sind in 
großen, teuren Anlagen nicht gefragt. Die Anlagen laufen unter Umständen 
auch viele Jahre, wenn dann die Anlage ausfällt, hat man ein Problem: 
Der Konstrukteur ist weg, die Teile werden genau so nicht mehr 
lieferbar, Dokumentation ist weg, oder dann fällt erst auf, dass die 
ganz fehlt oder falsch ist :) ...

Deshalb setzen Großanlagen-Betreiber auf große Firmen. Die können 
GARANTIEN abgeben: Dass die SPS und Peripherie auch in zehn Jahren noch 
lieferbar ist, das Programm ohne Probleme so überspielt werden kann, 
dass die Konstruktion dauerhaft laufen kann...

Ich hatte mit SIMATIC zu tun. Da war es schon ziemlich praktisch, dass 
sich die Geräte auch ziemlich ähnelten -- das kann man jetzt natürlich 
mit mangelnder Innovationskraft oder Phantasielosigkeit bemängeln, hatte 
aber wie gesagt Vorteile bei teuren, langlebigen Industrieanlagen. Und 
sollte doch tatsächlich eine Komponente zu gering dimensioniert worden 
sein, kann immer noch eine Nachfolgegeneration eingesetzt werden, und 
das Programm unverändert dort eingespielt werden.

Was STEP7 vs. C++ angeht: Das ist keine Konkurrenz. Es gibt kaum 
C++-Programme, die jahrelang durchlaufen. Allenfalls werden in 
Anwendungen kurze Progrämmchen gestartet, die etwas machen und dann 
wieder beendet werden. Zum Beispiel in der Produktionsleitung alle paar 
Minuten die Datenbanken durcharbeiten. Bei längerem Betrieb gibt es 
zwangsläufig Speicherlecks, irgendwas sammelt sich immer irgendwo an. 
Und sei es die Fragmentierung des Heaps. Meistens gibt es dann noch 
einen unabhängigen Watchdog, der, wenn das Programm zu lange für seine 
Aufgabe gebraucht hat, dieses radikal beendet, und bei der Datenbank ein 
Rollback anordnet.

SPS-Programme haben (theoretisch) einen linearen Ablauf (Schleifen sind 
unter AWL natürlich möglich -- "fallen aber unangenehm auf"). Der 
Betreiber möchte nicht Werkstücke oder gar Werkzeuge verlieren, nur weil 
gerade eine Array-sortierung einen Stoppbefehl verzögert. Auch ist die 
Unfallgefahr dadurch ziemlich groß, so dass auch die 
Berufsgenossenschaften Bastellösungen schwer akzeptieren.
Meine Algorithmen waren infolgedessen immer iterativ.

Auch muss das Betriebssystem einer SPS diesen Dauerbetrieb durchhalten. 
Wenn bei einer Anlage mit dutzenden SPS jede alle paar Tage neu 
gestartet werden muss, und damit auch die Anlage auch wieder neu 
hochgefahren werden muss, wobei wahrscheinlich Ausschuss produziert 
wird, kann das schon sehr teuer werden. Das ist dann nicht so locker, 
als wie wenn man den Videorekorder hin und wieder mal neu einschalten 
muss.

Wie gesagt: In einer PERFEKTEN Welt wäre die Sache mit ein paar 
Hobby-Einplatinenrechnern gut zu realisieren. Aber in Großanlagen ist 
das Risiko zu groß!

Ich hätte da für Interessierte noch folgendes Buch, neu und ungelesen, 
nur mal geblättert, abzugeben.

Bitte Preisvorstellung angeben.

http://www.amazon.de/Automatisieren-Programmierung-Entwurfsverfahren-Bausteinbibliotheken-Web-Technologien/dp/3834815047/ref=pd_cp_b_2

Bei Interesse bitte Mail an georaecher at gmx dot de

>Deshalb setzen Großanlagen-Betreiber auf große Firmen. Die können
>GARANTIEN abgeben: Dass die SPS und Peripherie auch in zehn Jahren noch
>lieferbar ist,
Zu 100% garantieren kann das keiner.


>SPS-Programme haben (theoretisch) einen linearen Ablauf (Schleifen sind
>unter AWL natürlich möglich -- "fallen aber unangenehm auf").
Was zeigt wie simpel (fast alle) SPS-"Programme" sind.
Noch dazu im 10..100 ms-Bereich. Da schläft mancher uC ein. In etlichen 
SPS-Geräten sind 'klitzekleine' Mikrocontroller drin, und selbst die 
sind noch unterfordert. (Ja, manche haben PC-Prozessoren, mit grösseren 
(langsamen) Betiebssystemen)

>Der Betreiber möchte nicht Werkstücke oder gar Werkzeuge verlieren, nur
>weil gerade eine Array-sortierung einen Stoppbefehl verzögert.
Da sieht man's. Wenn schon eine Array-sortierung die Echtzeitfähigkeit 
in Frage stellt, dann ist das System zu billig. (Wäre bei richtiger 
Programmierung nicht der Fall)


>Wie gesagt: In einer PERFEKTEN Welt wäre die Sache mit ein paar
>Hobby-Einplatinenrechnern gut zu realisieren. Aber in Großanlagen ist
>das Risiko zu groß!
Schon mal was von professioneller Entwicklung gehört?
Wer baut und verkauft all die tausende Spezialgeräte?

MCUA schrieb:
>>Deshalb setzen Großanlagen-Betreiber auf große Firmen. Die können
>>GARANTIEN abgeben: Dass die SPS und Peripherie auch in zehn Jahren noch
>>lieferbar ist,
> Zu 100% garantieren kann das keiner.
Doch! Wenn der Kunde das verlangt machen die das. Steht in den 
Verträgen.

>>SPS-Programme haben (theoretisch) einen linearen Ablauf (Schleifen sind
>>unter AWL natürlich möglich -- "fallen aber unangenehm auf").
> Was zeigt wie simpel (fast alle) SPS-"Programme" sind.
> Noch dazu im 10..100 ms-Bereich. Da schläft mancher uC ein.
Das SPS-Programm ist Teil eines großen Ganzen. Es hat die Aufgabe, einen 
Anlagenteil also eine Maschine zu steuern. Dabei werden diese auch oft 
in einzelne Einzelteile zerlegt.

Aber ich glaube, die Komplexität einer Maschine wird hier unterschätzt. 
Es gibt unzählige Sensoren, die es auszuwerten gibt. Und das 
schwierigste ist, die ganzen Sonderfälle zu behandeln. Die Maschine muss 
ja auch an-, und herunterfahren. Sicherheitssensoren müssen oft 
ausgewertet werden, manchmal aber auch nicht. Die Maschine muss 
justierbar sein, und dann läuft sie langsamer, timeouts dürfen dann 
nicht ausgewertet werden, ebenso wie manche andere Sicherheitssensoren, 
oft kann sie in diesem Zustand auch rückwärts laufen. Dann zeigt sich, 
ob das Konzept stimmt.
Und wie kommt man von irgendwo wieder in den Grundzustand?
Oft zeigen sich erst auch in der Programmierphase Fehler in der 
Konstruktion, fehlende, falsche Sensoren, instabiles Verhalten...
Der Programmierer darf dann sehen, wie der das dann regelt. Der 
Konstrukteur ist dann nämlich schon weg, nachträgliche Änderungen kaum 
mehr möglich.
Zum dritten ist der Anlagenprogrammierer der letzte, der auf der 
Baustelle ist. Oft ist das Projekt schon im Verzug, wenn er anfängt. 
Wenn das Programm dann auf Anhieb läuft, ist das schön. So ist es aber 
nicht. Manche Fehler (prinzipielle,konstruktive,mechanische,usw.) 
tauchen wie gesagt erst ganz zum Schluss auf. Möglicherweise kommen die 
Maschinenbauer noch kurz zur Nachbesserung, jedenfalls wenn der 
Automatisierer ein Fehlverhalten nachgewiesen hat. Der Programmierer ist 
aber, der den Verzug ausbaden darf -- Vor Ort, mit dem Auftraggeber im 
Nacken.

>>Der Betreiber möchte nicht Werkstücke oder gar Werkzeuge verlieren, nur
>>weil gerade eine Array-sortierung einen Stoppbefehl verzögert.
Naja, Array-Sortierung ist jetzt mal ein schlechtes Beispiel gewesen. 
Aber rasch gehen einige Schleifen schon mal nicht zu Ende ( 
for(i=0;i+=1/99;i!=1) oder for(i=0;i++;j<100);{}  ), oder eine 
Garbage-Collection kommt dazwischen, manchmal hängt auch ein i/o oder 
ein Interrupt verzögert das System. Wenn so was "hin und wieder" 
passiert, kann man es kaum dingfest machen. Deshalb ist 
deterministisches Verhalten unbedingt nötig.

>>Wie gesagt: In einer PERFEKTEN Welt wäre die Sache mit ein paar
>>Hobby-Einplatinenrechnern gut zu realisieren. Aber in Großanlagen ist
>>das Risiko zu groß!
> Schon mal was von professioneller Entwicklung gehört?
> Wer baut und verkauft all die tausende Spezialgeräte?
Testumgebungen sind nicht die Wirklichkeit. Sie helfen schon. Wenn sich 
die Wirklichkeit nicht an die Testumgebung hält, dann ist man froh, wenn 
das System einfach genug ist, damit die Nachfrickelei (Wie gesagt: 
Zeitdruck, konstruktive, konzeptionelle, elektrische, mechanische 
Fehler-korrekturen) das System nicht komplett undurchschaubar macht.
Schön sind auch flackernde Sensoren. Wenn dann jedes mal der Prozess 
beendet wird, gibts Ausschuss. Soll man dann den Sensor ignorieren, oder 
verzögern? Gibt es dann noch größere Probleme? Wie ist es besser? :)

Deshalb: Solche Systeme MÜSSEN von ANFANG AN simpel sein. Die 
Nachkorrekturen unter Zeitdruck machen das dann schon von alleine 
schwieriger. Und wenn es dann vorher schon kompliziert war, hat man 
keine Chance.

>>>Deshalb setzen Großanlagen-Betreiber auf große Firmen. Die können
>>>GARANTIEN abgeben: Dass die SPS und Peripherie auch in zehn Jahren noch
>>>lieferbar ist,
>> Zu 100% garantieren kann das keiner.
>Doch! Wenn der Kunde das verlangt machen die das. Steht in den
>Verträgen.
Nicht, wenn die Verträge aus irgent einem Grund gebrochen oder hinfällig 
werden.

>Es gibt unzählige Sensoren, die es auszuwerten gibt.
unzählige? von wegen! Selbst bei 800 binären Sensoren wären das gerade 
mal lächerliche 100 Bytes. 800 Outs, nochmal lächerliche 100 Bytes.
Die 100 Bytes liesst ein Mikroprozessor (wenn die richtige Hardware dran 
hängt) in ca µs ein (wenn's sein muss, auch schneller).
Das ist 1/100000 von 100 ms Std-Zykluszeit!

>>>Der Betreiber möchte nicht Werkstücke oder gar Werkzeuge verlieren, nur
>>>weil gerade eine Array-sortierung einen Stoppbefehl verzögert.
>Naja, Array-Sortierung ist jetzt mal ein schlechtes Beispiel gewesen.
>Aber rasch gehen einige Schleifen schon mal nicht zu Ende (
>for(i=0;i+=1/99;i!=1) oder for(i=0;i++;j<100);{}  )
Da sieht man's wieder.
Bei richtiger Programmierung (mit entsprechenden INT-Prioritäten, 
Ausnützung der uC-Hardware usw) wäre diese Blockade gar nicht möglich.
(Aber dazu müsste man ja den uC kennen)

>Deshalb: Solche Systeme MÜSSEN von ANFANG AN simpel sein.
Und wenn's doch kompliziert wird, geht es mit Std-SPS überhaupt nicht 
mehr.
(Jedoch, mit spez. entw. Hardware ist (fast) alles möglich. Auch 
µs-Schleifen innerhalb einer 100ms-Schleife)

>Der Betreiber möchte nicht Werkstücke oder gar Werkzeuge verlieren, >nur weil 
gerade eine Array-sortierung einen Stoppbefehl verzögert.

Bei vernünftiger PRogrammierung passiert das auch nicht.


>>Es gibt unzählige Sensoren, die es auszuwerten gibt.
>unzählige? von wegen! Selbst bei 800 binären Sensoren wären das >gerade
>mal lächerliche 100 Bytes. 800 Outs, nochmal lächerliche 100 Bytes.
>Die 100 Bytes liesst ein Mikroprozessor (wenn die richtige Hardware dran
>hängt) in ca µs ein (wenn's sein muss, auch schneller).
>Das ist 1/100000 von 100 ms Std-Zykluszeit!


Das rechnerisch sicherlich richtig, aber trotzdem totater Blödsinn.
1)
Der Sensor ist selten direkt einem Pin des µC angeschlossen. Es gibt 
Bussysteme mit Zykluszeiten, Prozessabbilder müssen kopiert werden, etc.

GEgenbeispiel:
Ein Atmel kann bei 16MHz etwa 1MByte/sek Daten per SPI versenden. Rein 
Rechnerisch. Aber programmier das mal. Bei SPI-Clock von 8MHz hast du 
gerade mal eine µs Zeit, das nächste zu sendende Zeichen irgendwo 
herzuholen. Was damit gemacht, ist nicht mehr möglich wegen 
Auslastung...

Matthias Lipinsky schrieb:
> Bei vernünftiger PRogrammierung passiert das auch nicht.

Das ist zwar prinzipiell nicht falsch, aber mit dem Argument wirst du 
keinen Kunden überzeugen ;-)

>>>Es gibt unzählige Sensoren, die es auszuwerten gibt.
>>unzählige? von wegen! Selbst bei 800 binären Sensoren wären das >gerade
>>mal lächerliche 100 Bytes. 800 Outs, nochmal lächerliche 100 Bytes.
>>Die 100 Bytes liesst ein Mikroprozessor (wenn die richtige Hardware dran
>>hängt) in ca µs ein (wenn's sein muss, auch schneller).
>>Das ist 1/100000 von 100 ms Std-Zykluszeit!

>Das rechnerisch sicherlich richtig, aber trotzdem totater Blödsinn.
>1)
>Der Sensor ist selten direkt einem Pin des µC angeschlossen. Es gibt
>Bussysteme mit Zykluszeiten, Prozessabbilder müssen kopiert werden, etc.
Schwachsinn! Wenn du hinterm Mond lebst, heisst das noch lange nicht, 
dass Andere da leben. Also nenn es gefälligst nicht "totater Blödsinn", 
wenn du keinen Schimmer hast.
Es gibt etliche Möglichkeiten, das zu realisieren.
800 Bits/us sind 800 Mb/s, also weniger als 1 Gb/s. Sind problemlos 
lesbar, und mit mittlerer CPU auch machbar (entspr. Protokoll voraus 
gesetzt). Wenn es sein müsste wäre auch ein mehrfaches davon möglich)
Ausserdem sind 800 Bits/us auch 50 Worte(16bits)/us, was heisst, dass 
bei einem 16-bit-Parallelbus dazu eine Frequenz von (rel. 
unproblematischen) 50 MHz nötig wären, bei 32-bit-Parallelbus wären's 
nur 25MHz. Auch 8-bit-Parallelbus mit 100MHz könnte man realisieren 
(allerdings nicht mehr auf klassischen Wege).

Also, wenns sein muss, kann ein Mikroprozessor in 1/100000 der 
Zykluszeit von 100ms die 800 (oder mehr) Eingänge lesen.
(Allerdings nicht mit SPS-"Programmierung")

>ei einem 16-bit-Parallelbus dazu eine Frequenz von (rel.
>unproblematischen) 50 MHz nötig wären, bei 32-bit-Parallelbus wären's
>nur 25MHz. Auch 8-bit-Parallelbus mit 100MHz könnte man realisieren

Tja, nur leider ist eine Maschine größer als eine Platine, sogar hier 
auf der Rückseite des Mondes.


>(Allerdings nicht mit SPS-"Programmierung")

Sorry. Ich muss mich entschuldigen. Der Thread hat ja nichts mit SPS 
zutun. WIe konnte ich das Thema hier nur reinbringen.. Naja, Es ist 
Vollmond. Also ists ziemlich dunkel auf der Rückseite.

>wenn du keinen Schimmer hast.

Ich scheine gut Schauspielern zu können, denn genau dafür (SPS-SW) 
bezahlt mich mein Arbeitgeber seit Jahren...

Aber das muss ja so sein, bei 2x 384Tkm Arbeitsweg pro Tag

>Die angesprochenen Roboter oder Slave-Teilnehmer, verschiedene Antriebe,
>usw nimmt der SPS-"Programmierer" nur in Betrieb oder parametriert
>diese, er baut sie aber nicht.

Du hättest nicht das Wort "Programmierer", sondern das Wort "nur" in 
Anführungszeichen setzen sollen. Aktuelle Peripherie hat nicht selten 
Dokumentationen zur Parametrierung, die die 1000-Seiten-Grenze 
überschreiten.

>Mit dem Innenleben dieser
>Geräte/Module/Teile oder "Uplink zur Warte" hat der SPS-"Programmierer"
>nicht die Bohne zu tun.

Aber z.B. bei Antrieben sollte der SPS-"Programmierer" schon "ein wenig 
Ahnung" von der Antriebstechnik haben. Bist Du der Meinung, 
Antriebstechnik und ihre Komponenten wären triviale Geräte?

>Kameras, Roboter, Scanner, Servoantriebe, Schraub- und Messsysteme ???
>parametrieren,ja. (selbst gesagt)

Wie gesagt, auch "einfach nur parametrieren und ansteuern" kann schon 
mächtig kompliziert sein ;-)

[...]

>Aber eins ist total sicher: Du hast im Leben noch keinen uC von innen
>gesehen, sonst hättest du diesen Schwachsinn

Also ich hatte sowohl viel mit uCs zu tun und habe auch schon einige 
entsprechende Systeme entwickelt, mein aktuelles Tagesgeschäft ist 
allerdings die Steuerungstechnik.

>Letztlich ist z.B. AWL nichts anderes als Assembler,
>hier nicht gschrieben!

Also hier muss ich widersprechen: AWL ist von der Mächtigkeit durchaus 
auf der Assemblerebene anzusiedeln, und auch der Befehlsvorrat deutet in 
diese Richtung (auch wenn AWL natürlich deutlich spezifischer auf die 
Steuerungstechnik ausgerichtet ist, aber das ist ja auch sinnvoll).

>Es gibt unzählige Sensoren, die es auszuwerten gibt.
>unzählige? von wegen! Selbst bei 800 binären Sensoren wären das gerade
>mal lächerliche 100 Bytes. 800 Outs, nochmal lächerliche 100 Bytes.
>Die 100 Bytes liesst ein Mikroprozessor (wenn die richtige Hardware dran
>hängt) in ca µs ein (wenn's sein muss, auch schneller).
>Das ist 1/100000 von 100 ms Std-Zykluszeit!

Dummerweise ist das Ziel der Steuerungstechnik nicht, möglichst schnell 
die Peripheriedaten einzulesen, sondern es soll ärgerlicher Weise auch 
noch was mit den Daten gemacht werden. Eine SPS ist ja kein 
datenfressendes schwarzes Loch, das nur dem Zweck dient, den 
Schaltschrank zu füllen, den Geldbeutel der Kunden zu leeren und 
nebenbei noch Strom zu verbrauchen.

[...]
>Da sieht man's wieder.
>Bei richtiger Programmierung (mit entsprechenden INT-Prioritäten,
>Ausnützung der uC-Hardware usw) wäre diese Blockade gar nicht möglich.
>(Aber dazu müsste man ja den uC kennen)

Deine Wortwahl ist interessant. Was ist "richtige" Programmierung?
Wenn Du in einem uC sowohl langlaufende Prozesse und gleichzeitig 
zyklisch ausgeführte Programmteile realisieren willst, dann kannst Du 
z.B. den zyklischen Teil über einen Timer-Interrupt ausführen. Der oder 
die rechenintensive Teile können sich dann "irgend wie" die restliche 
Rechenzeit teilen. Aber ohne Laufzeitsystem, das einem das Konzept der 
Prozesse oder Threads bietet, macht's keinen Spaß. Und wenn, dann ist 
regelmäßig die Echtzeitfähigkeit in Gefahr. OK, ich weiß, es gibt z.B. 
echtzeitfähige Linux-Kernel, aber da wird einiges an Aufwand getrieben.

Systeme, die teilweise rechenintensive Aufgaben erledigen und 
gleichzeitig mindestens eine weiche Echtzeitfähigkeit haben sollen, sind 
nicht einfach zu programmieren und leiden nicht selten an sporadischen 
Synchronisationsproblemen/Deadlocks. Auf SPS-Basis sind rechenintensive 
Schleifen oder andere Programmteile durch den zyklischen Ablauf des 
Programms (was auch bei uCs durchaus üblich ist) schwierig zu 
implementieren. Entweder man stellt sicher, dass die maximale Zykluszeit 
niemals überschritten wird, oder man führt nur einen oder wenige 
Schleifendurchläufe pro SPS-Zyklus aus.

Aber mich wundert schon ein wenig, dass hier einige Threadteilnehmer die 
Funktion einer SPS und eines (entsprechend einem ähnlichen 
Anforderungsprofil programmierten) uCs so deutlich differenziert haben 
wollen. Ich sehe diese großen Unterschiede nicht. OK, auf Hardwareebene 
sicher, aber nicht auf Anwendungsebene. Es ergeben sich bei ähnlicher 
Aufgabenstellung ähnliche Möglichkeiten und Probleme bei der Umsetzung.

Ich verstehe auch nicht was Herr MCUA mit seinen Aussagen hier bezwecken 
will.
Vor 10-20 Jahren gab es viele Anlagenbauer die ihre eigenen Steuerungen 
aus Mikrocontrollern zusammengelötet und programmiert haben. Heutzutage 
läuft in bestimmt 99% aller Anlagen weltweit, ob im Anlagen- oder 
Maschinenbau, eine SPS. Und das ist sicher nicht so weil die Hersteller 
von Automatisierungskomponenten das den Betreibern aufs Auge gedrückt 
haben, sondern weil sich dieses System eben in diesem Bereich als das 
Beste herausgestellt hat. Es herrschen in dem Bereich eben andere 
Anforderungen als bei einem Controller in einer Waschmaschine: 
Modularität, Erweiterbarkeit, Fehlersuche, etc.

Klar kann man das alles auch mit einem Mikrocontroller selber 
programmieren. Nur wenn man die oben genannten Funktionalitäten einbaut 
kommt was raus? Na, eine SPS eben.

Und bezüglich AWL/Assembler:
Es gibt Siemens Steuerungen die einen speziellen ASIC besitzen der quasi 
AWL als Befehlssatz natürlich spricht. Genauer gesagt MC7, was noch eine 
Stufe unter AWL liegt. Aber über 90% von AWL entspricht dem direkten 
MC7-Code.
Oder der Speed7-Prozessor von Profichip, welcher nativ AWL/MC7 spricht.
Wenn man Assembler so definiert, dass es direkt der Maschinensprache des 
Prozessors entspricht, ist in diesem Falle MC7 eben Assembler.

Braun schrieb:
> Ich verstehe auch nicht was Herr MCUA mit seinen Aussagen hier bezwecken
> will.

Am besten der bewirbt sich beim Siemens. Da kann er sich austoben und 
die ganze SPS von Null auf neu erfinden.
Oder er geht zu den Maschinenbauern und bewirbt seine Kenntnisse und 
Alternativen. Diskutieren kann man da vielleicht mir seinem Chef aber 
nicht hier im Thread. Was kommt denn da als nächstes?

Kommt mir vor wie ein frustierter Bastler und µC Profi, dessen 
Kenntnisse in seiner Firma nicht mehr benötigt werden.

Nach 7 Jahren als Projektingenieur für Prozessleitsysteme in der 
Lebensmittelindustrie und Verfahrenstechnik kann ich davon nur abraten.

Man ist nur unterwegs und entfremdet sich von Familie und Freunden.

In Projekten sind die Programmierer immer die letzten "Hunde":
Architekten, Bau, Verfahrenstechniker, Installation der Anlagen, 
Elektroplanung und -installation -- jede Firma/Abteilung bringt einen 
zusätzlichen Verzug - nur der Inbetriebnahmetermin steht wie ein Fels in 
der Brandung. Die Wunder dürfen dann die Programmierer und 
Inbetriebnehmer vollbringen.

Zum Himmel schreiende Bedingungen (kommt ganz auf die Länder an), 
Wochenlanges 24/7 abdecken mit zuwenig Personal, anschließend 24h 
Bereitschaft falls die Anlage mal stehen bleiben sollte usw. usw.

Vorteile: Man ist sein "eigener" Chef, kann Lösungen mit dem Kunden 
selbst erarbeiten, die laufende Anlage gibt einem Feedback genug.
Man kommt viel rum in der Welt und lernt die verschiedensten Länder 
kennen.

In diesem Umfeld gibt es auch Freelancer, aber kaum welche die man ein 
zweites Mal trifft, weil es nur wenige schaffen durchzuhalten um Profis 
zu werden. Wir mussten auch schon Leute nach Hause schicken. Die 
Freelancer arbeiten für Subs, die Subs für Spezialmaschinen- und 
Anlagenbaukonzerne. Da bist Du dann als Freelancer schon wieder der 
letzte Hund in der Reihe und ein Monteur dritter Klasse.
Deswegen als Anfänger auch nur als Angestellter. Mit Berufserfahrung und 
einem entsprechenden Ruf kann es durchaus lukrativer sein und 
Selbstständigkeit ist eine Alternative.

Es kommt nicht auf die Programmiersprache, die Hardware oder das 
Framework an mit dem man arbeitet. Jede Branche hat ihre Eigenheiten. Es 
ist mehr die Frage, ob man dieses Leben will und ob man ein Talent zum 
programmieren hat.
Auch wenn es lukrativ ist - von diesem Leben jedenfalls hatte ich die 
Nase voll.

Oder so:

1

(****************************************************************)

2

(** Lampe fault *************************************************)

3

(*-- Alarmlevel zu klein ---------------------------*)

4

IF ( i_pAlarmLevel^ < c_AL_Warning )

5

THEN

6

  pOutLampFault^:= FALSE;

7

8

(*-- Alarmlevel mindestens Warnung -----------------*)

9

ELSE

10

  (*-- keine Fehler ---------------------*)

11

  CASE ( i_pAlarmStat^ ) OF

12

  c_AS_Off:

13

    pOutLampFault^:= FALSE;

14

15

  (*-- Information ----------------------*)

16

  c_AS_Temp:

17

    pOutLampFault^:= FALSE;

18

19

  (*-- Acknowledge ----------------------*)

20

  c_AS_Confirm:

21

    pOutLampFault^:= TRUE;

22

23

  (*-- Störung --------------------------*)

24

  c_AS_Active:

25

    IF ( PifMsTimeDiff( dwTm1 ) >= 250 )

26

    THEN (* 2Hz *)

27

      dwTm1:= PifMsTimeGet();

28

      pOutLampFault^:= NOT(pOutLampFault^);

29

    END_IF

30

31

  (*-- ungültig -------------------------------------*)

32

  ELSE

33

    pOutLampFault^:= FALSE;

34

  END_CASE

35

36

END_IF

Ist ein belangloses Stück Code. Aber es ist zeitgemässer als AWL.

Ich bin immer kurz vorm Verhungern.

;-)

>Zeitgemässer ist nicht unbedingt besser lesbar.

Soweit stimme ich da mit Dir überein.

>Ich bin ein Fan von Anweisungslisten.

Ok. Deine Ansicht. Aber ich kann dieser Sprache nix abgewinnen. Und kann 
mir ehrlich gesagt, die Projekte hier in der Firma in AWL oder FUB 
garnicht vorstellen..

Zuckerle schrieb im Beitrag #2336197:
> Ist so wie beim Trabbi und beim Maybach, kann nicht sagen ist das
> gleiche,
> nur weil beide einen Aschenbecher haben.
>
> Der eine ist übrigens ein Aschenbecher!

Fährst du einen? Wenn ja, Bilder!

Zuckerle schrob:
>Fahre was anderes! Bilder kannst du dir im Internet
>unter "Zuffenhausen" ansehen.

Ich habe es unter "Zuffenhausen" gefunden:
http://bild7.qimage.de/puky-fahrrad-16-foto-bild-55666487.jpg

Alle Achtung, Du hast es zu Etwas gebracht ODER
NICHT

MfG Paul

Steppi schrieb:
> vor Jahren habe ich mal Radio- und Fernsehtechniker gelernt. Zur Zeit
> habe ich das Gefühl, dass ich bei meiner Tätigkeit nur so vor mir her
> wurschtel und nicht richtig weiterkomme. Über die Jahre ist mein
> Realverdienst auch zurück gegangen.

also ganz allgemein B2C (mit Konsumern als Kunden) im Bereich Multimedia 
(wenn auch nur Bild und Ton)

>
> Macht es wohl Sinn, mich in STEP 7 einzuarbeiten um dann damit in ein
> bis zwei Jahren meine Brötchen als Freelancer zu verdienen?
> Wie denkt Ihr darüber, bzw. welche Erfahrungen liegen dazu vielleicht
> schon vor?

als B2B im Bereich Automatisierungstechnik.


Halte ich für sinnlos da du deine ganzen alten Skills entwertest und was 
völlig neues machen willst. Bis du da einen Kundenstamm aufgebaut hast 
und verstehst wie die ticken, Lieferanten u. das ganze drumherum drauf 
hast so das du wertvoll genug bist das dir dafür jemand was zahlt 
vergehen IMHO weit mehr als 2 Jahre.

Warum baust du das was du kannst nicht aus? Home Vernetzung, Smartphones 
Heimkino Mediaserver und so weiter.

Mikrocontroller-Programmierung ist nicht schwer, man braucht kein 
Studium, nur gute Bücher, Begeisterungsfähigkeit und interessante 
Projekte. Bin zwar selbst Dipl.-Ing., richtig lernt man aber erst in 
Projekten.
Man kann auch umfangreichere Steuerungen in Assembler machen.
Ich habe einmal ein Projekt mit einer etwa 5m langen Montagelinie 
gehabt: mit PCWorx von Phönix Contact, da war richtig Zeitdruck hinter, 
5 Stationen die über den Interbus kommunizieren und wo Teile 
zusammengefügt werden,die verschiedenen Betriebsarten: Anlaufen, 
Automatikbetrieb, Abfahren und Service, war richtig lehrreich.
Da steckt deutlich mehr dahinter als ein AA-Kurs, aber trotzdem kann er 
etwas bringen, wenn die Praxis folgt.

bücki schrieb:

> Mikrocontroller-Programmierung ist nicht schwer,

Kommt drauf an, was man machen will. Die möglichen Anwendungsgebiete 
sind so vielfältig, wie das gesamte Spektrum der Technik.

Ne LED blinken lassen mag manchmal noch einfach sein. Aber ich sah da 
eine Menge Kameraden, die sogar beispielsweise in Regelungstechnik viel 
besser waren als ich, aber einfach keinen Zugang zu C und noch viel 
weniger Assembler bekommen. Wie Scheuklappen bei einem Pferd.

Hallo Zuckerle,

es war allein eine Kostenfrage, unabhängig von der Technik, dafür hatte 
sich mein Vorgesetzer entschieden, ein Konstrukteur und 
ex-Pleite-Geschäftsführer. Die PC-Worx-Komponenten waren billiger als 
die Siemens-Teile. Wieso krank ? Wenn eine Unterbrechung da ist, läuft 
die gesamte Anlage nicht(steht bei Ender-Electronic,Friedrichshafen), 
aber was nützt es, wenn nur eine Station nicht funktioniert, da kann 
doch eh nicht produziert werden.
Ventil nicht schaltet ? Dazu gibt es ein Service-Programm, wo man mit 
einem Taster Schrittbetrieb machen kann und so hängende Sensoren, 
Ventile lokalisieren kann, hast Du kein Service-Programm in Deinen 
Steuerungen vorgesehen ?

Wilhelm Ferkes schrieb:
... Regelungstechnik vielbesser waren als ich, aber einfach keinen 
Zugang zu C und noch vielweniger Assembler bekommen. Wie Scheuklappen 
bei einem Pferd.
Assembler ist nicht schwer, ich finde es einfacher als c, ausserdem kann 
man auch Regelungen(in begrenztem Umfang) realisieren.

Bei einer einzelnen,zentralen Steuerung im Schaltschrank , die durchaus 
bei der kurzen Linie möglich gewesen wäre, ist der Verdrahtungsaufwand 
höher.

bücki schrieb:

> Wilhelm Ferkes schrieb:
> ... Regelungstechnik vielbesser waren als ich, aber einfach keinen
> Zugang zu C und noch vielweniger Assembler bekommen. Wie Scheuklappen
> bei einem Pferd.
>
> Assembler ist nicht schwer, ich finde es einfacher als c, ausserdem kann
> man auch Regelungen(in begrenztem Umfang) realisieren.

Darüber können wir uns noch mal unterhalten. C ist eine Art Abstraktion 
gegen Assembler, und bietet viel mehr Möglichkeiten. Und wenn es nur mal 
Datenstrukturen sind, Wartbarkeit und Wiederverwertbarkeit sowieso. Auch 
die Unabhängigkeit von Controllertypen und deren Befehlssatz, mit 
Ausnahme einiger spezieller Hardware-Features.

Ein Assemblerschnipzel kann aber hin und wieder nötig sein.

Ok ich gebe Dir Recht, mein Fall war C nie, umständlich zu lesen mit den 
Klammern, ist eben Geschmackssache, wobei ich auch in der Lage bin 
komplexe Probleme in A. zu lösen.
Da finde ich die die grafischen Sprachen, wie LabView viel besser als 
C++, innerhalb sehr kurzer Zeit zu Lernen, übersichtlich, gut 
simulierbar, alles nur eine Frage der Vorliebe.

bücki schrieb:

> Ok ich gebe Dir Recht, mein Fall war C nie, umständlich zu lesen mit den
> Klammern, ist eben Geschmackssache, wobei ich auch in der Lage bin
> komplexe Probleme in A. zu lösen.

Dachte ich anfangs auch, bis ich es lernte.

> Da finde ich die die grafischen Sprachen, wie LabView viel besser als
> C++, innerhalb sehr kurzer Zeit zu Lernen, übersichtlich, gut
> simulierbar, alles nur eine Frage der Vorliebe.

Das sagt wiederum mir überhaupt nichts.

Bei Mikrocontrollern braucht man kein LabView, das ist klar, ich habe 
nur meine Vorlieben beschrieben.
Stelle Dir die Aufgabe vor: ein vollautomatisierter Prüfplatz z.B. 
TE-Messung von Platinen soll entwickelt werden, ein 
Hochspannungsprüfgerät liefert der Kunde, man bekommt eine LabView-CD in 
die Hand gedrückt, vorher nie damit gearbeitet und nun soll das 
umgesetzt werden.
Meine Lösung: da sind noch alte LabView-Bücher vorhanden, ich eigne mir 
das fehlende Wissen selbst an, dauert etwa 2-3Wochen, der Treiber des 
Hochspannungsprüfgerätes funktioniert auch nicht richtig: es gibt keine 
Unterstützung des Herstellers, also den Fehler im fremden Programm 
selbst finden: Machen und Tuen,ausführbares Programm schreiben. Später 
Kundenvorführung: eine Platine wird in einen Adapter eingelegt, anhand 
dessen Codierung die vorher im Eingabeprogramm eingegenen Parameter 
automatisch aufgerufen werden.

>Was war denn da billiger ?

Ich bin zwar kein Siemens-Fan, aber:

Das Display. Das wird eingekauft. Also hat man gespart. Das andere sind 
Enbetriebnahmekosten. Die tauchen woanders auf.

Die Herstellkosten der Maschine sind 1000€ weniger. So wird leider auch 
woanders "gerechnet"

Hallo,

ich war sechs Jahre in einem 4-Personen-Ingenieurbüro beschäftigt, da 
kenne ich Höhen und Tiefen, Vorteil: einziger Programmierer, da konnte 
niemand mir reinreden, Nachteil: Bezahlung sehr rückständig, da tauchten 
Vollstreckungsbeamte auf, nie wieder so eine kleine Firma, aber man 
konnte sich frei entwickeln, das PCWorxs-Projekt war interessant, man 
muss erstmal an so ein Projekt herankommen, wenn nach Firmengrösse und 
schlechter Bilanz gefragt wird.
Wo liegt der Vorteil von Simatic gegenüber PCWorx ?

Hallo ,

also man kann die SPS Programmierung in ganz verschiedenen Welten 
betrachten.
Da gibt es zum einen die "Programmierer" welche grafisch mittels FUP 
etc. programmieren und rein gar nichts von Struktur gehört haben. Die 
knallen alles in einen Baustein und wundern sich später nicht mehr 
durchzublicken.

Und dann gibt es da noch super strukturierte Programmierer bei denen man 
sofort einen Durchblick findet wenn man sich kurze Zeit mit der Struktur 
beschäftigt. Da sind Welten dazwischen.

Meiner Meinung kann man nur in AWL oder SCL proffesionell programmieren
da man hier auf alle Möglichkeiten, welche die Steuerung bietet 
zurückgreifen kann. Wobei SCL doch etwas langsamer ist, da es ja in AWL 
umgewandelt wird.

Natürlich kommt es auch auf das Verständnis des Programmiers an was die 
Physik betrifft. Er kann noch so gut programmieren können, wenn er nicht 
versteht was die maschiene / anlagemachen soll geht alles in die Hose.

Also es sind die verschiedensten Faktoren welche da zusammentreffen.
Ich persönlich bin immer wieder begeistert wir komplex und für einen 
Anfänger unverständlich die Programmierung in hoch technologischen 
Systemen ist.

Grüße Chris