Sie sind nicht angemeldet.

1

Montag, 10. März 2014, 04:15

Fragen zum Projekt

Moin,

da dies das einzige Forum-Kapitel mit "Fragen" in der Überschrift ist, frage ich mal hier. Falls das woanders hin gehört, bitte ich um Verschiebung.

Mit Eagle habe ich schon mehrere Platinen erstellt. Nur diese ULPs sind für mich böhmische Dörfer, weil ich für einen PC nicht programmieren kann. Ich kann lediglich auf die in Eagle vorhandenen ULPs klicken.

Ich versuche, mir derzeit einen Überblick über die microsps zu verschaffen, bei dem sich leider viele Fragzeichen für mich auftun. Ich hoffe, dass ich das Forum jetzt mit dem ellenlangen Katalog nicht zu sehr aufmische.

Ich finde hier in Beschreibung und Forum Verlinkungen zu zwei anderen Projekten, die sich ebenfalls "microsps" nennen und beide auf der Basis von Eagle als Programm- respektive virtueller Schaltungseditor arbeiten. Die Funktionsbausteine sind ebenfalls ähnlich.
http://www.microsps.com/
http://www.cadsoft.de/mikrosps/
Die Cadsoft microsps arbeitet statt Atmel mit Microchip PIC Prozessoren. Mit letzteren habe ich schon unter C, Assembler und Parsic gearbeitet, mit ersteren noch gar nicht.
Was haben die drei microsps Projekte miteinander zu tun? Was muss ich von den anderen beiden Projekten verstehen, um das hiesige zu begreifen?

Verstehe ich es richtig, dass ich hier alle zum Betrieb der microsps nötigen Dinge bekomme - von der Software bis zur Platinenbeschreibung? Müssen neben den Bauteilen und der Platine Teile käuflich erworben werden, die exklusiv nur hier zu bekommen sind?

Das zur microsps ähnliche Programm Parsic, das grafische Funktionsbausteine für Microchip PIC Prozessoren bereitstellt, "compiliert" diese in Assembler. Dabei heißen praktischerweise die zugeordneten Register in Assembler genau so wie die Signale bzw. Funktionsbausteine in Parsic. Mithilfe der Microchip Entwicklungsumgebung MPLABX wird dann in Maschinencode übersetzt. MPLABX eröffnet auch die Möglichkeit, dem Microcontroller beim Ausführen des Assembler Programmes zuschauen und per Einzelschritt jedes interne Register bei der Programmausführung beobachten und (bitweise) zu stimulieren. Hierzu muss man lediglich zwei Pins des Microcontrollers und dessen beiden Versorgungsspannungspins sowie Reseteingang über einen Hardware-In-Circuit-Debugger mit dem PC verbinden. Damit kann ich dann auch die Programme in den Controller einspielen.
http://www.microchip.com/Developmenttool…PartNO=DV164035

Ferner kann man in Parsic die Schaltung rein auf dem PC ohne Microcontroller simulieren und stimulieren. Zum Beispiel kann man binäre Eingänge der Funktionsbausteine durch Anklicken mit der Maus auf High (Leitung wird rot) oder Low (Leitung wird blau) setzen. Die Auswirkungen für die gesamte Schaltungen werden dann angezeigt. Bei mehrbittigen Signalen wird der augenblickliche Zahlenwert angezeigt.

Gibt es äquivalente Lösungen für das Live Debuggen und Stimulieren im Microcontroller als auch auf dem PC ohne Microcontroller auch für die hiesige microsps?

Kann ich statt der microsps-Platine auch den nackten Microcontroller mit der hiesigen Software betreiben? Das würde mich in die Lage versetzen, periphere Hardware durch eigene Adaptierungen anzuschließen. Insbesondere die mechanischen Relais im Ausgang liegen mir im Magen. Da würde ich lieber MOSFETs oder Halbleiter-Relais verwenden. Kann man jeden Pin des Microcontrollers beliebig als Ein- und Ausgang benutzen?

