SPS Programmiersprachen

"Frank Buss" schrieb im Newsbeitrag news:kj9dkqowiaib.1fnaubdagaxx8$. snipped-for-privacy@40tude.net...

Wenn, dann musst du alle SPS "Sprachen" anbieten. Allerdings nicht auf dem DAQ-Modul selbst, sodern auf dem PC, der dann das SPS-Programm zum DAQ uebertraegt (und dabei beliebig kompilieren kann).

Mit SPS spricht man SPS Leute an, mit BASIC eben Programmierer, wobei das BASIC ereignisgesteurt sein sollte ("on timer", "on interrupt") und Prozessprioritaten unterstuetzen muss (zumindest Hauptprogramm, Interruptroutine), sonst ist es wenig geeignet.

Auch hier gilt: Der PC muss das BASIC verstehen, das DAQ-Modul nur das vom PC uebertragene (und das kann kompilierter Maschinencode sein).

--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.

Kann man nicht auch nur eine Sprache implementieren? Die haben aber eine gemeinsame Basis, z.B. Datentypen usw., sodaß es nicht schwierig ist, wenn man die Basis implementiert hat, darauf aufbauend dann verschiedene Sprachen zu implementieren.

Ja, so hatte ich mir das auch gedacht. Vielleicht in einen Bytecode übersetzen, damit man es leichter portieren und debuggen kann, wobei zeitkritisches dann direkt in Assembler implementiert werden könnte.

Ich denke Programmierer würden auch mit Structured Text zurechtkommen. Sehr interessant finde ich die gute Mischung aus speziellen Hardwareaspekten, wie Flipflops und herkömmlicher serieller Programmierung. Damit müsste es eigentlich viele Leute ansprechen: Diejenigen, die normalerweise nur Hardware machen und Programmierer. Für den typischen Visual Basic Programmierer könnte man ja noch als sechste Sprache einen Basic-Compiler für den Bytecode schreiben.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Gut, dann zeichne ich mal hier ein Bild, was nach meinem Daf=FCrhalten optimal w=E4re. Abstriche werden wohl aufgrund des Aufwandes zu machen sein.=20

Zun=E4chst einmal sind SPS Programmierer, die sich dazu bekennen, verh=E4ltnism=E4ssig selten aktiv im Internet anzutreffen, obwohl davon Heerscharen existieren. Auch von Herstellerseite bem=FCht man sich, Informationen m=F6glichst kryptisch zu halten. Denn hier er=F6ffnet sich vorzugsweise Siemens als dominierendem Marktf=FChrer (und somit vermutlich bei einer Normierung tonangebend) als auch den Kammern und sonstigen Bildungseinrichtungen ein =E4u=DFerst lukrativer Markt f=FCr =46ortbildungskurse, der eine sichere Einnahmequelle bietet. Z.B. eine Einf=FChrung in das Programmieren in graphischer Funktionsdarstellung ist kaum unter einem halben Tausender zu bekommen.=20

Ergo sehe ich kaum eine M=F6glichkeit, sich einen halbwegs objektiven Eindruck zu verschaffen. Und genau deswegen ist es nicht m=F6glich, diese Informationen in einen Wikipedia Artikel zu schreiben. Man kann sie kaum belegen.=20

Ich habe AWL mehr als idealistes, denn als eintr=E4gliches Projekt mal recht g=FCnstig an einer VHS angeboten. Der Zulauf war gut und musste begrenzt werden. Ein Problem war die Hardware. Ich musste mich um Alles insbesondere um das Bereitstellen der Hardware als auch das Ersetzen defekter Teile (ebay) selbst k=FCmmern. Das Niveau der Teilnehmer war unglaublich verschieden. Obwohl ich manchmal mit einzelnen Leuten noch bis zu einer Stunde nach offiziellem Schluss zusammensa=DF, waren alle diese Probleme kaum unter einen Hut zu bekommen, was mich letztendlich zu einer Aufgabe des Projektes bewogen hat. Die bessere L=F6sung wird daher diese sein: =20

warum nicht auf gr=F6=DFeren? 8-bitter sind wegen der geringer werdenden St=FCckzahlen kaum mehr billiger, mitunter sogar schon teurer als

