# Wünsche an Programmier- und Entwicklungstools



## Martin Buchwitz (17 Juni 2013)

Die Tools zur Programmierung und Inbetriebnahme von Steuerungen (Steuerungssystemen) haben sich zu den zentralen Werkzeugen der Anwender entwickelt. Meine Frage an der Stelle ist: werden diese dem Anspruch gerecht? Anders gefragt: Welche konkreten Veränderungen und Verbesserungen wünscht Ihr Euch bei den Engineeringtools (TIA, Automation Studio, Jetsym, Codesys, Lasal, …..) der Steuerungstechnik?


----------



## Larzerus (17 Juni 2013)

Ich kann nur für die Siemens Welt sprechen da ich leider bisher nichts anderes kennengelernt habe. Aber was ich mir wünschen würde gerade beim TIA Portal ist das es  was schneller wird. Kann nicht sein das ich den halben Tag warte das das Programm mit laden fertig wird. Und als dankeschön auch noch zwischendurch 2 mal abstürzt. 

Grundlegend wäre es mal angebracht das Siemens die Entwicklung im eigenen Haus macht und nicht beim Kunden.
Ich habe mit TIA V10.5 anfangen müssen und zum aktuellen V12 ist da ja auch echt ne positive Entwicklung zu sehen.
Und ich würde schätzen ab V15 kann man sich damit auch bei nem Kunden sehen lassen. 

Und die Tolle technische Hilfe die man da am Telefon bekommt ein Traum. :sm12:
"Ja ich hab das hier im Büro mal nachgebaut und ich komm zum gleichen Fehler. Da kann ich ihnen nicht weiter Helfen. Ich gebe das mal weiter an die Technische Entwicklung"
Und dann hört man einfach 5 Wochen nichts mehr.


----------



## Martin Buchwitz (17 Juni 2013)

Larzerus schrieb:


> Grundlegend wäre es mal angebracht das Siemens die Entwicklung im eigenen Haus macht und nicht beim Kunden.



Das scheint mir einer der grundlegenden Probleme zu sein in der Automatisierungstechnik. In anderen Bereichen würde ein Sturm der Entrüstung durch das Internet gehen und das Thema wäre sehr schnell erledigt. Irgendwie sind wir Automatisierer da recht geduldig. Das ist aber auf alle Fälle nicht nur ein Siemens-Problem.


----------



## van (17 Juni 2013)

Na ja, sich hier einzelne Funktionen zu wünschen ist schwierig. 

Deswegen lasse ich meinen Rant einfach mal allgemein ab  

Generell sollte die gesamte Branche im 21. Jahrhundert  ankommen. Und in der IT Welt. 

Das wird langsam, aber dauert halt doch etwas arg lange. 

Und dabei sich auch einmal getrauen alte Zöpfe abzuschneiden.

Alle reden immer von Frameworks, Bibliotheken und Standards.

Und wie sieht die Wirklichkeit aus ??
z.B Bei den meisten Feldbusgeräten bekommt man eine lange Doku mit Hex Werten aus der man sich jedes Bit selber von Hand rauspobeln darf. Mit etwas Glück/Pech noch ein rotziges Programm Beispiel das nach S5 riecht. 

Wo ist da die Bibliothek in SCL/ST die den Standard abbildet und mit der man 90% der Aufgaben abdecken kann ??

Und die Entscheider in den Firmen verstehen nicht einmal warum der SPS Programmierer sich dabei etwas Komfort wünscht. Der ehemalige SPS'ler am der Hotline hat mich nach einem halben Satz verstanden und versteht seine Kollegen auch nicht ...

Aber Hauptsache das ISO Zertifikat hängt in der Eingangshalle.


----------



## Thomas_v2.1 (17 Juni 2013)

Was ich wichtig finde sind offene Schnittstellen.

Man programmiert Anlagen wo alles bis ins letzte automatisiert werden soll, aber die Programmierumgebungen sind so verschlossen dass man per Copy&Paste zusammenkopieren muss. Kann eigentlich nicht sein.
Genauso sollte heutzutage die Möglichkeit bestehen, ein Programm / Projekt in einen gängiges Versionsverwaltungstool (SVN, Git etc.) einchecken zu können, und zwar ohne zweifelhafte Zusatzprogramme für mehrere tausend Euro.

Bei Step 7 gab es wenigstens noch die Kommandoschnittstelle (und die interne Datenbank ist ja auch größtenteils entschlüsselt) die beim TIA-Portal komplett entfallen ist.
Bei Codesys (2.x) muss man auch immer erst umständlich Quellen exportieren. Codesys 3 habe ich mir noch nicht angesehen, da es auf dem Visual Studio aufsetzt und dort die Projekte in XML-Dateien abgespeichert werden, lässt sich hoffen dass man dort etwas mehr Zugriff hat.

Wenn man sich enige Produktvideos anschaut, könnte man meinen die "Entscheider" denken wirklich die SPS-Programmierer klicken bei Anlagen mit mehreren hundert oder tausend E/As mit Copy&Paste und Drag&Drop zusammen.
Ich denke ich bin nicht der einzige, der sich aus einer Excel-Datei mit Antriebs- und Messstellenliste, automatisch die Symbolik (wobei die schon aus Eplan kommt), die Grundkonstrukte der Antriebsaufrufe inkl. Beschaltung, Datenbasis und Alarme für Bedienpanel und Scada-System vollautomatisch generieren lässt.


----------



## Martin Buchwitz (17 Juni 2013)

van schrieb:


> Generell sollte die gesamte Branche im 21. Jahrhundert  ankommen. Und in der IT Welt.
> Das wird langsam, aber dauert halt doch etwas arg lange.
> Und dabei sich auch einmal getrauen alte Zöpfe abzuschneiden.



Das liegt meines Erachtens nach daran, dass der Stellenwert der Software viel zu lange unterbewertet wurde und das ist auch heute noch viel zu oft der Fall. Eine Frage stellt sich natürlich auch: Wären Anwender mehr Geld für eine bessere Software auszugeben, bzw. bei manchen Herstellern überhaupt mal Geld dafür bezahlen?


----------



## Martin Buchwitz (17 Juni 2013)

Thomas_v2.1 schrieb:


> Was ich wichtig finde sind offene Schnittstellen.



Das scheint mir einer der grundlegenden Probleme zu sein. Oft gewinnt man den Eindruck, dass tatsächliche Offenheit gar nicht gewollt ist. Da gibt es definitiv Handlungsbedarf, das kann ich nur so bestätigen.


----------



## ducati (18 Juni 2013)

Naja, der Standardwunsch: Die Komplexität der Engineeringtools verringern bzw. nicht noch weiter erhöhen. Ich würde mich lieber auf das eigentliche Automatisierungsproblem konzentrieren und nicht ein Großteil der Zeit mit dem Engineeringsystem kämpfen.


----------



## Larry Laffer (18 Juni 2013)

ducati schrieb:


> Naja, der Standardwunsch: Die Komplexität der Engineeringtools verringern bzw. nicht noch weiter erhöhen. Ich würde mich lieber auf das eigentliche Automatisierungsproblem konzentrieren und nicht ein Großteil der Zeit mit dem Engineeringsystem kämpfen.



Ich würde sagen, dass das genau der falsche Weg wäre - das zielt hier aber (glaube ich) auch in Richtung TIA.
Die Frage hier ist m.E. wie es umgesetzt ist.
Darüber hinaus haben mir bislang eher Möglichkeiten gefehlt.
Ein Entwicklungssystem könnte sowohl von der Performance als auch von den Möglichkeiten ganz gut an Visual Studio angelehnt sein (wurde aber auch schon genannt). Wenn es im Bereich HMI dann auch dessen Möglichkeiten (hier z.B. Entwicklen von Controls) hätte dann wäre es sicherlich schon mal ein guter Ansatz ...

Gruß
Larry


----------



## ducati (18 Juni 2013)

Naja, kommt wie immer drauf an 

Nein ich ziele nicht nur in Richtung TIA. Selbst bei PCS7 verbringt man immer ne Menge Zeit mit dem System und nicht mit der eigentlichen Automatisierungsaufgabe. Vielleicht mangelt es aber oft auch einfach nur an der Ausgereiftheit der Systeme.

Unterschiede bestehen sicherlich auch zwischen dem Anwendungsbereich Serienmaschinenbau und Prozessautomatisierung. Im Serienmaschinenbau will man auch die Kleinigkeiten nach und nach verbessern. In der Prozessautomatisierung einfach nur schnell, fehlerfrei und unproblematisch fertig werden.

Aber vielleicht 2 grundlegende Dinge: Ausgereifte, fehlerfreie und intuitiv zu bedienende Engineeringsysteme und Kontinuität (also nicht ständig neue Versionen mit neuen Funktionen).

Vielleicht noch integrierte Test- und Simulationstools (nicht nur alla PLCSIM, sondern auch die Möglichkeit den Prozess einfach nachzubilden). Anderswo nenn man das "Software in the Loop"...

Gruß.

Gruß.


----------



## ducati (18 Juni 2013)

Larry Laffer schrieb:


> Darüber hinaus haben mir bislang eher Möglichkeiten gefehlt.



Naja, vielleicht ist das aber auch ein Teil des Problems, irgendjemandem fehlt immer irgendeine Funktion. Diese Wird dann nachträglich irgendwie integriert. Nach mehreren solcher Schritte ist das System dann u.U. alles andere als "aus einem Guss" ...

Natürlich immer eine Frage der Umsetzung


----------



## Perfektionist (18 Juni 2013)

Martin Buchwitz schrieb:


> Anders gefragt: Welche konkreten Veränderungen und Verbesserungen wünscht Ihr Euch bei den Engineeringtools (TIA, …..) der Steuerungstechnik?


TIA: mehr Druck seitens Siemens, TIAP durchzusetzen. Classic sollte jetzt abgekündigt werden. Sodenn die innovierten Classic-CPUs nicht durch ein FW-Update noch die Fähigkeiten von 1200/1500 bekommen sollen und trotzdem Classic-kompatibel bleiben.


----------



## Larzerus (18 Juni 2013)

Perfektionist schrieb:


> TIA: mehr Druck seitens Siemens, TIAP durchzusetzen. Classic sollte jetzt abgekündigt werden. Sodenn die innovierten Classic-CPUs nicht durch ein FW-Update noch die Fähigkeiten von 1200/1500 bekommen sollen und trotzdem Classic-kompatibel bleiben.




Die sollen ehr mal auf die bremse treten was dieses unfertige TOOL angeht. Siemens sollte erst mal zusehen das TIA auch alles kann was Simatic Manager schon seit Jahren kann.
Wenn das dann vielleicht so GOTT will auch noch fehlerfrei Funktioniert kann man TIA weiter verbreiten. 
Solange sollte es ehr nen 5.6 geben was auch die neue Hardware unterstützt.


----------



## ducati (18 Juni 2013)

Perfektionist schrieb:


> TIA: mehr Druck seitens Siemens, TIAP durchzusetzen. Classic sollte jetzt abgekündigt werden.



Muss das sein, auch hier wieder mit dem Glaubenskrieg anzufangen?...