Steht vielleicht auf der Agenda, einen Microcontroller mit mehr Pins als den AT90CAN128 zu unterstützen, so dass man mehr digitale Aus- und Eingänge zur Verfügung hätte? Oder kann das die derzeitige Software schon?

Wird auch ein 4x40 LCD Display unterstützt?

Läuft die microsps Software für den PC wie Eagle auf Windows und Linux?

Schlussendlich verstehe ich den Sinn und Zweck des Bootloaders nicht. Kann man bei einem Atmel Controller nicht direkt ein Programm einspielen, das dem Funktionsschaltplan entspricht? Warum der Umweg über den Bootloader?

Besonders interessant finde ich die im Forum genannte Zusammenarbeit mit einem Android Phone oder Tablet. Wennn ich es richtig verstehe, könnte man sämtliche Tasten, LEDs, Anzeigen, Text- und Grafikdisplays einer Steuerungsfrontplatte hierdurch ersetzen und sich damit nahezu sämtlicher damit zusammenhängenden mechanischen Probleme entledigen. Kurz gesagt: Tablett statt Frontplatte. Habe ich das so richtig verstanden?

Über die Beantwortung der Fragen würde ich mich freuen.

Grüße
Alvos

P.S.: Die Vorschau zeigte nicht an, dass Links klickbar werden. Aber glücklicherweise funktioniert es nach dem Abschicken doch. :-)

Dieser Beitrag wurde bereits 7 mal editiert, zuletzt von »Alvos« (10. März 2014, 04:38)


madcat

Fortgeschrittener

Beiträge: 64

Wohnort: Köln/Bonn

  • Nachricht senden

2

Montag, 10. März 2014, 10:40

Hallo Alvos.

Erst einmal ein Herzliches Willkommen hier im Forum.

Ich bin zwar auch noch sehr neu hier und habe gerade erst damit begonnen mich mit dem Thema SPS auseinander zu setzen, aber einige Deiner Fragen kann ich Dir doch schon beantworten.

Die von Dir genannten Projekte
http://www.microsps.com/
http://www.cadsoft.de/mikrosps/

haben mit diesem hier keinerlei Zusammenhang, da es aber hier und da Ähnlichkeiten gibt, werden schon mal Verwandte Themen Besprochen.

Da Reinhold sämtliche Schaltpläne frei zugänglich macht, kann man sich die Hardware bei entsprechender Möglichkeit selber zusammenstellen, so wie man es benötigt. Man kann diese aber auch Voll oder Teilbestückt bei Reinhold beziehen.

Sämtliche benötigte Software ist auch hier im Forum frei zu beziehen.

Einzig zum Fläshen der Firmware wird noch Hardware benötigt, die hier im Forum nicht angeboten wird, aber auch frei erhältlich ist. Bei Bezug des Prozessors über Reinhold, würde das aber auch wegfallen.

Was das Display angeht, es gibt bereits einige hier aus dem Forum, die ein 4 Zeiliges Display verwenden, dazu müssten dann lediglich ein paar kleine Änderungen in der Software vorgenommen werden.

Ob es die Möglichkeit der Simulation am PC gibt, weiß ich leider nicht. es gibt einen Debugger, mit dem die SPS angesprochen werden kann, aber wenn ich das richtig verstanden habe, meinst Du die Simulation ohne Hardware.

Was den Vorschau der Links angeht, das liegt leider an der Forensoftware, da hat man keinen Einfluss drauf, ansonsten, bei Fragen was das Forum angeht, kannst Du Dich gerne an mich wenden, da ich Reinhold hierbei etwas unterstütze.

Ich hoffe ich konnte Dir schon etwas weiter helfen und wünsche Dir noch viel Spaß hier im Forum.


Gruß Ralph

3

Montag, 10. März 2014, 18:22

Hallo Alvos,
das sind viele Fragen. Einige Antworten hat dir Ralf schon gegeben.