16-bitter. Als Beispiel sei hier der Microchip Onlineshop genannt, da ich dort das Preisgef=FCge kenne:=20

Wenn man ersthaft versucht, SPS in Microccontrollern zu implementieren, so sollte IMHO bei den Anfangs=FCberlegungen neben der =46rage nach der Wahl der Sprache insbesondere die nach den Inline-Debuggingm=F6glichkeiten (also SPS in der Anwendung eingebaut) gestellt werden. Genau die sind es n=E4mlich, die der SPS zum Siegeszug in der Automation verholfen haben. Dies ist ein Feature, das bei den Microcontrollern erst sp=E4ter kam. Bei der SPS werden in Realtime und ohne das Setzen von Breakpoints s=E4mtliche Variablen auf Kosten einer verl=E4ngerten Zykluszeit im Programmtext eingeblendet. Hier stellt sich nat=FCrlich die Frage, ob beispielsweise eine Zeigerstruktur sinnvoll so darstellbar w=E4re. IMHO w=E4re das nur dann m=F6glich, wenn es sich um = eine festumrissenes Objekt, wie zum Beispiel einer verkettete Liste handelt, die z.B. als Baustein mit spezieller graphischer Debugdarstellung implementiert sein k=F6nnte. Schwierig d=FCfte es = dennoch bleiben. Genau diese =DCberlegungen sind sicher dabei angestellt worden, als man den Sprachumfang der SPS Sprachen bestimmte.=20

=DCblich ist es auch, s=E4mtliche Werte der Ports geschlossen darstellen und Inline vorgeben zu k=F6nnen, um beispielsweise die dranh=E4ngende Elektronik und Mechanik testen zu k=F6nnen.=20

Unverzichtbar ist nat=FCrlich bei der SPS die Boolean Variable, die dort hardwarem=E4ssig als soche implemtiert ist, w=E4hrend das bei Microcontrollern nicht zwangsweise so sein muss. =20

Bei vielen Herstellern kann man, egal in welcher Sprache das Programm geschrieben wurde, dieses in jeder anderen, also auch im Kontaktplan oder in der grafischen Funktionsdarstellung aufrufen. Hierdurch kann jeder bei Einsicht ins Programm diejenige M=F6glichkeit w=E4hlen, die er beherrscht. Allerdings ist diese =DCbersetzung teilweise sehr schlecht zu verstehen, da die Anwendungsprozess-Orientiertheit, die beim Schreiben des Programmes in aller Regel die Leitlinie ist, dabei zumindest teiweise verlorengeht. Bei aufwendigen Maschinen ist das Programm daher nur in der Quellsprache wirklich verstehbar. =20

Sch=F6n w=E4r es nat=FCrlich, wenn man das Ganze dann auch auf dem PC = ohne Hardware SPS durch Vorgabe der Eing=E4nge und Darstellung der Ausg=E4nge als LED, Zahlanzeige, (freilaufendes) Oszilloskop etc. emulierend debuggen k=F6nnte.

der

gibt,

Das Konzept scheint nicht schlecht, da es alle Mittel einer Hochsprache bietet, die dann auch noch inline-debugbar bleiben, ist aber IMHO weniger verbreitet. Das IMHO ist hier wirklich wichtig, denn objektive und verl=E4=DFliche Infos sind hierzu kaum ermittelbar.=20

Bei den "echten" Programmierern scheint in Richtung Automatisierung jeder sein eigenes S=FCppchen zu kochen und eigene Umgebungen zu backen.

bauen,

laufen

Die Frage ist, ob Du damit Kohle verdienen m=F6chtest, oder ob Du die SPS Sprache be"frei"en m=F6chtest. Ein Konzept in Funktionsdarstellung auf Basis des Eagle Schaltplaneditors wurde von Elektor ver=F6ffentlicht. Das Ganze ist als fertig in den Controller gebrannte und ansonsten unzug=E4ngliche Firmware (von Deinem Namensbruder) zu kaufen:

