Mikrocontroller Programmierung nach IEC61131-3

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?

yes, ich komm aus der 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.