Die Programmiersprache Parsic kenne ich nicht. So wie du das beschrieben hast, handelt es sich dabei um einen Compiler, welcher Maschinencode erzeugt. Bei der microSPS ist das etwas anders. Aus dem Schaltplan wir für jeden Baustein eine Zeile erzeugt Die Zeile wird von der Firmware gelesen und umgesetzt. Der so erzeugte Code nenne ich Anweisungsliste. Es handelt sich also um einen Interpreter, welcher den erzeugten Code aus dem Schaltplan abarbeitet. Die Ein und Ausgänge der Bausteine sind Signalen zugeordnet, welche in Tabellen abgespeichert sind. Jede Verbindung im Schaltplan wird einem Signal zugeordnet. Im Vergleich zu Maschinencode ist ein Interpreter eher etwas langsamer.

Der Bootloader ist erforderlich um das Programm (Firmware / Anweisungsliste ) im Speicher abzulegen. Es gibt auch Controller, welche einen Bootloader intergriert haben. Bei den ATmega Baustein ist das jedoch nicht der Fall. Das Flashen geht über ein Programmiergerät oder über einen Bootloader. Da für die Anwendung ein Programmiergerät zu umständlich und zu teuer ist, habe ich die Möglichkeiten ein Programm im Flash abzuspeichern den Bootloader zur Verfügung gestellt. Dieser muss dann nur einmal programmiert werden, die Software (Firmware und AWL) wird dann über den Bootloader abgespeichert.

Die Software, die Schaltpläne und die Beschreibungen sind kostenlos. Falls Hardware benötigt wird, kann ich diese nicht kostenfrei zur Verfügung stellen. Es besteht aber die Möglichkeit die Hardware auch selber zu erstellen. Die einfachste Version ist ein ATmega1284 als DIP Version zu beschaffen, diesen mit einem Quarz und einem RS232 Treiber zu versehen und einen bootloader zu laden. Die günstigste Variante die ich anbieten kann ist eine unbestückte Platine. Diese kann dann mit einer Minimalbestückung zum laufen gebracht werden. Das kann ich aber nur empfehlen, wenn Grundkenntnisse vorhanden sind.

Ich könnte sicher noch viel Schreiben, aber für Heute möchte ich hier Schluß machen. Sollten noch Fragen offen sein, so einfach solange nachfragen, bis die Antwort stimmt. Biite in einem Beitrag nicht zu viele Fragen stellen. Einen besseren Überblick habe ich wenn die Themen mehr unterteilt sind.

Viele Grüße,
Reinhold

4

Dienstag, 11. März 2014, 02:59

Erst einmal vielen Dank für Eure Antworten. :-)

Ich habe ein Ätzgerät und damit häufiger Microcontrollersteuerungen hergestellt. Bei (kommerziellen) SPS stehe ich immer wieder vor dem Problem, jede Menge Adaptierung an die dort genutzten 24V vornehmen zu müssen. Daher würde ich einen möglichst nackten Microcontroller bevorzugen, den ich selbst adaptieren kann. Ich finde es hervorragend, dass hier Unterstützung für diejenigen angeboten wird, die entsprechende Möglichkeiten nicht haben. :-) Auch als Developing-Tool für den ersten Start ist das Ganze sicher nützlich.

Ich würde aber hier gerne noch einmal das Debuggen in den Vordergrund schieben. Denn wenn man ein (grafisches) Programm geschrieben hat, funktioniert es in aller Regel nicht sofort, insbesondere wenn es um eine schnell laufende Maschine geht. Kommerzielle SPS bieten hier die Möglichkeit, sowohl im Funktionsplan als auch in AWL die Vorgänge in den Variablen live sichtbar zu machen. Falls der Bildschirm des angeschlossenen Notebooks nicht schnell genug ist, kann man eine zu beobachtende Variable auf einen Ausgang legen und dann oszilloskopieren.