Dies hat nat=FCrlich aus Anwendersicht den Nachteil, dass das Konzept nicht einmal auf anderen Controllern desselben Herstellers laufen w=FCrde. Ein be"freie"endes Konzept w=FCrde eventuell Schnittstellen beinhalten, in man z.B. die Portbezeichnung oder eine Routine f=FCr eine AD Wandlung getrennt nach Initialisierung, Interrupt und Mainloop selbst anpassen k=F6nnte. Hierbei k=F6nnten dann beispielsweise bei Anwendern vorhandene Routinen oder Libraries genutzt werden. Dies w=E4re analog zu dem Prozess, den man nutzt, um die GUI von Programmen in verschiedene Weltsprachen zu =FCbersetzen. =20

Ganz besonderes Augenmerk sollte dabei dem in einem anderen Thread schon ausf=FChrlich besprochenen Konzept der parallelen Delayerzeugung geschenkt werden, der als Grundlage f=FCr mehrere Bausteine z.B. der Timerbausteine bereitgestellt werden m=FCsste.

w=E4re

ST bietet wie gehabt vermutlich dasjenige, was mit den Mitteln einer SPS auch debugbar bleibt. Basic hingegen ist (noch vor C) IMHO und vermutlich unter denjenigen SPS Programmierern, die eine Hochsprache beherrschen, die verbreitetste.=20

Mit kleineren meinte ich auch schon moderne 32-Bit Systeme, z.B. mit Cortex-M3 Core, was man schon für Bei der SPS werden in Realtime und

Die Datenübertragung stelle ich mir nicht allzu schwierig vor, USB wäre da schnell genug. Aber ich kann mir nicht ganz vorstellen, wie so eine Oberfläche aussehen könnte. Bei einigen Variablen würde man nichts mehr erkennen können, wenn die in Realtime aktualisiert werden.

Da muß ich mir mal die Norm genauer ansehen. Generell macht es aber wahrscheinlich bei größeren Programmen ohnehin keinen Sinn, alle Variablen anzeigen zu wollen, sondern ein Watch- und Locales-Fenster sollten ausreichen.

Vom ästhetischen Programmiererstandpunkt aus gesehen wäre es schön, wenn man das ganze System in der Sprache die es implementiert auch selbst implementiert, was bei Computersprachen üblich ist. Der (erfahrene) Anwender könnte dann auch das System selber erweitern und z.B. ganz neue Debuggingmöglichkeiten hinzuprogrammieren. Müsste ich mir mal anschauen, ob das mit den SPS-Sprachen praktikabel ist, oder man besser auf was anderes, wie .NET ausweicht.

Ja, das hatte ich auch gedacht. Mache ich bei meinen bisherigen Projekten immer so, z.B. die Hardware durch ein kleines Windows-Programm simulieren und über eine abstrakte Hardwareschicht, die einmal einen I2C-Bus für LCD auf dem Zielsystem ansteuert und zum anderen in der Emulation durch Windows GDI-Funktionen implementiert ist.

Befreien :-)

Interessantes Konzept, Eagle als Eingabemedium zu verwenden. Ich könnte mir aber vorstellen, daß durch die fehlende Darstellung der Schaltung längere Turnaround-Zeiten und das Debugging umständlicher wird (zumindest habe ich den Eindruck beim ersten Überfliegen der Screenshots, daß der Funktionsplan selbst nicht im Programm dargestellt wird). Eagle ist auch nicht unbedingt das Maß aller Dinge, wenn es um Komfort bei der Eingabe geht.

Ich könnte mir vorstellen, daß alles gut debuggbar bleibt. Die Sprachen würde ich zu einem Bytecode übersetzen und auf PC-Seite würde die Verknüfung hergestellt, wo das Programm sich gerade auf Source-Code Seite befindet. Großartige Optimierungen würde ich nicht einbauen, bei den STM32-Prozessoren mit 72MHz wäre das für die meisten Anwendungen nicht nötig, was Entwicklung, Debugging, Sicherheit usw. erhöht.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Lieber Frank!

Ich habe leider zu wenig Zeit hier mehr zu schreiben, daher meine Meinung in kurzen Worten: (Ich arbeite seit mehr als 20 Jahre im Steuerungsbereich und habe auch eigene Steuerungen auf den Markt gebracht, dies aber nur zur Info. Bei den erw=E4hnten Firmen bin ich nicht beteiligt oder besch=E4ftigt.)