----------



## Larry Laffer (18 Juni 2013)

Um mal wieder zum Thema zurück zu kommen (blöd von mir, dass ich das T-Wort ins Spiel gebracht habe).



ducati schrieb:


> Aber vielleicht 2 grundlegende Dinge: Ausgereifte, fehlerfreie und* intuitiv zu bedienende Engineeringsysteme *und Kontinuität (also nicht ständig neue Versionen mit neuen Funktionen).



Inituitiv ist m.E. das eine Schlagwort,
Offenheit das Andere - damit nämlich genau das :


ducati schrieb:


> ... verbringt man immer ne Menge Zeit mit dem System und nicht mit der eigentlichen Automatisierungsaufgabe ...


... kein Thema mehr ist ...

Gruß
Larry


----------



## bike (18 Juni 2013)

Perfektionist schrieb:


> TIA: mehr Druck seitens Siemens, TIAP durchzusetzen. Classic sollte jetzt abgekündigt werden. Sodenn die innovierten Classic-CPUs nicht durch ein FW-Update noch die Fähigkeiten von 1200/1500 bekommen sollen und trotzdem Classic-kompatibel bleiben.



Willst du die Schwächen nicht sehen, oder kannst du nicht?

Zurück zum Thema.
Bei den meisten Entwicklungsumgebungen wird nach meiner Erfahrung an der Praxis vorbei entwickelt.
Wenn ich heute mir PCS7 anschaue, da gäbe es einiges das mit wenig Aufwand uns die Arbeit erleichtern würden.
Eine intuitive Schnittstelle, die mit Script oder anderen tools, es erlaubt das Entwicklersystem an die eigenen Wünsche und Erfordernisse anzupassen.
Einfache Kompiler kann man das beibringen, sobald es visuelle Entwicklungssystem sind, wird es schwer.
Eclipse macht es eigentlich vor wie es gehen kann, warum, kann das BigS nicht?
Ist die Software nicht teuer genug?


bike


----------



## Onkel Dagobert (18 Juni 2013)

Perfektionist schrieb:


> TIA: mehr Druck seitens Siemens, TIAP durchzusetzen. Classic sollte jetzt abgekündigt werden..





Perfektionist schrieb:


> ..Sodenn die innovierten Classic-CPUs nicht durch ein FW-Update noch die Fähigkeiten von 1200/1500 bekommen sollen und trotzdem Classic-kompatibel bleiben.



Perfektionist, überdenke doch mal deine Grundeinstellung! Du denkst wie ein Politiker, wie ein praxisfremder Chef oder wie ein Bürokrat, jedoch nicht wie ein versierter Anwender. So denken m.E. auch die Siemens-Manager, die von der Technik keinerlei Ahnung haben, aber alles auf Teufel komm raus nach vorn bringen wollen. Mag sein dass alles Neue deinen primitiven Ansprüchen genügt, mir nicht! Ganz ehrlich, vor solchen Leuten wie dir habe ich indirekt Angst!

Gruß, Onkel


----------



## Jochen Kühner (18 Juni 2013)

Thomas_v2.1 schrieb:


> Was ich wichtig finde sind offene Schnittstellen.
> 
> Bei Step 7 gab es wenigstens noch die Kommandoschnittstelle (und die interne Datenbank ist ja auch größtenteils entschlüsselt) die beim TIA-Portal komplett entfallen ist.
> .



Ich habs an der Produktvorstellung auf der SpsDrives angesprochen, da wurde mir gesagt was ähnliches (Dokumentierte DotNet Objekte) kommt ende 2013, wo bei Ich das nicht wirklich glaube (ebensowenig wie die Versionsverwaltung (welche mir auch gesagt wurde würde Ende 2013 kommen))

AberbIch sehs wie du, hätte man einfach ein Textformat z.B. Xml für Bausteine, Config, Bilder etc verwendet, müsste sich Siemens gar nicht selbst um Versionsverwaltung und Schnittstellen kümmern! Man könnte einfach Git, etc einsetzen...


----------



## Martin Buchwitz (19 Juni 2013)

ducati schrieb:


> Aber vielleicht 2 grundlegende Dinge: Ausgereifte, fehlerfreie und intuitiv zu bedienende Engineeringsysteme und Kontinuität (also nicht ständig neue Versionen mit neuen Funktionen).
> 
> Vielleicht noch integrierte Test- und Simulationstools (nicht nur alla PLCSIM, sondern auch die Möglichkeit den Prozess einfach nachzubilden). Anderswo nenn man das "Software in the Loop"...



Das scheint mir, ohne die Details zu betrachten, die Sache doch ziemlich auf den Punkt gebracht. Wobei die Details für eine konkrete Betrachtung dann schon wichtig sind. Themen wie Versionsmanagement, Arbeiten in Teams etc.


----------



## Martin Buchwitz (19 Juni 2013)

Perfektionist schrieb:


> TIA: mehr Druck seitens Siemens, TIAP durchzusetzen.



Auch ein interessanter Ansatz. Dann müsste Das TIA Portal eben auch sehr schnell alle Funktionalitäten beinhalten.


----------



## Ralle (19 Juni 2013)

Ich sehe. dass wir immer IT-lastiger werden. Für Leute wie mich (Maschinenbauer mit langjähriger SPS-Programmierung), ist aber das grundlegende Problem, dass viele IT-ler von ihrer Ausbildung her tolle Programme (OOP und Trallala) scheiben können, damit aber keine Maschine ordentlich zum Laufen bringen (Warum auch immer). Und natürlich auch umgekehrt, Maschinenbauer, die das "Verständnis" von der Machine haben, aber mit ihrem Spagetticode einen IT-ler zur Verzweiflung treiben.

Beide Seiten muß man aber unter einen Hut bringen können. Das heißt für meine Seite, etwas weniger IT-Komplexität (entweder kein OOP oder von vornherein so gut durchdacht und umgesetzt, dass ich mich damit nicht bis ins Detail befassen muß). Diese halbgaren Werkzeuge und dazu zählt genauso TIA wie auch Codesys V3 (wobei auch Codesys V2 nicht wirklich zu Ende entwickelt wurde, wenn ich nur an die Fenster-Orgien beim Online-gehen in einem FB denke) kann niemenad wirklich brauchen. Was nützen mit Ansätze von OOP, wenn man dann nichts mehr debuggen kann was damit zusammenhängt? (Siehe Beitrag um Bereich Codesys von gestern). Maschinen (hier meine ich besonders den Sondermaschinenbau) werden für jeden Kunden neu und speziell entwickelt, dazu gehört auch die Software. Die zu Programmieren und die Maschine/Anlage in Gang zu setzen ist meißt in einer endlichen Zeit abzuwickeln. Das muß also Hand und Fuß haben. Wie soll ich das erreichen, wenn immer neue Gimmicks den Blick für das Wesentliche (die Funktion der Maschine) verstellen. Wenn ich hier im Forum so manchmal mitlesen, dann scheint es oft wichtiger, dass Chefe eine SMS von der Anlage erhält, als dass diese stabil und störungsfrei läuft. 

Also mein Wunsch: Weniger ist mehr, dafür aber stabil und erprobt über viele Jahre.


----------



## Larry Laffer (19 Juni 2013)

... ich glaube, die Wahrheit liegt irgendwo dazwischen.
Ein Sondermaschinenbauer macht ja auch nicht heute eine Presse, morgen eine Aufteilsäge und dann einen Kran und dann einen Rundschalttisch - man bleibt immer ungefähr in seinem Metier. Und hier lassen sich durchaus Verallgemeinerungen und Basis-Funktionalitäten schaffen (in der SPS und auch in der HMI) - ich nenn das jetzt mal bewußt nicht OOP.
Wichtig wäre es aber, dass mir das Entwicklungssystem (intuitive Bedienbarkeit desselben immer vorausgesetzt) keine Steine in den Weg legt oder mich zu irgendwelchen abstrusen Konstrukten zwingt.
Grundlage aller Überlegungen sollte natürlich sein, dass das Entwicklungssystem (ich nenne mal keine Namen) schon weit aus dem Beta-Stadium heraus ist - diese Massgabe scheint heute aber nicht mehr unbedingt zu gelten ... und das ist m.E. das Hauptproblem.

Gruß
Larry


----------



## Perfektionist (19 Juni 2013)

Larzerus schrieb:


> Die sollen ehr mal auf die bremse treten was dieses unfertige TOOL angeht. Siemens sollte erst mal zusehen das TIA auch alles kann was Simatic Manager schon seit Jahren kann.
> Wenn das dann vielleicht so GOTT will auch noch fehlerfrei Funktioniert kann man TIA weiter verbreiten.
> Solange sollte es ehr nen 5.6 geben was auch die neue Hardware unterstützt.


Ein V5.6, das die neuen jemals unterstützt, wird es nie geben. Hier ist Schnitt. Was überhaupt noch zu einer 5.5-Release führte, wird vermutlich auch nur Politik gewesen sein. Seit V5.2 habe ich kaum spürbare Verbesserungen gehabt.



Martin Buchwitz schrieb:


> Auch ein interessanter Ansatz. Dann müsste Das TIA Portal eben auch sehr schnell alle Funktionalitäten beinhalten.


Ich persönlich bin in der Lage, bereits mit der vorliegenden Funktionalität vollausreichend leben zu können. V12 durfte ich noch nicht testen. V11 unterstützt ja Antriebe noch nicht, V12 verspricht es und vielleicht kann es auch bereits das abdecken, was nun aktuell an Siemens-Antriebstechnik bei uns dazu kommt. Die Abkündigung wäre ein eindeutiges Signal an die Kunden, die sonst glauben, mit dem alten noch zehn Jahre weiterleben zu können.

@Ralle:
Mein Programmierstil ist als eher prozedural einzustufen. Den gesamten OOP-Backgrund hab ich nicht und werde ihn vermutlich auch nicht mehr erlernen. Aber mir ist bewusst, dass ich offenbar auch Teile des OOP-Gedanken nutze. Zur Zeit ist für mich die halbgare Software die Classic-Version, die mich zwar vollständig bei der symbolischen Programmierung (seit V5.2) unterstützt, aber jedesmal mir die Aktualdaten zerschießt, wenn ich eine Instanzdeklaration ändere. In diesem Punkt ist TIAP V12 nun einen für mich großen Schritt weitergegangen. Ich habe es schon tausendmal gesagt: für mich haben FC und Global-DB ausgedient. Ob dieser Weg für andere Maschinen/Anlagen der bessere ist, weiß ich nicht. Für meine Verpackungsmaschinen und Transportanlagen und auf mich passt das Konzept. Und seit TIAP + 1500er optimal.



> ... schon weit aus dem Beta-Stadium heraus ist ...


@Larry: V11 SP2 ist keine Beta mehr, sondern ein vollwertiges Werkzeug, das die von mir geforderte Funktionalität für Classic-CPUs voll unterstützt.


----------



## bike (19 Juni 2013)

