Ich hab da mal eine Frage, ist das Thema Programmierung von Mikrocontrollern nach IEC61131-3 ein Thema? Es wird ja primär in C programmiert, wär es nicht interessant bzw. cool, dies auch in anderen Sprachen wir ST, SFC, FBD zu machen? Wie ist dazu grundsätzlich eure Meinung? Danke und lg, Jürgen
Es beschr'nkt nur die Funktionialität auf die der vorgefertigten bausteine. Wer grafik braucht um seine eigenen werke zu verstehen sollte sich nachhilfe in sachen vorstellungskraft suchen. Yum veranschaulichen von c programmen gibt es auch grafische tools.
Flip B. schrieb: > Es beschr'nkt nur die Funktionialität auf die der vorgefertigten > bausteine. nicht unbedingt. LogiCad ist so ein System, das generiert C-Code aus FBD oder ST und kann auch dadurch um eigene Bausteine erweitert werden. Aber das ist preislich eine Liga jenseits von Hobby...
@jojos stimmt nur bedingt! ;-) logi.CAD 3 compact kostet nichts. Darin kannst du weiterhin in C proggen und auch in ST. Wenns jemand grafisch möchte, kostet es was. woher kennst du logiCAD?
Damit quälen sich meine Kollegen rum. Kommst du aus der LC Ecke?
Jürgen schrieb: > Mikrocontrollern nach IEC61131-3 ein Thema? Hallo, In meiner beruflichen Praxis ist es eher anders herum: Bisweilen ist es praktisch einen PAC (Programmable automation controller), neben IEC sprachen eben auch in C oder C++ programmieren zu können. Für komplexe Aufgaben hat hier IEC schlicht nicht die sprachlichen Mittel. Entweder die komplette Task ist in C oder C++, oder es werden In C und C++ geschriebene Bausteine innerhalb der IEC Task aufgerufen. Auch wenn es bisweilen Erbsenzählerei ist , einen Artikel zum Unterschied von PLC (SPS) zu PAC findet ihr beispiels weise hier: http://www.controleng.com/single-article/plc-vs-pac/44448cf771be09bff7115c621633bd94.html Oder anders: Es gibt ja grafische Programmiertools etwa Flowcode https://www.matrixtsl.com/flowcode/features/ Aber: Wie andere schrieben: Ich finde C / C++ nicht schlimm zu lernen . Die Befürchtung, das eine solches "Framework" immer nur eine Teilmenge der Möglichkeiten der Plattform abbildet hätte ich jedoch auch. Das muß jedoch nicht schlimm sein. Da es jedoch auch eine Codesys implementierung für Raqsberry Pi gibt http://store.codesys.com/codesys-control-for-raspberry-pi-sl.html Kann es Sinn machen: Wenn man das "Embedded Control system" Menschen besser zugänglich machen will, die aus der "klassischen SPS" Welt kommen. Andere Beispiele: Arduino <--> bare Metal .Net Bare <--> bare Metal Wie die vielfältigen kontroversen Diskussion zeigen: Am Ende Muss jeder selber für sich allein herausfinden welche Lösung am besten passend ist. Ein möglichen Toolkit wäre hier: https://www.codesys.com/products/codesys-runtime/runtime-toolkit.html Gruß
Jürgen schrieb: > Ich hab da mal eine Frage, ist das Thema Programmierung von > Mikrocontrollern nach IEC61131-3 ein Thema? Eher selten, soweit ich das im Laufe meiner beruflichen Praxis beurteilen kann. > Es wird ja primär in C programmiert, wär es nicht interessant bzw. cool, > dies auch in anderen Sprachen wir ST, SFC, FBD zu machen? Hoffentlich nicht... > Wie ist dazu grundsätzlich eure Meinung? Die klassischen LC-Sprachen, vornehmlich FUP, KOP und AWL, sind eine Zumutung. Ich persönlich halte sie für indiskutabel bis unverantwortlich. Allein die hunderttausend impliziten Sachen sind ätzend (reservierte Bausteine...) ST krankt im Wesentlichen daran, dass dieselben hirnverbrannten Datenstrukturen zugrunde liegen, wie bei AWL. Das wird auch dadurch nicht besser, dass man sie für "Industriestandard" hält und sie weit verbreitet sind. Nüchtern betrachtet laufen die meisten SPS-Projekte, die auf FUP/KOP/AWL basieren, fast immer auf dasselbe hinaus: Einen riesigen Haufen mies dokumentierter und verwirrender Blockdiagramme (naja, S5/S7-FUP ist halt starr formatiert und lässt wenig anderes zu) und einen einzelnen Techniker und Autor, der einigermaßen versteht, wie der Haufen funktioniert.
Hallo Nase; ich habe das zu deinen Angaben und Hinweisen ein paar Fragen. Nase schrieb: > Ich persönlich halte sie für indiskutabel bis > unverantwortlich. Warum genau ? Mit welchen SPS Systemen hast du größere Projekterfahrung (Inbetriebnahmen eingeschlossen) gesammelt, um zu diesem Schluss zu kommen ? Weil: Da ein Großteil der Sicherheitsfunktionen (Maschinensicherheit), unter Anwendung entsprechender Hardware, durchaus funktional und eben Sicher für Mensch und Maschinen eben auch mit diesen sprachlichen Mitteln umgesetzt werden. Verantwortungslos wäre nur eine unsachgemäße, den Maschinenrichtlinien nicht entsprechende = falsche Anwendung der "Werkzeuge". In diesem Fall geht die Verantwortungslosigkeit aber von Anwender aus und die Ursache ist hierbei nicht der beschränkte aber ausreichende Sprachumfang. Allein die hunderttausend impliziten Sachen sind > ätzend (reservierte Bausteine...) ST krankt im Wesentlichen daran, dass > dieselben hirnverbrannten Datenstrukturen zugrunde liegen, wie bei AWL. Was findest zu in diesem Zusammenhang, für die Bedürfnisse der "normalen" SPS Programmierung ausgelegten" Datenstrukturen hirnverbrannt ? Danke für deine hilfreichen Erläuterungen Gruß Marc
>Auch wenn es bisweilen Erbsenzählerei ist , einen Artikel zum >Unterschied von PLC (SPS) zu PAC findet ihr beispiels..... Da gibt es prinz. keinen Unterschied. Es sind alles (endanwenderorientierte) SPS-Geräte. (und von den eingebauten uCs kennt der typ. SPS-"Programmierer" rein gar nichts)
Hallo MCUA; "Da gibt es prinz. keinen Unterschied." Im Prinzip nicht, im Detail aber schon: Richtig ist das es hierfür keine "normierte" Begriffstrennung zwischen PLC und PAC gibt. Sagen wir es mal mit anderen Worten: "Der Markt" oder eben die Anbieter der betreffenden Geräte, haben den Begriff PAC "erfunden" um sich von den "klassischen" PLC abzugrenzen. ALSO: SIEMENS S,S7 (300, und 400) Control Logix, PLC5 ....... Wo du diese in der Regel nicht, ergänzend zur "klassischen" SPS Programmierung (zusätzlich) auch in C, C++ programmieren und Einfluß auf das ggf. Vorhandenen Echtzeitbetriebsystem (VXVorks...) nehemen kannst. Wenn man so will kann man einen PAC auch als "PLC + x" betrachten. Ob ein Programmierer Controller und Betriebsystem der Steuerung kennen muss hängt immer von seinen Aufgaben und Projekt bedingten Aufgaben ab. Sagen wir vereinfachend : Eine klassische SPS "kapselt" das Steuerungssystem mehr als ein PAC.
Man kann jede SPS auch in ASM programmmieren, wenn man will.
bei all den grafischen Programmiermethoden (inkl. LabView, LegoNXT, Scratch + die ganze Gilde, auch Schemazeichnen): wie macht man ein Diff zwischen der Version die man in bearbeitung hat und z.B. jener von letzten Woche? Eben. Man endet bei NUR einem Techniker/Autor UND diese Person wird zum SPOF des Projektes. Entsteht z.B. ein Jahr nach Abgang dieser EINEN Person die Anforderung von Erweiterungen, wird GuterRat Teuer. Bei Schemas haben sich bestimmte Ordnungsformalismen (ohne Normierung!) eingebürgert. Bei der Programmierung nicht. Auf ein "noch nicht" stelle ich mich im Rest dieses Lebens nicht ein.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.