Das unabhängige Board
|
Das unabhängige Board |
|
|||||||
| Portal | Alternatives Portal | Forum | Spenden | TT-Links | TT-Lexikon | Markt | TT-Datenbank | Album | Events | Galerie | Chat |
 |
|
|
Themen-Optionen | Ansicht |
04.4.04, 0:58
|
#1 |
|
z. Zt. inaktiver Foriker
Registriert seit: 02.2004
Ort: Berlin
Beiträge: 168
|
Rechnersteuerung ohne teure Zentraleinheit - Teil 3 - SRCP-Clients
Hallo,
im vorigen Thread habt ihr die Hardwarekonfiguration für DDW/DDL kennengelernt. Dort war zu sehen, dass man die Programme über verschiedene Rechner mit unterschiedlichen Betriebssystemen (Linux/Windows) verteilen kann. Sowohl DDL als auch DDW arbeiten nach dem SRCP-Protokoll. Für Leute mit Märklin-Interface M6051 ist die DDL-Rubrik besonders interessant und für Leute mit Uhlenbrock Intellibox die TrackONE-Rubrik. Die aktuellen Versionen sind 0.7.3 und 0.8.2. Die Protokoll-Spezifikationen werden von zur Zeit 12 Leuten weiterentwickelt. Das Konzept ist zwischen 0.7 und 0.8 stark geändert worden und daher müssen die SRCP-Clients auf eine spezielle Version ausgelegt sein. Manche SRCP-Clients unterstützen sogar beide Versionen. Eine Auflistung von Servern und Clients findet man auf: Link http://www.der-moba.de/Digital Hier kommen Informationen zu den SRCP-Servern: Hierzu kann ich nur sagen, dass der DDL-Server (Daemon) erddcd (Electric Railroad DigitalDirect Command Daemon) heisst und ein Kommandozeilen-Programm für Linux ist. Es gibt eine stabile Version für SRCP 0.7.1 und eine Entwicklerversion für SRCP 0.8.2. Man kann den DDL-Server auch per TELNET ansprechen. Zu Linux kann ich zur Zeit keinerlei Client-Tests bieten, da zur Zeit kein Linux installiert habe und auch den DDL-Daemon von der Bedienung her nicht so sinnvoll finde. Neben den normalen grafischen Linux-Clients für DDL gibt es auch DDSH (Digital Direct Shell) oder RCSH (Railroad Command Shell). Das sind SRCP-Clients mit denen man Scripts für bestimmte sich wiederholende Modellbahnsteuerungsabläufe erstellen kann. Ein weiteres Highlight für Linux-Benutzer ist die Möglichkeit, das Märklin-Interface M6051 zu emulieren und dann auch NICHT-SRCP-Software wie z.B. Railroad&Co zu verwenden:  Ob das gut funktioniert kann ich aber wegen fehlenden Testmöglichkeiten nicht sagen. Den DDW-Server kann man über die Programmeinstellungen entweder auf SRCP 0.7.3 oder auf 0.8.0 konfigurieren. Ein kleiner Nachteil ist, dass man nur COM1 oder COM2 einstellen kann. Wenn man also eine Schnittstellenkarte drin hat, kann man die nicht benutzen (außer man schaltet die Mainboard-Schnittstellen ab). Für Windows NT, 2000, XP benötigt man einen Treiber für die serielle Schnittstelle. Funktioniert dann aber hervorragend. Es gibt den DDW-Server auch als Dienst für NT, 2000, XP, jedoch nur in der älteren Version 0.66. Etwas nachteilig ist, dass der DDW-Server manchmal durch bestimmte Konstellationen / Clients eine CPU-Auslastung von 100% auslösen kann. Eine Server-Version für SRCP 0.8.2 ist in Arbeit. TrackONE ist ein spezieller SRCP-Server zum Betrieb mit Uhlenbrock Intellibox. Ich kann den TrackONE - Server nicht testen, da ich keine Intellibox habe, jedoch ist schon ersichtlich, dass man COM1-COM4 einstellen kann. Und jetzt kommen Informationen zu SRCP-Windows-Clients (mit DDW getestet):
Bewertung: Allgemein: Gleisplaneditor: Lok-Einstellungen: Lok-Steuerung: Rückmeldung: Automatik:
Ausblick: Für Railware ist SRCP-Unterstützung geplant. Link http://www.railware.de ------------------------------ Lebenslauf dieses Beitrags: erstellt: 04.04.04 Stand: 06.04.04 Fortschritt Teil 3: 100 % (wegen fehlender Zeit vorerst fertig) Edits: Zuletzt bearbeitet von Epoche VI, 04.4.04 um 11:50. Grund: Beschreibungen zu den Clients Zuletzt bearbeitet von Epoche VI, 06.4.04 um 22:16. Grund: Beschreibungen zu den Clients Hier findet Ihr Teil 1 (Auswahl): http://www.tt-board.de/forum/showthread.php?t=2289 Hier findet Ihr Teil 2 (DDW/DDL-Hardware): http://www.tt-board.de/forum/showthread.php?t=2325
__________________
Bis dann, Stephan alias Epoche VI  Epoche VI? Na klar. Zurück in die Zukunft!  Guckst du hier: TT-Bahn von Epoche VI Geändert von Epoche VI (06.4.04 um 22:17 Uhr) |
|
|
|
24.5.04, 13:37
|
#2 |
|
Gast
Beiträge: n/a
|
Hallo,
ich will mich kurz vorstellen: Meine Name ist Peter K. und ich bin der Entwickler des SRCP-Clients TRAINer!. Mit Interesse habe ich hier den Vergleich aller SRCP-Clients gelesen und möchte nun die Chance nutzen euch folgendes zu Bitten: Alle Wünsche und Anregungen, welche Ihr zu TRAINer! habt, bitte an die E-Mail Adresse Trainer@Keintzel.at zu senden. Da mein Client, wie bereits erwähnt, noch in der frühen Phase der Entwicklung steckt, bin ich für alle Hinweise sehr dankbar. Mit bestem Dank, Peter |
|
|
|
14.3.05, 21:19
|
#3 |
|
z. Zt. inaktiver Foriker
Registriert seit: 02.2004
Ort: Berlin
Beiträge: 168
|
RR&Co bzw. Railware mit DDW/SRCP bald möglich!
Hallo,
wie aktuell im DDW-Newsletter zu lesen ist, laufen erste Tests mit einem M605x Emulator, die einen Betrieb von Railroad & Co bzw. Railware mit DDW bzw. SRCP möglich macht (allein mit Booster und PC-Adapterkabel ohne teure Zentraleinheit). Roman Lauer hat dazu den Grundstein mit einer M605x Emulator Delphi-Komponente gelegt. Michael Gräfe, der auch den DDW-Server und Gplan entwickelt hat, arbeitet gerade an einem Tool, das RR&Co bzw. Railware eine Märklin M605x Zentraleinheit an einem virtuellen seriellen Port vorgaukelt und dabei die M605x Signale in SRCP-Befehle umsetzt. Zur Zeit werden die letzten Kinderkrankheiten beseitigt. Ein Tester berichtet, dass es ansonsten wunderbar funktioniert. PS: wenn euch die nötigen Voraussetzungen für DDW interessieren, dann sucht mal nach meinen anderen Threads "Rechnersteuerung ohne teure Zentraleinheit ..."
__________________
Bis dann, Stephan alias Epoche VI Epoche VI? Na klar. Zurück in die Zukunft! Guckst du hier: TT-Bahn von Epoche VI |
|
|
|
|
03.5.05, 10:33
|
#4 |
|
Gast
Beiträge: n/a
|
Hallo Leute
ich beschäftige mich seit kurzem mit dem Thema DDW / DDL. Zu diesem Zweck habe ich mir verschiedene Softwaren als Demos downgeloaded. U.a. auch den TC 5 von Railroad&Co. Nach prüfen der SW stellte ich fest,das diese nicht über DDW funktioniert, sondern nur mit etablierter Hardware verschiedener Hersteller. Daraufhin habe ich mir erlaubt, mal die Leute von Railroad&Co zu kontaktieren. Mit der höflichen Frage, ob den Ihre Software nicht auch ohne diese HW zu betreiben ist. Die Antwort die ich erhielt war mehr als nur unerfreulich (  ). Sie lautet, so nach dem Motto:" Kauf Dir was teures dann geht auch unsere Software". Das ist jetzt zwar nur übertragen, aber letztendlich ist es so. Es hieß in der Mail, das sie ihre SW nur auf qualitativ, hochwertigen und datentechnischen abgesicherten Hardwareschnittstellen läuft. Und das senden der Gleissignale direkt an einen Booster stellt eben keine solche dar. Da war kein Hinweis von wegen "Benutze doch einen Emulator" oder "Ja, da ist gerade jemand dabei ein Lösung zu finden". Oder sind die Leute Betriebsblind ??? Was bitteschön macht eine CU anders als ein PC ? Abgesehen vielleicht von den Pegeln an der RS232 !!!!!!!!Traurig, Traurig die Angelegenheit. Zum Glück wissen aber andere immer mehr , scheinbar auch als der Hersteller selbst ;-) Zum Glück fand ich dann RailroadExpress und die SW unterstützt DDW. |
|
|
|
11.7.05, 11:43
|
#5 |
|
Foriker
Registriert seit: 06.2004
Ort: Chemnitz
Beiträge: 84
|
Hallo rocomania,
wo gibt es das Railroadexpress- Programm? Kannst du mal einen link angeben oder was näheres dazu sagen. Übrigens gibt es in der neuen RAILYPLAN-Version eine Möglichkeit, über eine (fast beliebige, im Haushalt vorhandene) IR-Fernbedienung Loks, Weichen usw. zu bedienen. Habs getestet. Bei mir gings prima- die Idee ist einfach klasse. Gruß Roland |
|
|
|
|
11.7.05, 14:38
|
#6 |
|
Foriker
Registriert seit: 10.2004
Ort: Erding
Beiträge: 392
|
Stellungnahme
hallo leute,
ich stelle hiermit zum Beitrag von "rocomania" eine Stellungnahme von Jürgen Freiwald (TrainController) ins Forum, da er sich nicht extra dafür anmelden und diesen Beitrag auch nicht unkommentiert stehen lassen wollte: Zitat Anfang: "Möglicherweise war meine Antwort an Sie nicht ganz unmissverständlich formuliert. Das Wort "teuer" habe ich in meiner Antwort nicht verwendet. Das Schlüsselwort war vielmehr die Passage "qualitativ hochwertig und datentechnisch abgesichert". Mit "datentechnisch abgesichert" ist folgendes gemeint: wenn die Gleissignale direkt an den Fahrzeugempfänger geschickt werden, so entsteht dadurch eine direkte Datenverbindung zum Fahrzeugempfänger. Das heisst: der PC tauscht direkt mit dem Fahrzeugempfänger Daten aus. Ein eventuell zwischengeschalteter Booster spielt hier keine Rolle, da er hier nur elektrisch, nicht aber datentechnisch einwirkt. Diese Datenverbindung ist aber aus technischer Sicht natürgemäss alles andere als "datentechnisch abgesichert". Es gibt hier prinzipbedingt keinerlei Handshake, Quittungsmechanismen oder Absicherungen für Kommunikationsstörungen, u. ä. Diese Art Schnittstelle entspricht nicht dem, was wir für unsere Software als Mindestanforderung festgelegt haben. Unter "qualitativ hochwertig" ist folgendes zu verstehen: wir geben unsere Software aus Qualitätsgründen grundsätzlich nur für die Kommunikation mit solchen Geräten und Gerätekombinationen frei, die wir selbst getestet haben. Im Moment sind dies ca. 30 Digitalsysteme und Schnittstellen. Bei Direktbetrieb a la DDW / DDL müssten wir unsere Software seriöserweise auch noch mit allen am Markt verfügbaren Decodern verifizieren, um dieselbe Qualität garantieren zu können. Dies ist wirtschaftlich natürlich nicht darstellbar. Aber auch wenn wir nur mit ausgewählten Decodern testen und uns beim Rest auf die Einhaltung der NMRA-Norm verlassen würden, so müssten wir damit rechnen, dass es im Einzelfall zu technischen Problemen im Zusammenspiel zwischen unserer Software und bestimmten Decodern kommen kann (Beispiele für solche Probleme im Zusammenspiel zwischen existierenden Digitalsystemen und bestimmten Decodern gibt es schliesslich genug). Auf solche Probleme und den damit verbundenen Zusatzaufwand wollen wir uns nicht einlassen. Natürlich sind uns auch die technischen Lösungen und Alternativen bekannt. Dass wir diese nicht empfehlen, hat nichts mit Betriebsblindheit zu tun, sondern damit, dass wir nur Lösungen empfehlen, die wir auch selbst ausprobiert haben. Sie haben in Ihrer Anfrage höflich und prägnant nach "geht" oder "geht nicht" gefragt und ebenso höflich und prägnant ein "geht nicht" als Antwort erhalten. Dass Sie möglicherweise auf etwas anderes gehofft haben und diese Antwort daher unbefriedigend oder unerfreulich war, kann ich gut verstehen. Aber mehr als die ehrliche Antwort, dass unsere Software die von Ihnen ins Auge gefasste Konfiguration nicht unterstützt, kann ich Ihnen nun einmal nicht geben." Mit freundlichem Gruß, Jürgen Freiwald Zitat Ende!
__________________
Gruß Alex ---------------------------- TrainController™- Consultant |
|
|
|
|
11.7.05, 15:06
|
#7 |
|
Mineralsekretär
Registriert seit: 03.2004
Ort: Düsseldorf am Rhein
Beiträge: 2.542
|
@tokaalex
Danke für die Einstellung des Zitats. Da funktioniert die Kommunikation mit den Herstellern ja doch besser als manche glauben machen wollen. Jürgen Freiwald ist aber ausdrücklich eingeladen, hier mitzumachen! Denn gerade in diesem Board werden ja Steuerungsthemen des öfteren behandelt. Vielleicht kannst Du es ihm ja vermitteln. Gruß vom Rhein Lokwolf |
|
|
|
|
11.7.05, 15:18
|
#8 |
|
Foriker
Registriert seit: 10.2004
Ort: Erding
Beiträge: 392
|
@ lokwolf,
das wird aus zeitlichen gründen wohl leider nicht möglich sein, da er das tc-eigene forum ja auch noch neben dem software-support und der weiterentwicklung der produkte zu betreiben hat. aus diesem grund wäre es besser, wenn dann spezielle fragen direkt in diesem forum geklärt werden würden, da es auch unterteilt ist in "hardware" und "software".
__________________
Gruß Alex ---------------------------- TrainController™- Consultant |
|
|
|
|
12.7.05, 15:35
|
#9 |
|
Foriker
Registriert seit: 02.2002
Ort: Dresden
Beiträge: 647
|
... das kann man aber auch nicht ganz unkommentiert stehen lassen, denn es liegt seitens SRCP sehr wohl eine "datentechnische Sicherung" vor! Es liegt bei SRCP mit DDL/DDW sogar eine sehr ähnliche Abgrenzung vor, wie in jeder anderen Digitalzentrale - auch und insbesondere hätte TrainController nichts mit der Signalerzeugung zu tun. Insofern sind die Argumente auch nicht schlüssig, denn es müsste weder ein Dekoder, noch eine Zentrale getestet werden. Vielmehr muss nur die Protokollkonformität übeprüft werden, wobei sogar der Test eines einzigen DDL/DDW Servers (oder der Referenzimplementierung) ausreichend ist. Von "unüberschaubarem Aufwand" kann also meines Erachtens keine Rede sein dürfen.
Der einzigste wesentliche Unterschiede zwischen der DDL/DDW- und der Digitalzentralenvariante ist und bleibt der physische Ort des Signalerzeugers. Werkelt in Digitalzentralen ein eigener Mikroprozessor mit vermutlich ähnlicher Software wie es durch DDW/DDL geschieht, wird dieser eigenständige Prozessor in DDL/DDW-Systemen durch einen eigen Prozess (+Thread) auf der CPU des Host-Computers ersetzt. Selbst die Steuerung des Signalerzeugers ist ähnlich - während die Signalerzeuger in Digitalzentralen ihre Steuerbefehle über proprietäre Protokolle (RS, LocoNet, ...) empfangen geschieht dies im Falle von DDW/DDL durch die TCP/IP-Schnittstelle. Was Hr. Freiwald sicher meint ist zwar, dass keine datentechnische Absicherung seitens des Signalerzeugers (hier DDL/DDW-Servers) vorliegt, aber diese liegt bei den herkömmlichen Digitalzentralen auch NICHT vor. Bis auf das Lenz'sche System gibt es keinerlei Möglichkeit im Fahrbetrieb von den Lokdekodern Bestätigungen über das Gleis zu empfangen - das anliegende Digitalsignal läuft also an dieser Stelle unidirektional hin zum Dekoder. Daran ändert der Ort des Signalerzeugers herzlichst wenig. Eine "datentechnische Absicherung" liegt nach Hr. Freiwald also höchstens zwischen der Zentrale und dem Steuercomputer vor. Doch genau diese "datentechnische Absicherung" bietet auch der DDL/DDW Server, jeder abgegebene Befehl wird entweder bestätigt oder mit einer Fehlermeldung abgewiesen. (siehe SRCP-Protokoll!) Meiner Meinung können das also nicht die wahren Gründe sein - ebenso halte ich es für relativ einfach, die gängigen Softwarepakete DDL/DDW-fähig zu machen, denn es müsste nur ein einziges Modul, wie es für jede Zentrale bereits vorliegt, neu geschrieben werden. Wurde die Software gut designed, müssten die Hersteller eine Art Hardwareabstraktionsschicht implementiert haben, welche sich an das SRCP sehr einfach anpassen lassen müsste - schließlich sind die übertragenen Informationen gleicher Natur, nur das Format unterscheidet sich. P.S. Das Protokoll zwischen der Lenzzentrale über RS232 und SCRP sind übrigens sehr ähnlich, alle bestehen aus einer Initialisierung, einem Datum für je einen Befehl (z.B. Lokfahrstufe oder Schaltdecoder), der Adresse und den Parametern. Ich vermute hingegen viel mehr (nein, dass lass ich jetzt lieber  ) ...
|
|
|
|
|
12.7.05, 15:41
|
#10 |
|
Mineralsekretär
Registriert seit: 03.2004
Ort: Düsseldorf am Rhein
Beiträge: 2.542
|
Wie sieht es mit der Echtzeitfähigkeit (gerade des DDW) aus?
Windows garantiert diese ja nicht. Wie kann die Software diese dann sicherstellen? Ich gehe mal davon aus, dass das ein der Voraussetzungen für eine automatische Steuerung ist. In einer Zentrale mit einem Microchip ist das relativ einfach. Vielleicht liegt auch genau da das Problem für dei Steuerungssoftware?  Mögen sich die Spezialiten mal außern... Gruß vom Rhein Lokwolf |
|
|
|
|
12.7.05, 16:19
|
#11 |
|
Foriker
Registriert seit: 02.2002
Ort: Dresden
Beiträge: 647
|
Jo, "echtzeitfähig" ist DDL/DDW natürlich nicht - alle Befehle werden nur so schnell wie möglich umgesetzt. Da ich leider (noch?) keine Digitalzentrale besitze, kann ich nun natürlich nicht behaupten, diese seien nicht oder doch echtzeitfähig, aber ich halte das zumindest für sehr unwahrscheinlich dass diese echtzeitfähig sind, denn man liest doch hin und wieder von Abstürzen oder langen Reaktionszeiten. Auch ist die Kommunikation zwischen Computer und Signalerzeuger nicht "echtzeitfähig", übrigens in beiden Fällen nicht!
Ein einziges Problem (theoretischer Natur) bleibt natürlich, dass bei Überlast des Host-Rechners auch der Signalerzeugerprozess nicht mehr genügend Rechenzeit bekommt. An dieser Stelle sitzt man zur Zeit noch auf zwei Stühlen. Einerseits läßt sich der Signalerzeugerprozess so konfigurieren, dass er die höchste Priorität im System erhält und damit immer die angeforderten Ressourcen bekommt - als Anwendungsprozess lässt sich dieser dann nur noch durch das Betriebssystem selbst oder durch Hardware-Treiber unterbrechen. Allerdings gibt es wohl doch noch einige Bugs im Server, ... Offiziell wird als Konfiguration aber sowieso ein eigener dedizierter eigener (alter) Rechner empfohlen, was dann wiederum keinen Unterschied mehr zu Digitalzentralen macht. Nicht verwechseln sollte man übrigends DDL/DDW mit SRCP. DDL/DDW sind die Signalerzeugerprozesse, SRCP ist das Steuerprotokoll! Auch die Intellibox lässt sich wohl per TrackONE über SRCP steuern - ohne Signalerzeugerprozess, der läuft in der IntelliBox. Insofern ist die Ablehnung aller großen Softwarehäuse gegenüber SRCP umso unverständlicher für mich, denn eigentlich bräuchte man in Zukunft nur noch SRCP fähige Software und die entsprechenden Signalumsetzer SRCP<->Lenz, usw. Richtig tödlich ist am Ende nur der "Blue Screen of Death" - der aber in allen Fällen P.S. Warum schreib ich das alles? Nun, ich möchte in Zukunft zumindest Digital schalten und hatte mich mit einiger Steuersoftware beschäftigt, ebenso mit SRCP und einen kurzen Blick in's Lenz'sche RS232-Protokoll. Alle Softwarehäuser hatten mir auf meine Anfrage per eMail Ihre ablehnende Haltung gegenüber SRCP geschildert. Der Tenor war leider immer der gleiche "Wollen wir nicht, zu viel Aufwand, zu unsicher." Auf ewige und wahrscheinlich fruchtlose Diskussionen per eMail habe ich aber keine Lust, ich hoffe nur, dass spätestens mit SRCP 1.1 auch die großen Softwarehäuser mal umdenken werden ... |
|
|
|
|
12.7.05, 21:01
|
#12 |
|
Foriker
Registriert seit: 07.2004
Ort: Weidenbach
Beiträge: 449
|
Echtzeitfähig ist mit dem Pc schon möglich, allerdings unter DOS.
Für eine komplette Steuerung incl. DCC-Signal-Erzeugung in Echtzeit ist ein Rechner ab etwa 150MHz ausreichend (wenn er nicht gerade das Miwula steuern soll). Die Signalpegel am Com-Port sind im Prinzip direkt Booster-tauglich. Tja-und Abstürze unter DOS... Das Problem ist nur, daß heutzutage niemand mehr DOS-Programme will. Jens |
|
|
|
|
13.7.05, 3:07
|
#13 | |||
|
Foriker
Registriert seit: 02.2004
Ort: im Westhavelland
Beiträge: 300
|
@maercz
Deinen Ausführungen bzgl. des Arguments "qualitativ hochwertig und datentechnischen abgesichert" aus #9 kann ich nur zustimmen. @all Zitat:
¹ solch eine Unterbrechung ist in zeitlicher Länge nicht definiert, also ganz mies für die Signalerzeugung ² Wie kommuniziert eigentlich die Software des Herrn Freiwald mit den DCC-Zentralen und wie wird sichergestellt, daß eine Unterbrechung der Kommunikation mit der Zentrale durch bpsw. Systemprozesse diese Kommunikation nicht nachhaltig stört? zu ²: Hier beißt sich IMHO die Katze in den Schwanz, stellt nämlich das Computerinterface der DCC-Zentrale keine Möglichkeit bereit atomar mit der Software zu kommunizieren, muß die Software in einem Echtzeitkontext³ laufen, anders ist für mich "datentechnisch abgesichert" sonst nicht erklärbar. Tut die Software letzteres nicht, ist sie IMHO im Falle der Kommunikation mit einer DCC-Zentrale genauso unsicher - bzgl. der Übermittlung der Daten zur Zentrale - wie bei der Kommunikation mit DDL/DDW oder die Erzeugung von DCC-Signalen durch DDL/DDW. Letztlich sollte es schließlich unerheblich sein, ob Latenzzeiten bei der Erzeugung des DCC-Signals mittels DDL, bei der Erzeugung des Signals zur Erzeugnung des DCC-Signal in der Zentrale durch Herrn Freiwalds Software oder bei einer Kombination aus beidem auftreten. ³ siehe dazu auch: hard, firm, soft real time Zitat:
Zitat:
Ich hoffe ich war irgendwie verständlich, cya Micha ps: "Du kannst aus Sicherheitsgründen nur alle 30 Sekunden einen neuen Beitrag schreiben." - war mir neu. |
|||
|
|
|
|
13.7.05, 9:53
|
#14 | |
|
Mineralsekretär
Registriert seit: 03.2004
Ort: Düsseldorf am Rhein
Beiträge: 2.542
|
OT: Beiträge
Zitat:
Gruß vom Rhein Lokwolf |
|
|
|
|
|
| Lesezeichen |
| Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1) | |
| Themen-Optionen | |
| Ansicht | |
|
|
Linear-Darstellung