@Perfektionist:Glaubst du wirklich was du schreibst?
Denkst du BigS kann diese funktionierende Entwicklungsumgebung sterben lassen?
Was wird aus PCS7? Was wird aus der NC?
Es ist erschreckend, dass du deine kleine Programmiererwelt als Massstab für die Programmierung im Allgemeinen nimmst.
Warum gibt es mehr Kritik als Lob für das TIA?

Ich kann Ralle voll und ganz beipflichten:
Eine Maschine ist kein Rechner und es wird immer ein Unterschied bleiben zwischen IT und Maschinenprogrammen.

Wir als Entwickler werden bei der Entwicklung der Werkzeuge für unsere Arbeit nicht beachtet.
Das war bei Step7 V1 so und ist bei TIA auch so.


bike


----------



## Werner29 (20 Juni 2013)

Ihr Lieben,

ich bin Entwickler bei 3S und das wäre ein Super-Thema für mich, aber leider finde ich überhaupt nichts konkretes in diesem Thread. 
Bisher kommen nur allgemeine Schlagworte: "Die Software sollte intuitiv sein" etwa, oder "Komplexität reduzieren".
Ja schön, wie wenn das so einfach wäre. Jeder Entwickler will das erreichen.
Gut, die Frage war relativ allgemein gestellt, vielleicht kann man da nur allgemeine Antworten erwarten, wer kennt schon alle
Entwicklungstools?
Dann will ich mal eine allgemeine Antwort geben, zu den Problemen, die wir Software-Entwickler haben. 
Ein SPS Programmiersystem wie Codesys hat 1000 Features. Keines der Feature soll einen nerven wenn man es nicht braucht (Komplexität),
aber jedes sofort gefunden werden, wenn man es braucht (Intuitivität). Es ist nun mal sauschwierig das zu vereinen, und deswegen
ist Software manchmal komplex oder nicht intuitiv, und nicht weil sich die Entwickler dagegen wehren, oder zu doof sind.

Ein anderer wünscht sich mehr offene Schnittstellen: klingt gut, aber jede offene Schnittstelle ist ein Angriffspunkt, und wir müssen immer mehr
auf Sicherheit achten, auch das lässt sich nicht immer verbinden.

Noch eine Antwort zum Beitrag von Ralle: OOP ist dazu da die Komplexität der Software zu beherrschen, sonst macht man was falsch.
Und: natürlich kann man seine OOP-Software in CODESYS debuggen, aber in dem angesprochenen Fall muss man als Programmierer was tun:
http://www.sps-forum.de/beckhoff-co...desys-v3-bzw-somachine-motion.html#post448887

Ein letztes: wir sind eine Firma mit 100 Mitarbeitern, haben mehrere 100 OEM Kunden, entwickeln ein Produkt mit > 1 Mio Codezeilen (wir haben schon lange nicht
mehr gezählt). Wenn wir unsere Software "fehlerfrei" bekommen wollen, dann müssen wir mit unseren Ressourcen wahrscheinlich
10 Jahre lang die Entwicklung einstellen und nur Testen und Fehler beheben.
Ich glaube im Rahmen unserer Möglichkeiten machen wir einen guten Job, auch was die Qualität angeht. Aber ja, es werden noch Fehler drin sein.

So, hat jetzt jemand mal einen konkreten Punkt, was man besser machen könnte?


----------



## Larry Laffer (20 Juni 2013)

Werner29 schrieb:


> So, hat jetzt jemand mal einen konkreten Punkt, was man besser machen könnte?



Da ich / wir nicht mit CodeSys arbeiten kann ich zu dem Punkt nichts sagen. Ich würde aber auch sagen, dass ihr aufgrund von verschiedenen Rückmeldungen eurer Kunden auch genau (wie jeder Andere) wisst, wo bei euch die "Probleme" sind. Das Thema hier ist vielleicht auch, wie mit den Rückmeldungen von Kunden umgegangen wird (und ob überhaupt).
Ich würde aber auch mal behaupten wollen, dass sich die genannten (selbstverständlich etwas schwammigen) Angaben nicht unbedingt in Richtung 3S sondern an einen etwas größeren SW-Hersteller gerichtet haben.

Gruß
Larry


----------



## ducati (20 Juni 2013)

Werner29 schrieb:


> Ein SPS Programmiersystem ... hat 1000 Features.



Jo, das ist des Pudels Kern... wer braucht die wirklich... und welche davon sind einfach nur aus Marketinggründen entstanden... oder Hersteller xy hat das auch, also muss das bei uns auch rein...

Ich brauche nicht 1000 Möglichkeiten/Protokolle wie die SPS mit der Visu kommunizieren kann, ein ordentliches reicht mir. Aber es muss ja jeder alles und jeden unterstützen.
Siemens hat das Problem, dass sie x Firmen/Produkte aufkaufen und das dann alles unter einen Hut bringen müssen (Totally Integrated Automation...) 

Nur jetzt im Nachhinein ist das schwer zu reduzieren...

Gruß.


----------



## Werner29 (20 Juni 2013)

Larry Laffer schrieb:


> Da ich / wir nicht mit CodeSys arbeiten kann ich zu dem Punkt nichts sagen.


Genau das ist der Fehler. Ist schon klar dass die Siemens-Software hier im Forum wichtiger ist als CODESYS.
Aber es gibt doch schon genügend TIA-Nörgel Threads, das interessiert mich naturgemäss wenig.
Es ist zwar beruhigend zu sehen dass Siemens auch Probleme hat, aber wenn ich mir deren Umsätz ansehe, dann
machen die offensichtlich alles richtig.

Ich versuche ganz eigennützig die Diskussion in eine andere Bahn zu lenken. 
Unabhängig vom speziellen Tool: wie sieht die Software eurer Träume aus?


----------



## Werner29 (20 Juni 2013)

ducati schrieb:


> Jo, das ist des Pudels Kern... wer braucht die wirklich... und welche davon sind einfach nur aus Marketinggründen entstanden... oder Hersteller xy hat das auch, also muss das bei uns auch rein...
> 
> Ich brauche nicht 1000 Möglichkeiten/Protokolle wie die SPS mit der Visu kommunizieren kann, ein ordentliches reicht mir. Aber es muss ja jeder alles und jeden unterstützen.
> Siemens hat das Problem, dass sie x Firmen/Produkte aufkaufen und das dann alles unter einen Hut bringen müssen (Totally Integrated Automation...)
> ...



Wenn ich 10 Kunden Frage, auf welches Feature sie verzichten können, bekomme ich 10 Antworten, aber die Schnittmenge ist leer. Das ist leider so.
Jeder kann auf das verzichten, was jemand anders braucht. 

Ich weiss gar nicht ob Siemens so ein grosses Problem mit zugekaufter Software hat. Ich glaube eher, dass in so einer
Firma einfach zu viele Leute mitquatschen. Aber ich habe da keinerlei Insiderwissen.


----------



## Perfektionist (20 Juni 2013)

bike schrieb:


> @Perfektionist:Glaubst du wirklich was du schreibst?
> Denkst du BigS kann diese funktionierende Entwicklungsumgebung sterben lassen?
> Was wird aus PCS7? Was wird aus der NC?
> Es ist erschreckend, dass du deine kleine Programmiererwelt als Massstab für die Programmierung im Allgemeinen nimmst.


OK, meine kleine Welt kommt tatsächlich ohne PCS7 zurecht. Kann ich mir tatsächlich kein Urteil zu erlauben, solange das richtige WinCC, NC etc. auch bei TIAP nicht mit integriert wurde.


----------



## Ralle (20 Juni 2013)

Werner29 schrieb:


> Noch eine Antwort zum Beitrag von Ralle: OOP ist dazu da die Komplexität der Software zu beherrschen, sonst macht man was falsch.
> Und: natürlich kann man seine OOP-Software in CODESYS debuggen, aber in dem angesprochenen Fall muss man als Programmierer was tun:
> http://www.sps-forum.de/beckhoff-co...desys-v3-bzw-somachine-motion.html#post448887



Den Thread hab ich auch mitgelesen, aber es erschien mir damals schon als absolut suboptimal, dass ich zum debuggen auch noch extra Code schreiben muß und u.U. bei zu heftigem Gebrauch zu SPS zeitlich überfordere. 

Und so mancher Kollege ist schon mit der Komplexität der Maschine am Rande und dann noch OOP.

Weißt du Werner, wenn das *wirklich* funktionieren würde, bitte, gerne, ich mache mit. Aber das ist Wunschdenken und geht weit an der Realität vorbei. Ich sitze vor dem PG und versuche verzweifelt einen Fehler zu suchen, der so tief in der verschachtelten, vererbten, u.U. mutierten Software vergraben ist, dass man einfach nicht die Zeit (und oft auch nicht das Wissen) hat so etwas zu suchen. Aber BMW wartet auf Teile, die bauen Autos. Was also ist mir lieber? Einfach, gerade, funktional.

Bekommt ihr das hin mit V3? Wäre nett!

Ich kann die Probleme der Softwareentwickler durchaus nachvollziehen, es sind aber oft die kleinen Dinge, die einen einfach wahnsinnig machen. (mal von echten Bugs abgesehen) 

Ein kleines Beispiel:
Wenn ich in Codesys V2 online gehen, ist das Fenster des zu debuggenden FB immer vertikal in der Mitte geteilt (Variablen/Code), der Cursor steht am Anfang der Datei. Keine Ahnung, ob das an euch oder an der Implementierung von Festo (in diesem Fall) liegt, aber allein das macht mich im Laufe der Zeit einfach irre, immer muß ich erst zum Code scrollen, die Fensterverteilung ändern. Das hat nicht mal was mit proggen zu tun, das nervt einfach nur tödlich. Vielleicht gibts ne Einstellung??? Genau die suche ich schon lange.

Das hat Siemens mit TIA noch viel konsequenter durchgezogen, unglaublich, wie unergonomisch und unhandlich das ganze Teil geworden ist. Eigentlich schade...

Mal ehrlich, wenn ich die Entwicklung betrachte, von Step5, als Siemens jahrelang an CPM festhielt, das später sogar emulierte um die Entwickungsumgebung weiternutzen zu können.
Das war zum damaligen Zeitunkt, nach Lage der Möglichkeiten sogar halbwegs ergonomisch. Was könnte man heute nicht alles verwirklichen und damit meine ich nicht, dass ich das Kästchen für den Ethernetanschluß an der SPS mit der Maus packen kann und einfach auf den Bus ziehe. Toll, super, 250Mbyte Code für so einen Scheiß, das braucht kein Mensch, aber ist nett und schön bunt. Auf das wesentliche konzentriert und dann nach und nach den Wünschen der User und der Entwicklung der Technologie gefolgt, was ist daran so schwer? Dafür bekommen die seit Jahren von mir immerhin regelmäßig 500 Ökken.

Ich verstehe auch deinen Wunsch nach härteren Fakten, aber das alles dann auch zu dokumentieren, was mit so manches Mal begegnet (neben dem eigenen Misthaufen natürlich  ), das geht dann einfach zu weit, man ist ja froh es hinter sich zu lassen.


----------



## Interface (20 Juni 2013)

Ralle schrieb:


> Ein kleines Beispiel:
> Wenn ich in Codesys V2 online gehen, ist das Fenster des zu debuggenden FB immer vertikal in der Mitte geteilt (Variablen/Code), der Cursor steht am Anfang der Datei. Keine Ahnung, ob das an euch oder an der Implementierung von Festo (in diesem Fall) liegt, aber allein das macht mich im Laufe der Zeit einfach irre, immer muß ich erst zum Code scrollen, die Fensterverteilung ändern. Das hat nicht mal was mit proggen zu tun, das nervt einfach nur tödlich. Vielleicht gibts ne Einstellung??? Genau die suche ich schon lange.


Du bist nicht alleine 
Mich stört das nicht nur im eingeloggten Zustand, sondern (bei TwinCAT 3) auch während dem Programmieren sehr.

Nachtrag:
Ich würde mir wünschen, dass dort gescrollt wird, wo sich mein Mauszeiger (nicht mein Cursor) befindet.
Es gibt aber wahrscheinlich andere, die dort scrollen wollen, wo sich der Cursor befindet, weil das die Regel ist.
Eine Lösung könnte sein, dass einstellbar ist, ob der Cursor beim Öffnen eines Elements (FB, Methode, etc.) standardmäßig im Deklarationsteil oder im Implementierungsteil gesetzt wird (egal ob eingeloggt oder ausgeloggt).
Nutzen: Für mich und vielleicht 1% der Anwender hoch, aber alle anderen wird solch ein Häkchen in den Einstellungen verwirren 

Nachtrag 2:
Ich habe es mal mit Codesys getestet und 3S ist in dieser Hinsicht Beckhoff um 10 Schritte voraus. Bei Codesys wird die Cursorposition sogar pro Element gespeichert. Auch eine gute Lösung (zumindest im ausgeloggten Zustand) 8)


----------



## hucki (20 Juni 2013)

Interface schrieb:


> Nachtrag:
> Ich würde mir wünschen, dass dort gescrollt wird, wo sich mein Mauszeiger (nicht mein Cursor) befindet.


Wenn das bei Dir nicht funktioniert, liegt das an Deinem Maustreiber, nicht an der Programmiersoftware.

Bei mir ist das Standard, das in dem Fenster gescrollt wird, in dem sich der Mauszeiger befindet. Auch egal, ob es den Focus hat oder andere Fenster zum Teil davor liegen.


----------



## Oberchefe (20 Juni 2013)

> Wenn das bei Dir nicht funktioniert, liegt das an Deinem Maustreiber, nicht an der Programmiersoftware.



dann hätte ich auf jedem PC in meiner Umgebung ein Problem mit dem Maustreiber! 
Dieses Verhalten stelle ich nur bei 3S fest, ich kann nicht glauben dass das kein 3S Problem sein soll!


----------



## hucki (20 Juni 2013)

Wenn es sonst funktioniert und nur bei 3S nicht, kann es vlt. wirklich daran liegen.
Prinzipiell ist aber der Maustreiber dafür verantwortlich, das entsprechende Fenster zu erkennen und die Scrollbefehle dorthin zu übermitteln.

Bei meinem alten PC konnte ich das sogar noch in den Mauseinstellungen auswählen. Hier auf meinem Lappi finde ich momentan allerdings keine Einstellung dazu, er macht es einfach. Und das zumindest auch bei TwinCat 2.10.


----------



## norustnotrust (21 Juni 2013)

Also ich würde mir etwas wünschen das die Erstellung der Bedienungsanleitung erleichtert sowie vernünftige Mittel zum kollaborativen Engineering + Versionkontrolle (a'la Integration in einen TFS wie's TC3 hat)


----------



## Werner29 (21 Juni 2013)

Ralle schrieb:


> Den Thread hab ich auch mitgelesen, aber es erschien mir damals schon als absolut suboptimal, dass ich zum debuggen auch noch extra Code schreiben muß und u.U. bei zu heftigem Gebrauch zu SPS zeitlich überfordere.



Der Aufwand hält sich sehr in Grenzen. Man muss das Feature halt finden. Aber bestimmte Dinge kann man aus Sicherheitsgründen nicht einfach
ohne nochmalige Aktion des Benutzers einschalten. 



Ralle schrieb:


> Und so mancher Kollege ist schon mit der Komplexität der Maschine am Rande und dann noch OOP.
> 
> Weißt du Werner, wenn das *wirklich* funktionieren würde, bitte, gerne, ich mache mit. Aber das ist Wunschdenken und geht weit an der Realität vorbei. Ich sitze vor dem PG und versuche verzweifelt einen Fehler zu suchen, der so tief in der verschachtelten, vererbten, u.U. mutierten Software vergraben ist, dass man einfach nicht die Zeit (und oft auch nicht das Wissen) hat so etwas zu suchen. Aber BMW wartet auf Teile, die bauen Autos. Was also ist mir lieber? Einfach, gerade, funktional.



Es schliesst sich nicht aus: man kann mit OOP einfach und gerade programmieren. Und man kann auch ohne OOP schlechte Programme schreiben.
Ich kann und will dich nicht bekehren, aber für viele unserer Kunden ist das mittlerweile eine wichtige Funktionalität.
Besonders in der Bibliotheksentwicklung. Man muss das schon auch richtig einsetzen. Vermutlich hast du Recht: man sollte nicht auf der Baustelle
eine unübersichtliche Vererbungshierarchie durchsteppen müssen. Aber jede Funktionalität kann missbraucht werden, mit grosser Macht kommt grosse Verantwortung.



Ralle schrieb:


> Ich kann die Probleme der Softwareentwickler durchaus nachvollziehen, es sind aber oft die kleinen Dinge, die einen einfach wahnsinnig machen. (mal von echten Bugs abgesehen)
> Ein kleines Beispiel:
> Wenn ich in Codesys V2 online gehen, ist das Fenster des zu debuggenden FB immer vertikal in der Mitte geteilt (Variablen/Code), der Cursor steht am Anfang der Datei. Keine Ahnung, ob das an euch oder an der Implementierung von Festo (in diesem Fall) liegt, aber allein das macht mich im Laufe der Zeit einfach irre, immer muß ich erst zum Code scrollen, die Fensterverteilung ändern. Das hat nicht mal was mit proggen zu tun, das nervt einfach nur tödlich. Vielleicht gibts ne Einstellung??? Genau die suche ich schon lange.



Sowas kann ich absolut verstehen. Es scheint mir aber, dass du von Festo in diesem Fall eine alte Codesys-Version bekommst.
Die Fensterverteilung sollte erhalten bleiben und die Scrollposition auch. Anders ist das allerdings wenn du eine bestimmte Instanz eines FB fürs Monitoring öffnest,
die hat nicht die Scrollposition wie der Implementationseditor.
Man kann übrigens mittlerweile auch den Balken zwischen Code und Watchwerten mit der Maus verschieben.



Ralle schrieb:


> Ich verstehe auch deinen Wunsch nach härteren Fakten, aber das alles dann auch zu dokumentieren, was mit so manches Mal begegnet (neben dem eigenen Misthaufen natürlich  ), das geht dann einfach zu weit, man ist ja froh es hinter sich zu lassen.



Die Leute verwenden hier so viel Energie und Zeit in ergebnislose Diskussionen...


----------



## Werner29 (21 Juni 2013)

Oberchefe schrieb:


> dann hätte ich auf jedem PC in meiner Umgebung ein Problem mit dem Maustreiber!
> Dieses Verhalten stelle ich nur bei 3S fest, ich kann nicht glauben dass das kein 3S Problem sein soll!



Ja das ist so: gescrollt wir das Fenster in dem sich der Focus befindet. Das ist auch das Fenster, das die Tastatureingaben
bekommt, das heisst Page up/down wirkt auf dasselbe Fenster wie am Mausrad drehen. Es gibt aber eine Menge
Programme die das so machen. Das ist nicht wirklich eine Spezialität von CODESYS.
Irgendwie muss man sich entscheiden. Du muss halt einmal klicken und dann scrollen.


----------



## Werner29 (21 Juni 2013)

norustnotrust schrieb:


> Also ich würde mir etwas wünschen das die Erstellung der Bedienungsanleitung erleichtert sowie vernünftige Mittel zum kollaborativen Engineering + Versionkontrolle (a'la Integration in einen TFS wie's TC3 hat)


Das sind wichtige Punkte, Codesys kann man übrigens mit SVN verbinden. 
http://store.codesys.com/codesys-svn.html


----------



## Perfektionist (21 Juni 2013)

ganz nebenbei: bei Siemens scrollt es bei den Querverweisen bei den nicht verwendeten Symbolen mit dem Mausrad bis heute nicht. in den normalen Querverweisen schon...


----------



## hucki (21 Juni 2013)

Werner29 schrieb:


> Ja das ist so: gescrollt wir das Fenster in dem sich der Focus befindet. Das ist auch das Fenster, das die Tastatureingaben
> bekommt, das heisst Page up/down wirkt auf dasselbe Fenster wie am Mausrad drehen.


Hab' gerade mal die V3.5 SP3 installiert und auch da kann ich unabhängig von der Cursorposition genau das Fenster mit dem Mausrad scrollen, über dem sich der Mauszeiger befindet. Und der Cursor bleibt, wo er ist.
Aber - (bis ebend) nur mit dem Scrollfeld vom Touchpad.

Mit meiner Bluetooth-Maus scrollte auch nur das aktive Fenster.
Aber dafür gibt's Abhilfe: pcwHoverWheel von PC-Welt. Eine kleine exe, gestartet und schon macht's (jetzt) auch meine Bluetooth-Maus.


----------



## bike (22 Juni 2013)

Ich stelle die Frage in den Raum:
Muss es immer komplexer werden? Dass nicht mehr der Programmierer bzw der Entwickler den Code komplett beherrschen?
Warum OOP in Maschinen und Anlagen?
Wenn im Parent in irgendeiner Konstellation eine falsche Reaktion hat, dann sind die Child betroffen und keiner weiß warum.

Meine Meinung ist, man muss die Komplexität aus den Softwaren wieder heraus bringen.

Nicht alles was möglich ist, ist auch sinnvoll.


bike


----------



## van (22 Juni 2013)

Martin Buchwitz schrieb:


> Das liegt meines Erachtens nach daran, dass der Stellenwert der Software viel zu lange unterbewertet wurde und das ist auch heute noch viel zu oft der Fall. Eine Frage stellt sich natürlich auch: Wären Anwender mehr Geld für eine bessere Software auszugeben, bzw. bei manchen Herstellern überhaupt mal Geld dafür bezahlen?




Na ja, Hardware ohne Software hat heute maximal den Wert eines Briefbeschwerer. Das sollte jedem klar sein.

Und kostenlose Software gibt es ja nicht wirklich. Entweder bezahle ich direkt für die Software oder indirekt über die Hardware bzw. Runtime.
Je nach Geschäftsmodell halt.

Hardware kosten kann ich direkt an den Kunden durchreichen, bei zusätzlichen einmaligen kosten für die Software wirds schwierig. Für eine "kleine" Parametriersoftware extra nochmal x hundert Euro ausgeben wird schwierig, für eine "große" IDE geht das schon viel einfacher.