Genau solche Debuggermöglichkeiten bietet das der microsps ähnliche Parsic (wie schon im ersten Posting detaillierter beschrieben) im Zusammenhang mit der kostenlosen Entwicklungsumgebung MPLABX (für die es auch kostenlose C-Compiler gibt) und einem Hardware Debugger, den man zwischen Notebook und Controller schaltet und dabei zwei Pins des letzteren hierfür opfern muss. Dabei kostet Parsic allerdings 250 Euro und der Hardware Debugger 140 Euro. Allerdings sind die Funktionsbausteine in Parsic mit Ausnahme des möglichen 4x40 Displays deutlich dürftiger ausgestattet als bei der microsps. Daher würden mich interessieren, wie das Debugging bei der microsps funktioniert.

Falls es interessiert:
Von Parsic gibt es eine Demo und komplette Beschreibung kostenfrei. Dabei kann auch der kompilierte Assemblercode eingesehen aber als einzige Einschränklung nicht abgespeichert werden. Falls jemand spingsen mag, um Anregungen zu holen:
http://www.parsicitalia.it/development-t…-parsic-v4.html
Und die kostenlose Microcontroller Entwicklungsumgebung MPLABX gibt es hier:
https://www.microchip.com/pagehandler/en-us/family/mplabx/

Wie gesagt: Ich würde mich freuen, wenn ich etwas zu den Debugging Möglichkeiten der microcsps erfahren könnte.

Gruß
Alvos

5

Dienstag, 11. März 2014, 20:02

Hallo Alvos,
die Fehlersuche ist mit unterschiedlichen Methoden möglich. Die einzelnen Signale lassen sich über die RS232 Schnittstelle oder auch über die LCD Anzeige ausgeben. Es ist auch möglich die Signale über Telegramme abzufragen. Hier hat Lutz eine Software erstellt, mit der Signale aufgezeichnet oder visualisiert werden können. Ursprünglich wollte Lutz einen Debugger zur Verfügung stellen. da aber das Thema Visualisierung auch nachgefragt wurde, hat das eine entscheidenden Anteil eingenommen. Falls du dich mit dem Debugger von Lutz beschäftigen möchtest, musst du die Fragen direkt an Lutz richten.
Bei anderen Steuerungsanbieter gibt es oft einen Simmulationsmodus im Schaltplan. Diesen kann ich leider nicht anbieten. Dies ist ein Chinesischer Hersteller der auch ein Simulation im Schaltplan anbietet. www.xlogic-plc.com Vielleicht entspricht dies in Bezug auf das Debuggen deine Vorstellungen.

Gruß Reinhold

6

Dienstag, 11. März 2014, 20:08

Hallo Alvos,
den Link zu parsic habe ich angeschaut. Das sieht doch auch ganz gut aus. Was spricht gegen parsic?

Gruß Reinhold

7

Mittwoch, 12. März 2014, 05:47

Gegen Parsic spricht der geringe Funktionsumfang der Bausteine. Da ist die microsps deutlich besser ausgestattet. Außerdem habe ich hier im Forum mit leuchtenden Augen gesehen, dass sich ein Android Gerät an die microsps anschließen lässt. Das hieße womöglich, dass man statt einer Bedienungs-Frontplatte nur noch ein Android Tablett bräuchte. Um die mechanische Einfassung eines Displays braucht man sich auch nicht zu kümmern, denn die ist im Tablett schon perfekt enthalten. Bei späteren Erweiterungen ließen sich damit Tasten, Leds, Displays und ähnliches nachprogrammieren. Wenn der Platz für parametrische Einstellungen nicht mehr ausreicht, könnte man hierfür einfach einen weiteren Bildschirm definieren. Man versuche so etwas mit einer mechanisch angefertigten Frontplatte, deren Fläche schon ausgefüllt ist. ;-) Auch so etwas bietet Parsic nicht. Da für ein Tablett ein oder wenige Bedienungs-Bildschirme eine lachhaft geringe Anforderung darstellen würden, wären vermutlich schon billige Exemplare geeignet.

