Moin zusammen! Ich habe da im Moment eine 'etwas delikate' Aufgabe, für deren Lösung ich zwar schon einige Ideen&Ansätze habe, zu der ich aber gerne noch ein paar unabhängige Meinungen und vielleicht Ideen hätte, auf die ich vor lauter Betriebsblindheit nicht komme... Kurze Beschreibung: Über 24 serielle Schnittstellen laufen mit max. 9600bps Datentelegramme ein, die jeweils aus 3 Byte bestehen. Die Telegramme kommen Byte an Byte, ohne Pause, das Protokoll ist aber so strukturiert, daß die Telegramme eindeutig zu synchronisieren sind. (Die Datenquellen stammen aus den 80ern, da wusste man noch, wie sowas geht...) Diese Daten müssen !Zeitrichtig! zusammengefasst werden, mit einem Zeitstempel (Da ist die über GPS synchronisierte Systemuhr genau genug) versehen über LAN ins System gespeist werden. Erschwerend kommt hinzu, daß die Datenquellen seeeeehr weit entfernt sein können, oder schlimmstenfalls über Satellitenstrecken angebunden, so daß Laufzeiten von ca. 50ms bis 800ms zu berücksichtigen sind. Diese können aber für die einzelne Strecke als konstant angesehen und berücksichtigt werden. Es gibt sogar einen Mechanismus an den Datenquellen, der es erlaubt, die Laufzeit zu messen, indem man bestimmte, mit einem Zeitstempel versehene Telegramme hinschickt und die (fast) ohne Verzögerung geechot werden. Wenn die Laufzeit erstmal bekannt ist, ist es kein Problem, diese beim zusammensortieren der Daten zu berücksichtigen. Dazu muß man die Daten aber erstmal zeitgenau senden können... Problem ist also: Erstmal 24 serielle Schnittstellen an einen heutigen PC anzuschliessen, und diese unter Windows7 (alternativ ginge auch Linux, aber eher ungern) so zu betreiben, daß die Software die Daten mit einer Zeit(un)genauigkeit von ca. 10ms bearbeiten kann. Das langt. Zur Verfügung stehen: 1 bis N (Ja, ich kann soviele verwenden, wie ich will...) moderne Rechner und ein paar k€ für zusätzliche (Interface)Hardware nebst einigen Entwicklerstunden in Java oder C++ (VS2010). Jede Idee ist mir willkommen! Meine bisherigen Lösungsansätze verrate ich mit Absicht nicht, um den freien Fluß der Ideen&Meinungen nicht vorzeitig in eine Richtung zu lenken. Soviel sei aber verraten: GENAU dieses Problem haben wir 1994 mit einem 68040 auf VMEBus und drei ISIO-Karten unter pSOS+ in K&R C spielend gelöst bekommen. Nur leider bekommt man dafür keine Ersatzteile mehr. Das ist der Fluch der Nachhaltigkeit... Für jeden Denkanstoß dankbar: Baku P.S.: Oder sollte ich einfach die Amper hochskillen??? ;-) P.P.S.: Die Option, selber etwas mit einem (oder 24) ausreichend leistungsfähigem Controller (ATMega...) hinzubraten und zu programmieren besteht NICHT. Das wäre zu einfach und würde 'den Prozessen' zuwiederlaufen. Wo käme man denn hin, wenn die Probleme einfach so gelöst würden ohne 'die Prozesse' einzuhalten??? P.P.P.S.: Immerhin, immerhin, wurde von der Managementebene bereits signalisiert, daß man für diese hochspeziell diffizile Aufgabe auch von dem Dogma, alles nur noch in Java zu machen, mal eine Ausnahme machen würde.
Ich wuerd 8 Mega 64 so baumfoermig zusammrnschalten, dass 24 Schnittstellen brauchbar sind. Dann mit einer einzigen zum PC.
Fuenf Tassen schrieb: > Ich wuerd 8 Mega 64 so baumfoermig zusammrnschalten, dass 24 > Schnittstellen brauchbar sind. Dann mit einer einzigen zum PC. Lern lesen :D
Die Fa. Sorcus www.sorcus.com bietet PC Einsteckkarten auf denen versch. Peripheriekarten aufgesteckt werden können, unter anderem mehrere 8-fach RS-232. Es gab die PC-Karte mit eigener CPU zur Datenvorverarbeitung mit viel Ram.Wie das aktuell ist, weiß ich nicht. Dieses System ist sehr gut für dein Vorhaben geeignet. www.sorcus.com 900ss
Wenn Du wiklich auf Windows setzen willst, musst Du Deine Zeitstempel unbedingt "in Hardware" generieren. Mit Hardware meine ich irgendetwas echtzeitfähiges (also z.B. einen µC mit brauchbarer Programmierung). Windows nimmt sich gerne mal etwas "Zeit für sich" - also egal wie hochprior Du deine Anwendung setzt, es kommt immer wieder mal vor, dass sie einige Zeit (10ms bis 300ms) einfach nicht "dran kommt". Die von der Anwendung generierten Zeitstempel sind dann für die Katz'. Auch mehrere Prozessor-Cores schaffen da keine Abhilfe.
Gerade der Zeitversatz macht die Sache interessant. Mit Windows oder Linux bekommst Du das nicht in Echtzeit hin. Ich würde auch erst mal µCs als Puffer nehmen, die den Zeitversatz ausgleichen und dann erst auf den PC gehen.
Martin H. schrieb: > Wenn Du wiklich auf Windows setzen willst, musst Du Deine Zeitstempel > unbedingt "in Hardware" generieren. Mit Hardware meine ich irgendetwas > echtzeitfähiges (also z.B. einen µC mit brauchbarer Programmierung). > > Windows nimmt sich gerne mal etwas "Zeit für sich" - also egal wie > hochprior Du deine Anwendung setzt, es kommt immer wieder mal vor, dass > sie einige Zeit (10ms bis 300ms) einfach nicht "dran kommt". Die von der > Anwendung generierten Zeitstempel sind dann für die Katz'. Auch mehrere > Prozessor-Cores schaffen da keine Abhilfe. Du kannst für das genaue Zeit messen ein Produkt namens Kithara nutzen. Funktioniert sehr gut. Must mal ne Suchmaschine bemühen. Kithara bietet verschiedene Echtzeit Treiber an, die auf Kernelebene arbeiten und damit echtzeitfähig sind. Aber die oben erwähnte Sorcus Karte ist am besten geeignet. 900ss
Ich würde das über ebenddet system lösen. z.b. http://sphinxcomputer.de/MOXA/MOXA-NPort-5150/p1396.html oder mit einen/vielen Rasberry(s). Die systeme lesen die Daten ein und senden es mit der empfangsuhrzeit an einen PC. Am PC spielt dann die Verarbeitungszeit keine rolle mehr. Die einzelnen System können die Uhrzeit per NTP abgleichen, das sollte genau genug sein.
ich versuche das nochmal zusammen zu fassen: du hast 24 serielle schnittstellen (also auch 24 quellen?), über die jeweils 3 byte große telegramme ankommen, die durch das protokoll synchronisiert werden können. z.b. port1 3 byte lesen, alle anderen haben inzwischen sendepause port4 3 byte lesen, alle anderen haben inzwischen sendepause port12 3 byte lesen, alle anderen haben inzwischen sendepause und die byte sollen dann in der richtige reihenfolge (mit zeitstempel) über die netzwerkkarte raus (nicht mehr so zeitkritisch) p1.12345 p4.12346 p12.12347... habe ich das soweit richtig? in dem fall würde ich versuchen über steckkarten die 24 schnittstellen in einen pc zu bekommen, jede der schnittstellen hat einen fifo-buffer. bei einer datenrate von 9600bps braucht ein byte ca. 1 ms, 3 byte daher ca. 3 ms. als betriebssystem verwendest du z.b. rtlinux und schreibst dir ein rt-modul, das z.b. alle 5ms die 24 schnittstellen abfragt und falls daten empfangen wurden diese in einen ringbuffer überträgt (daten + zeitstempel). dieser ringbuffer wird dann aus dem userspace abgerufen und über das netzwerk verschickt... falls der netzwerk-teil auch zeitkritisch ist, müsste man den auch in ein rt-modul auslagern. p.s. ich weiß, dass oben steht "linux aber eher ungern" nur fällt mir absolut keine möglichkeit ein, das ganze unter windows mit rt-anforderungen umzusetzen.
alternativ zu 24 schnittstellen einbauen und erfüllt (teilw.) auch "Die Option, selber etwas mit einem (oder 24) ausreichend leistungsfähigem Controller (ATMega...) hinzubraten und zu programmieren besteht NICHT." http://www.enterpoint.co.uk/moelbryn/raggedstone1.html und die 24 schnittstellen in vhdl umsetzen ;-)
Hallo, ich würde eine Einsteckkarte designen mit einem leistungsfähigen µP und 24 seriellen Interfaces (so wie beschrieben wird ja wohl nur RxD gebraucht), die das Zeitstempeln und Zwischenspeichern erledigt und das Ganze als eine einzige serielle Schnittstelle an Windows weitergibt. Auf so einem Embedded System bekommt man alle Probleme in den Griff, die mit Windows nicht wirklich lösbar sind. Allerdings nicht unbedingt in Java. Gruss Reinhard
Reinhard Kern schrieb: > einem leistungsfähigen µP und 24 seriellen Interfaces Mag programmtechnisch möglich sein, aber ein kluger Bauer legt nie alle Eier in einen Korb. Elektrisch gesehen, sind Interfaces öfter eine Schwachstelle, wo schnell mal eine höhere oder verschleppte Spannung was zerräuchert. Daher ist austauschfreundlicher Aufbau günstig.
oszi40 schrieb: > Daher ist austauschfreundlicher Aufbau günstig. Ja, bei einem industriellen System mache ich das auch so. Die handelsübliche PC-Technik gibt das aber nicht mehr her, da muss man schon froh sein, wenn man mehr als 2 Platinen einstecken kann. Und ein Baum aus USB-Hubs und chinesischen USB-V24-Adaptern ist auch nicht das was ich mir unter industrieller Technik vorstelle, wenn auch unschlagbar billig. Ich würde, richtig altmodisch, je 4 RxDs auf einen MC1488 oder ähnlichen Empfänger führen und den in DIL-Fassung austauschbar machen - muss ja nicht alles SMD sein. Gruss Reinhard
Hallo zusammen! Erstmal vielen Dank für die große Resonanz und die vielen Vorschläge! Hatte leider bis jetzt kein Internet (vielleicht sollte ich mir doch mal ein Schmartphon zulegen...). Daniel F. schrieb: > ich versuche das nochmal zusammen zu fassen: > du hast 24 serielle schnittstellen (also auch 24 quellen?), über die > jeweils 3 byte große telegramme ankommen, die durch das protokoll > synchronisiert werden können. > z.b. > port1 3 byte lesen, alle anderen haben inzwischen sendepause > port4 3 byte lesen, alle anderen haben inzwischen sendepause > port12 3 byte lesen, alle anderen haben inzwischen sendepause > > und die byte sollen dann in der richtige reihenfolge (mit zeitstempel) > über die netzwerkkarte raus (nicht mehr so zeitkritisch) > p1.12345 p4.12346 p12.12347... > habe ich das soweit richtig? Nope. Die Sensoren liefern jeweils einen ununterbrochenen Datenstrom, und es soll sicher gestellt werden, daß trotz unterschiedlicher Verzögerungen (10..800ms) bei der Übertragung die Meßdaten am Ende zeitlich zusammengehörig wieder heraus kommen, so daß sie das gleiche 'Ereignis' beschreiben. Am Ende soll also rauskommen: p1,p2..p24.12345 p1,p2..p24.12346 etc. Eine Ungenauigkeit von ~10ms wäre durchaus tolerierbar. >[...] > p.s. ich weiß, dass oben steht "linux aber eher ungern" nur fällt mir > absolut keine möglichkeit ein, das ganze unter windows mit > rt-anforderungen umzusetzen. Wat mutt, dat mutt :-) Sehr interessant ist auch der Tip von Peter II >Ich würde das über ebenddet system lösen. >z.b. http://sphinxcomputer.de/MOXA/MOXA-NPort-5150/p1396.html Eine fertige Schachtel, die man 'nur noch' programmieren müsste. Wäre dann auch mit embedded Linux, ich habe da keine Berührungsängste. >oder mit einen/vielen Rasberry(s). Scheidet ebenso wie die Lösung mit dem FPGA-Board aus, weil zwar keine Platinen gemacht werden müssten, aber ein Gehäuse, Verdrahtung etc. Einstweilen allen vielen Dank, falls es interessiert, werde ich über den Fortgang der Forschungen berichten! IdS Baku
Baku M. schrieb: >>Ich würde das über ebenddet system lösen. >>z.b. http://sphinxcomputer.de/MOXA/MOXA-NPort-5150/p1396.html > > Eine fertige Schachtel, die man 'nur noch' programmieren müsste. > Wäre dann auch mit embedded Linux, ich habe da keine Berührungsängste. bei dem link hatte ich mich vertan, die box hat den nachteil das sie die schnittstelle nur 1:1 an den PC weitereicht, der PC muss sie dann auch noch aktiv abfrage. Damit hast du wieder ein Timingproblem. Besser ist diese http://sphinxcomputer.de/MOXA/MOXA-UC-7101/p2011.html oder diese: http://sphinxcomputer.de/MOXA/MOXA-UC-7420-7410/p281.html diese haben ein eigenes Betriessystem und können damit die daten selber mit einem Zeitstempel versehen und dann in ruhe zu einem PC senden. Hier findest du noch mehr von diesen dingen, das ist auf jeden Fall das passende dabei: http://sphinxcomputer.de/produkte.php?id=49
Wenn k€ keine Rolle spielen und Du eine hohe Redundanz haben willst - ich würds mit der entsprechenden Anzahl von Xports von Lantronix machen. Das paßt ganz wunderbar auf eine kleine Platine, die in einem Rack steckt. Daten werden über LAN mit Zeitstempel ausgegeben und wenn ein Kistl defekt ist - einfach tauschen und SW neu einspielen. Du mußt das nicht selber machen sondern kannst das Auftrag vergeben und dann ist diese "Scharte" des "Bastelns" auch gelöst.... PS: das ganze funktioniert als Konzept mit 4 Stk bei einem Kunden ganz wunderbar und ist defakto fast beliebig skalierbar. Grüße MiWi
MiWi schrieb: > Wenn k€ keine Rolle spielen und Du eine hohe Redundanz haben willst - > ich würds mit der entsprechenden Anzahl von Xports von Lantronix machen. > Das paßt ganz wunderbar auf eine kleine Platine, die in einem Rack > steckt. Daten werden über LAN mit Zeitstempel ausgegeben und wenn ein > Kistl defekt ist - einfach tauschen und SW neu einspielen. wenn € wirklich keine Rolle spielen, warum denn selber entwicklen und bauen lassen? Gibt es schon fix und fertig -> moxa (siehe post darüber).
Also wenn ein externer selbst gebauter Multiplexer/Zeitstempeleinfüger nicht geht, dann wirst Du wohl oder übel ein paar serielle Karten (gibts glaub ich bis 32 Ports) an einen Linuxrechner anschließen müssen. Da Du ja "nur" 24 Schnittstellen hast, kannst Du im ersten Schritt einfach ein Programm schreiben, welches vom Port ließt und die Eingabe als Text mit Zeitstempel ausgibt. Mit dem kannst Du dann weiter arbeiten. 10ms sollten noch möglich sein, einige Ports unterstützen spezielle "Disziplinen" mit denen Du das toggeln von Steuerleitungen (und evtl. auch Datenleitungen) mit einer realistischen Unsicherheit von wenigen Mikrosekunden messen kannst. Von Lösungen mit USB würde ich abraten, das wirst Du nicht stabil genug hinbekommen, von den Problemen der Echtzeitfähigkeit möchte ich gar nicht sprechen.
Peter II schrieb: >[...] > bei dem link hatte ich mich vertan, die box hat den nachteil das sie die > schnittstelle nur 1:1 an den PC weitereicht, der PC muss sie dann auch > noch aktiv abfrage. Damit hast du wieder ein Timingproblem. >[...] Ich hatte mich bei dem Link auch vertan... Ich meinte natürlich die Schachtel mit den 8 Ports und embedded Linux drauf. Das Thema mit Moxa N-PortServern (16*RS232 auf LAN) haben wir schon durch, da ist mit 'zeitnah' prinzipbedingt überhaupt nichts hinzubekommen.
MiWi schrieb: > [...] > Du mußt das nicht selber machen sondern kannst das Auftrag vergeben und > dann ist diese "Scharte" des "Bastelns" auch gelöst.... > [...] Tscha, wenn das so einfach wäre... Dank wohldefinierter Prozesse, Qualitätsmanagement und einer großbehördengleichen Organisationsstruktur zöge die Fremdvergabe einer Entwicklung einen bürokratischen Aufwand nach sich, für den man für jede Schnittstelle einen eigenen Rechner samt Racks und allem kaufen könnte, noch bevor der erste Handschlag beim Zulieferer getan ist... Wenn das nicht so wäre, hätte ich es schon längst selber lösen können :-( IdS, Baku -jetzt wieder deprimiert-
JAVA und Echtzeit. ;-) Nur, wenn man echt Zeit hat! Wie man Probleme mit High Tec löst, die man ohne sie nie hätte. Gute Lösungen wurde ja schon zuhauf genannt. Aber man WILL sich ja ins Knie schiessen . . .
Windows würde ich ganz schnell wieder vergessen. Ich erinnere mich an ein recht aktuelles Projekt, wo 'nur' 8 serielle Schnittstellen verbaut waren und selbst das war schon ein Krampf. Teils wegen Treiberwahn (Windows-Treiber sind effektiv nicht nachhaltig, dank der Signierung), teil weil die Schnittstellen sporadisch irgendwo auftauchten, also die Zuordnung zu den 'COM'-Nummern eher willkürlich passierte. Den Jitter von 10ms kannst du im Userspace schon alleine wegen des Multitasking vergessen. Da müssstest du schon in den Kernelspace bzw. ein echtzeitfähiges Windows beschaffen. Gerade das geht aber mit Linux deutlich einfacher. Was wäre denn mit einem FPGA? So ein mittelgroßes Spartan dürfte genug Platz bieten, um die seriellen Schnittstellen abzubilden.
Wenn du keine Lösung basteln kannst, dann kauf dir einen Data Concentrator für 32 Leitungen, oder eben ein 24 port + 4 port. Ist für Satelliten/Funkbridges sehr gängig, kostet aber 2-3k€ und lass auf einem Port ein GPS timing modul laufen. Jedoch sollte das Timing Modul auch uC unterstützt sein, ansonsten wenn beim nächsten Terroranschlag das GPS abgeschaltet wird, gibt es keine Daten. Ev. findet sich ein DCF77 Modul mit uC was dafür geeignet ist.
>oder >schlimmstenfalls über Satellitenstrecken angebunden, so daß Laufzeiten >von ca. 50ms bis 800ms zu berücksichtigen sind. Diese können aber für >die einzelne Strecke als konstant angesehen und berücksichtigt werden. ist das nicht eher unrealistisch? Meiner Meinung nach müssen die Daten direkt bei der Quelle mit einem Zeitstempel versehen werden (per GPS) sonst wird das nicht gehen?!?
Nicht wirklich. Solche Strecken sind über Mikrowellen oder Glasfaser recht üblich. Dabei werden die zwischen den Nutzdaten übertragen in normalerweise padding flags, sodaß man da durchaus eine konstante Zeitverzögerung hat. Teilweise wird darauf sogar TCP/IP gefahren, um damit die Anlagen remote zu steuern.
Die 24 Schnittstellen kriegt man am Schnellsten und Einfachstem mit einem MOXA rein. Ich habe sowas vor Jahren mal mit 64 Kanälen gemacht und dazu 2 Geräte benutzt. Damals waren es allerdings andere Geräte von www.COMTROL.com, die ECOS laufen. Draufgekommen bin ich durch eine Suche nach einer Library. Hier findest Du eine serielle Lib mit der das geht. https://iftools.com/download/ctb/spmdwx.pdf Nach Angaben des Autors funktioniert es bis zu 460BAUD je Kanal. Leider wird die Tool-Lib wxWindows nicht mehr weiterentwickelt, seit es QT frei gibt. Sicher gibt es aber auch dort eine Möglichkeit, diese Geräte anzubinden. Programmiert werden ja nur die seriellen Ports. Mit heutigen Prozessoren sollte es kein Problem sein, die schnell in den Rechner zu bekommen.
Vielleicht sollte der ein oder andere erst einmal grundlegende PC Hardware Kenntnisse auffrischen. Die X86 Hardware stellt für serielle Schnittstellen erst einmal nur 2 Interrupts zur Verfügung. Durch IO/Mapping konnte/kann man jedoch auch die Interrupts sharen, so dass maximal 4 serielle Schnittstellen möglich waren und sind. Selbst das hat früher schon oft nicht funktioniert. Hier wären spezielle IO Karten mit Software und Vorverarbeitung nötig. Eigenbau wäre über den Ansatz mehrere Microkontroller einzusetzen um hier eine Vorverarbeitung zu realisieren möglich. Dann wäre auch eine Kopplung in den PC über USB oder auch RS232 möglich. Hier steht jetzt Eigenentwickelung gegen kaufen im wirtschaftlichen Kontext gegeneinander. Jörg Schieb kann sich noch gut erinnern....
Lösung USB HUB 8fach, das drei mal 24 USB Seriell Wandler von z.B. Pollin schon hast du Schnittstelen zum Säue füttern
OLD BOY schrieb: > Dummkopf ... Selber Dummkopf. Feige anonyme Beleidiger haben hier nichts zu suchen.
Die Moxa Karten mit ihren 128byte in und out buffern eignen sich nicht wirklich für das Timing was benötigt wird, da können schon mal 400 ms Zeitdifferenz zustandekommen im worst case. Ich würde da je serielle Schnittstelle einen uC nehmen von HW RS232 auf spi und einen Master welcher dann den Zeitslot vorgibt sowie auch die Daten ausgibt mit 250Kbps sowie einen uC welcher mittels GPS/DCF77 einen Timestamp ausgibt. Da aber dann die Datenübertragung ca 29mS dauern würde, müsste wirklich jeder uC einen Timestamp dazugeben (Timer value seit pps mit 32khz) und dann mit 500kpbs übertragen, sowie einen Datenstrom mit Zeitwerten.
OLD BOY schrieb: > Vielleicht sollte der ein oder andere erst einmal grundlegende PC > Hardware Kenntnisse auffrischen. > > Die X86 Hardware stellt für serielle Schnittstellen erst einmal nur 2 > Interrupts zur Verfügung. eine aktuelle karten muss sich aber nicht an diese alten Vorgaben halten. Sie kann es über andere IO-Adressen lösen. Es muss nur einen Treiber passend zum Betriebssystem mitgleiefert werden.
Wegen dem Zeitstempel.. Serielle Schnittstellen sind naturgemäß asynchron. Das heisst es passiert irgendwas, irgendwann!! , in einem Zeitfenster. Also sind Daten mit der Windowstypischen "Nichtechtzeit!" genauso aktuell wie RealTime Operating Systeme..also ~200..300mS Präzision. Das ganze könnte mit z.B einfach mit einem "LabView" Programm abgefangen, Präpariert und mit dem Systemzeitstempel verarbeitet werden. Genaueres ist meiner Meinung nach mit Seriellen Schnittstellen nicht drin. Und praktikabel sind tatsächlich jede Menge USB HUBs und USB COM Wandler. (5€/Stk bei Pollin) Billig und austauschbar. Die MOXA Box tut nichts anderes und ist nur teuerer. Gruß Christof
Christof Ermer schrieb: > Die MOXA Box tut > nichts anderes und ist nur teuerer. doch tut sie, sie hat einen eigen Prozessor und kann die Daten aktiv mit einem zeitstempel versehen. Dann können die daten später zu einem PC gesendet werden. Die Box läuft auch ohne PC - usb wandler nicht.
möglich.. aber ein PC läuft ja sowieso. Sonst macht das ganze keine Sinn.
@ OLD BOY (Gast) >Die X86 Hardware stellt für serielle Schnittstellen erst einmal nur 2 >Interrupts zur Verfügung. >Durch IO/Mapping konnte/kann man jedoch auch die Interrupts sharen, so >dass maximal 4 serielle Schnittstellen möglich waren und sind. >Selbst das hat früher schon oft nicht funktioniert. Wozu Interrupts? Da man WEIß, dass die Daten IMMER mit 9k6 ankommen, pollt man einfach reihum. Wir reden über 24x 1kByte/s, mit etwas sinnvoller Programmierung packt das ein 8 Bit Controller mit 20 MHz. Ein 1ms Timer und die passende State Machine, ausreichend RAM sollte aber sein, 32-64kB würde ich mal ansetzen. Möglicherweise ist es sinnvoll, das Ganze auf einem der neuen ARMs zu packen, dann hat man gleich Ethernet an board und genug Resourcen. >Eigenbau wäre über den Ansatz mehrere Microkontroller einzusetzen um >hier eine Vorverarbeitung zu realisieren möglich. Viel zu komplex und speziell. @ pic tech (pic) >Die Moxa Karten mit ihren 128byte in und out buffern eignen sich nicht >wirklich für das Timing was benötigt wird, da können schon mal 400 ms >Zeitdifferenz zustandekommen im worst case. Wer sagt denn, dass die UARTS/Karten die riesigen Verzögerungen ausgleichen sollen? Das macht ein Software-FIFO. Dieses Verfahren wird in diversen Telekomübertragungsstandards genutzt (IMA, Inverse Multiplexing over ATM; SDH-Ethernet Mapping).
Dani schrieb: > Leider wird die Tool-Lib wxWindows nicht mehr weiterentwickelt, seit es > QT frei gibt. Sie heißt seit einigen Jahren wxWidgets, und wird durchaus weiterentwickelt; die letzte Version ist 2.9.3 vom Dezember letzten Jahres. http://www.wxwidgets.org/
Wie wärs mit 2x EPIA-M900 (http://semiaccurate.com/2012/02/23/via-puts-out-a-very-odd-quad-core-mini-itx-board/) Sind dann zwar 2 systeme und auch nicht billig aber naja... einfach :) 73
Ich würde das mit einer Soft-SPS wie Beckhoff TwinCAT machen. IO kannst du reichlich anschließen, die RS232 sind einzeln austauschbar, EMV fest, keine Treiberprobleme, Echtzeituhr in der RT-Laufzeit, Industrie-PC mit Windows, SPS-Programm und dazu ein kleines .NET Programm welches die Daten aus der SPS abholt und dann per LAN verschickt. Das Programm kannst du dann auch in Java schreiben.
Hmmmm. IMHO ist das bei weitem nicht trivial. Man braucht ja eine "Instanz", die sowohl die Telegramme als auch die Zeitinformation parallel abfragen bzw. annehmen kann. Das bedeutet, diese Instanz muss den "internen" Zeitstempel halten, und der muss genau sein. IMHO geht das nur über eine FPGA Lösung in Verbindung mit einer sehr genauen Zeitquelle. Also die Annahme auf 24 SIO, und bei jedem Telegramm wird die Zeit gespeichert. Das kann ein z.B. 256b Counter sein, der dann mit den Zeitsignalen verrechnet wird. Ales andere wird schwierig zu begründen bzw. zu beweisen sein, das es "echt" parallel ist.
eugler schrieb: > IMHO geht das nur über eine FPGA Lösung in Verbindung mit einer sehr > genauen Zeitquelle. warum soll das mit 24 embeddet computer nicht gehen? Es geht hier nicht im µs sondern im ms! Über NTP kann man die PC auf weniger als 1ms abgleichen, die hardware ist immer gleich es läuft nur software die gebraucht wird. Damit sollte man es auch weniger als 10ms hinbekommen, dafür braucht man nicht etra ein FPGA board zu entwickeln.
Peter II schrieb: > eugler schrieb: >> IMHO geht das nur über eine FPGA Lösung in Verbindung mit einer sehr >> genauen Zeitquelle. > > warum soll das mit 24 embeddet computer nicht gehen? Es geht hier nicht > im µs sondern im ms! Jup, natürlich. Ich dachte nur über eine günstige, kleinskalige Lösung nach. Da ist ein "Wald und Wiesen" FPGA Board wahrscheinlich günstiger als n "Industrial RS2322" Lösungen. > Über NTP kann man die PC auf weniger als 1ms abgleichen, die hardware > ist immer gleich es läuft nur software die gebraucht wird. Die Aussage halte ich für sehr gewagt. Das mag die Erfahrung zeigen ... . Ein WIN ohne RT wird dir das nicht garantieren können. Und da ist es egal, ob us, ms oder s. Im Blöden Fall kann es sogar h sein ;-). > Damit sollte man es auch weniger als 10ms hinbekommen, dafür braucht man > nicht etra ein FPGA board zu entwickeln. Wie gesagt, es geht hier nicht darum, ein 14 lagiges FPGA Board zu entwickeln. Aber eventuell macht es ein Sparten 3 Dev Kit mit USB auch ... .
eugler schrieb: > Jup, natürlich. Ich dachte nur über eine günstige, kleinskalige Lösung > nach. Da ist ein "Wald und Wiesen" FPGA Board wahrscheinlich günstiger > als n "Industrial RS2322" Lösungen. nur das er etwas fertig will und nicht selber "basteln" Auch lernt man nicht in ein paar min wie man so ein FPGA Board programmiert. Und Zeit ist nun mal auch Geld.
Peter II schrieb im Beitrag #2733173:
> sorry post gehört hier nicht rein.
Höhö, ganz so falsch war er nicht, wenn ich mir manche Antworten hier so
ansehe ;-)))
Es geht hier auch nicht um irgendwelche Glaubensfragen, wer denn nun das
realtimigere Betrübssystem hat, sondern es geht, wie einer schon sehr
treffend bemerkte, um einige MILLIsekunden. Nicht Mikro, Nano, Femto
oder Atto...
Ich habe inzwischen ein paar Versuche gemacht, über deren Ergebnisse ich
mal kurz berichten will, da sich das Thema doch offenbar eines gewissen
Interesses erfreut: (Versuch macht kluch!)
Einfach mal auf meinem Arbeitsplatzrechner 'so ähnliche' Telegramme
rausgehauen, die statt der Nutzdaten einen Zeitstempel vom 'high
performance counter' (oder wie das Ding noch heisst..) tragen, mit 100us
Auflösung. Es gelingt (unter Win7 64Bit) schon mal, diese mit +-100us
Ungenauigkeit zu senden.
Damit ist der Zeitpunkt gemeint, an dem mein Testprogramm die Daten
erzeugt und über das Win-API auf die Reise ins Ungewisse schickt. Und
das gelingt immer (Ich habe extra etwaige Ausreisser protokolliert) über
Stunden, selbst wenn ich nebenbei in Outlook Mails lese oder
Word-Dokumente mit Visio-Grafiken bastle.
Die Daten schleife ich mit einem Kurzschlußstecker auf das gleiche
Interface zurück. Beim Empfang wird dann der 'high-performance-counter'
(oder wie das Ding noch heisst) gelesen und die Differenz gebildet. Dann
weiss ich genau, wie lange das Päckchen von der Sendeseite meines
Testprogrammes bis zur Empfangsseite unterwegs war.
Ich will euch jetzt nicht mit ALLEN Ergebnissen in epischer Breite
langweilen, deswegen kurz zusammengefasst:
COM1 auf dem Mainboard (ich musste extra noch in die EDV-Abteilung, um
mir das Slotblech mit dem Stecker zu holen, weil die normalerweise
garnicht mehr eingebaut werden... Und die waren echt froh, daß ich das
selber reinschrauben wollte...): 4-10ms Laufzeit (wenn man die
FIFO-Parameter in der Systemsteuerung richtig hindreht)
Moxa NPort-Server (über LAN): 50-800ms. Wenn man die Paketgröße auf 3
stellt, steigt die Laufzeit stetig an, weil all die kleinen Paketchen
garnicht mehr übers LAN passen. Indiskutabel.
USB-RS232-Wandler mit FTDI-Chip: 4-6ms Laufzeit.
Und nein, ich habe bewusst keinen billigen Sching-Ping-Billig Adapter
von Reichelt für 3,95 verwendet, weil da Prolific oder SciLabs oder
irgendwas noch viel grauslicheres samt unsäglich behindertem Treiber
hintersteckt...
(Prolific erkennt z.B. gerne mal eine Maus anstatt eines GPS-Empfängers.
Windows kann man das ja abgewöhnen, aber bei Prolific erledigt das schon
der Treiber, was für eine Kacke!)
Hier zuhause mache ich 1Mbps full duplex mit Windows und FTDI.
Und: Es gibt USB-seriell-Konverter mit FTDI-Chipsatz 8-fach für
Rackmontage. Habe ich schon mal bestellt.
Morgen werde ich eine 8fach-seriell-PCI-Karte in meinen Rechner
schrauben (wo war hier nochmal der Kasper mit den Interrupts? Es gibt
nur zwei Interrupts für serielle Schnittstellen und so??? Willkommen im
Jahre 2000+ als PCI und Interruptsharing schon erfunden waren... selbst
1992 habe ich schon ISA-Karten mit 4 seriellen Schnittstellen (und
shared Interrupt) benutzt. Erfolgreich.)
OK. Ich gebe zu: Ich benutze magisches Geheimwissen! Z.B. wie eine
serielle Schnittstelle funktioniert. Und das Windows API. Ja wie
altmodisch ist das denn??? Ich habe das alles untenrum selber
programmiert und keine fertige (Java)Klassenbibliothek benutzt! Das ist
ja fast schon unfair gegenüber den heutigen Hochschulabsolventen!
Auf der anderen Seite sehe ich das auch als Herausforderung an. Wir
haben das Problem ja bereits 1994 mit einer VME-Bus Kiste hinlänglich
gelöst. Die Herausforderung ist nicht, das Problem zu lösen, sondern es
unter Win7 mit COTS-Hardare zu lösen.
Für mich sieht es aber lösbar aus :-)
IdS!
Vielen Dank für die Anteilnahme (Und die Einsichten in die diversen
menschlichen Verhaltensweisen, z.B. eine Antwort parat zu haben, noch
bevor man die Frage gelesen, geschweige denn verstanden, hat)
Baku
Das schafft ein einzelner AVR mit genügend Pins, und zwar locker. Wenn er nur empfangen muss, kann man sich sogar die Pegelwandler sparen.
:
Wiederhergestellt durch Moderator
defekt schrieb: > Das schafft ein einzelner AVR mit genügend Pins, und zwar locker. Wenn > er nur empfangen muss, kann man sich sogar die Pegelwandler sparen. JA, und ich kann mir auch eine Schnarbelhültze um den Schmurkel binden, oder die Garpatzten verhöhnen. MENNO!!! Liest hier eigentlich irgendein Spacko die Posts, auf die er antwortet???
:
Wiederhergestellt durch Moderator
M_ schrieb: > Ich würde das mit einer Soft-SPS wie Beckhoff TwinCAT machen. IO kannst > du reichlich anschließen, die RS232 sind einzeln austauschbar, EMV fest, > keine Treiberprobleme, Echtzeituhr in der RT-Laufzeit, Industrie-PC mit > Windows, SPS-Programm und dazu ein kleines .NET Programm welches die > Daten aus der SPS abholt und dann per LAN verschickt. > Das Programm kannst du dann auch in Java schreiben. genau das würde ich dir auch vorschlagen. An jede Datenquelle einen EtherCat-Koppler oder einen CX, via Netzwerk an den Master( ein normaler Windows-PC mit Twincat). Geht auch über VPN durch die ganze Welt. Am Besten, du ruftst einfach mal beim Beckhoff-Support an und schilderst dein Vorhaben. Die werden dir sicherlich sagen können, ob das machbar ist. Gruß Tom
@Baku M. Nachdem Du ja ohnehin klüger als alle anderen bist, warum frägst Du eigentlich hier? So ein überhebliches Getue habe ich ja ganz besonders gerne... Nimm Dein Windows und werde glücklich (oder eben auch nicht). OK, ich muss zugeben, unsere Versuche waren damals mit Windows XP, aber dass Windows 7 so viel besser ist in diesem Punkt glaube ich einfach mal nicht. Vermutlich wird Dein High-Performance-Counter nicht in Hardware vorhanden sein und per Software emuliert, was Dein Messkonzept ein wenig sinnfrei macht. Aber wie gesagt: Versuch's mit Windows - vielleicht klappt's ja. Und falls es schief geht, hast Du ja ein paar brauchbare Tipps bekommen.
Nunja - man kann ihn verstehen. Er schreibt ja ausdrücklich er kann/darf/will es nicht mit selbstgestrickter Hardware lösen (es soll Firmen geben wo es einzuhaltende Regeln gibt.....) und jeder dritte schreibt was von ATMega, ARM, MIPS, blah blah... was soll man da noch als Fragender von halten? ;)
Oliver Lehmann schrieb: > Nunja - man kann ihn verstehen. Er schreibt ja ausdrücklich er > kann/darf/will es nicht mit selbstgestrickter Hardware lösen (es soll > Firmen geben wo es einzuhaltende Regeln gibt.....) und jeder dritte > schreibt was von ATMega, ARM, MIPS, blah blah... was soll man da noch > als Fragender von halten? ;) Ach, ich danke dir für dein Verständnis! Damit hat sich die Beantwortung obigen Postings auch erübrigt ;-) Nichtsdestotrotz werde ich hier die weiteren Ergebnisse posten, nur für den Fall, daß mal wieder jemand in eine ähnlich mißliche Lage kommt wie ich gerade... IdS, besten Dank an alle und Oliver insbesondere! Baku
nur so interessehalber: wie ist eure/deine Erfahrung mit des USB-Serial Adaptern und windows 7 ich hab bisher keinen gehabt (egal ob FDTI oder Profilic, mehr gibt es eh nicht??), der länger als ein paar tage "durchgehend" funktioniert hätte... (standby usw. natürlich ausgeschaltet) ich hab es aber auch immer nur mit einem Acer REvo getestet, u.U: ist der schuld?
@Baku
Ich kann Dir zwar bei Deinem Problem nicht helfen, aber dennoch hat es
sich
gelohnt, den Thread zu lesen -vor Allem wegen diesem Satz:
Zitat:>A, und ich kann mir auch eine Schnarbelhültze um den Schmurkel
>binden, oder die Garpatzten verhöhnen.
Das ist von so irrsinniger sprachlicher Schönheit...
;-)
MfG Paul
Mein Vorschlag: Hardware: - 1x Exsys EX-44032 RS232 Controller. Das Teil hat jeweils 32x RS232 Ports - 1x serielles GPS/DCF77-Device für die Zeit - Einen normalen Intel Industrie-PC mit 1x PCI-E auf dem Mainboard Software: - Scientific Linux mit einem RT_PREEMPT Kernel Begruendung: Linux nimmt dir das komplette Management für die serielle Karte ab und lässt die interne Zeit mittels GPS/DCF77/NTP synchronisieren. Damit wäre die HAL-Schicht schonmal im Eimer. Dadurch das Scientific Linux ein Redhat-Klon ist, wird dir API-Stabilität für grob 10 Jahre garantiert - aktuelle Sicherheitslücken werden aber zeitnah korrigiert. Das macht, wenn die Laube einmal läuft, das Leben ziemlich leicht. Mit der Linux-Echtzeiterweiterung kriegst du verdammt kleine Jitterzeiten im ~100-300uS Bereich für periodische Tasks hin, d.h. deine Geschichte mit vielen Milisekunden ist damit auch erledigt. Dadurch das Linux dir bestehende APIs für die serielle Konsolen als auch die Zeit und das Netzwerk anbietet, muss sich dein bezahlter Entwickler nur noch um die eigentliche Sychronization und die Erstellung der Datenpakete kümmern.
Weiterer Vorteil von meinem Vorschlag: Für alles gibt es Second-Source Lieferanten: - Die serielle Schnittstelle ist ist austauschbar, höchstens die Device-Namen müssen vielleicht verändert werden - Mainboard allesamt Peripherie ist austauschbar D.h. wenn es einmal läuft, freut sich der Praktikant wenn er es auf neuere Hardware upgraden darf. Alles ziemlich schmerzfrei. Zudem gibt es freie Compiler als auch ausgiebigste Tools, die die Entwicklung unterstützen.
Um fair zu bleiben, der Multimedia Timer unter Windows erfüllt auch die Anforderungen, ist zwar nicht in Java programmierbar, dafür kann es auf den so von BWL heissgeliebten Windows PC laufen. Wenn dann die RS232 Karten die Addressen in den Ram bereich verschoben werden greift dann auch nicht mehr der legacy 1ms timeout bei HW-zugriffen, und damit sind dann die hw-rs232 Schnittstellen mit 1ms Auflösung registrierbar. Wenn man das mit dem Adressraum nicht hinbekommt, dann braucht der Zugriff schon 25mS und man ist außer Spezifikation.
pic tech schrieb: > Um fair zu bleiben, der Multimedia Timer unter Windows erfüllt auch die > Anforderungen, ist zwar nicht in Java programmierbar, dafür kann es auf > den so von BWL heissgeliebten Windows PC laufen. Yepp, so isses. Mit dem 1ms MM-Timer kann man dann ein Event setzen, das, ausreichende Priorisierung des Threads vorausgesetzt, in unter 100us abgefrühstückt wird. > Wenn dann die RS232 Karten die Addressen in den Ram bereich verschoben > werden greift dann auch nicht mehr der legacy 1ms timeout bei > HW-zugriffen, > und damit sind dann die hw-rs232 Schnittstellen mit 1ms Auflösung > registrierbar. Wenn man das mit dem Adressraum nicht hinbekommt, dann > braucht > der Zugriff schon 25mS und man ist außer Spezifikation. Neenee, auf die Hardware sollten schon die Treiber zugreifen, dafür gibt es sie ja. Die dürfen dann auch deutlich schneller... Außerdem muß man das ganze direkte Handling ausserhalb der Windows-Messagepumpe erledigen, sonst haut das natürlich niemals hin. Ich bin jetzt bei max. 3ms Verzögerung, im Mittel 1ms. Es laufen 6 Instanzen auf 6 Ports, die Anzahl hat aber keine merklichen Auswirkungen auf die Reaktionszeit. Und die CPU-Auslastung liegt bei 0%... Übernächste Woche bekomme ich eine 32-fach PCIx-Karte, dann wird es richtig spannend!!! IdS, Baku
Robert L. schrieb: > nur so interessehalber: > > wie ist eure/deine Erfahrung mit des USB-Serial Adaptern > und windows 7 [...] > ich hab es aber auch immer nur mit einem Acer REvo getestet, u.U: ist > der schuld? Keine Ahnung. Wir haben aber FDTI mit Win7 am laufen, und die laufen durchgehend (wochenlang...) und haben noch nie Probleme gemacht. Sind aber auch fest installiert und werden nicht bewegt, ebnso werden keine anderen USB-Geräte an- oder abgesteckt. Ich habe aber von vornherein auf FTDI bestanden, alles andere ist Käse...
Rufus Τ. Firefly schrieb: > Dani schrieb: > >> Leider wird die Tool-Lib wxWindows nicht mehr weiterentwickelt, seit es >> QT frei gibt. > Sie heißt seit einigen Jahren wxWidgets, und wird durchaus > weiterentwickelt; die letzte Version ist 2.9.3 vom Dezember letzten > Jahres. > http://www.wxwidgets.org/ nun ja, die 3.0 ist seit 2009 angekündigt! eugler schrieb: > Hmmmm. IMHO ist das bei weitem nicht trivial. Man braucht ja eine > "Instanz", die sowohl die Telegramme als auch die Zeitinformation > parallel abfragen bzw. annehmen kann. Das bedeutet, diese Instanz muss > den "internen" Zeitstempel halten, und der muss genau sein. > > IMHO geht das nur über eine FPGA Lösung in Verbindung mit einer sehr > genauen Zeitquelle. oder mit einem Stempel in den Daten selber, die die Quellen einprägen. So sollte man sowas nämlich lösen, wenn es ordentlich sein soll. Das Ganze Kartengedöhns über Treiber und womöglich noch Konverter mit unbekannter Latenz taugt leider nicht viel. Niemand weiss, wie der 8:1-Konverter abpollt und wann er die Daten wo einsortiert.
.. und wenn die Seriellen Daten mit Arduino direkt ann der Schnittstelle ausgelesen werden? Arduino verpasst einen "Zeitstempel" und schickt diese dann über das Ethernet-Shield an eine SQL Datenbank im Interet per GET. lala.php?schnittstelle=1&Zeit=11.07.2012-08.55&daten=irgendwas Kosten Hardware ca 60 Euro - Programmierung 20min. Gruß Peter
Baku M. schrieb: > Über 24 serielle Schnittstellen laufen mit max. 9600bps Datentelegramme > ein, die jeweils aus 3 Byte bestehen. Ich schlage einen einfachen seriellen Terminal-Server vor: 24 x RS232, 1 x ETH, zum Beispiel: http://www.perlesystems.de/products/Terminal-Server.shtml Dann schreibst Du Dein Windows-Programm, welches sich über IP mit den 24 Ports verbindet und sammelst die Daten ein. Das schöne an der Lösung: Die Schnittstelle ist betriebssystem-unabhängig. Gruß, Frank
Baku M. schrieb im Beitrag ganz oben #2730653: > Diese Daten müssen !Zeitrichtig! zusammengefasst werden, mit einem > Zeitstempel (Da ist die über GPS synchronisierte Systemuhr genau genug) Frank M. schrieb: > Dann schreibst Du Dein Windows-Programm, welches sich über IP mit den 24 > Ports verbindet und sammelst die Daten ein. Das schöne an der Lösung: Zeitrichtig?
oszi40 schrieb: > Frank M. schrieb: >> Dann schreibst Du Dein Windows-Programm, welches sich über IP mit den 24 >> Ports verbindet und sammelst die Daten ein. Das schöne an der Lösung: > > Zeitrichtig? Ja, natürlich. Wo ist das Problem, 24 IP-Verbindungen gleichzeitig aufzumachen und dann per select() das Zeug so einzusammeln, wie es gerade kommt?
>Ja, natürlich. Wo ist das Problem, 24 IP-Verbindungen gleichzeitig >aufzumachen und dann per select() das Zeug so einzusammeln, wie es >gerade kommt? du siehst da keine probleme? das Hauptproblem ist mal, das: >Datentelegramme >ein, die jeweils aus 3 Byte bestehen. es gibt also genau 2 Möglichkeiten jedes der 3 Byte Pakete wird EINZELN verschickt (was nicht geht, dazu ist TCP/IP zu langsam, ..) und IMHO ist (bei 24 Verbindungen) die Reihenfolge dann trotzdem nicht garantiert.. oder die Pakete werden in TCP/IP pakete gesammelt, dann hast du aber keine Chance die Reihenfolge zu ermitteln.. welche der 2 Methoden verwendet jetzt dein "terminal-server"???
Robert L. schrieb: > du siehst da keine probleme? Nö. > jedes der 3 Byte Pakete wird EINZELN verschickt (was nicht geht, dazu > ist TCP/IP zu langsam, ..) Wieso das? Die kommen mit 9600Bd an, das entspricht 960 Byte/sec, wenn man 8BN1 rechnet. Bei 24 Datenleitungen sind das läppische 23040 Byte/sec = 23 kB/sec, diese verpacke ich in zig 3-Byte-TCP/IP-Päckchen mit bunten Schleifchen drumherum :-) EDIT: Außerdem glaube ich nicht, dass jeweils 3 Bytes in ein TCP-IP-Paket gestopft werden. Es sind zwar logisch gesehen 3 Bytes, aber der TO schreibt, dass diese fortwährend geschickt werden - ohne Pause. Der Terminalserver wird daher soviele Bytes in ein Paket stopfen, wie er gerade in der Input-Queue hat. > und IMHO ist (bei 24 Verbindungen) die Reihenfolge dann trotzdem nicht > garantiert.. Du musst sowieso lt. TO Laufzeiten messen und selbst die Zeitstempel korrigieren. So what? Meinst Du, das bekommst Du mit 24COM-Schnittstellen am PC besser hin? So oder so ist es eine anspruchsvolle Ausgabe, die Bytes in die richtige Reihenfolge zu bekommen. Aber das hat nichts mit der Hardware-Frage zu tun, sondern ist eine reine Frage der Software. EDIT: Ausserdem hat der TO überhaupt nichts dazu gesagt, wie genau das System die "Zeitstempel" auflösen soll.
>23040 Byte/sec also 7680 3Byte Pakte / Sekunde dass geht nicht mit TCP/IP über LAN >elbst die Zeitstempel >korrigieren. welche Zeitstempel? >Es sind zwar logisch gesehen 3 Bytes, aber >der TO schreibt, dass diese fortwährend geschickt werden - ohne Pause. >Der Terminalserver wird daher soviele Bytes in ein Paket stopfen, wie er >gerade in der Input-Queue hat. sag ich ja, genau das ist ja das Problem, du hast dann 24 Pakete (pro COM Port) mit jeweils z.b. 50 "3 Byte paketen" wie willst du die sortieren.. >Außerdem glaube ich nicht, keine Hardware frage, sondern eine Frage des Glaubens.. ok..
Robert L. schrieb: > welche Zeitstempel? Der TO muss die unterschiedlichen Laufzeiten berücksichtigen - z.B. bei Satellitenübertragung vs. Kabel. Er bekommt also sowieso die Daten in der falschen Reihenfolge rein - dagegen kann er nichts anderes machen, als die "Zeitstempel" ("wann wurde das 3-Byte-Paket losgeschickt") selbst auszurechnen. > sag ich ja, > genau das ist ja das Problem, du hast dann 24 Pakete (pro COM Port) mit > jeweils z.b. 50 "3 Byte paketen" > > wie willst du die sortieren.. Komisch, eben hast Du noch erzählt, dass TCP/IP zu langsam wäre... Okay, ich erklärs Dir: Ich weiß, wann ich das letzte Mal Daten von dem jeweiligen Terminal-Port gelesen habe. Diese Zeit X merke ich mir für jeden Terminal-Port. Hole ich dann beim nächsten Mal z.B. 240 Zeichen an diesem Port ab, kann ich für jedes empfangene Byte in der Queue die Zeit des Eintreffens errechnen: 1. Byte: X + 1/960 sec 2. Byte: X + 2/960 sec 240. Byte: X + 240/960 sec Ist doch nicht sooo schwierig, oder? >>Außerdem glaube ich nicht, > keine Hardware frage, sondern eine Frage des Glaubens.. ok.. So ein Terminalserver ist spezialisiert auf seine Aufgabe. Er wird seinen Job allemal besser machen als ein zusammengestöpseltes PC-System. Ich habe jahrelang mit solchen Dingern gearbeitet und war damit immer sehr zufrieden.
Frank M. schrieb: > Der TO muss die unterschiedlichen Laufzeiten berücksichtigen - z.B. bei > Satellitenübertragung vs. Kabel. 1.Die Laufzeiten können auch schwanken? Dann müßte jedes Gerät "seine Atomzeit" relativ genau mitliefern und die Differenz ähnlich dem NTP-Server nachberechnet werden? 2.Nach meiner bisherigen Erkenntnis kann man aber maximal 50% der verfügbaren Zeitfenster ausnutzen wenn es "ein wenig" funktionieren soll.
>Komisch, eben hast Du noch erzählt, dass TCP/IP zu langsam wäre...
ja, wenn man 3 byte einzeln senden würde (aber egal) im beispiel sprach
ich dann ja von 50 3-byte auf einmal...
ok, das könnte gehen, WENN zwischen den 3byte paketen keine Pausen sind
(ich bin immer davon ausgegangen, dass zwischen den Paketen auch
mal Pausen sind, hab ich wohl überlesen/missverstanden)
wenn man nämlich immer exakt genau 320 3-Byte Pakete pro Sekunde und
Kanal bekommt, ist die Aufgabe ja extrem einfach (wie du ja selber
schreibst) (egal wie man sie löst, solange man alle Daten erhält)
für so was einfaches: da wäre mir jetzt die Erstellung des Thread hier
nicht ganz klar..
oszi40 schrieb: > 1.Die Laufzeiten können auch schwanken? Der TO schrieb in seinem Eröffnungsposting: "so daß Laufzeiten von ca. 50ms bis 800ms zu berücksichtigen sind. Diese können aber für die einzelne Strecke als konstant angesehen und berücksichtigt werden." Also: für jede Strecke konstant. Außerdem hat er geschrieben, dass das Protokoll es vorsieht, Laufzeitmessungen jederzeit durchzuführen. Diese könnte man ja in regelmäßigen Abständen vorsehen, um sich selbst wieder neu zu kalibrieren. > Dann müßte jedes Gerät "seine > Atomzeit" relativ genau mitliefern und die Differenz ähnlich dem > NTP-Server nachberechnet werden? Dann ja, ist aber hier - so wie ich es verstanden habe - nicht notwendig.
Robert L. schrieb: >>Komisch, eben hast Du noch erzählt, dass TCP/IP zu langsam wäre... > > ja, wenn man 3 byte einzeln senden würde (aber egal) im beispiel sprach > ich dann ja von 50 3-byte auf einmal... Wie groß wird ein TCP/IP-Paket auf Ethernet-Ebene mit einer Nutzdatenlänge von 3 Byte? Ich glaube schon, dass ich davon ca. 7000 Stück in der Sekunde über ein Ethernet geschickt bekomme. Aber das Berechnen ist theoretischer Natur: Du bekommst in einem TCP/IP-Paket soviele Bytes, wie seit der letzten Abfrage angekommen sind - und nicht nur 3 Bytes. > ok, das könnte gehen, WENN zwischen den 3byte paketen keine Pausen sind Das schrieb der TO: es wird permanent gesendet, ohne Pausen. > wenn man nämlich immer exakt genau 320 3-Byte Pakete pro Sekunde und > Kanal bekommt, ist die Aufgabe ja extrem einfach (wie du ja selber > schreibst) (egal wie man sie löst, solange man alle Daten erhält) Ja, sie ist relativ einfach. Ich anstelle des TO würde mich auf die Software konzentrieren - und als Hardware einfach so ein serielles Terminalservergerät nehmen... ein Problem weniger.
Frank M. schrieb: > Wie groß wird ein TCP/IP-Paket auf Ethernet-Ebene mit einer > Nutzdatenlänge von 3 Byte? In einem Ethernet-Frame müssen minimal 50 Byte an Nutzdaten enthalten sein.
Chris schrieb: > In einem Ethernet-Frame müssen minimal 50 Byte an Nutzdaten enthalten > sein. nicht ganz, ein Frame muss minimal 64byte lag sein, darin kann aber nur 1 byte nutzdaten enthalten sein. Der rest wird im PAD als Dummy gesendet.
Peter II schrieb: > nicht ganz, ein Frame muss minimal 64byte lag sein, darin kann aber nur > 1 byte nutzdaten enthalten sein. Der rest wird im PAD als Dummy > gesendet. Okay, damit ergibt sich: 7680 pakete/sec * 64 Byte/Paket = 491520 Byte/sec = ~3,9 MBit/sec Das sollte schon mit 100Mbit Ethernet überhaupt kein Problem sein. Aber wie gesagt: Diese Berechnung ist rein theoretisch.
Frank M. schrieb: > Okay, damit ergibt sich: > > 7680 pakete/sec * 64 Byte/Paket = 491520 Byte/sec = ~3,9 MBit/sec dazu kommt der Paketoverhead und das ganze mal 24.
Vlad Tepesch schrieb: > dazu kommt der Paketoverhead und das ganze mal 24. ist schon alles mit drin.
Hallo alle zusammen! Erstmal vielen Dank für das Interesse, es scheint ja kein triviales Problem zu sein... @Frank: Du hast natürlich Recht, über einen Terminal-Server / TCP/IP lässt sich die Datenmenge spielend einlesen. Ist bei uns auch die bevorzugte Lösung (Wir haben noch andere Systeme mit VIELEN seriellen Schnittstellen, Erbe der grauen Vorzeit), weil man keine Schnittstellenkarten in den Rechner würgen muß und die Verarbeitungssoftware räumlich völlig von den Hardwareanschlüssen entkoppelt ist. In genau diesem Fall geht das aber nicht, weil die Zeit, die ein empfangenes Byte (oder 3Byte-Telegramm) von der Schnittstellenbuchse bis es in der Software auftaucht, irgendwo zwischen 50ms und über 800ms (gemessen) liegt und völlig unvorhersehbar ist. (in TCP-Pakete packen, 2 mal über einen TCP/IP-Stack, über LAN und evtl.Switche...) Kein Problem, die Daten kommen ja 'Byte an Byte', da brauch ich also nur die Telegramme zählen, und weiß, wo ich bin. Eine Pufferung aller Daten mit anschließendem zeitrichtigem Zusammenfügen muß die Software sowieso machen, das ist ja die eigentliche Hauptaufgabe. Dabei gibt es dann 2 Probleme: - Die Datenraten werden von den Sendern vorgegeben, werden also geringfügige Abweichungen untereinander haben. Und schon laufen sie nach einiger Zeit auseinander, weil ein absoluter Zeitbezug fehlt. Der Fehler wird also mit der Zeit immer größer. - Viel Schlimmer: Es muß ja einmal ein gemeinsamer Startzeitpunkt für alle Daten festgelegt werden, ab dem mit der Zählung begonnen werden kann. Das ginge evtl. über die Laufzeitmessung, die allerdings nur über eben diese seriellen Schnittstellen durchgeführt werden kann. Damit bekommt man also, völlig unabhängig von der Laufzeit, einen Fehler von 2*(20...500ms) rein, der sich auch nicht mehr auflösen lässt. - Kurzzeitge Unterbrechungen des Datenstroms sind jederzeit möglich, auch sollte das Aus- und Wiedereinschalten eines Sensors keine Neukalibration erforderlich machen. Der Fall 'Keine Daten von Sensor X' ist in der weiteren Verarbeitung durchaus vorgesehen. -> Ergebnis: Das geht so nicht, und mir ist bislang kein Softwaretrick eingefallen, mit dem sich diese fehlende Information beschaffen liesse. Ich bin natürlich für jeden Geistesblitz dankbar, wenn ich der Meinung wäre, ich wüsste schon alles, würde ich ja hier nicht fragen ;-) Falls ich vergessen hatte, es zu erwähnen: Die maximal tolerable Abweichung liegt so bei ca. 10-15ms, und die Laufzeitmessung kann max. einaml am Tag ausgeführt werden, weil dann das System natürlich keine Nutzdaten liefert. Nächste Woche bekomme ich eine 32-fach PCIe-Karte und werde mal messen, wie schnell (und vor allem wie reproduzierbar) ich die Daten damit von der Buchse in die Software bekomme. Sollte das nicht hinzukriegen sein, dann werde ich den Moxa mit dem Embedded Linux nehmen. Der kann dann schön die Telegramme zu Paketen zusammenfassen und Zeitstempel dranmachen... Ich werde berichten! Einstweilen schönes Wochenende Baku P.S.: Und in ca.3 Jahren will der Kunde das Geld für neue Sensoren zusammen haben, die machen dann gleich an Ort und Stelle GPS-Zeitstempel an die Daten und verschicken sie über TCP/IP... Das wird schön :-)
Baku M. schrieb: > -> Ergebnis: Das geht so nicht, und mir ist bislang kein Softwaretrick > eingefallen, mit dem sich diese fehlende Information beschaffen liesse. Evtl. Tabelle mit letztem oder voreingestellten Wert füllen damit kein Loch entsteht? Kritisch wird die ganze Sache wenn die Zeitfenster zu knapp werden. Habt Ihr ein Echtzeitsystem laufen oder ein normales Betriebssystem? Beim normalen Windows wird die Auswertung wohl nicht so genau werden, weil das System andere Prioritäten hat. http://de.wikipedia.org/wiki/Echtzeitbetriebssystem
Baku M. schrieb: > Kunde Ich bin ja echt nicht kleinlich bei Non-Profit-Projekten und gebe dort auch gerne ehrenamtlich Support, aber wir sollen dir kostenlos bei einem kommerziellen Projekt helfen und eine nahezu fertige Problemlösung vorkauen und du streichst die Prämie dann ein?!
oszi40 schrieb: > Baku M. schrieb: >> -> Ergebnis: Das geht so nicht, und mir ist bislang kein Softwaretrick >> eingefallen, mit dem sich diese fehlende Information beschaffen liesse. > Evtl. Tabelle mit letztem oder voreingestellten Wert füllen damit kein > Loch entsteht? Dazu müsste man dann wissen, wie lang die Lücke ist, und da beisst sich die Katze wieder in den Schwanz... > Kritisch wird die ganze Sache wenn die Zeitfenster zu knapp werden. Habt > Ihr ein Echtzeitsystem laufen oder ein normales Betriebssystem? Beim > normalen Windows wird die Auswertung wohl nicht so genau werden, weil > das System andere Prioritäten hat. > http://de.wikipedia.org/wiki/Echtzeitbetriebssystem Nönö. Ist schon ein stinknormales Windows, vulgo kein 'Echtzeitbetriebssystem'. Da aber die Reaktionszeiten (bei richtiger Programmierung) ausreichen, um Audio- und sogar Videowiedergabe knacks- und ruckelfrei hinzukriegen, sollte diese eher harmlose Aufgabe auch damit lösbar sein. Wie bereits oben erwähnt: Das Senden über einen ComPort am PCI-Bus bekommt man auf unter 100us genau hin, auch wenn aller möglicher Kram nebenbei läuft.
Atmeltierchen schrieb: > Baku M. schrieb: >> Kunde > > Ich bin ja echt nicht kleinlich bei Non-Profit-Projekten und gebe dort > auch gerne ehrenamtlich Support, aber wir sollen dir kostenlos bei einem > kommerziellen Projekt helfen und eine nahezu fertige Problemlösung > vorkauen und du streichst die Prämie dann ein?! Wo war von 'fertiger Lösung vorkauen' die Rede und 'Prämie einstreichen'? Hier werden häufig genug Themen aus dem professionellem Bereich diskutiert, wenn du daran nicht teilnehmen willst, ist das deine Sache. Ansonsten: http://fotos.mtb-news.de/p1/911406 IdS, Baku
Angehängte Dateien:
So höret denn, all ihr Verzagten, Zweifler und Ungläubigen: Das große Rätsel ist gelöst! Es geht! Mit Windows. Man muß das nur können. Und Threads ohne irgendeine durch eine virtuelle Maschine aus dem Internet heruntergeladene Klassenbibliothek einfach nur durch Betriebssystemaufrufe erzeugen. Das geht! Events werden in unter 100us gemeldet, wenn der wartende Thread ausreichend priorisiert ist. Außerdem muß man noch Glück mit der Interfacekarte haben, viel mehr noch mit den Treibern. Und alle 64 FIFOs per Hand auf 3 Byte stellen. @atmeltierchen: Ich streich jetzt meine Prämie ein, und wer wissen will, wie ich das gemacht habe, dem verrate ich es gerne. :-)
Baku M. schrieb: > Ich streich jetzt meine Prämie ein, und wer wissen will, wie ich das > gemacht habe, dem verrate ich es gerne. Ja, erzähl doch mal!
Baku M. schrieb: > Ich streich jetzt meine Prämie ein, und wer wissen will, wie ich das > gemacht habe, dem verrate ich es gerne. Glückwunsch - trotz meines Gepampfes ;-)
Atmeltierchen schrieb: > Glückwunsch - trotz meines Gepampfes ;-) Nix für ungut, immerhin hattest du ja auch schon die EX-44032 vorgeschlagen. Wer konstruktiv ist, darf auch nörgeln ;-) Ach ja: Ich benutze jetzt die Exsys EX-44023 in meinem relativ-standard Windows7/64 Arbeitplatzrechner. Programmiert wird in VC++/VS2010 als 32Bit-Applikation, damit man auch rückwärtskompatibel ist. Die COM-Ports werden mit CreateFile(..) und overlapped IO geöffnet. Dazu gibt es bei Microsoft einen Beispielcode, der auch die Initialisierung des Ports und die Behandlung der CommEvents beschreibt, als Einstieg. Müsste ich ggfs. raussuchen. Dabei sind einige Feinheiten zu optimieren, aber das geht jetzt sehr ins Detail. Dann werden pro Port 2 Threads erzeugt, von denen einer für den Empfang (und die anderen CommEvents) zuständig ist, der andere fürs zeitgenaue Senden. Die Threads werden auf THREAD_PRIORITY_ABOVE_NORMAL gesetzt. Eine weitere Erhöhung der Priorität bringt keinen messbaren Vorteil. Der Empfangsthread wartet mit WaitCommEvent(..) auf ein Ereignis (vorzugsweise das Eintrudeln von Daten), holt die Daten ab und verarbeitet sie. -Das WaitCommEvent(..) wurde übrigens im M$-Beispielcode vergessen, weswegen das nichts als eine Pollingschleife in einem separaten Thread ist, unheimlich effizient... Da die FIFOs der Karte auf 3 Byte gestellt sind, kommen die Daten immer 3-Byte-Weise, genau die Telegrammlänge. Die Reaktion auf das EV_RXDATA, d.h. wenn 3 Bytes da sind, dauert im Mittel unter 1ms, maximal 4ms (Wenn alle 32 Ports laufen). Der Sendethread wartet auf ein Event, welches von einem Multimedia-Timer gesetzt wird. CreateWaitableTimer(...) würde zwar das gleiche tun, nämlich nach Ablauf der Zeit ein Event setzen, ist aber eine Katastrophe, weil die Timerauflösung recht unvorhersehbar ist, und statt 4ms auch mal 15ms gewartet wird. Ist für solche Zeiten völlig unbrauchbar! Mit einem Multimedia-Timer und einem eigenem Thread kommt man auf >100us wiederholgenauigkeit beim Senden. Oszilloskopisch geprüft, sehr zur Verwunderung der Informatiker unter den Kollegen... Was noch? Die Zugriffe auf das File (oder besser den Port) aus den beiden Threads sollte man mit einer CriticalSection gegeneinander abschotten. Und so läuft das denn. Eine große Unbekannte bei der ganzen Geschichte sind natürlich die Treiber und deren Integration ins OS, aber ExSys scheint da garnicht schlecht zu sein. Hoffe, daß irgendwem diese Hinweise irgendwann mal helfen mögen! IdS, Baku
Baku M. schrieb: > Was noch? Die Zugriffe auf das File (oder besser den Port) aus den > beiden Threads sollte man mit einer CriticalSection gegeneinander > abschotten. ich hätte gedacht es es ebend bei overlapped IO nicht notwendig ist.
Peter II schrieb: > ich hätte gedacht es es ebend bei overlapped IO nicht notwendig ist. Hm... Da bringst du mich ins grübeln... Ich habe auf die schnelle nichts gefunden, ob lesen und schreiben auf das gleiche File bei overlapped IO thread-safe ist. Generell ist es aber eine gute Idee, bei Zugriffen auf die gleiche Ressource aus verschiedenen Threads diese gegeneinander zu verriegeln. Da die Zugriffe bei overlapped IO nicht blockierend sind, geht da auch kaum Zeit verloren, und es kann -im Falle daß sie nicht thread-safe sind- langwierige, lästige Suche nach sporadisch auftretenden Fehlern ersparen. Hat vielleicht jemand definitive Informationen dazu? fragt Baku
Hi ich habe nicht Alles gelesen (!). Ich hab mal sowas vor 25 Jahren gemacht. Warum nimmst du nicht einfach einen Terminalserver zB.: http://www.perlesystems.de/products/Terminal-Server.shtml oder ähnliches, mache ich derzeit im Heimbereich mit rs232 to Ethernetconverter..... Ich hatte damals einen 16fachen und das hat super funktioniert....
@ womisa du brauchst ja nicht alles lesen, aber suche zumindest den link den du gepostet hat in dem thread...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.