Und am Ende gilt halt, wer nicht bezahlt darf auch nicht meckern.


----------



## van (22 Juni 2013)

Werner29 schrieb:


> Ein anderer wünscht sich mehr offene Schnittstellen: klingt gut, aber jede offene Schnittstelle ist ein Angriffspunkt, und wir müssen immer mehr
> auf Sicherheit achten, auch das lässt sich nicht immer verbinden.


Dokumentierte Schnittstellen, APIs und Dateiformate in der IDE sind jetzt ja per se noch keine Sicherheitslücke.

Und auf dem Runtime System muss man bald auch mal über Authentifizierung und Verschlüsseln nachdenken. Wobei das natürlich auf Systemen die Jahrzehnte im Einsatz sind und so gut wie nie ein Update sehen, noch eine ganz andere Nummer ist.



Werner29 schrieb:


> Ein letztes: wir sind eine Firma mit 100 Mitarbeitern, haben mehrere 100 OEM Kunden, entwickeln ein Produkt mit > 1 Mio Codezeilen


Genau, die OEMs sind eure Kunden, nicht wir Endanwender. 
Wenn ich mit dem OEM rede zuckt der mit den Schultern, können wir nichts machen 3S ist Schuld.
Wenn ich mit 3S rede verweisen die auf die OEMs.

 ok ist jetzt ein fiktives Beispiel. Du lieferst ja hier den Gegenbeweis.



Manchmal fragt man sich auch ob die Entwickler einer IDE auch nur mal 10 Minuten damit gearbeitet haben, oder einem Endanwender zugeschaut haben.


----------



## Werner29 (24 Juni 2013)

bike schrieb:


> Ich stelle die Frage in den Raum:
> Muss es immer komplexer werden? Dass nicht mehr der Programmierer bzw der Entwickler den Code komplett beherrschen?
> Warum OOP in Maschinen und Anlagen?
> bike



Und warum nicht? Gibt es denn einen wirklich nachvollziehbaren Grund, warum OOP für eine Maschine schlecht sein soll?
OOP macht nichts komplizierter. Im Gegenteil, OOP bietet Möglichkeiten um komplexe Aufgaben beherrschbar zu machen.
Man muss diese Möglichkeiten nicht nutzen, und ich verstehe auch dass es Gründe gibt, das nicht zu tun.
Es gibt in den Optionen übrigens einen Haken um alle OOP-Features auszuschalten. Ich glaube es wird niemand von CODESYS
genötigt, Features zu verwenden die er nicht haben will.
Insofern finde ich, ist das hier die falsche Diskussion, CODESYS wird nicht besser oder einfacher, wenn wir OOP rausnehmen.


----------



## Larry Laffer (24 Juni 2013)

... ich würde mir wünschen, dass an dieser Stelle die Grundsatzdiskussion "OOP - Pro und Kontra" vermieden wird - dabei kommt doch ohnehin nichts heraus. 
Wenn man für sich den Bezug dazu nicht herstellen kann dann bringt das Diskutieren darüber gar nichts.
Das ist jetzt übrigens keine Wertung der Person oder der Meinung sondern im Gegenteil eher das Verständnis derselben ...

Gruß
Larry


----------



## Ralle (24 Juni 2013)

Werner29 schrieb:


> Anders ist das allerdings wenn du eine bestimmte Instanz eines FB fürs Monitoring öffnest,
> die hat nicht die Scrollposition wie der Implementationseditor



Irgendwie hab ich alles FB und daher auch immer genau dieses Problem. 

Aber ich wollte das nicht zur Diskussion stellen, sondern nur ein Beispiel geben, wie wichtig kleine Nebendinge werden und sein können.


----------



## Martin Buchwitz (24 Juni 2013)

ducati schrieb:


> Ich brauche nicht 1000 Möglichkeiten/Protokolle wie die SPS mit der Visu kommunizieren kann, ein ordentliches reicht mir. Aber es muss ja jeder alles und jeden unterstützen.
> Gruß.



Mich wundert es ein wenig, dass es wohl nur selten gelingt eine Software so zu gestalten, dass es verschiedene Zugangsebenen gibt - je nach Ansprüchen der User. Von einer Software mit einer derartigen Herangehensweise träume ich und ich bin überzeugt, dass es machbar sein muss. Man muss sich natürlich auch immer darüber im Klaren sein: Software wächst über die Jahre zu einem Moloch heran. Ist man bereit einen echten Schnitt zu machen, dann kommt ein Sturm der Entrüstung, da man seine Funktionen nicht mehr dort findet wo sie bisher waren, auch wenn es noch so komplex war.


----------



## Martin Buchwitz (24 Juni 2013)

Werner29 schrieb:


> Ich versuche ganz eigennützig die Diskussion in eine andere Bahn zu lenken.
> Unabhängig vom speziellen Tool: wie sieht die Software eurer Träume aus?



Das war auch meine Intension. Das Problem ist: Man bleibt entweder zu oberflächlich oder geht zu sehr ins Detail - beides hilft nicht so recht weiter. Ich glaube es ist einfach sehr schwer, sich gedanklich einmal komplett von dem zu lösen, mit dem man jahrelang gearbeitet hat. Man könnte auch anders fragen: Nenne mir die 10 Punkte die dich bei der SPS-Programmierung am meisten nerven und/oder dich unnötig Zeit kosten. Dann nenne mir noch einmal 10 Punkte, die dir beim SPS-Programmieren so richtig Spaß machen.


----------



## Werner29 (24 Juni 2013)

van schrieb:


> Dokumentierte Schnittstellen, APIs und Dateiformate in der IDE sind jetzt ja per se noch keine Sicherheitslücke.



Richtig. Aber es ist eben nicht mehr so einfach mal eben eine Schnittstelle für dritte zu öffnen. Man muss die Schnittstelle
so gestalten, dass sie keine Angriffe erlaubt. Je mehr Schnittstellen es gibt, desto schwieriger wird es das alles zu kontrollieren.



van schrieb:


> Genau, die OEMs sind eure Kunden, nicht wir Endanwender.



Wir haben viele Endanwender als direkte Kunden. Aber das sind halt in der Regel grosse Maschinenbauer. Es stimmt
durchaus, dass wir mit einer bestimmten Klasse von Anwendern weniger direkten Kontakt haben. Die trifft man dann in Foren oder auch auf Messen.
Oder hier http://www.users-conference.com/



van schrieb:


> Wenn ich mit dem OEM rede zuckt der mit den Schultern, können wir nichts machen 3S ist Schuld.
> Wenn ich mit 3S rede verweisen die auf die OEMs.



Auf meiner Seite fühlt sich das anders an...
Der Endkunde tritt den OEM, und der OEM tritt uns.



van schrieb:


> Manchmal fragt man sich auch ob die Entwickler einer IDE auch nur mal 10 Minuten damit gearbeitet haben, oder einem Endanwender zugeschaut haben.


Natürlich arbeite ich den ganzen Tag mit unserem eigenen Tool. Aber ich mache damit andere Dinge als ein normaler Anwender. Es ist auch unmöglich
die typischen Anfängerprobleme festzustellen. Ohne Anwender wird ein Tool nicht gut. 

Dadurch, dass unsere eigene Bibliothekslandschaft mit CODESYS geschrieben wird und auch IO-Treiber, Visualisierung und Softmotion viel mit CODESYS
geschrieben sind, sind wir auch selbst Anwender unseres Tools.


----------



## Perfektionist (24 Juni 2013)

Martin Buchwitz schrieb:


> Mich wundert es ein wenig, dass es wohl nur selten gelingt eine Software so zu gestalten, dass es verschiedene Zugangsebenen gibt - je nach Ansprüchen der User. Von einer Software mit einer derartigen Herangehensweise träume ich und ich bin überzeugt, dass es machbar sein muss.


Ich bin neulich an Software verzweifelt, wo es Zugangslevel gab bis ich fand, dass es sie gibt. Nach drei Jahren Pause erinnerte ich mich dann irgendwann vage...

Zum Thema wächst zum Moloch: *ACK*


----------



## ducati (24 Juni 2013)

Ralle schrieb:


> sondern nur ein Beispiel geben, wie wichtig kleine Nebendinge werden und sein können.



Jo, wenn die unausgereifte Software voreilig auf den Markt geworfen wird, bleiben teilweise viele kleine Nebendinge dauerhaft erhalten und summieren sich zum großen Frust auf.

Beispiel von Siemens: der Baustein SEL_R



> Dieser Baustein schaltet abhängig vom Wert des Eingangs K den Wert des Eingangs IN0 (K = 1) oder des Eingangs IN1 (K = 0) auf den Ausgang.



bei K=1 wird IN0 verwendet und bei K=0 IN1. Solche Dinge treiben einen zum Wahnsinn... Da fallen mir noch viel mehr ein, wo Dinge einfach invertiert intuitiv funktionieren

Gruß.


----------



## Larry Laffer (25 Juni 2013)

Martin Buchwitz schrieb:


> Mich wundert es ein wenig, dass es wohl nur selten gelingt eine Software so zu gestalten, dass es verschiedene Zugangsebenen gibt - je nach Ansprüchen der User. Von einer Software mit einer derartigen Herangehensweise träume ich und ich bin überzeugt, dass es machbar sein muss. Man muss sich natürlich auch immer darüber im Klaren sein: Software wächst über die Jahre zu einem Moloch heran. Ist man bereit einen echten Schnitt zu machen, dann kommt ein Sturm der Entrüstung, da man seine Funktionen nicht mehr dort findet wo sie bisher waren, auch wenn es noch so komplex war.



Ich glaube nicht, dass das wirklich möglich ist - ich kann es mir jedenfalls nicht wirklich vorstellen ... (denn dafür sind die Ansprüche zu unterschiedlich)

Wenn man aber dann irgendwann einmal so einen "Moloch" hat dann sollte man sich darüber im Klaren sein (und das ist m.E. das Problem der Benutzer) das die Dinge von Version zu Version der gleichen Namen behalten sollten und idealerweise im Menue-Baum ansatzweise gleich plaziert bleiben sollten.

Gruß
Larry


----------



## Werner29 (25 Juni 2013)

Martin Buchwitz schrieb:


> Mich wundert es ein wenig, dass es wohl nur selten gelingt eine Software so zu gestalten, dass es verschiedene Zugangsebenen gibt - je nach Ansprüchen der User. Von einer Software mit einer derartigen Herangehensweise träume ich und ich bin überzeugt, dass es machbar sein muss. Man muss sich natürlich auch immer darüber im Klaren sein: Software wächst über die Jahre zu einem Moloch heran. Ist man bereit einen echten Schnitt zu machen, dann kommt ein Sturm der Entrüstung, da man seine Funktionen nicht mehr dort findet wo sie bisher waren, auch wenn es noch so komplex war.