-) IEC 1131 oder DIN 61131 sind die richtigen Normen (DIN 61131 ist die aktuelle).

-) Wenn du etwas machen willst, dann halte dich an diese Normen, alles andere bringt keinen kommerziellen Erfolg.

-) Pers=F6nlich w=FCrde ich die Finger von so einem Projekt lassen, man(n) l=E4sst einfach zu viele Haare (meine fangen erst ab den Ohren an :-)

-) Schaue dir auf einer Fachmesse den Mitbewerb zu deiner Idee an.

-) Fast alle gro=DFen Hersteller (ich wollte nicht alle sagen) verwenden, in Teilprojekten oder vollst=E4ndig, CodeSys von 3S (www.3s- software.com).

-) Als uC geht nur eine Type mit Speed, alles andere will man nicht mehr. Der Cortex ist in Ordnung.

Herzliche Gr=FC=DFe Peter

Erstmal sollte es nur ein kleines System sein, um mal ein wenig Erfahrung in diesem Bereich zu sammeln. An verkaufen hatte ich nicht gedacht. Software quelltextoffen und frei unter einer nicht-viralen Lizenz wie BSD (GPL dagegen wäre z.B. viral) und vielleicht über eine andere Firma das Gerät dazu, wer es nicht nachbauen kann oder will. Anwendungsgebiete wären z.B. Aquariums Heizungs/Licht/Fütterungssteuerung, Modelleisenbahn, bis hin zur Steuerung kleiner Machinen (Waschmaschine, Kesselsteuerung einer kleinen Brauerei). Nicht angedacht ist die Produktionsstraße einer Autofabrik o.ä. Also eher als kleines Hobbyprojekt, aber schon mit dem Anspruch, nicht irgendwas selbst zu stricken, sondern etwas allgemein verwendbares und auf Standards aufbauendes zu bauen. Ich hoffe dann davon nicht allzuviel mehr graue Haare zu bekommen :-)

Danke, CodeSys sieht interessant aus. Da steckt bestimmt mehr als meine geplante Zeit von einem Jahr an Arbeit drin. Interessantes Geschäftsmodell. Das wäre vielleicht etwas was ich entwickeln könnte, wenn ich genügend Erfahrung mit dem ersten Projekt gesammelt habe.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

"Oberflächlich betrachtet" stelle ich mir da einen Logicanalyzer vor, der auf Triggerbedingung hin die Ereignisse speichert und dann in Ruhe anschauen läßt. Nachdem erst mal 20t Granulat neben der Spritzgußmschine liegen hat man ja Zeit;-)

Was ich so von normalen Debuggern her kenne ist die Dereferenzierung von Pointern nicht eben trivial. Wenn man das ernsthaft will, kommt man wahrscheinlich nicht um sowas wie den managed Code von .net herum. Dann ist aber selbst ein "int" nicht mehr einfach nur eine Speicherzelle. Und die Laufzeit...

Auch dort wollen komplexe Strukturen angemessen dargestellt werden oder unverständlich bleiben.

Was mir bisher persönlich als SPS begegnet ist, war alles andere als komplex. Das sind Baugrruppen, die die ehemaligen Waschmaschinensteuerungen aus Zahnrädern und Relais emulieren. Nach "1 Umdrehung" hast du die Funktion bewiesen und Sonderfälle sind auch schnell abgehandelt.

Diese einfache, nicht abstürzen könnende Struktur war es jeweils, die mich bewogen haben, das einzusetzen.

Willst Du Hardware, die mit M¤ in den Büchern steht, einem Prozessor aussetzen, der sich zu 90% um das Userinterface kümmert? Ich bekomme dabei Bauchschmerzen.

Aha, Du träumst von BusSPS. So ähnllich wie LinuX: Angefangen aus Neugier, weiterentwickelt von Enthusiasten, eingesetzt von verwegenen "Auskennern". Bei Linux geht es zunächst mal um reine Software. Da geht nicht viel kaputt. Und ein Apache unter Linux kann lange ausgiebig kosten- und folgenlos getestet werden.