Auch die chinesischen SPS haben die 24 Volt Ein- und Ausgänge, die häufig nicht passen. Außerdem haben die kommerziellen SPS den Nachteil, dass sie in rauher Umgebung spinnen, z.B. in der Nähe von geschalteten Hochspannungen mit einigen kV. Auch hier ist ein nackter Microcontroller hilfreich, da man hier dessen Beschaltung selbst solange modifizieren kann, bis er störsicher ist. Notfalls betreibt man den eigentlichen Controller per Batterie oder Akku mit geringer Selbstentladung, z.B. Eneloop. Bei einer kommerziellen SPS geht das Alles nicht.

Gruß
Alvos

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Alvos« (12. März 2014, 14:52)


8

Mittwoch, 12. März 2014, 17:32

Hallo Alvos,
wie im richtigen Leben gibt es Vor und Nachteile. Die Überlegung mit einem Tablet die Oberfläche zu gestalten ist aus meiner Sicht auch der richtige Weg. Was ich anbieten kann, sind Telegramme die eine Visualisierung oder eine Fernsteuerung zulassen. Im Forum gibt es einige Teilnehmer, welch sich damit auch schon auseinandergesetzt haben. Ich habe darin wenig Erfahrung. Ich würde es aber begrüßen wenn du dich mit dem Thema beschäftigst und falls möglich möchte ich dich darin auch unterstützen.

Viele Grüße,
Reinhold

9

Donnerstag, 13. März 2014, 05:51

Hallo Reinhold,
vielen Dank für die Antworten.

Du stellst darin auf die Fähigkeiten der microsps Software ab. Die ist aber nur in zweiter Linie gefragt. Ich weiß nicht, ob ich das richtig herübergebracht habe und hole daher noch einmal weiter aus:

Es gäbe beim SPS-Debuggen zwei Dinge zu unterscheiden.

1) Simulation des Funktionsschaltplans (bzw AWL) auf dem PC. Hierbei benötigt man keinen Microcontroller, sondern stimuliert und schaut nur mit dem PC. Das ist ein "nice to have".

2) Unverzichtbar hingegen ist das Live-Debugging, also das Stimulieren und Hineinschauen in den Microcontroller während er in der Anwendung läuft. Nur so können zeitkritische Probleme insbesondere bei schnell laufenden Maschinen analysiert werden, wo Eingangssignale im Abstand von wenigen Millisekunden eintreffen. Daher ist dieses ein "must have". An dieser Stelle möchte ich noch einmal verdeutlichen, dass es nicht die microsps-Software ist, die das Live-Debugging ermöglichen muss. Ich denke, ich habe wohl noch nicht herüberbringen können, dass auch im Falle von Parsic nicht Parsic selbst, sondern die Entwicklungsumgebung des Microcontroller Herstellers das Live Debugging bereitstellt.

Der Witz dabei ist, dass in Parsic beispielsweise mit "Merker 2.0"( "2.1 .. 2.7") benannte Signale auch nach dem Übersetzen in Assembler (!!NICHT!! in Maschinensprache) auch im Assembler so heißen. Außerdem ist dort immer durch Kommentare angegeben, wo beispielsweise das Gatter "UND7", der "Zähler 25" ausgeführt werden. Nach dem Übersetzen wird Parsic nicht mehr benutzt, sondern nur noch Werkzeuge des Microcontroller Herstellers, nämlich die kostenlose Entwicklungsumgebung MPLABX in Verbindung mit dem Hardware Debugger, der zwischen Notebook und Microcontroller geschaltet wird. Jetzt kann ich beispielsweise den "Merker 2.0"( "2.1 .. 2.7") in ein Watch-Window ziehen und beispielsweise durch Breakpoint oder Einzelschritt durch das Assemblerprogramm navigieren und dessen Live-Ausführung im Controller verfolgen - ähnlich wie man es von den kommerziellen SPS her kennt.