Wir versuchen das durchaus: standardmässig hat CODESYS  ein vereinfachtes Bibliothekshandling, eine vereinfachte Gerätekonfiguration, einen reduzierten Sprachumfang, einige Objekttypen
fehlen, etc. Den Einstieg macht es sicher einfacher, ob man dauerhaft mit diesen Einstellungen arbeitet, weiss ich nicht.
Man kann sich da viel vorstellen: der einzelne Programmierer hat seine Vorstellungen, sein Arbeitgeber hat Vorstellungen, der OEM hat seine Vorstellungen, 
wir haben unsere Vorstellungen, es gibt branchenbezogene Unterschiede:
Prozessindustrie, Maschinenbau, Fahrzeuge, Gebäudeautomation etc. haben unterschiedliche Anforderungen.
Das gibt eine n-dimensionale Matrix von möglichen Konfektionierungen für die (im Grunde) immer gleiche Software. Wenn man das übertreibt, dann ist das Ergebnis ein Alptraum,
für die Entwickler, für den Support, für den Test und auch für den Kunden.
Man muss auch hier wieder einen Mittelweg finden zwischen Konfektionierungen und Standardisierung. Ich persönlich bin eher dafür einen guten Standard zu setzen.


----------



## Larry Laffer (25 Juni 2013)

Werner29 schrieb:


> Ich persönlich bin eher dafür einen guten Standard zu setzen.



Das sollte eigentlich für jeden die Prämisse sein - *ACK*


----------



## Interface (19 September 2013)

*Codesys Smart Coding fügt Namespace automatisch ein*

In der Hoffnung, dass Werner29 hier noch mitliest:

In irgendeiner CoDeSys-Version wurde eingeführt, dass bei Nutzung des SmartCodings (Auto-Vervollständigung/"IntelliSense") der Bibliotheks-Namespace automatisch hinzugefügt wird, wenn es sich um ein Element aus einer Bibliothek handelt.

Ich bin davon ausgegangen, dass das ein Bug ist. Nun musste ich vom 3S-Support erfahren, dass dies ein Feature ist.

Ich hätte dafür gerne eine Erklärung. Ich vermute, dass diese Anforderung von einem Bibliotheksentwickler kommt, denn nur dort macht der intensive Einsatz von Namespaces Sinn. Die Mehrheit der Anwender dürften aber Maschinenprogrammierer sein. Als Maschinenprogrammierer muss ich dafür sorgen, dass die Maschine funktioniert und dass man das Programm einigermaßen verstehen und lesen kann.

Wenn man sich diese beiden Code-Ausschnitte anschaut, erkennt man das Problem des Maschinenprogrammierers.
Diese Farbe = GVL
Diese Farbe = FB-Instanz
Diese Farbe = Enum
Diese Farbe = Struktur-Instanz
Diese Farbe = Lib-Namespace

Ohne SmartCoding *nach *Einführung des Features bzw. mit SmartCoding *vor *Einführung des neuen Features:

```
IF ([COLOR=#008000]Cylinder1[/COLOR].[COLOR=#0000FF]Handling[/COLOR].Position = [COLOR=#FF8C00]CylinderPosition[/COLOR].BOTTOM)
THEN
  [COLOR=#008000]Cylinder1[/COLOR].[COLOR=#0000FF]Handling[/COLOR].PositionRequest := [COLOR=#FF8C00]CylinderPosition[/COLOR].TOP;
  [COLOR=#008000]Cylinder1[/COLOR].[COLOR=#0000FF]Handling[/COLOR].Timeout := [COLOR=#008000]Cylinder1[/COLOR].[COLOR=#AFEEEE]Timeout[/COLOR].Auto;
  [COLOR=#008000]Cylinder1[/COLOR].[COLOR=#0000FF]Handling[/COLOR].Start := TRUE;
END_IF

IF ([COLOR=#008000]Cylinder[B]1[/B][/COLOR].[COLOR=#0000FF]Handling[/COLOR].State = [COLOR=#FF8C00]HandlingState[/COLOR].ACTIVE) OR
   ([COLOR=#008000]Cylinder[B]2[/B][/COLOR].[COLOR=#0000FF]Handling[/COLOR].State = [COLOR=#FF8C00]HandlingState[/COLOR].ACTIVE) OR
   ([COLOR=#008000]Cylinder[B]3[/B][/COLOR].[COLOR=#0000FF]Handling[/COLOR].State = [COLOR=#FF8C00]HandlingState[/COLOR].ACTIVE)
THEN
  [COLOR=#008000]Cylinder[B]1[/B][/COLOR].[COLOR=#0000FF]HMI[/COLOR].Update();
  [COLOR=#008000]Cylinder[B]2[/B][/COLOR].[COLOR=#0000FF]HMI[/COLOR].Update();
  [COLOR=#008000]Cylinder[B]3[/B][/COLOR].[COLOR=#0000FF]HMI[/COLOR].Update();
END_IF
```

Dasselbe nun mit SmartCoding *nach *Einführung des neuen Features:

```
IF ([COLOR=#008000]Cylinder1[/COLOR].[COLOR=#0000FF]Handling[/COLOR].Position = [COLOR=#DDA0DD]AC_PneumaticCylinders[/COLOR].[COLOR=#FF8C00]CylinderPosition[/COLOR].BOTTOM)
THEN
  [COLOR=#008000]Cylinder1[/COLOR].[COLOR=#0000FF]Handling[/COLOR].PositionRequest := [COLOR=#DDA0DD]AC_PneumaticCylinders[/COLOR].[COLOR=#FF8C00]CylinderPosition[/COLOR].TOP;
  [COLOR=#008000]Cylinder1[/COLOR].[COLOR=#0000FF]Handling[/COLOR].Timeout := [COLOR=#008000]Cylinder1[/COLOR].[COLOR=#AFEEEE]Timeout[/COLOR].Auto;
  [COLOR=#008000]Cylinder1[/COLOR].[COLOR=#0000FF]Handling[/COLOR].Start := TRUE;
END_IF

IF ([COLOR=#008000]Cylinder[B]1[/B][/COLOR].[COLOR=#0000FF]Handling[/COLOR].State = [COLOR=#DDA0DD]AC_BaseSystem[/COLOR].[COLOR=#FF8C00]HandlingState[/COLOR].ACTIVE) OR
   ([COLOR=#008000]Cylinder[B]2[/B][/COLOR].[COLOR=#0000FF]Handling[/COLOR].State = [COLOR=#DDA0DD]AC_BaseSystem[/COLOR].[COLOR=#FF8C00]HandlingState[/COLOR].ACTIVE) OR
   ([COLOR=#008000]Cylinder[B]3[/B][/COLOR].[COLOR=#0000FF]Handling[/COLOR].State = [COLOR=#DDA0DD]AC_BaseSystem[/COLOR].[COLOR=#FF8C00]HandlingState[/COLOR].ACTIVE)
THEN
  [COLOR=#008000]Cylinder[B]1[/B][/COLOR].[COLOR=#0000FF]HMI[/COLOR].Update();
  [COLOR=#008000]Cylinder[B]2[/B][/COLOR].[COLOR=#0000FF]HMI[/COLOR].Update();
  [COLOR=#008000]Cylinder[B]3[/B][/COLOR].[COLOR=#0000FF]HMI[/COLOR].Update();
END_IF
```

Wie man sehen kann, nutze ich bereits die GVL- und Enum-Namen als "Mini"-Namespace. Das hat durchaus Vorteile, weil ich dann z.B. die Enum-Werte selbst einigermaßen kurz halten kann bzw. logisch strukturierte Namen habe.
Bei den Bibliotheks-Namespaces gibt es offizielle Präfixe von 3S, damit es keine firmenübergreifende Konflikte gibt. Oben habe ich einfach mal das Präfix "AC_" gewählt.

Nun arbeiten an meinem Projekt mehrere Programmierer. Die einen nutzen das SmartCoding, wodurch deren Code mit lauter Bibliotheks-Namespaces ergänzt wird. Die anderen Programmierer nutzen das SmartCoding nicht und haben den kürzen, übersichtlichen Code.
Ich nutze das SmartCoding nur teilweise - nämlich nach dem Tippen eines Punktes. Das passt super zu meinen "Mini"-Namespaces. Wenn ich bei den Enums aber keinen Bibliotheks-Namespace davor schreibe, dann bekomme ich nicht einmal mehr die Enum-Werte nach Tippen des Punktes vorgeschlagen :evil:

Dem Compiler ist es egal, wie man es schreibt - solange alles eindeutig ist. Ich habe ein recht großes Projekt (25 Bibliotheken, über 3000 Elemente) und keinen einzigen Namenskonflikt, wenn ich den Bibliotheks-Namespace weglasse. Deshalb machen die Bibliothek-Namespaces in meinem Programm einfach keinen Sinn.

Klar, wenn ein Bibliotheksersteller seine Bibliothek mit dem Attribut "qualified only" versieht, dann muss man den Bibliotheks-Namespace dazuschreiben. Und wenn sich ein Programmierer die Mühe macht, immer zuerst den Namespace einzutippen, dann soll er das auch können. *Aber den Namespace allein den Anwendern von SmartCoding aufzuzwingen, halte ich für falsch.*

Zum Glück erfindet 3S nicht alles neu, sondern schaut sich bei C# Features ab.
Auch im Bereich SmartCoding hätte 3S lieber bei C#/.NET nachschauen sollen. Dort wird nämlich der Namespace auch nicht automatisch ergänzt und im IntelliSense erscheinen nur Elemente, die im aktuellen Namespace verfügbar sind. Wenn ein Element einen anderen Namespace benötigt, dann muss ich erst den Namespace eintippen, bevor ich im IntelliSense dessen Elemente sehe. Und wenn es mehrere gleichnamige Elemente im aktuellen Namespace gibt, dann erscheint im IntelliSense ein rotes Ausrufezeichen und beim Übersetzen ein Fehler, dass das Element nicht eindeutig ist und man ggf. den Namespace davor schreiben muss. *Das ist bei CoDeSys korrekterweise auch der Fall - nur das SmartCoding geht in eine andere Richtung.*

So viel Text wie ich hier geschrieben habe, so sehr stört mich dieses Feature von 3S! :sb2:


----------



## Werner29 (20 September 2013)

Hallo,

Zunächst: in der nächsten Version wird es wieder so sein wie früher.
Tatsächlich war das mal ein Kundenwunsch, den wir ein bisschen zu willfährig umgesetzt haben.
Es haben sich dann einige Leute beschwert und jetzt bauen wir das wieder zurück (Version 3.5 SP 4), und man kann sich das per Option
wieder einschalten.

Das Problem ist natürlich: ein Bezeichner kann zum einen uneindeutig sein, z.B: wenn dieselbe POU in mehreren Libs vorkommt.
Oder derselbe Typ "ERROR". Das ist weniger schlimm, weil der Compiler das anmeckert.
Aber ein Bezeichner kann auch einen anderen Bezeichner verschatten, z.B: wenn im Projekt ein Typ ERROR existiert,
dann verschattet der alle ERROR-Typen in den Bibliotheken.
Es kann dann entweder zu seltsamen Fehlermeldungen kommen, oder schlimmer, zu unerwartetem Verhalten.
Und noch schlimmer: das kann natürlich erst im nachhinein passieren: durch definieren eines lokalen Typs CylinderPosition,
verwendet der obige Code auf einmal einen anderen Typ und man bekommt es nicht mit.