Findest Du solche Leute auch unter den Automatisierungstechnikern? Gut, man könnte mit kleinen Projekten, wie der Umluft-Kellerentfeuchtung anfangen. Aber dann ist große Komplexizität wieder obsolet.

Paul, mal ehrlich: Wie schätzt Du Deine Kollegen ein?

--
Gruß, Raimund
Mein Pfotoalbum 
Mail ohne Anhang an  wird gelesen. Im Impressum der Homepage
findet sich immer eine länger gültige Adresse.

Ja, das wäre eine gute Idee. Heutzutage haben die PCs ja genügend Speicher, sodaß man im Prinzip deterministisch die gesamte Steuerung simulieren kann, wenn man alle Eingangswerte im Zeitraster der SPS aufzeichnen kann. Könnte man sogar eine Scrollleiste nehmen und in der Zeit beliebig vor und zurück scrollen oder was es sonst noch so von Logicanalysern gibt, wie Ausgangssignale als Wellenform darstellen, dann dahin scrollen und sich den Zustand der SPS zu diesem Zeitpunkt ansehen usw. Kann man bestimmt viel machen.

Wenn man in C programmiert, dann sollte man eben nicht mit void* als Datentyp arbeiten, dann kann das der Debugger auch schön auflösen :-) Bei C++ kann er es bei eingeschaltetem RTTI immer auflösen.

Ich habe mir den EN 61131-3 Standard mal was genauer angesehen und dort sind alle Variablen typisiert und es scheint keine gefährlichen Pointer-Operationen zu geben, also z.B. die Adresse einer Variablen zu ermitteln und per Cast einem anderen Pointer zuzuweisen. Gibt allerdings die Möglichkeit, für eine Variable einen festen Speicherplatz vorzugeben, wahrscheinlich auch für Arrays. Aber auch das müsste man zur Compilierzeit feststellen können, z.B. wenn zwei Variablen unterschiedlichen Typs denselben Speicherbereich haben wollen.

Sieht insgesamt recht solide aus. Wenn man sich nicht allzu dumm anstellt und es nicht allzu komplex wird, dann sollte es tatsächlich möglich sein, wenn ein Programm einmal durchgelaufen ist, daß man dann sicher sein kann, daß es immer läuft.

CodeSys scheint ein wenig in diese Richtung zu gehen. Irgendwo auf der Webseite stand, daß direkt auf der Plattform die Grafikzeichenbefehle generiert werden und dann per Java Applet im Browser oder auch einem speziellen Programm, dargestellt werden können. Wenn da eine fette CPU dahintersteckt und das System gut programmiert ist, kann man sowas auch in harter Echtzeit hinbekommen, aber für mein angedachtes System wird das wohl eher nichts sein und ich schicke besser die rohen Daten einfach raus.

Klingt gut, ich denke damit wäre schonmal ein Projektname gefunden. Vielleicht noch international BussLPC. Oder noch ein paar Buchstaben verändern, wie von Linus zu Linux: BuzzLPC. Google kennt es nicht, habe eben schonmal buzzlpc.org reserviert :-)

Lange und ausgiebig testen kann man auch ein SPS, z.B. mit Fischertechnik, Modelleisenbahn o.ä., wobei dann auch nicht viel kaputtgehen oder jemand verletzt werden kann.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

