Die Hardware gibt es eigentlich schon her, der Controller ist der einzige Master und das Poll-Intervall ist auch festgelegt (d.h. eine beliebig lange Busbelegung eines Devices ist verboten). Die Frage ist eher ob der Stack im Host auch entprechend RT-faehig implementiert ist.
Micha
Nicht wirklich; es ist halt schnell.
-- Ralph. http://www.dk5ras.de/ http://www.db0fue.de/ http://www.bclog.de/
Oliver's Idee mit den Cores ist nicht schlecht. Vielleicht hilft ein Dual-Core PC tatsaechlich, die COM Routine einigermassen in Ruhe zu lassen.
-- Gruesse, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
und
ad
n, da
,=FCr
.Hallo und zun=E4chst mal Danke f=FCr eure rege Beteiligung an meinem Thema, ich versuche jetzt mal die Thread-Priorit=E4t hochzusetzen. Danke an Oliver f=FCr den Code. Aktuell kompiliere ich das ganze unter VS2005Express also nichts wirklich besonderes.
Bez=FCglich dem USB ist es bei mir wie folgt: Ich habe einen virtuellen Com-Port welcher die USB->RS485 umsetzung macht. Diese Geschichte m=FCsste ich also irgendwie unter Linux erstmal zum laufen bekommen. Da ich noch nie einen Treiber programmiert habe (nicht unter Windows und auch nicht unter Linux) stehe ich da nat=FCrlich erstmal total auf dem Schlauch. Falls ich das aber irgendwie mit eurer Hilfe hinbekommen kann, so sollte es auch nicht weiter schwierig sein, das RTAI zu verwenden und damit wirklich harte Echtzeit zu realisieren.
Einen sch=F6nen Abend.
Gru=DF,
Joachim
Die FT2xx laufen out-of-the-box, diese Billigst-Prolific-Teile auch.
Gruß Henning
jimbo :
WinXP, RS232
40msDas geht nur manchmal. :)
M.
Hallo nochmal,
[...]
Diese Information ist nicht ganz unwichtig. Zumindest unter Windows handelst Du Dir damit erhöhte Latenzen um 1-10 ms ein. Meinen Erfahrungen nach helfen da auch keine anderen Treiber und kein anderer Hersteller, der USB-Stack braucht einfach so lange. Kurz gesagt: USB überträgt sehr schnell die Daten, aber mit hohen Latenzen. Und das ist für Deine Regelung gar nicht gut. Ich kenne Dein Budget nicht so genau, aber falls es immer noch die Computerlösung sein sollte, dann könntest Du auch eine PCI-RS485-Karte (z.B. 'ne JetCard von Korenix, ~150?) kaufen, die WESENTLICH geringere Latenzzeiten aufweist. Linux-Treiber gibt es dafür auch. Dein Problem dürfte dann wohl eher darin bestehen herauszufinden, was die WINDOWS-Ansteuerungs-Dll so macht. Die Dll ist ja auch kein Treiber, sondern benutzt nur die SIOs auf dem PC zum Senden der Daten. Wenn Du das herausgefunden hast, dann ist es auch kein Problem mehr einen Mikrokontroller einzusetzen. Der dürfte die Aufgabe problemlos erledigen, Du bist alle zusätzlichen Latenzen los und die Programmierung der Teile ist mit den heutigen Mitteln ja auch nicht mehr schwer.
Gruß,
Oliver
jimbo :
Da sind mehrere Puffer dazwischen. Erstmal die Queues vom Windos-USB, die machen so ca. 2ms aus (in den meisten Fällen), es kann regulär bis
10ms hochgehen und manchmal (hab ich nur auf einem Notebook bisher beobachtet), bremst die Aktivierung des "Bildschirmschoners" das komplette System 500ms lang aus. Es bildet sich so ne Art Glockenverteilung aus; sehr viele Pakete laufen 2-3ms und einige wenige brauchen dann mal länger (bei sonst "ruhendem Desktop", wie es so schön heisst :). Ungünstig ist auch, dass der USB/RS232 Wandler höchstwahrscheinlich den BULK-Modus auf dem USB verwendet. Wenn er im Interrupt-Modus laufen würde, dann wäre die Antwortzeit wesentlich definierter. Nächster Puffer ist der im USB/RS232 Wandler. Da weisst Du z.B. nicht, wann er das nächste Paket hochschickt zum Host. Es kann sein, dass er wartet, bis ein paar Bytes zusammen sind, oder er schickt sofort, wenn der nächste USB-Frame bereit ist (USB-Tick ist 1ms, schneller geht es sowieso nicht). Bei den britischen Chips kann man das im Treiber sogar etwas beeinflussen.M.
n n -
Hallo, zun=E4chst mal h=F6rt sich das schon gut an, dass ich wohl den USB->RS485 Umrichter unter Linux zum laufen bekomme. Jetzt muss ich "nur" noch die aktuelle windows steuerungs dll vom Hersteller nach Linux =FCbersetzen und dann hoffen, dass ich das mit dem RTAI auch zum laufen bekomme.
Das mit dem Oszi brauche ich wahrscheinlich gar nicht erst versuchen. Den Beschreibungen von Matthias nach ist das ja hinsichtlich Schnelligkeit jenseits von gut und b=F6se :(
Hat einer von euch schon einmal Treiber unter Linux programmiert und wenn ja, kann man die dann so ohne weitere Anpassungen auch unter RTAI verwenden?
Viele Gr=FC=DFe,
Joachim
jimbo schrieb: ...
Von scratch programmiert nicht, aber modifiziert. Das ist nicht halb so schlimm, wie man glauben könnte.
Wenn ich das richtig sehe, ist RTAI im wesentlichen ein Kernel-modul. Damit sollte alles andere auch laufen.
Falk
is
=F6n
den
ews-
Hier geht es ja im Sekundentakt weiter :) Ist das denn mit diesen Mikrocontrollern nicht recht aufwendig? Ich muesste ja die komplette DLL Geschichte irgendwie auf dem Mikrocontroller unterbringen. Der SteuerPC w=FCrde dann nur noch zum Starten und stoppen genommen werden. Das hei=DFt ich dr=FCcke Enter, der Mikrocontroller startet mit der Abarbeitung der Bahnpunkte und schickt mithilfe der Steuerungsdll (bzw. den Funktionen daraus) die notwendigen Befehle an die Portalbearbeitungsmaschine und liest zeitgleich vom Roboter alle 40ms die Position und Geschwindigkeit ein, verrechnet das dann mit dem PID und so weiter und so fort.
Ob es da nicht einfacher ist, gleich alles auf Linux und RTAI umzubauen?
Gru=DF,
Joachim
Ok, dann werde ich mal beim Hersteller nachfragen ob der mir da zumindest die Windows Version zur Verf=FCgung stellen kann, damit ich das gute St=FCck dann auf Linux portiere.
Da hoffe ich jetzt einfach mal drauf, dass das dann ohne Probleme geht.
Gru=DF und Danke f=FCr die Infos,
Joachim
Hi,
was Matthias zum USB gesagt hat ist erst einmal vollkommen richtig und kann so auch von mir bestätigt werden.
Für die meisten dieser Umrichter gibt es Linux-Treiber. Mal eben schnell selbst schreiben würde ich Dir nicht empfehlen, der Aufwand ist schon nicht ohne. Du setzt jetzt allerdings voraus, dass damit auch das Zeitverhalten über USB viel besser ist. Leider kann ich unter Linux dazu nichts sagen, ich habe das nur mit Windows nachgemessen.
Einige (kleinere) Treiber habe ich schon unter Linux programmiert und würde daher mal sagen, dass auch mit dem RTAI das Zeitverhalten des Treibers ohne Anpassungen nicht besser wird (Wikipedia->RTAI). Das Problem ist immer folgendes: Die meisten SIOs und auch die USB-RS485-Umsetzer haben einen FIFO implementiert. Ist dieser fast voll, dann wird ein Interrupt ausgelöst und der Treiber liest die Daten. Wenn das FIFO jetzt aber mit der Antwort von Deinem Gerät gar nicht erst voll wird, dann würdest Du auch keine Antwort vom Treiber bekommen (es wird kein Interrupt ausgelöst). Aus diesem Grund startet der Treiber immer auch noch einen Kernel-Timer der alle x Millisekunden im FIFO nachschaut, ob da was liegt und liest die Daten dann. Und diese x Millisekunden sind dann Deine (zusätzliche) maximale Latenzzeit. Unter Linux wird z.B. dieser Timer durch den build eines Low-Latency-Kernels beeinflusst (so ist es zumindest in den PCI-16550(950)-Treibern). Du siehst also, mit Latenzen kann man sich ziemlich lange herumschlagen, die meisten Betriebssysteme sind halt eher auf den schonenden und gleichberechtigten Umgang mit den Ressourcen optimiert.
Nicht unbedingt. Eventuell benutzt Du ja nur wenige Befehle der Dll und die macht doch nicht viel mehr daraus, als Daten an den SIO zu senden oder zu lesen. Die Funktionsweise der Dll müsstest Du ja in jedem Fall erst einmal verstehen und ob der Hersteller damit herausrückt... Es gibt aber auch Tools (unter Windows) die alles Mitschneiden, was so über den SIO geht. Vielleicht sind die Befehle ja recht einfach aufgebaut und Du kannst das Kommunikationsprotokoll schnell verstehen. Der Mikrokontroller sollte 3 SIOs haben (eine RS232 für den Rechner und die zwei RS485 für die Maschinen).
So könnte es gehen. Da die Mikrokontroller sich gut in C programmieren lassen, sollte es keine unüberwindbaren Probleme hierbei geben.
Kommt immer darauf an, ob man die Latenzen in den Griff bekommt oder nicht.
Gruß,
Oliver
Das hängt wohl von der Definition von Echtzeit ab ;-)
So rein von den Grundlagen her dürfte FireWire für Echtzeitanwendungen tendenziell besser geeignet sein IMHO. Die nominelle Datenrate ist da eher nicht ausschlaggebend. Und Firewire wurde halt für Anwendungen wie Kameras und so gemacht...
Just my 0,02 $WAEHRUNG Gruß, Florian
"Unser $OS garantiert mindestens 20ms Latenzzeit". Vertriebsdrohne auf einem Vortrag.
Falk
*prust* Wer macht jetzt mein Display sauber??
BTW: auch ne Latenzzeit von einer Stunde kann als "harte Echtzeit" durchgehen, man muß nur sicherstellen, daß es nach dieser einen Stunde wirklich erledigt ist und auch so spezifizieren...
SCNR, Florian
Das ist ja im Grunde nichts anderes als die max. 6000kb/s, die mein DSL-Anbieter "garantiert". Nur daß man sich daran gewöhnt hat.
Falk P.S.: Wenn ich die jemals mit mehr als 6000Kb/s erwische, dann ist aber was los ;-)
Naja, ich hab mich daran nicht gewöhnt. Mag aber daran liegen, daß ich haargenau weiß, daß denen sonst die Kalkulation flöten geht ;-)
Naja, ich hab auf ner VDSL-Leitung mit "50MBit max." auch schonmal knapp über
70 rausgeholt, auf ner 16MBit-ADSL kamen ebenfalls schon gut 20 durch. Oder halt "damals" [TM] auf ner 1MBit-ADSL 7,8MBit rausgezaubert. IP over ATM statt IP over Ethernet over ATM macht halt schon nen Unterschied, wenn das Traffic-shaping auf Ethernet-Eben läuft ;-)Liegt halt immer daran, wer an der Technik rumkonfiguriert.
SCNR, Florian
85 .
Hi Oliver, ich sehe schon du hast hier schon gut was an Arbeit investiert um diese Erfahrungen zu haben. Prinzipiell h=F6rt sich die Idee mit dem Mikrocontroller jetzt gar nicht mehr so schlecht an. Vor allem die Sache mit dem Mitschneiden m=FCsste ich mir mal in Ruhe anschauen und so Funktion f=FCr Funktion analysieren. Muss mich mal nach einem Tool umschauen welches meinen Port =FCberwachen kann. Anschlie=DFend komme ich gerne wieder auf dich zur=FCck wenn es darum geht den Mikrocontroller zu programmieren :) Bis dahin viele Gr=FC=DFe und muchas gracias a todos
Joachim
???
Mit Zugriff auf das Ende, an dem der Anbieter schraubt, nehme ich mal stark an.
-- Ralph. http://www.dk5ras.de/ http://www.db0fue.de/ http://www.bclog.de/
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.