Daher ist es erstmal sicherer, alles immer vollqualifiziert zu schreiben. 

Ich kann es jetzt nicht mehr rekonstruieren, vermutlich war es so: es gab in einem Projekt einen Fehler, weil jemand unqualifiziert
danebengegriffen hat. Dann beschwert sich jemand: wenn euer Intellisense das so anbietet, dann darf das doch keinen Fehler produzieren.
Dann machen wir die Funktion halt "sicher". Damit macht man ja scheinbar nichts falsch.

Bernhard


----------



## Interface (20 September 2013)

Werner29 schrieb:


> Ich kann es jetzt nicht mehr rekonstruieren, vermutlich war es so: es gab in einem Projekt einen Fehler, weil jemand unqualifiziert
> danebengegriffen hat. Dann beschwert sich jemand: wenn euer Intellisense das so anbietet, dann darf das doch keinen Fehler produzieren.
> Dann machen wir die Funktion halt "sicher". Damit macht man ja scheinbar nichts falsch.


Vielen Dank für die Erklärung, mit der ich dieses Feature besser nachvollziehen kann und es nicht mehr als Bug ansehe.

Prinzipiell ist es das gleiche Problem mit lokalen und globalen Variablen. Ich kann in einem FB eine lokale Variable deklarieren, die genauso heißt wie eine globale. Deshalb schreibe ich immer die GVL davor. Insofern ist es tatsächlich richtig, wenn der Lib-Namespace auch dazugeschrieben wird.

Das eigentliche Problem ist, dass es in der SPS keine using-Direktive gibt. In C# ist der Namespace auch Pflicht, es sei denn man nutzt die using-Direktive. Da man in der SPS den Namespace von Libs nicht angeben muss, kann man das so interpretieren, dass von allen eingebundenen Bibliotheken automatisch die Direktive "using [Lib-Namespace]" zur Applikation hinzugefügt wird (man sieht es nur nirgends). Wenn man sich an C# orientiert, bedeutet das wiederum, dass man bei einem Typ (Enum, Struktur, POU), den es sowohl in der Applikation als auch in einer eingebundenen Bibliothek gibt, immer den Namespace (einer Bibliothek oder der Applikation) davor schreiben muss - ansonsten muss der Compiler einen Fehler melden. Dadurch entsteht der von Werner29 beschriebene Fehler weder bei SmartCoding-Nutzern, noch bei den reinen Tippern ohne SmartCoding (die vom aktuellen Feature der Namespace-Ergänzung gar nichts mitbekommen haben). Im IntelliSense erscheint der Typ idealerweise dann auch als Vorwarnung mit einem roten Ausrufezeichen (denn es gibt diesen Typ in zwei Namespaces: Bibliothek und Applikation, oder 2x Bibliothek).

Das heißt, es fehlt in CoDeSys eigentlich ein Namespace für die Applikation, oder nicht?

Falls sich das nicht realisieren lässt, ist die deaktivierbare Namespace-Ergänzung akzeptabel. Wie in den Beiträgen zuvor aber schon angemerkt wurde, bedeutet jede Option eine Komplexität mehr. Diese Option sollte außerdem projektspezifisch sein und nicht PC-spezifisch. Ansonsten könnte sich ein Programm auf unterschiedlichen Entwicklungsrechnern anders verhalten.


----------



## Werner29 (20 September 2013)

Interface schrieb:


> Das eigentliche Problem ist, dass es in der SPS keine using-Direktive gibt.


Nein die gibt es nicht. Könnte man natürlich machen. Im Moment ist es so, dass eine Lib selbst festlegen kann, ob man auf ihren Inhalt nur
qualifiziert zugreifen darf und viele Bibliotheken machen das so.
Das ganze ist halt auch gewachsen. Ursprünglich gab es keine Namespaces, dann liessen sich aber Zweideutigkeiten gar nicht auflösen.


Interface schrieb:


> Das heißt, es fehlt in CoDeSys eigentlich ein Namespace für die Applikation, oder nicht?


Natürlich definiert die Applikation implizit auch einen Namensraum, man kann diesem Namensraum halt keinen Namen geben.
Zweideutige Namen werden wie gesagt vom Compiler angemeckert. Verschattungen sind allerdings für den Compiler OK 
wenn auch manchmal für den Programmierer unerwartet.
Das ist nicht viel anders wie in C#. Wenn man in C# einen Namensraum mit #using importiert, dann kann es durch Verschattung
auch Probleme geben. 


Interface schrieb:


> Falls sich das nicht realisieren lässt, ist die deaktivierbare Namespace-Ergänzung akzeptabel. Wie in den Beiträgen zuvor aber schon angemerkt wurde, bedeutet jede Option eine Komplexität mehr. Diese Option sollte außerdem projektspezifisch sein und nicht PC-spezifisch. Ansonsten könnte sich ein Programm auf unterschiedlichen Entwicklungsrechnern anders verhalten.


Das ist keine Option an den Compiler, sondern nur für das Intellisense. Und dafür gibt es ohnehin schon mehrere Optionen, jetzt gibt es halt eine mehr.
Und da sich das an die Bedienung richtet ist es eine Arbeitsplatzoption. Das Programm verhält sich anschliessend überall gleich.


----------



## Interface (20 September 2013)

Werner29 schrieb:


> Das ist nicht viel anders wie in C#. Wenn man in C# einen Namensraum mit #using importiert, dann kann es durch Verschattung
> auch Probleme geben.


Stimmt. Codesys ist an dieser Stelle genauso gut wie C#/.NET. Die Verschattung betrifft auch nur den Applikationscode und keinen Code in Bibliotheken.
Sobald man den applikationsspezifischen Typ (z.B. ein Enum) mit dem Bibliotheks-Typ in einer Zuweisung mischt, meldet der Compiler einen Fehler. Die Meldung "Cannot convert type 'HANDLINGSTATE' to type 'HANDLINGSTATE'" ist vielleicht nicht ganz selbsterklärend, aber man kann nichts falsch machen (ok, mit Pointer geht alles, aber da ist man selbst Schuld).


----------



## Interface (16 Juni 2014)

*Geht immernoch nicht!*



Werner29 schrieb:


> Zunächst: in der nächsten Version wird es wieder so sein wie früher.
> Tatsächlich war das mal ein Kundenwunsch, den wir ein bisschen zu willfährig umgesetzt haben.
> Es haben sich dann einige Leute beschwert und jetzt bauen wir das wieder zurück (Version 3.5 SP 4), und man kann sich das per Option
> wieder einschalten.


Leider ist die Funktion entgegen der Aussage in CoDeSys 3.5 SP4 immernoch nicht verfügbar! (Edit: Soll in SP5 anscheinend richtig funktionieren, von daher *erledigt*)
Es gibt in den Einstellungen zwar eine Option, um das automatische Einfügen des Namespaces zu verhindern, aber das IntelliSense (das eigentliche Problem) funktioniert dann immernoch nicht.

Vorgehen:

In den Einstellungen bei Smart Coding das Häkchen "List components after typing a dot" aktivieren und das Häkchen "Insert with namespace" deaktivieren. 
Die Bibliothek Util (3.5.*) zum Projekt hinzufügen. 
Nun in einer ST-POU "GEN_MODE." tippen -> es erscheint kein IntelliSense. 
Wenn man stattdessen "Util.GEN_MODE." eintippt, erscheint das IntelliSense.


----------



## Pico1184 (12 Juli 2014)

Warum kuckt man sich nicht einfach die IDEs von Microsoft etc. an (Visual Studio usw) das 
sind doch erprobte Systeme, ich habe über 3 Jahre mit C# entwickelt und Visual Studio ist eine mächtige
IDE mit wahnsinnig vielen Funktionen.

Dort gibt es offene Schnittstellen um die IDE zu erweitern, bzw können dann Drittanbieter addOns dazu
anbieten. Ebenso die ganzen Programmiererleichterungen (IntelliSense etc).

Die Entwickler arbeiten doch selbst mit solchen erprobten IDEs, wieso setzt man das nicht genau so um?

Grüsse Pico


----------



## Werner29 (14 Juli 2014)

Hallo Pico,

das ist durchaus unser Anspruch. Und das sollte man CODESYS auch ansehen. Vor allem im Vergleich zu den herkömmlichen SPS-Programmiersystemen.
Aber es gibt nicht zu vernachlässigende Unterschiede:
- das Microsoft Visual Studio ist kein Remote-Debugger: Debugger und Debuggee laufen auf der gleichen Maschine 
- die codesys Runtime muss auf so gut wie allen Plattformen laufen (z.B. hat CODESYS 15 verschiedene Codegeneratoren, und läuft auf Windows, Linux, CE, VxWorks, +++)
- Microsoft braucht kein Jitterfreies Online Change
- die zyklische Abarbeitung
- Microsoft kennt keine graphischen Programmiersprachen (alle Features müssen immer für alle Editoren funktionieren).
- Ohne die Abarbeitung anzuhalten kann man im Visual praktisch gar nichts machen (kein Watch, kein Editieren etc.),
auf der SPS ist das aber notwendig. Versuch mal einem normalen PC-Programmierer den Sinn von Flow Control zu erklären.

Daneben hat 3S natürlich nur einen Bruchteil der Entwickler von Microsoft zur Verfügung. Und die müssen neben dem eigentlichen Programmiersystem
auch Visualisierung, IO-Konfigurationen, Motion, Safety etc. stemmen.

Aber anders gefragt, welche Features aus dem Visual Studio fehlen in CODESYS?


----------



## MasterOhh (14 Juli 2014)

Ich arbeite selber viel und gerne mit Visual Studio. Man mag von WinzigWeich halten was man will, aber zumindest für Wald- und Wiesenprogrammierer wie mich ist das ein sehr gutes Tool.
Beckhoff ist mit TwinCAT 3 ja einen sehr cleveren Weg gegangen. Die haben sich gesagt, die ganzen tollen Funktionen die das VS bietet müssen sie nicht neu erfinden. Und das was man für die SPS-Programmierung zusätzlich braucht, haben sie als PlugIn bzw. Erweiterung eingebunden. Und es scheint zu funktionieren. Allein der Safety-Editor in TC3 ist um Welten besser als der von TC2. Die Möglichkeit Hochsprachen- und SPS Projekte zu einem Projekt zu bündeln macht die Codeverwaltung leichter. Viele der Ansätze sind aber auch ganz klar der "Automation in Science"-Schiene geschuldet. Da ein normaler Anlagenprogrammierer auch locker ohne viele der neuen Goodies auskommt.

Codesys 3 kenne ich leider nicht aus der Praxis. Ich habe mich natürlich aus reiner Neugier damit befasst (theoretisch und recht oberflächlich) und würde erstmal sagen das es ein grundsolides Entwicklungstool für Steuerungsprogramme ist, das wenig Wünsche offen lässt. Allgemein möchte ich behaupten, das sowohl Beckhoff als auch 3S der Umstieg auf die neue Generation gelungen ist. Anders als beim Marktführer, bei dem man das Gefühl besteht, dass da mehr mit dem Hintern umgrissen wurde als man mit den Händen aufgebaut hat.