(www.3s-

Gesch=E4ftsmodell.

gen=FCgend

Wobei nach meinem pers=F6nlichen Eindruck eine Diskrepanz zwischen dem Software Angebot der Hersteller und der Nachfrage besteht. Zieht man bei der Nennungsh=E4ufigkeit in Stellenanzeigen neben den "normierten" Sprachen noch die propriet=E4ren mit ein, so war hier "Step5" und ist jetzt "Step7" oder "Siemens" die mit Abstand meistgefragteste. Alles Andere muss man schon fast wie die Stecknadel im Heuhaufen suchen. Hier zeigt sich, dass der Anwender von Normierung eigentlich recht wenig wei=DF. Hier identifiziert man eher eine Produktlinie als eine Quasi-Norm. Der Begriff CodeSys mag bei Herstellern bekannt sein, bei den Anwendern eher um so weniger, wenn man einmal von wenigen Spezialfirmen absieht.

Bei den Stellenanzeigen wird witzigerweise h=E4ufig nicht dazu geschrieben, welche der in der Step7 beinhalteten Sprachen nun gemeint ist. Nach dem, was ich so h=F6re, geht man nach wie vor wie selbstverst=E4ndlich von Funktionsplan und Anweisungsliste aus, wie schon von der Step5 bekannt. Auch bei den hier mit Siemens oder anderen SPS betriebenen Fremdprodukten habe ich nie etwas Anderes auf den Notebooks der Techniker gesehen. Es bringt halt nichts, wenn die Programme beispielsweise im "besseren" ST geschrieben sind, die Serviceleute vor Ort es aber nicht beherrschen. Denn wie schon gesagt, ist die "=DCbersetzung" zwischen den Sprachen eine etwas haarige Angelegenheit.=20

Kann CodeSys denn schon Thumb-2-Code generieren?! So wie ich es verstehe ist der Cortex ja nicht Binärkompatibel zum normalen ARM..

--
Thomas Kindler, mail@t-kindler.de

Laut Wikipedia-Artikel kann man zumindest mit Step 7 mit den im Standard

61131-3 definierten Sprachen programmieren. Wie im Detail die Entwicklungsumgebung auszusehen hat, ist sowieso nicht genormt und dann kann es sinnvoll sein in Stellenbeschreibungen nach Kenntnissen mit speziellen Implementierungen zu fragen (so wie z.B. auch C++ Programmierer mit Erfahrung in Visual Studio und MFC gesucht werden und nicht nur C++ Programmierer).

Schade, sieht eigentlich gut aus. Habe auch eben ein Open Source Projekt gefunden:

Die flash-Animation sieht vielversprechend aus, aber mit den vielen Fenstern würde mich stören. Gute Idee, Inkscape zu verwenden, was zur Bearbeitung von SVG-Dateien eingesetzt wird und dann diese damit erstellen Vektorgrafiken als Benutzerinterface zu benutzen. Noch besser wäre es aber wohl, den Editor ins Programm zu integrieren.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

w=E4re da

Zumindest bei den PICs muss eine "Verzahnung" des USB Codes mit der Anwendung stattfinden. Ich wei=DF nicht, wie das bei anderen Controllern zu handhaben ist. Es w=E4re nat=FCrlich hilfreich, wenn Deine Software = den User gegebenenfalls davon entlastet.

Zudem w=E4ren die Problematik der USB IDs abzukl=E4ren.

Hilfreich k=F6nnte in der geplanten Hardwareeinheit eine zuschaltbare optische Strecke im USB sein, um diese galvanisch vom netzbetriebenen PC/Notebook zu entkoppeln. Ich kenne da Ger=E4te, die nur am akkubetriebenen Notebook zuverl=E4ssig funktionieren. :-(

w=E4re da

mehr

In der Tat muss man hier gegebenfalls von Hand einige Zeilen einf=FCgen, um das lesbar zu gestalten. Bisweilen muss man die Variablen sogar auf Ausg=E4nge legen, um sie oszilloskopieren oder Logik-analysieren zu k=F6nnen. Besser sind nat=FCrlich, wie gehabt, entsprechende interne Werkzeuge.=20

Variablen

Die Darstellung aller Variablen ist nat=FCrlich in AWL recht gut m=F6glich, da es hier nur eine Variable pro Zeile gibt und man den Platz f=FCr diese Darstellung von vorne herein reservieren kann. Sinnvollerweise korrespondiert der Umfang des Variablenholens hier mit dem Umfang der aktuellen PC Monitordarstellung.

Wunderbar :-) Was Du da vorhast, ist bahnbrechend. Zumal wie an anderer Stelle von Dir geschrieben, Du hierf=FCr einen Zeitrahmen von einem Jahr investieren m=F6chtest. 8-)

Stimme zu, wobei dies zumindest in Teilen der Verbindung mit dem Board-Editor geschuldet sein d=FCrfte. M=F6glicherweise k=F6nnte bei der graphischen Darstellung auch Scicos hilfreich sein.=20