Wie Du beschrieben hast, kommt bei der microsps ein Interpreter zur Anwendung. Nun stellt sich die Frage, ob sich in dem Programm, das im Microcontroller läuft, noch nachvollziehen lässt, wo welcher Baustein und welche Variable des originalen Grafikprogramms abgearbeitet wird. Falls dies gegeben ist, stellt sich die zweite Frage, ob es für den Atmel eine Entwicklungsumgebung und einen Hardware Debugger gibt, den man zwischen Notebook und Microcontroller schalten kann und so in den Controller hineinschauen kann.

Gruß
Alvos

10

Donnerstag, 13. März 2014, 17:16

Hallo Alvos,
die Anforderungen unter 1 sind nicht möglich. Hier geht es um die Simmulation des Schaltplans auf dem PC.

Für das Überprüfen der Funktion der Schaltung stellt die microSPS Telegramme zur Verfügung. Der Debugger von Lutz nutzt diese Telegramme um die Signale darzustellen. Die Zuordnung der Leitungen zu den Signalnamen ist vorhanden. Die microSPS ist jedoch nicht so schnell, dass diese Signale von wenigen ms verarbeiten kann. Die Zykluszeit beträgt 10ms. Das ist die Zeiteinheit in der der Schaltplan einmal abgearbeitet wird.

Das Untersuchen der Software über einen Hardwaredebugger ist theoretisch möglich, steht aber für den Anwender nicht zur Verfügung. Dazu müsste dem Anwender ja der Quellcode und die entsprechenden Werkzeuge zur Verfügung stehen. Weiterhin müsste sich der Anwender in das Programm einarbeiten und den Controller verstehen. Das Programm in Assembler zu untersuchen ist selbst für mich ein Weg den ich nicht anstreben würde. Falls ich mir ein Programmteil näher anschaue, mache ich das auf der C-Ebene. Meisten reichen für das Überprüfen der Funktion ein paar Zeilen über die RS232 aus. Die microSPS soll für den Anwender eine einfache Möglichkeit bieten, eine Schaltung mit Hilfe eines Schaltplans umzusetzen.

Für komplexere Anwendungen oder schnelle Datenverarbeitung gibt es bessere Möglichkeiten für die Programmierung. Der Aufwand und die Kosten sind dann auch um ein vielfaches größer.

Gruß Reinhold

11

Sonntag, 16. März 2014, 11:53

Hallo Reinhold,

ich hätte statt "einige Millisekunden" lieber "einige 10 Millisekunden" schreiben sollen. 10ms Zykluszeit ist ausreichend.

Jetzt ist klar, dass Debuggen über Assembler bei der microsps nicht funktioniert. Falls Dich aber interessiert, wie Parsic es möglich macht, in Assembler zu debuggen, ohne diesen zu beherrschen oder mehr vom Controller zu verstehen als auf der Funktionsbausteinebene, dann sei dies hier anhand eines UND Gatters illustriert:

Angenommen man hat ein einen Funktionsplan, der nur aus einem UND Gatter namens LG1 (Logisches Gatter 1) besteht. Die Eingänge seien mit S0.0 und S0.1 bezeichnet, der Ausgang mit S0.2. (S = Signal/Merker). Dann sieht der Assembler-Output von Parsic für das Main Programm etwa so aus, wie man in der Demo detaillierter nachvollziehen kann. ";" leitet dabei einen Kommentar ein:

;__________
; LG1
;__________

;LG 1_1
...S0.0...

;LG1_2
...S0.1...

;LG1_True
.....

;LG1_False
.....

;LG1_END
...S0.2...
;__________