----------



## Werner29 (14 Juli 2014)

Hallo,

Also ich bin durchaus ein anspruchsvoller Programmierer, ich arbeite jeden Tag mit dem Microsoft Visual C#-Editor (2010, Professional Edition) und ich bin voll zufrieden mit dem Tool.
Natürlich vergleichen wir uns damit und das Ziel ist, dem SPS-Programmierer den gleichen Komfort und die gleichen Möglichkeiten zu bieten. Zur 3.5 SP 5 wird es auch nochmal einige Features geben, mit denen wir dem Ziel näher kommen.

Beckhoff hat, anders als 3S, nicht das Problem, Plattformunabhängigkeit bieten zu müssen. Die haben - glaube ich - nur Microsoft Plattformen (XP, Windows7 / 8, CE ...).
Beckhoff bedient mit TwinCat auch keine OEM-Kunden. Deswegen können die sich in die Microsoft Umgebung leichter integrieren als wir. Wenn man den Visual kennt, dann hat
man als Anwender auch einen Vorteil, aber für die meisten SPS-Programmierer ist das nicht der Fall.

Die Integration in den Visual Editor kann für Beckhoff durchaus der richtige Weg sein, aber für uns wäre es das nicht.


----------



## bike (14 Juli 2014)

Für mich ist es der falsche Weg, eine bestimmte Entwicklungsumgebung als Standard zu nehmen.
PLC ist eine andere Welt, als Hochsprachen.
Warum soll bzw muss alles gleich geschaltet werden?
Ich finde Unterschiede gut und wenn ich VB oder C# programmiere, dann nutze ich diese Umgebungen und wenn ich an Maschinen oder Anlagen bin, dann mit den anderen.

Aber das ist wohl ein Glaubenskrieg, der kein Ergebnis bringen wird, denke ich.


bike


----------



## Werner29 (14 Juli 2014)

Na ja, ich habe ja nicht geschrieben dass wir einfach 1:1 alles nachmachen.
Dann kann man natürlich auch gleich den Visual selbst nehmen.

Aber beispielsweise werden zur nächsten Version von CODESYS die meisten Fehler bereits bei der Eingabe direkt im Editor angezeigt werden.
Das ist ein Feature das der Visual seit der Version 2010 kennt und das sinnvoll ist und das wir gerne umsetzen.
Wir werden in dieser Version auch einen Core Dump anbieten, damit kann man eine Situation auf einer Steuerung offline nachstellen,
mit allen aktuellen Variablenwerten.
Beliebige Bedingungen für Breakpoints haben wir zur Version SP 4 eingebaut. Das kennt der Visual natürlich schon immer.
Ich wüsste nicht, was daran für SPS-Programmierer schlecht sein soll. 

Wir bieten als Zusatztools statische Codeanalyse à la Lint an und demnächst einen Profiler. Natürlich muss das alles angepasst sein auf SPS-Programmierung.

Ich will damit eigentlich nur gesagt haben, dass die Hochsprachen-Entwicklungsumgebungen für uns mehr Inspiration liefern als die Konkurrenz der SPS-Programmiersysteme.


----------



## bike (14 Juli 2014)

Werner29 schrieb:


> Ich will damit eigentlich nur gesagt haben, dass die Hochsprachen-Entwicklungsumgebungen für uns mehr Inspiration liefern als die Konkurrenz der SPS-Programmiersysteme.



Vermutlich habe ich mich nicht ganz klar ausgedrückt.
Mir, wenn ich entwickle, ist es völlig egal, wie die Umgebung aufgebaut ist. 
Bei Step 7 schreibe ich oft mit einem dummen Editor Quellen. 

Mit dem Anpassen an angebliche Standards werden beim Endkunden die Instandhalter überfordert, da viel zu viel an Funktionen angeboten wird.  
So zum Beispiel das Speichern auch bei Fehlern ist für mich notwendig.  
Gerade bei einer IBN, wenn die Kiste schon läuft und man nebenbei weiter schreibt und dann einen Fehler suchen muss.   

Es ist klar, CODESYS ist ein anderes, eigenständiges Produkt. 
Ob es gut ist, so weit von den Funktionen von anderen Systemen zu sein sei dahingestellt.   


bike


----------



## Werner29 (15 Juli 2014)

bike schrieb:


> So zum Beispiel das Speichern auch bei Fehlern ist für mich notwendig.



Kennst du CODESYS?



bike schrieb:


> Ob es gut ist, so weit von den Funktionen von anderen Systemen zu sein sei dahingestellt.



CODESYS ist jedenfalls das einzige System dass es geschafft hat, als Konkurrenz zu den proprietären Programmiersystemen
wahrgenommen zu werden. Ich denke der Erfolg gibt uns recht.


----------



## MasterOhh (15 Juli 2014)

Um ehrlich zu sein, es ist mir sch... egal wie gut irgend ein Instandhalter ein Entwicklungstool bedienen kann. Es soll mich als Programmierer optimal dabei unterstützen ein Programm zu erstellen, Punkt. Je besser das läuft, um so mehr Zeit habe ich die Funktionen eines Programms zu testen. Damit sinkt die potentielle Fehlerquote und auch die Wahrscheinlichkeit, dass überhaupt ein Instandhalter Zugriff auf die Steuerung benötigt.

Als Kompromiss gibt es bei vielen Entwicklungumgebungen die Option die Darstellung anzupassen (Einfach - Normal - Experte).


----------



## bike (15 Juli 2014)

Werner29 schrieb:


> Kennst du CODESYS?



Kann man Beckoff mit Step7 Programmieren?

Ich kenne es und habe schon einiges damit programmiert.

Wegen dem "Speichern bei Fehler" war der Hinweis, dass in der nächsten Version eine Eingabeprüfung wie bei M$ kommen soll.
Warum wird M$ als Maßstab genommen? Nur weil es Win$ gibt? 
Also ich arbeite gern und viel mit Eclipse, auch ohne M$ features

Warum ist die Verbreitung von CODESSYS im Anlagen- und Maschinenbau ist nicht wirklich groß?

Aber um das abzugrenzen:
Ich habe absolut nichts gegen neue und / oder alternative Technologien.
Die Erfahrung von uns zeigt jedoch, dass die Entwicklung sich immer weiter von der Praxis entfernt.
Es wird nicht einfacher, sondern es wird, vermutlich auch gewollt, immer schwerer Maschinen und mit Maschinen zu produzieren.
Dieses ganze ist ein Glaubenskrieg, der Eine verkauft geistiges, der Andere etwas zum anfassen.

Und die Aussage, mir ist egal wie der Endkunde mit dem Produkt umgehen kann finde ich echt bescheiden.
Denn wir produzieren für unser Kunden, damit die gut und sinnvoll produzieren können.


bike


----------



## Werner29 (15 Juli 2014)

bike schrieb:


> Wegen dem "Speichern bei Fehler" war der Hinweis, dass in der nächsten Version eine Eingabeprüfung wie bei M$ kommen soll.


Speichern mit Fehler geht natürlich beim Visual ebenso wie bei CODESYS. Deswegen wundert mich die Bemerkung.


bike schrieb:


> Warum wird M$ als Maßstab genommen? Nur weil es Win$ gibt?
> Also ich arbeite gern und viel mit Eclipse, auch ohne M$ features


Eclipse kenne ich nicht so gut, nur deswegen. Aber natürlich ist das auch eine Umgebung, die wir uns anschauen.


bike schrieb:


> Warum ist die Verbreitung von CODESSYS im Anlagen- und Maschinenbau ist nicht wirklich groß?


Woher hast du deine Zahlen? 

Es wurden bisher mehr als 3 Millionen Gerätelizenzen weltweit verkauft, also Geräte die mit Codesys programmiert wurden.
Den Anteil im Maschinenbau kann ich dir nicht nennen. Ich würde mindestens die Hälfte schätzen. Vom Maschinenbau kommen wir
und da haben wir die meisten Kunden. Im Anlagenbau sind wir tatsächlich nicht sehr stark.

Hier findest du eine Auswahl:
http://de.codesys.com/applications/factory-automation/browse/3.html



bike schrieb:


> Und die Aussage, mir ist egal wie der Endkunde mit dem Produkt umgehen kann finde ich echt bescheiden.
> Denn wir produzieren für unser Kunden, damit die gut und sinnvoll produzieren können.



So soll es ja auch sein. Aber ich denke es kommt auf die Applikation an. Ich kann mir beim besten Willen nicht vorstellen, was der Kunde einer
Spritzgussmaschine oder einer Druckmaschine mit dem Quellcode anfangen will. Ich ändere ja auch nicht mal eben die Quellen zu WORD.


----------



## Gerhard Bäurle (15 Juli 2014)

bike schrieb:


> ...
> Mit dem Anpassen an angebliche Standards werden beim Endkunden die Instandhalter überfordert, da viel zu viel an Funktionen angeboten wird.
> So zum Beispiel das Speichern auch bei Fehlern ist für mich notwendig.
> Gerade bei einer IBN, wenn die Kiste schon läuft und man nebenbei weiter schreibt und dann einen Fehler suchen muss.
> ...



War nicht die Instandhaltung (mit) der Auslöser für die Standardisierung?

Anfangs der 90er hatte jeder Steuerungshersteller, Siemens, KlöMö, 
Saia, AB, Modicon, TI, Selectron ... ihre eigene Entwicklungssoftware.

Nicht mal die einzelnen Hersteller waren damals immer mit sich selbst 
kompatibel, "herstellerübergreifend", gab es das Wort damals schon?

Wenn der Betrieb eine gewisse Systemvielfalt hatte, waren die 
Instandhalter schon mal mehr mit ihren Tools beschäftigt, als mit 
ihrer eigentlichen Aufgabe.

Meine Meinung: Standardisierung ist nicht nur hilfreich, sie ist
essentiell.


----------



## MasterOhh (15 Juli 2014)

bike schrieb:


> [*Schnipp*]
> Und die Aussage, mir ist egal wie der Endkunde mit dem Produkt umgehen kann finde ich echt bescheiden.
> Denn wir produzieren für unser Kunden, damit die gut und sinnvoll produzieren können.



Eine Anlage die es dem Kunden abnötigt im Quellcode herum zu wursteln lässt sich für mich nicht mit den Attributen "gut" und "sinnvoll" in Einklang bringen.

Wie der Endkunde mit dem von mir gelieferten Produkt umgehen kann ist mir alles andere als egal. Die Liste mit Punkten die wir zu erfüllen haben um eine funktionstüchtige und gut zu bedienende Anlage zu liefern ist ellenlang. Aber die Auswahl des Programmiertools danach zu gestalten was den Leuten vor Ort evtl. am besten gefallen könnte, ist darauf nicht zu finden. 
Wenn ein Kunde der Meinung ist, unbedingt mit Programm XY auf die Steuerung zugreifen zu müssen, dann soll er es in das Lastenheft schreiben. 
Ansonsten arbeiten wir mit der Entwicklungsumgebung die uns am besten in den Kram passt.


----------