Mist, sehe gerade, dass die Seite nur innerhalb einer Sitzung erreichbar ist. Suche unter "Berufe" nach "SPS" und klicke dann auf "SPS Fachkraft".

Das sollte die Software auf jeden Fall. Ich würde das so programmieren, daß gar kein direkter Zugriff zum USB-Bus besteht, sondern nur ein abstrakter Kommunikationsstream zwischen der Software auf dem Gerät und auf dem PC. Im Logging-Modus wird dann sowieso alles auf dem PC simuliert und nur die Eingangsdaten weitergeleitet. Man könnte sich noch einen anderen Modus vorstellen, wo die Software auf dem Gerät gezielt Daten schickt.

Da habe ich bereits vor einiger Zeit 10 Nummern gekauft:

Das klingt ja merkwürdig. USB zu trennen könnte aufwendiger werden. Einfacher wäre es wohl, die IOs bei Bedarf per Optokoppler zu trennen. Könnte man generell in Form kleiner Platinenmodule lösen, im Falle der optischen Trennung z.B. 8 digitale Eingänge, zusätzliche Stromversorgung auf der getrennten Seite und 8 Ausgänge. Ein weiteres Modul, was bei Bedarf die galvanisch getrennte Stromversorgung aus der USB-Betriebsspannung generiert, wenn man da kein externes Netzteil haben möchte. Kann man sich dann per Klemmleiste

die gewünschte Konfiguration beliebig zusammenstellen, wobei man die einzelnen Module auf einer Basisplatte aufschraubt.

Das würde aber nur für Standalone-Betrieb gelten. Wenn man tatsächlich alle Eingangsdaten per USB überträgt und auf dem PC speichert, dann kann das dort komplett simuliert werden und man kann jeden Zeitpunkt per Scrollbar beliebig vor- und zurück anfahren und sich alle Variablen und IOs zu jedem Zeitpunkt ansehen.

Das Verfahren ist schon länger bekannt und gibt da einige Forschungen zu. Z.B. hier: "Walk Backwards to Happiness?Debugging by Time Travel":

Real gesehen habe ich es aber noch in keinem Programm. Das wäre schon interessant, sowas mal zu programmieren.

Bahnbrechend wohl nicht gerade, scheint schon ein gutes System zu geben:

Ich habe eben den Quelltext dort per CVS geladen, aber was mich stört ist, daß es unter GPL steht. Besser fände ich BSD, dann gibt es weniger Probleme, wenn man es später doch mal in eigenen Produkten verkaufen möchte.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Frank Buss schrieb:

Nicht vielleicht lieber buzzplc.org?

Gruß

Eugen

Stimmt, habe es umgemeldet. Sind ja sowieso Inklusivdomain, sodaß mein Schreibfehler also nur peinlich war, und nichts gekostet hat :-)

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

Ich habe es noch nicht ausprobiert, aber direkt oben auf der Webseite steht "Download 2008.0 Beta 2 Windows installer".

Die Webseite ist aber eine Katastrophe. Zwar schön viele bunte Bildchen, aber auch nur mal ein kleiner Satz dazu, auf welchen Betriebssystemen es alles läuft, fehlt. Nur in den beiden PDFs steht, daß es unter Windows und Linux läuft, aber keine Aussage dazu, ob es z.B. auch unter Windows 98 noch laufen würde, oder Vista und wie man welche Hardware anbinden kann, in welchen Projekten es schon eingesetzt wurde usw. Scheint mehr in Richtung Forschungsprojekt zu gehen.

Was kann man per SPS Sprache nur schwer schreiben? ST sieht mir so aus, als könnte man damit alles programmieren, was man möchte. Nur eine dynamische Speicherverwaltung vermisse ich beim vom SPS-Standard definierten System, was zusammen mit dem Fehlen von Pointern allerdings auch dazu führt, weniger Fehler machen zu können.

