Hallo, 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. 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? Gruß Steppi
Hi, slebstständig ist immer gut. Hast Du auch potentielle Auftraggeber? Rosa
Schau mal erst wer das noch kann. Mehr Könner heißt noch lange nicht mehr (verteilbaren) Kuchen. Außerdem würde ich erst mal mit S5 beginnen und mich dann in S7 steigern. Anfänger haben da jedenfalls kaum eine Chance wenn da nicht langjährige Berufspraxis vorher im Angestelltenverhältnis erworben wurde.
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
Hallo, du solltest allerdings bedenken, dass Anlagen, in denen eine SPS drin ist, meistens nicht zu dir kommen, sondern du zu der Anlage fahren musst. Was unter Umständen recht weit sein kann. Auch sind Anlagen mit einer S7 (oder anderen SPS) in der Regel keine Unterhaltungsgeräte, sondern im produktiven Einsatz, d.h. wenn sie mal stehen, dann kostet das gleich ne Menge Geld, der Produktionsleiter steht hinter dir und die Sache wird recht ungemütlich. Auch werden Produktionsanlagen gerne am Wochenende oder in den Werksferien, zwischen Weihnachten und Neujahr um- oder aufgebaut. Da ist Fernseher reparieren schon angenehmer :-) Frank
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...
Frank B. schrieb: > Da ist Fernseher reparieren schon angenehmer :-) Wenn die noch repariert werden? Meist werden Module getauscht oder das Ding gleich ins Werk geschickt wo die Teststände stehen. Da finden die den Fehler in Minuten, oder Sekunden während der Techniker stundenlang Messungen macht bis zur Unwirtschaftlichkeit. Das ist wie der Weber, ein aussterbender Beruf.
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)
Globi schrieb: > Das ist doch Unsinn Das haben mir ein Meister und ein Umgeschulter dieses Berufes, die beim Blödmarkt beschäftigt waren, so vermittelt. Kann natürlich übertrieben gewesen sein, aber hörte sich für mich plausibel an. Ist wohl auch Regionsabhängig.
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.
Hallo, naja. Ich bin gelernter Energieelektroniker. Step 7 ist nicht aussagefähig. Zu unserem Standart gehört mittlerweile auch PCS7. Haben genug Anlagen, die mittels Multiprojekt auf mehreren Cpu's laufen. Dazu kommt natürlich auch noch Antriebstechnik. Z.B einen Sinamics am laufen zu kriegen ist ein Kinderspiel, aber wenn es um positionierung oder Momentenregelung geht, reichen "Step 7" Kenntnisse nicht mehr aus. Da muß man sich schon mehrgleisig einarbeiten. KOP ist tot, es lebe CFC, SCL und auch noch FUP. Gruß Sascha
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.
Step7 können und Step7 können sind zwei paar Schuhe. Wie schon aufgeführt, gibt es neben UND und ODER noch etwas mehr. ANY-POINTER, bereichsübergreifende indirekte Adressierung, UDT's und Multiinstanzen sind nur ein paar Schlagwörter. Hier fehlen dann noch die ganzen FM's, fehlersichere und hochverfügbare Systeme. Auch wenn ich das AVR-Tutorial hier durchgearbeitet habe, kann ich noch nicht Mikrocontroller programmieren. Bzw. würde mich hüten, mich auf diesem Gebiet selbstständig zu machen. cu Georg
>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 :)
Sagen wir ein Mikrocontroller light (von der Programmierung her, nicht von der Leistungsfähigkeit)
>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ß
MCUA schrieb: > 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".) Es kann einer drin sein, vor allem bei den neuen. Im allgemeinen ist das Gerät erst mal ein Automat an dem man die vorgebenen Waschprogramme parametrisieren kann. Ändern kann man die Programme nicht aber das macht das Programmieren aus.
>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: > h 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... Das ist schön. Bei uns ist das fast das Tagesgeschäft. Anton schrieb: > PCS7 ist voll im Trend und Anspruchsvoll! TIA ist das Schlagwort! In der Chemischen Industrie find ich es auch gut. Dort spricht man bei der Zykluszeit aber nicht in Millisekunden sondern Sekunden. Wir haben eine Anlage in PCS7. Eine CPU (417H) ist nur für die Antriebe. Mehr als noch einen weiteren Antrieb einfügen ist nicht mehr. Da fehlt mir echt die FM. So gut ist halt PCS7 noch lange nicht. Mittlerweile haben wir nun 2 Anlagen mit PCS7. Aus eigener Erfahrung, kann ich nur sagen: Programmieren und so weiter geht gut von der Hand. Aber der Spaß hört auf, wenn ich mich zur Fehlersuche durch 5-10 CPU's durchquälen muß................ Gruß Sascha
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
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. ;-)
Lippy schrob: >Aber es ist zeitgemässer als AWL. Zeitgemässer ist nicht unbedingt besser lesbar. Ich bin ein Fan von Anweisungslisten. Zuckele schrob: >Sowas lernt man aber >nicht auf dem Kurs vom AA oder Freitags in der Volkshochschule. ...und wo hast Du es gelernt? Außerdem fanden die Volkshochschulkurse immer am Dienstag statt. ;-) MfG Paul
>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..
IEC 61131 Sprachen sind generell grässlich ;-) mit Ausnahme von Structured Text, weil diese eine relativ große Ähnlichkeit zu Pascal aufweist.
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.
Ich arbeite mit Beckhoff & Moeller SPS. Der freie Markt draußen verlangt jedoch fast ausschließlich nach Siemens. Kann zum Problem werden, wenn man plötzlich einen neuen Auftraggeber sucht. :)
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 ?
Ich weiß garnicht was ihr habt Schützschaltungen werden auch intressant wenn dir die Kontaktlaufzeit langsam das Genik bricht.
Die netten Schaltungen in der die Funktion nicht gegeben ist weil dein Schliesser nicht mehr schliesst aber es mit Idealen Schaltverhalten ncoh gemacht hat. Gibt es sind wirklich lustig nur halt kein pipifax wie UND und ODER
Was ich damit sagen will ist das mir bisher selten eine SPS Schaltung Probleme bereitet und es immer die schicken Schützschaltungen sind die eine richtig zum nachdenken bringen aber euch scheint sowas ncoh nie untergekommen zu seine wenn du auf 10 DIN A1 seinten deine Kontakte zusammen suchen musst die ncoh mit Zeitfunktione dazwischen funken oder tolle Situation die nicht mehr Funktionen weil z.B die Selbsthaltung des Schütze nicht geht da ein Kontakt vorher öffnent bevor das eigen schliessen kann. Sps ist meisten einfach man bekommt das immer hin.
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
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.