Hallo Im Forum und von Profis wird ja nur Basic oder c++ und Co empfohlen. Aber gibt es eine Möglichkeit einen zB." ATmega128" oder "Arduino" "Grafisch mit Blöcken" (wie zB. Siemens Logo )zu Programmieren? Ich brächte es, um hauptsächlich Private "Relais Schaltungen" oder "Motor und Temperatur Steuerungen" zu ersetzen. LabVIEW zB. Ist mir als Privatanwender zu teuer . C-control von Conrad gibt es nicht mehr. Vielen Dank
Andreas Wein schrieb: > Grafisch mit Blöcken So in Richtung Funktionsbausteine und Logik eher weniger. Ansonsten verschiedene UML-Varianten mal ansehen. Die "Entwicklungsumgebung" SiSy unterstützt sowas. Ist ganz nett zum rumspielen, für ernsthafte Sachen aber noch zu unausgereift.
Conrad C-Control konnte man doch grafisch programmieren. Aber ob das heute noch geht weiß ich nicht.
http://www.matrixmultimedia.com/product.php?Prod=flowform&Var=AVR&PHPSESSID=$PHPSESSID hab aber nie selbst mit gearbeitet. eventuell kennt flowcode ja jemand aus eigener erfahrung.
Für den Fall das das jemals fertig wird: http://avrtools.no/Main.asp?page=2 Verschiebt sich allerdings schon seit Jahren ;-) Sonst gibt es einige Projekte von SPS auf AVR...
Sowas gab es in den 80-er Jahren mal von einer Firma AID, saßen glaube ich in Nürnberg. Der Name der SW ist mir leider entfallen. Für komplexe Anwendungen wurde die Graphik dann unübersichtlicher als ein "normales" gut gegliedertes Text-Programm. Hat sich, nicht nur wegen des Preises, wohl nicht so richtig durchsetzen können. Ich hatte die oben genannte SW in Verwendung, bin aber wieder auf die "alte Textdarstellung zurückgekehrt.
Simulink geht mittlerweile wohl auch ganz gut. Auf schlappe 4k€ für Simulink kommen dann nur noch die 20 EUR für den Arduino drauf. Und ca. 1,5k€ für die passende Simulink-Toolbox.
Andreas Wein schrieb: > C-control von Conrad > gibt es nicht mehr. Ups, hatte ich übersehen. War auch nicht der Bringer die grafische Programmierung. Frage mich ob das überhaupt mal jemand produktiv eingesetzt hat damals. Ich würde davon absehen, sowas grafisch programmieren zu wollen.
Andreas Wein schrieb: > Ich brächte es, um hauptsächlich Private "Relais Schaltungen" oder > "Motor und Temperatur Steuerungen" zu ersetzen. Vielleicht braucht er nicht mal Grafik: http://www.elektronik-labor.de/Projekte/TPS5.html Günstiger wirds kaum.
Hallo, Wie wäre es mit Flowcode? http://www.matrixmultimedia.com/flowcode.php Dieses Programm ist zwar nicht kostenlos, aber als "Home"-Version kostet es unter 60€. Die Benutzung entspricht dabei einem PAP.
Wenn du dich in Labview einarbeiten kannst kannst du dich auch in Basic einarbeiten. Trau dich und lerne was neues.
Hallo Was für eine Info-Flut, Danke Da muss ich mich erst durcharbeiten. ----------------------------------------------------------- "C-Control konnte man doch grafisch programmieren" Ich schieb ja , gibt es nicht mehr "neu". (und war sehr eingeschränkt, hab nie damit angefangen und gewartet…… ) ------------------------------------ "Labview einarbeiten" LV ist zu teuer, das einarbeiten in eine Prog-Sprache, für nur ein paar Projekte ist zu aufwendig (ich könnte dann eh nur an der Oberfläche kratzen) Da würde ich alles Elektromechanisch belassen. Flowcode auf den ersten Blick Ok Aber : die Software sollte/muß in Deutsch sein. Die Suche nach passenden Sensoren (analog/Digital Eingang)/Hardware wird wohl auch nicht leicht ------------------------------------ Vielen Dank
Andreas Wein schrieb: > Flowcode auf den ersten Blick Ok > Aber : die Software sollte/muß in Deutsch sein. Warum denn das? Mit dieser Anforderung senkst du deine Chancen was zu finden erheblich.
Andreas Wein schrieb: > Aber : die Software sollte/muß in Deutsch sein. Das ist Flowcode Siehe http://www.matrixmultimedia.com/resources/files/datasheets/Flowcode5Booklet-2.pdf Seite 3 "Copyright © 2012 Matrix Multimedia Ltd. Flowcode 5 is available in the following languages: Englisch, Chinesisch,... Deutsch,..."
Andreas Wein schrieb: > LabVIEW zB. Ist mir als Privatanwender zu teuer . C-control von Conrad > gibt es nicht mehr. Es gäb da auch noch "Profilab" - kostet glaube ich 100€. ist halt nicht so mächtig wie Labview, dafür aber wesentlich günstiger.
Hallo, schau dich mal auf dieser Seite http://mikrocontroller.com/de_sps/einleitung.php um. Vielleicht ist das ja was für dich. gruß ralf
Zur Blockprogrammierung auf dem PC (Die Frage ging ja eher über Mikrocontroller): Dasylab liegt bei ISBN 9783642018640 (Signale - Prozesse - Systeme von Karrenberg) in einer eingeschränkten Version auf CD bei. Und völlig kostenlos ist Gnuradio http://gnuradio.org/redmine/projects/gnuradio/wiki
Wenn du dich mit Ladder-Logik auskennst aus der SPS,kannst das hier ansehen: cq.cx/ladder-de.html
Die aktuellste Matlab/Simulink (nur Windows) Version hat kostenlos eine Arduino Mega256 Target Unterstützung.
Die Idee ist ja eigentlich nicht schlecht. Ich schreibe in einem anderen Zusammenhang gerade einen ähnlichen Editor zur Erstellung von Datenbank-Abfragen. Theoretisch wäre das gleiche Konzept auch für die Code Erstellung nutzbar. Vielleicht mache ich mich mal daran, einen grafischen Code Editor für Arduino zu schreiben (auch wenn das den ein oder anderen gleich wieder den Blutdruck in die Höhe treiben wird). Für "richtige" Controller-Programmierer wäre so ein Tool sicher nur von begrenztem Interesse. Da Arduino aber eher auf "Gelegenheits-Programmierer" abzielt, wäre das vielleicht eine passende Umgebung. Hätte hier denn der ein oder andere Interesse an einem solchen Projekt?
Christoph Kessler (db1uq) schrieb: > Und völlig kostenlos ist Gnuradio > http://gnuradio.org/redmine/projects/gnuradio/wiki Und was hat ein Software Defined Radio mit der Ausgangsfragestellung zu tun?
Hallo "schau dich mal auf dieser Seite http://mikrocontroller.com/de_sps/einleitung.php"; Das wäre die richtige Richtung . Die Seite scheint aber tot zu sein. Kein Forum, letze Einträge aus 2007, und seit ca. 4 Wochen warte ich auf eine E-Mail. Zubehör wird von einem anderen Shop verkauft, aber keine Unterstützung angeboten. ------------------------------------ Die Anderen Vorschläge beschäftigen mich nun eine Weile. ----------------------------------- Vielen Dank
Hallo, ein Forum für die MicroSPS scheint es auch zu geben. Ist zwar nicht allzuviel los dort. Aber es scheint so, das dort auch in 2013 noch geantwortet wird. http://forum.mikrokopter.de/forum-2.html Der Mikrokopter Shop, in dem es noch das Zubehör gibt gehört offentsichtlich den ehemaligen Entwicklern der MicroSPS. gruß ralf
Hallo Andreas, Andreas Wein schrieb: > "schau dich mal auf dieser Seite > http://mikrocontroller.com/de_sps/einleitung.php"; > > Das wäre die richtige Richtung . Natürlich möchte ich Dir nicht zu nahe treten, aber ich fürchte, daß Du auf einem Holzweg bist. Diese Versuche und Bestrebungen zur Realisierung einer grafischen Programmierung gibt es schon seit dreißig Jahren, aber ohne Erfolg: bislang hat sich das Konzept nirgendwo durchsetzen können. Das Problem ist: bei größeren Projekten wird die grafische Programmierung so unübersichtlich und komplex, daß sie keinen Vorteil mehr darstellt. Bei kleineren Projekten wird oft auch nur ein kleiner Teil des Funktionsumfangs einer Programmiersprache genutzt, so daß der Aufwand, diesen kleinen Teil zu lernen, nicht größer ist als das Erlernen der grafischen Programmierung. Von daher bietet eine grafische Programmierung weder bei kleinen noch bei großen Projekten einen Vorteil, und ebensowenig beim Einarbeitungs- und Lernaufwand. Außerdem bedingt eine grafische Programmierung immer, daß die einzelnen Funktionsblöcke korrekt aufeinander abgestimmt sind. Das erfordert einen Overhead, so daß das Ergebnis hinterher aufgebläht und / oder langsam ist. Bei einem Mikrocontroller mit seinen begrenzten Ressourcen ist beides keine sonderlich gute Idee -- hierbei wird ja oft sogar noch Assembler genutzt, um möglichst kleine, schnelle Programme und eine möglichst große Kontrolle über die Hardware zu erreichen. Infolgedessen fürchte ich, daß Du auf einem Holzweg bist, wenn Du nach einer vermeintlich einfachen grafischen Lösung suchst. IMHO täuschst Du Dich bei der Idee, daß Du Deinen Einarbeitungs- und Lernaufwand durch eine grafische Programmierung vermindern könntest. Deswegen würde ich Dir trotz allem empfehlen, jenen kleinen Teil von Basic oder C zu lernen, den Du für die Realisierung Deiner Projekte brauchst. Das ist vermutlich viel weniger Aufwand, als Du jetzt noch für möglich hälst -- und darüber hinaus eine prima Basis für größere Projekte in der Zukunft. HTH, Klaus
Hallo Ernüchternd , aber wahrscheinlich war. ( stimmt 30 Jahre wirklich ?, dann ist wirklich nicht mehr damit zu rechnen ) (Schade das es nach 30 Jahren noch keine "eierlegende Wollmilchsau" gibt) Dann würde ich beim jetzigen Elektromechanischen bleiben ,oder jemanden mit programmier Kenntnissen, in der Umgebung suchen. Die S.Logo ist Industriestandart , da scheint es zu funktionieren, aber nur mit teurer eigener Hardware. Werde mal übers Wochenende in mich gehen. Vielen Dank
Bei Rockwell funktioniert es auch. Deren Steuerungen haben u.a. die Möglichkeit per Funktions-Block oder Ladder-Diagram programmiert zu werden. Ob das viel genutzt wird, weiß ich allerdings nicht. Hast du dir denn mal BASCOM angeschaut? Einfacher gehts ja nun nicht mehr.
cyblord ---- schrieb: > Bei Rockwell funktioniert es auch. Deren Steuerungen haben u.a. die > Möglichkeit per Funktions-Block oder Ladder-Diagram programmiert zu > werden. Hm, das ist doch eher Konfiguration als Programmierung, oder?
Angehängte Dateien:
-
parsic.png
27 KB
Moin! Ich verwende schon seit einigen Jahren Parsic und bin sehr zufrieden damit. Für kleinere Projekte ist es für mich ausreichend. Leider ist die Seite nicht mehr aktiv und ich weiß nicht, ob es das Programm noch zu kaufen gibt. Du kannst ja mal nachfragen: http://parsic.de/impressum.htm Gruß, Joe
Konrad S. schrieb: > cyblord ---- schrieb: >> Bei Rockwell funktioniert es auch. Deren Steuerungen haben u.a. die >> Möglichkeit per Funktions-Block oder Ladder-Diagram programmiert zu >> werden. > > Hm, das ist doch eher Konfiguration als Programmierung, oder? Nene damit kann man das Programm erstellen, welches im normalen Betrieb dann abläuft. Auch Schleifen und Bedingungen und der Kram. Aber meine Sache ist das nicht. Mit Code kann man sich IMO schneller und eleganter Ausdrücken.
Es gibt sehr wohl grafische Programmiersysteme für Mikrocontroller. Auch wenn dies in diesem Forum als Spielerei abgetan wird. Für die Programmierung von Steuerungen, insbesondere in sicherheitsrelevanten Bereichen, sind grafischen Programmiersysteme heute Standard. Das grafische Programmiersysteme von vielen Programmierern abgelehnt werden, liegt einfach daran, dass viele Programmierer lieber trickreich rumprogrammieren und von Softwaredesign und professioneller, systematischer Softwareentwicklung nichts wissen wollen. Grafische Programmierung für komplexe Programme ist designorientiert und setzt systemisches Wissen voraus. Kontinuierliche Prozesse wie Signalverarbeitung und Regelungen werden seit je her von den Fachleuten grafisch in Blockdiagrammen modelliert. Es ist daher nicht nachzuvollziehen, warum hierfür textuelle Programmiersprachen besser geeignet sein sollen. Ich denke, dass ich ein guter C Programmierer bin, da ich viele Jahre für Mikrokontroller den Laufzeitkern (Firmware) für das grafische Programmiersystem iCon-L entwickelt habe. Ich würde mir aber nicht zutrauen, eine komplexe Applikation in C zu programmieren oder gar vor Ort in Betrieb zu nehmen. Dafür ist eine grafische Programmieroberfläche mit integrierter Online-Beobachtung auf Modellebene deutlich besser geeignet. Wer hier behauptet, dass dies in C mit einem Quelltext-Debugger besser geht, hat noch nie mit einem grafischen Programmiersystem gearbeitet, dass für den gesamten Entwicklungsprozess auf der grafischen Modellebene bleibt. Ich rede hier nicht von grafischen Codegeneratoren, da die meist das gleiche Inbetriebnahme-Problem haben, wie textuelle Programmiersprachen. Sicherlich gibt es Aufgabenstellungen, für die grafische Programmiersprachen nicht geeignet sind, aber Steuerungs- und Regelungsaufgaben gehören nicht dazu und kleine Mikrokontroller werden meist für diese Aufgabe verwendet. www.pro-sign.de Gruss ProSign
Komisch, da haben die Menschen sich weiter entwickelt und benutzen das geschriebene Wort anstatt Höhlenmalerei. Und dann kommen Menschen und wollen diese Idee bei der Programmierung rückgängig machen, weil Bilder ja viel übersichtlicher sind. Grafische Programmiersprachen sind nicht zu gebrauchen sobald es auch nur etwas komplexer wird. Und für die einfachen Sachen braucht man es auch nicht, denn da ist das geschriebene dann auch vollkommen trivial. P.S.: http://www.ni.com/cms/images/devzone/pub/nrjsxmfm912163998723206173.jpg
Also das mit den grafischen Programmiersprachen werde ich wohl nie verstehen. Vor allem weil das ja auch so umständlich ist. Aus einem
1 | int i = 5; |
wird da dann erstmal das Symbol für einen Integer suchen und reinziehen, das Symbol anklicken und ihm einen Namen geben, das Symbol für die Konstante suchen und reinziehen, den Wert der Konstante eingeben, eine Linie von der Konstanten zur Variable ziehen. Und wie sich so ein Programm dann im Endeffekt wirklich verhält, dass weiß man nie. Das einzig sinnvolle was ich da bisher gesehen habe waren die Ladder-Diagramms zum Programmieren von Logik-Verknüpfungen. Da ist man mit dem Shortcuts wirklich schnell. Das schlimmste die FBS/FUP (die ja wohl auch nur eingeführt wurde, damit die Steuerungs-Entwickler nicht komplett von Null anfangen müssen als die SPS aufkamen. Das entsprach halt dem, was sie gewohnt waren. Aber das sich dieser Krampf so lange hält...).
Komisch, da haben Menschen das Kommandozeileninterface des Computers gegen grafische Oberflächen ersetzt und haben sich damit auch noch durchgesetzt. Jeder Mensch klickt heute auf icons, um Programme zu starten. Einen komplexeren geschlossenen Regelkreis beschreibt man nicht in Worten, weil das niemand kapieren würde (außer ein Nerd). Matlab-Simulik ist heute Standard, um technische Prozesse zu beschreiben. Für die Beschreibung von komplexen dynamischen Prozessen sind Modellbeschreibungen im Blockdiagramm nun mal besser geeignet als textuelle Beschreibungsformen. Das Problem vieler Programmierer liegt einfach darin, dass sie nicht in der Lage sind, ein Problem in einem formalen Modell zu beschreiben und dann lieber so dahinprogrammieren. Das hat aber mit der Arbeit eines Ingenieurs nichts zu tun. Und das verlinkte Bild von NI (LabView) hat mit der Arbeit eines Ingeniers auch nicht viel zu tun. Zumal ich das Konzept von LabView selbst auch in Frage stelle, da hier zum Teil versucht wurde, die Idee einer imperativen Programmierung nachzubilden. Ich rede hier aber von klaren deklarativen Programmiersprachen. Gruss ProSign
ProSign schrieb: > Das Problem vieler Programmierer liegt einfach darin, dass sie nicht in > der Lage sind, ein Problem in einem formalen Modell zu beschreiben und > dann lieber so dahinprogrammieren. Das hat aber mit der Arbeit eines > Ingenieurs nichts zu tun. Warum werbt ihr dann laut eurer Homepage damit daß der Kern eurer Sprache mit C geschrieben ist. Warum ist eure Sprache nicht mit eurem eigen grafischen Tool geschrieben? So wie die meisten C Compiler auch mit C geschrieben sind. Die kleine Welt in der die Sprache Sinn machen kann sind Prozesssteuerungen. Die wirkliche Programmierwelt dürfte aber deutlich komplexer sein. Wenn das so einfach geht, dann zeige uns doch mal eine Kreuzkorrelation die du damit programmiert hast oder einen einfachen Edit Distance Algorithmus. Aber bitte beides auch halbwegs performant. Übrigens, wenn die letzten News in der News Sektion das Hochwasser vor 7 Monate war, dann sollte eine Firma die Seite besser weglassen. Ich habe das Gefühl du willst nur Werbung für deine 1 Mann Firma machen.
Hier gäbe es noch was: Beitrag "Grafische Programmierung (Linux + ATmega)" Vielleicht kannst Du Jörg überreden, das Programm noch ein wenig an Deine "praktischen" Bedürfnisse anzupassen.
ProSign schrieb: > Komisch, da haben Menschen das Kommandozeileninterface des Computers > gegen grafische Oberflächen ersetzt und haben sich damit auch noch > durchgesetzt. > Jeder Mensch klickt heute auf icons, um Programme zu starten. Also ich bin da doch noch sehr viel auf der Konsole unterwegs. Und grundsätzlich ist es wohl immer noch so: Je professioneller es wird, das heißt auch umso größer die Einstiegshürde ist, umso weniger Klicki-Bunti hat man und umso effizienter kann man damit arbeiten (wenn man sich einmal eingearbeitet hat). Diese grafischen Programmiersprachen (besser: Modellierungssprachen) sind halt für Leute die nicht programmieren können. Klar, so ein Regelungstechniker ist halt Regelungstechniker und kein Programmierer und der modelliert dann eben auf einer sehr hohen Abstraktionsebene in Simulink. Simulink macht aus dieser Modellierung dann irgendwie Code. Diese hohe Abstraktionsebene hat natürlich den Vorteil, dass man damit erstmal sehr unabhängig vom Target ist. Dafür weiß dann halt keiner mehr was am Target tatsächlich abläuft, das ist dann immer die Blackbox.
ProSign schrieb: > Komisch, da haben Menschen das Kommandozeileninterface des Computers > gegen grafische Oberflächen ersetzt und haben sich damit auch noch > durchgesetzt. > Jeder Mensch klickt heute auf icons, um Programme zu starten. Zweischneidiges Schwert. Denn genau diejenigen, die ausser auf Icons klicken nichts anderes können, sind genau dann die ersten die bei den Commandline-Fuzzis um Rat fragen, wenn irgendwas dann eben doch nicht so funktioniert, wie es sollte. > Einen komplexeren geschlossenen Regelkreis beschreibt man nicht in > Worten, weil das niemand kapieren würde (außer ein Nerd). Da geb ich dir recht. Aber ob man jetzt vorgefertigte Module mittels Linien grafisch miteinander verbindet, oder ob man per Text die Ergebnisse eines Moduls in ein anderes steckt, ist ja nicht das Hauptproblem in der Entwicklung. Siehe zb Arduino. Keiner streitet ab, dass man mit der Arduino Umgebung tolle Sachen machen kann. Durchaus auch von Leuten, die nicht Programmierer sind. Aber sobald das dann eben weiter geht, sind sie allerdings am Ende. Im übrigen: können wir das Thema wieder einschlafen lassen? Das Eröffnungsposting stammt aus 07/2013. Wenn der TO bis jetzt nicht fündig geworden ist, dann wird er es auch jetzt nicht mehr.
1 Ich sage nicht, dass man keine textuellen Programmiersprachen benötigt. C ist einen universelle Programmiersprache für die Systemprogrammierung und ist dafür gut geeignet. Eine grafische Programmiersprache wird als domanespezifischer Überbau für die Applikationsprogrammierung verwendet und hat ein ganz andere Zielgruppe. Aus meiner Sicht sollten Systemprogrammierung und Applikationsprogrammierung zwei getrennt Schritte sein. Das hat vielen Gründe und reicht von der Zuverlässigkeit der Software bis zur Portierbarkeit und Wartbarkeit. 2. Das ist das Mikrocontroller-Forum und Mikrocontroller werden nun mal meist in der "kleinen Welt" der Prozesssteuerungen verwendet. Diese kleine Welt bestimmt aber als eingebettete Systeme unser Leben stärker als man glaubt. 3. Klar will ich debenbei auch Werbung für meine Firma machen. Das ist ja auch nicht schlimm, da ich eventuell einigen Lesern helfe, sich zu orientieren. Hier wird immer alles Schwarz/Weiß gesehen. Es gibt in dieser Frage aber kein absolutes Richtig oder Falsch. Für einige Aufgaben sind grafische Sprachen besser geeignet und für andere Aufgaben sind textuelle Sprachen besser geignet. So wie es auch unterschiedlichen Menschen mit einer unterschiedlchen Ausbildung gibt. Ich denke, dass ich beide Seite gut kenne und auch recht gut beurteilen kann, wann ich lieber in C programmiere und wann ich lieber grafisch programmiere. ProSign
In der Kunst gibt es Schriftsteller und Maler. Ein Architekt zeichnet seine Häuser und beschreibt nur wenig im Text. Ein Elektroniker zeichnet seine Schaltungen. Graphische Programmiersprachen verlangen größere Rechnerresourcen des Entwicklungssystems. Vielleicht ist der Grund für die größere Verbreitung textueller Programmiersprachen schlicht ein "historischer", da die Resourcen am Beginn der Computerentwicklung zu klein für graphische Programmiersprachen waren. Oder wie unser Softwarearchitekt immer sagte: ein Bild beschreibt mehr als 1000 Worte.
chris_ schrieb: > ein Bild beschreibt mehr > als 1000 Worte Ein Bild beschreibt mehr Festplattenplatz als 1000 Worte. ;-)
Ardublocks ist ein Plugin direkt für die Arduino IDE. Grafische Programmierung mit Blöcken...
Link vergessen... http://blog.ardublock.com/ Gerade für Arduino und Co gibt es ein paar solche Oberflächen. Google ist dein Freund ;-)
ProSign schrieb: > Komisch, da haben Menschen das Kommandozeileninterface des > Computers > gegen grafische Oberflächen ersetzt und haben sich damit auch noch > durchgesetzt. > Jeder Mensch klickt heute auf icons, um Programme zu starten. > > Einen komplexeren geschlossenen Regelkreis beschreibt man nicht in > Worten, weil das niemand kapieren würde (außer ein Nerd). > > Matlab-Simulik ist heute Standard, um technische Prozesse zu > beschreiben. Für die Beschreibung von komplexen dynamischen Prozessen > sind Modellbeschreibungen im Blockdiagramm nun mal besser geeignet als > textuelle Beschreibungsformen. > > Das Problem vieler Programmierer liegt einfach darin, dass sie nicht in > der Lage sind, ein Problem in einem formalen Modell zu beschreiben und > dann lieber so dahinprogrammieren. Das hat aber mit der Arbeit eines > Ingenieurs nichts zu tun. > > Und das verlinkte Bild von NI (LabView) hat mit der Arbeit eines > Ingeniers auch nicht viel zu tun. Zumal ich das Konzept von LabView > selbst auch in Frage stelle, da hier zum Teil versucht wurde, die Idee > einer imperativen Programmierung nachzubilden. Ich rede hier aber von > klaren deklarativen Programmiersprachen. > > Gruss > ProSign Komischerweise haben sich alle produktiven Entwickler vom Icongeklicke entwöhnt und benutzen ausgiebig die Konsole. Weil man schneller und übersichtlicher arbeitet. Regelkreise als Blockdiagramm natürlich. Aber ein Regler lässt sich einfach wesentlich schneller und übersichtlicher textuell programmieren. Da kriegt man sonst nämlich schnell solche Bilder wie die verlinkten. Das Problem vieler Ingenieure liegt darin, dass sie nicht programmiern können und das durch Bilder aneinander schieben auch nicht lernen werden. Formale Modelle behindern dich übrigends oft genug, wenn das Problem sich nicht -oder nur mit Aufwand- in ein formales Modell pressen lässt. (Formale Modelle sind natürlich trotzdem notwendig und nützlich) Wieso hat denn das verlinkte Bild nichts mit der Arbeit eines Ingenieurs zu tun? Es zeigt doch einfach, dass grafische Programmiersprachen nicht übersichtlicher oder einfacher sind als textuelle, wie es gerne heisst. P.S.: Was ich von Ingenieuren so an SPS Anweisungen in dieser hässlichen Blockzusammenschieberei gesehen habe, lässt mich eher dazu tendieren entweder Ingenieuren progammieren beizubringen oder die Modelle zu entwickeln und an Programmierer weiterzugeben. Grafische Programmiersprachen sind überflüssig wie ein Kropf. Dass sie sich im Laborbereich mittlerweile durchgesetzt haben macht die Laborarbeit nicht produktiver...
>Das Problem vieler Ingenieure liegt darin, dass sie nicht programmiern >können und das durch Bilder aneinander schieben auch nicht lernen >werden. Allerdings habe ich in meinem Berufsleben schon viele Informatiker getroffen, auf die das auch zutrifft. Eher war es so, dass die Ingenieure im Embedded Bereich deutlich schneller zum Ziel kamen. >Formale Modelle behindern dich übrigends oft genug, wenn das Problem >sich nicht -oder nur mit Aufwand- in ein formales Modell pressen lässt. >(Formale Modelle sind natürlich trotzdem notwendig und nützlich) Das passt insbesondere für die Informatik >Grafische Programmiersprachen sind überflüssig wie ein Kropf. >Dass sie >sich im Laborbereich mittlerweile durchgesetzt haben macht die >Laborarbeit nicht produktiver... Überhaupt nicht. Ich habe 10 Jahre LabView programmiert und 10 Jahre diverse andere Programmiersprachen und muss sagen: Bei bestimmten Anwendungen war ich mit LabView deutlich produktiver. Ich würde sage, bei kleineren Projekten mit graphischer Oberfläche ist man mit LabView ca. 5 mal schneller.
Grafische Programmierung ist sicher sinnvoll, für einige wenige Problemdomänen, als Hilfsmittel. Nein, SPS gehört nicht zu diesen Domänen. Bei fast allen Problemen sind textuelle Programmiersprachen deutlich überlegen, und das wird sich auf absehbare Zeit nicht ändern. Vielleicht passt ein Fachbuch als Analogie: das ist i.d.R. auch zum größten Teil in Text geschrieben, aber beschreibt einige Sachverhalte mit Grafiken. Den Kommentar zur überholten Kommandozeile fand ich sehr amüsant, weil das ja nun offensichtlich kompletter Humbug ist.
In einer Schlosserwerkstatt oder einem Maschinenbaubetrieb sind hunderte bis tausende von Werkzeugen vorhanden. Sie füllen Schubladen, Schränke und Hallen. Davon gibt es einige sehr universelle Werkzeuge, andere sind nur sehr speziell brauchbar. Einige sind sehr platzsparend, andere riesig. Einige in schnell in Betrieb zu nehmen, bei anderen dauert es Wochen. Und kaum ein vernunftbegabter Mensch würde ihre Existenzberechtigung infrage stellen. Elektrotechniker haben eine handvoll Werkzeuge in ihrer Schublade und im glücklichen Fall eine große Menge davon im Labor (Meßgeräte). Ein Bauer hat entweder eine große Menge spezieller Geräte oder Erweiterungen für sein Standardgerät. Keinem Gerät wird ein vernünftiger Mensch die Daseinsberechtigung absprechen, höchstens ein schlechtes Kosten-Nutzen-Verhältnis für den jeweiligen Anwendungsfall. Nur im Programmierfall scheinen die Meinungen so verhärtet zu sein, daß die favorisierten Werkzeuge das einzig Wahre seien und alles andere sinnloser Mist. Gut, daß der durchschnittliche Bauer da deutlich cleverer als der durchschnittliche selbsternannte Softwareexperte, der sich in Foren herumtreibt, ist. My 2 Cents W.T.
:
Bearbeitet durch User
Wie wäre es denn mit dem AVR-NET-IO Board von Pollin mit der Software von Elektronik2000.de. Vielleicht ist das ja was für dich. Gruß Martin
Walter Tarpan schrieb: > Nur im Programmierfall scheinen die Meinungen so verhärtet zu sein, daß > die favorisierten Werkzeuge das einzig Wahre seien und alles andere > sinnloser Mist. Gut, daß der durchschnittliche Bauer da deutlich > cleverer als der durchschnittliche selbsternannte Softwareexperte, der > sich in Foren herumtreibt, ist. > Mehr ist es so, dass es (entgegen deiner hinkenden Analogie) tatsächlich qualitativ schlechtes Werkzeug gibt, oder welches das für seinen vorgegebenen Einsatzzweck ungeeignet ist. Die wenigsten hier werden aus Prinzip und Verbohrtheit diverse Arten von Tools verschmähen. Das kommt daher, weil man eben schlechte Erfahrungen mit solchen Tools gemacht hat.
alfred schrieb: > Das passt insbesondere für die Informatik Mhm, den Fehler zu glauben technische Informatik hätte etwas mit Computern und Programmieren zu tun hab ich auch schon gemacht. Tatsächlich ging's in der Vorlesung dann um Petri-Netze, UML und Statecharts. > Ich würde sage, > bei kleineren Projekten mit graphischer Oberfläche ist man mit LabView > ca. 5 mal schneller. Das liegt meiner Meinung nach allerdings an den Libraries die LabView mitbringt. Da ist halt sehr vieles schon fertig drin was man sich woanders erst selbst bauen muss. (Dafür muss man auch entsprechend viele Münzen bei NI einwerfen...)
Hi
>Heute ist es wieder soweit:
Du weist, was heute für ein Datum ist?
MfG Spess
Klaus Maus schrieb: > Das Problem ist: bei größeren Projekten wird die grafische > Programmierung so unübersichtlich und komplex, daß sie keinen Vorteil > mehr darstellt. Bei kleineren Projekten wird oft auch nur ein kleiner > Teil des Funktionsumfangs einer Programmiersprache genutzt, so daß der > Aufwand, diesen kleinen Teil zu lernen, nicht größer ist als das > Erlernen der grafischen Programmierung. Von daher bietet eine grafische > Programmierung weder bei kleinen noch bei großen Projekten einen > Vorteil, und ebensowenig beim Einarbeitungs- und Lernaufwand. > > Außerdem bedingt eine grafische Programmierung immer, daß die einzelnen > Funktionsblöcke korrekt aufeinander abgestimmt sind. Das erfordert einen > Overhead, so daß das Ergebnis hinterher aufgebläht und / oder langsam > ist. Bei einem Mikrocontroller mit seinen begrenzten Ressourcen ist > beides keine sonderlich gute Idee -- hierbei wird ja oft sogar noch > Assembler genutzt, um möglichst kleine, schnelle Programme und eine > möglichst große Kontrolle über die Hardware zu erreichen. Dieses Thema interessiert mich schon seit Langem, die oben genannte Einschätzung habe ich von vielen erfahrenen Programmierern gehört, und möchte diese realistische Einschätzung keinesfalls abwerten. A b e r : Im Bezug auf Übersichtlichkeit und Funktionalität gibt es ja auch schon lange grafische und etablierte Oberflächen. Z.B. werden viele SPS Steuerungen im Bahnwesen teilweise nur ( in manchen Projekten ausschließlich) in Funktionsblöcken eingegeben, was es natürlich nicht immer übersichtlicher macht. In anderen Bereichen bei denen z.B. Statemachines von großer Bedeutung ist werden auch diese als Oberfläche kompiliert, was eine völlig neue Herangehensweise erfordert (keine einfache Einarbeitung). Der Zwang auf Assembler wegen knappen Ressourcen sehe ich eigentlich nicht mehr , bei µC bekommt man ja schon unter 10 € einen 32-Bit Cortex M-3 mit 512 kB Speicher und einer 72MHz Taktung usw..., klar hat man dann auch andere Probleme (komplexe tools) D.h. wenn es um den Programmieraufwand eines Einmalprojektes geht, macht es ja keinen Sinn die paar Cents am Kontroller zu sparen, ein Overhead würde sich gegenüber der Ressource Zeit lohnen. Ich sehe das Problem eher darin , dass bei der Entstehung der Tools, der Architekturen und v.a. der höheren Programmierprachen in der Vergangenheit praktisch immer eine Down-to-Top-Entwicklung stattgefunden hat und der unterste Kern eines µC verarbeitet nun mal serielle Befehle --> Script und ähnliches gilt für den Input von Compilern. Im Gegensatz dazu sind (wen wundert es) alle etablierte, grafische Eingabeoberflächen an einer (bestimmten) Anwendung orientiert, wobei es sich ja nicht nur um Funktionsblöcke handeln muß. Ich vermute, dass sich auch der Programmierstil und Denkweisen sehr an dem Sprachstil orientiert. Es kommt nicht von Ungefähr, dass es zwischen Programmierer und Auftraggeber einer Applikation oft zu Mißverständnissen kommt. Langfristig sehe ich aber eine Tendenz, dass man sich bei den höheren Sprachen an die Applikation anpasst. mfg Ulli12v
Probier doch mal Profilab aus, das ist billiger als LABVIEW, so um die 90€ macht sich ganz gut, kannst ja mal die Demoversion probieren
Hallo Danke. Das Problem ist noch nicht vom Tisch. Das Angebot einer Programier-Hilfe wurde leider aus Zeitmangel im Anfangsstadium beendet. Eine Software und das passende Zubehör (Feuchte u. Temperatur-Sensoren Relaiskarten ) einzubinden, hat mich noch nicht voran gebracht. Ich benötige scheinbar zu viele Analoge Ein und Ausgänge. Ohne fremde Hilfe wird es wohl beim Gedanke bleiben. Habe mir zur Not (und als Übergang)auf elektromechanischem weg geholfen. MfG
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.