In anderen Bereichen funktioniert das gut. Z.B. wenn einer eine kaufmännische Software verwendet, dann muß der Anwender auch nichts von Programmiersprachen verstehen, aber der Programmierer muß Anforderungen (bei Individuallösungen) des Anwenders verstehen können und in ein Programm umsetzen können, sowie bei Supportanfragen, Probleme und Fehler im Programm zuordnen können. Wahrscheinlich ist der Markt nur zu klein bei SPS-Systemen, sodaß sich da noch keiner die Mühe gemacht hat, das anwenderfreundlich zu gestalten, oder es dann viel mehr kostet.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

mit

steht

Beremiz besteht aus vier Teilen, die alle unterschiedlichen Projekten entstammen. Und eines davon l=E4uft nur auf Linux.

kann.

als

In meinem System geht, wie im Nichtzitierten gesagt, nur AWL aber nicht ST. Und da ist das =FCber verwaltungstechnische Dinge Hinausgehende doch recht m=FChsam und un=FCbersichtlich.=20

System,

Das ist wohl auch der Grund, weswegen es fehlt. Raimund hat ja schon die Tragweite von Fehlern in Produktionsmaschinen deutlich gemacht. Wenn Du das inSystem ergonomisch debugbar hinkriegst, w=E4rest Du IMHO der Erste. Ich frage mich, ob sich da schonmal Forscher die Z=E4hne ausgebissen haben.=20

Programmierern,

von

Anforderungen

Programm

Programm

Ohne jetzt =FCberheblich sein zu wollen, w=FCrde ich den kaufm=E4nnischen Bereich aber nicht mit unserem Metier vergleichen wollen. Nur mal so als kleines Beispiel sei genannt, dass sich die Kaufleute beschweren, wenn die Techniker mit vielen Funktionen oder anderen Dingen als Papier an Ihren Kopierern herumexpirimentieren und ihnen daher im Servicefalle die Schuld am Defekt zuschieben. Oder wenn sie kopfsch=FCttelnd danebenstehen, wenn man mit einer Auswahl von "so einem kleinen Dingens" (gemeint sind Chips) so lange besch=E4ftigt sein kann. Meine Lieblingsantwort ist dann die, Ihnen die eigens hierzu ausgedruckten drei vollgepackten Ordner mit der Beschreibung eines einzigen Microcontrollers zur Einsichtname vor die Nase zu legen. Dem PDF am PC und dem Chip sieht man eben den Umfang nicht an.=20

Bei uns sind eben viele Dinge nicht so geradeaus, wie bei denen. Und im Produktionsbereich sind IMHO die Dinge noch einmal versch=E4rfter, als bei reinen Herstellern der Systeme, weil hier Bedienungsppersonal, Prozesseinbettung und Logistik weitere Zw=E4nge auferlegen. Ich kenne da beide Seiten von innen.=20

Die Komplexit=E4t geht soweit, dass man Pflichtenhefte nicht bis in letzter Konsequenz schreiben kann. W=E4re man dazu in der Lage, h=E4tte man auch schon das halbe Programm fertig. Aber in W=FCrdigung dessen ist es wohl auch f=FCr den Anwender nicht das Schlechteste, sich in die Denkweise des Programmierers hineinversetzen k=F6nnte.=20

Entsprechend sehe ich die Anspr=FCche an den Programmierer f=FCr die Anwendung Automatisation als h=F6her an, als f=FCr rein kaufm=E4nnische Anwendungen. Und da liegt m=F6glicherweise das wirkliche Problem, jemanden zu finden, der alle Anforderungen meistern kann.=20

Mit Sicherheit ist der Markt kleiner als bei kaufm=E4nnischer Software. Aber sie ist im Steuerungsbereich mit Abstand dasjenige Produkt mit den gr=F6=DFsten Marktanteilen. Davon zeugen Messen und viele Stellenanzeigen.

[...]

Der Knueller sind dann Aussagen der Vertriebler wie "In der heutigen Zeit mit den ganzen Chips duerfte das fuer Sie doch ein Kinderspiel sein" oder "Das Videospiel meines Sohnes hat aber bloss $49 gekostet". Dann fragte ich oft wieviele Millionen Geraete sie denn im nachsten Jahr in den Sales Forecast einzutragen gedenken. "Millionen? Aehm, wir dachten erstmal so an 700-800".

--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.