Dabei ist "..." davon abhängig, welcher Microcontroller ausgewählt ist. Ohne Assembler zu können, klickt man nun den Part für LG1 in mehreren Einzelschritten (oder per Breakpoint) durch. Natürlich ist es auch optional möglich, dabei Assembler zu lernen und hat somit auch eine edukative Komponente. Das Ganze ist dabei kein Muss. Man kann den Link zur assembler.exe von Microchip auch direkt in Parsic angeben und bekommt den beschriebenen Teil dann nicht zu Gesicht. Der zur microsps ähnlich einfache Weg ist also nicht verbaut. Die Umsetzung des Funktionsschaltbildes in Assembler kommt im Main-Programm zu liegen. Die Bausteine sind dabei hintereinander nach dem beschriebenen Muster angeordnet. Optional kann man die Reihenfolge der Bausteine in einem Menüpunkt von Parsic festlegen. Als einfachstes Beispiel für diese Notwendigkeit müssen beispielsweise zwei hintereinander geschaltete Schieberegister in einer SPS in umgekehrter Reihenfolge abgearbeitet werden, um an ihrem Übertragsbit vorschriftsmäßig zu funktionieren.

Um das Hintergrund System (Zeiterzeugung, Anlage der (System)Variablen, etc), das sich vor dem Main-Programm befindet, braucht man sich nicht zu kümmern. Es ist für Otto Normal-SPSler auch kaum zu verstehen.

In der Microchip Entwicklungsumgebung kann man über den Hardware Debugger S0.0, S0.1 und S0.2 oder das komplette Byte S0 (oder beispielsweise die Zählvariable eines Zählers oder Timers) in ein Watch Window ziehen und die Entwicklung live verfolgen. Dass dies möglich ist, ist dem Umstand geschuldet, dass Parsic die Baustein- und Signalnamen 1:1 aus dem Funktionsschaltplan in den Assembler übernimmt. Zudem sind die BITs in Parsic genau so zu Bytes zusammengefasst, wie sie es später in der RAM-Speicherzelle des Controllers sind.
Falls ich mir ein Programmteil näher anschaue, mache ich das auf der C-Ebene.
Heißt das, dass die microsps das Funktionsschaltbild in C übersetzt? Wenn ja: Ist in diesem C-Programm noch die Struktur des Funktionsschaltbildes oder einer äquivalenten AWL anzusehen? Kann man damit dann ähnlich wie in Parsic mit Atmel Werkzeugen noch per Einzelschritt oder Breakpoint nachvollziehen, welcher Baustein und welches Signal der ursprünglichen Quelle abgearbeitet wird? Dann wäre genau das erfüllt, was ich hier thematisiere.
Die microSPS soll für den Anwender eine einfache Möglichkeit bieten, eine Schaltung mit Hilfe eines Schaltplans umzusetzen.
Ist schon klar, und wird von mir auch in keiner Weise kritisiert. Im Gegenteil: Es ist beachtlich, was Du hier auf die Beine stellst. :-) Ich arbeite selbst in anderen freien Projekten mit und kenne den Aufwand an Zeit und Mühen. Ich wollte nur abchecken, ob dieses erweiterte Debugging mittels Atmel Werkzeugen machbar ist, ohne microsps-seitig großen Aufwand zu treiben. Da ich bisher nur mit Microchip Controllern gearbeitet habe und die Interna der microsps nicht kenne, kann ich dies nicht so ohne Weiteres übersehen. Die einfache Variante bliebe davon unberührt und weiter nutzbar.

Auch das teuere Labview bietet eine grafische Programmierung. Dabei wird dies durchaus von Personen genutzt, die die damit erstellten Projekte auch direkt in einer Programmiersprache erstellen könnten. Aber die Bausteine vereinfachen die Übersicht über komplexe Programme und periphere Vorgänge oder machen sie überhaupt erst möglich. Dinge, die sonst nur unter einem Austausch von vielen Programmzeilen möglich wären, lassen sich hier recht einfach ändern, analysieren und bleiben übersichtlicher. Mit anderen Worten: Nicht nur das Ergebnis, sondern auch der Weg dahin wird zum Ziel.

Von daher habe ich die microsps nicht nur als SPS, sondern auch als ein Labview entsprechendes Werkzeug gesehen. Sie macht es viel leichter, Steuerprogramme zu erstellen, selbst wenn man C und Assembler kann. Die Funktionalität der zur Verfügung gestellten Bausteine ist beachtlich und nach meinem Empfinden viel zu schade, um nur eine kleine SPS damit aufzubauen. Wenn es sich mit verhältnismäßig wenig Aufwand machen ließe, würde ich mir das Ganze mit einem Controller wünschen, der eine maximale Anzahl an Pins und somit viele digitale Inputs und Outputs hat. Und natürlich die Möglichkeit, das Ganze mit existierenden Atmel Soft-und Hardware Werkzeugen nach dem oben beschriebenen Prinzip live debuggen zu können. Die eigentlichen Werkzeuge hierfür existieren vermutlich und müssten also nicht von der microsps oder aus deren Umfeld kommen.

Übrigens habe ich mich in diesem Zusammenhang in der Vergangenheit darum bemüht, den Quelltext des Programmes Logiflash frei zu bekommen. Die Entwicklung wurde aus Steuermitteln (Universität) und aus Forschungförderungsmitteln finanziert. Leider ist mir dies nicht gelungen. Dieses Programm bietet eine hervorragende Grundlage für ähnliche Projekte. Die Simulation ist dabei schon perfekt integriert. Sogar ein Software-Logikanalyzer ist implementiert:
http://www.ti.cs.uni-frankfurt.de/wwr/LogiFlash.swf

Gruß
Alvos

12

Sonntag, 16. März 2014, 17:29

Hallo Alvos,
danke für die Rückmeldung. Da ich mich mit dem Thema beschäftige sind auch andere Wege für mich sehr informativ.

Du hast versucht den Ablauf in PASIC zu bescheiben. Ich kann auf den Ablauf der microSPS etwas eingehen. Jeder Baustein erzeugt eine Zeile Code. Das erste Byte stellt die Nummer für den Baustein dar. Der Interpreter holt sich also das erste Byte und kennt somit den Baustein. Danach wird das Unterprogramm für der Baustein aufgerufen. Das Unterprogramm holt sich dann die restlichen Informationen und verarbeitet diese. Bei einem Digitalen Ausgang sieht das dann so aus:

;E0 MSPS1DIGAUS#0:DIGAUS#0 K:00 (00:01:N$10)
E0:00:00:01

E0 es handelt sich um ein Ausgang
00 der Ausgang hat die Adresse 0
00:01 das Signal für den Ausgang ist eine 1 Bit Signal und dieses hat die Adresse 1

Alle Bausteine haben diesen Aufbau und werden entsprechend der Liste abgearbeitet. Das mit dem Testen habe ich so gemeint. Falls ich testen möchte wie der Baustein arbeitet, kann ich in das Programm des Bausteins die Eingangsinformation, Zwischenergebnisse und das Endergebnis über die serielle Schnittstelle ausgeben. Das ist zwar kein Debuggen in dem Sinn wie bei PARSIC aber um zu verstehen ob der Baustein richtig arbeitet, reicht das in den meisten Fällen schon aus.

Am besten wäre natürlich ein debuggen im Schaltplan. Das ist leider nicht möglich. Die microSPS stellt aber Telegramme zur Verfügung mit denn ein Debuggen möglich ist. Es lassen sich einzelne Signale abfragen und ein single step habe ich mal integriert. Das setzt aber auf der AWL auf. Es wird also ein Baustein abgearbeitet, danach könnten die Signale abgefragt werden und im nächsten Schritt kann dann der nächste Baustein ausgeführt werden. Ohne Oberfläche halte ich das aber für zu umständlich.

Für eine guten Ansatz halte ich auch http://www.beremiz.org HIer wird der Schaltplan auch in eine Hochsprache übersetzt. Zusätzlich kann auch bei dieser Variante noch Quelltext integriert werden. Ein großer Vorteil ist auch, dass das Programm in Tasks aufgebaut werden kann. Einzelne Aufgaben können also in Programmteilen erstellt werden.

Den Ansatz, das Programm in Tasks aufzuteilen habe ich bei der microSPS auch schon ausprobiert. Das hat soweit auch funktioniert, aber ich bin damit noch nicht ganz fertig. Es bleibt also spannend.

Gruß Reinhold