Hallo Forum, ich suche eine Möglichkeit die Systemzeit eines x86-x64 (auch amd64 genannt) Linux PCs möglichst genau mit einem PPS (pulse-per-second) Signal eines uBlox8 GPS Receivers zu synchronisieren. Der PC soll dann als IEEE1588 time grandmaster arbeiten und die Zeit per Netzwerk weitergeben. Bei einem Raspberry Pi ist PPS kein Problem, da kann man einen GPIO nehmen und muss dem PPS Kernel-Modul nur die Pin-Nummer konfigurieren. Leider haben die Raspis kein IEEE1588 Hardware-Sync tauglichen Netzwerkkarten (bis auf den CM4). Für x86 System gibt es ähnliche Lösungen, z.B. kann man den DCD oder RI Pin einer seriellen Schnittstelle verwenden. Zu ISA Zeiten wurde von serial chip 8250/16550 direkt ein Interrupt ausgelöst, wenn DCD oder RI signalisiert wurde. Heutzutage sind UARTs aber ggf. über USB oder PCIe angebunden. Es wird bei den heutigen PC Rechnern immer schwieriger eine kurze Reaktionszeit zwischen der Flanke des PPS Signals und dem Auslesen der Systemtime bzw. eines TSC oder anderen Timers hinzubekommen. Ich bin mir nicht sicher, wie genau das PPS Signal des GPS Receivers ist, 1us sollte aber m.E. machbar sein. Wenn da aber noch komplexe Busprotokolle wie PCIe und die Interrupt-Reaktionszeit der CPU dazukommen, dann wird es wohl schwierig dies zu erreichen. Meine Idee ist, die Erfassung des PPS Zeitpunktes nicht direkt über den Zeitpunkt des IRQ zu machen sondern bei der PPS Flanke den Zählerstand des TSC (oder eines besser passenden Timers) in einem Latch zu speichern, danach kann man dann in aller Ruhe die Phasenlage des TSC zum Anfang der Sekunde zu ermitteln. Ich befürchte nur, dass es da nichts dazu gibt. Eine andere Möglichkeit wäre, wenn ein PC Timer ebenfalls ein PPS Signal erzeugen würde, dann könnte ich mit einer externen MCU die Phasenlagen der beiden PPS Signale vergleichen z.B. über Input Capture des AVR. Hat jemand eine Idee, wie man das GPS Receiver PPS Signal möglichst latenzfrei im PC auswerten kann? Es wird eine DIY Bastellösung gesucht, keine fertigen Karten von Meinberg oder anderen Anbietern. Es geht mehr um das Interesse wie das am besten gehen kann um was zu lernen. Michael
:
Bearbeitet durch User
Wäre es eine Option, einen Ethernet-fähigen µC zu nehmen, dort das PPS-Signal auszuwerten und den IEEE1588-Master zu machen? Das sollte auch nicht so schwierig zu implementieren sein, wenn man den best-master-clock-Algorithmus nicht braucht.
Rolf M. schrieb: > Wäre es eine Option, einen Ethernet-fähigen µC zu nehmen, dort das > PPS-Signal auszuwerten und den IEEE1588-Master zu machen? Ja, das wäre die Rückfallstrategie. Ich habe hier noch einen Banana Pi R1, theoretisch könnte das mit dem funktionieren. Es interessiert mich nur, ob das mit X86 Hardware wirklich so schwer ist, oder ich die einfachen Lösungen nur nicht sehe. Michael
Man braucht eine parallel karte MIT msi-X dann geht es.
Michael D. schrieb: > ... > Es interessiert mich nur, ob das mit X86 Hardware wirklich so schwer > ist, oder ich die einfachen Lösungen nur nicht sehe. > ... Das hängt von deinem Linux ab. Es gibt echtzeitfähige Linux. Das ist Voraussetzung dafür, wiederholbar genau arbeiten zu können. Wie genau, sagt dir dann das Linux.
Chris schrieb: > Man braucht eine parallel karte MIT msi-X dann geht es. Hast du da einen Anhaltspunkt, welche Karten bzw. Chipsätze das sind? Bei Amazon habe ich mal gesucht und folgende Karten gefunden: mit Chipsatz MCS9901 => siehe https://bz-attachments.freebsd.org/attachment.cgi?id=106094 - Digitus DS-30020-1 mit Chipsatz WCH382L => siehe http://www.wch-ic.com/products/CH382.html - DeLock 90412 - Donkey PC Beim MCS9901 steht was von MSI im Datenblatt drin, aber kein MSI-X. Macht das einen Unterschied bei der Interrupt-Latenz? Michael
MSI ist ein Halbleiterhersteller, MSI/MSI-X ist eine HW/Driver Spec von Intel, welche die (L)APIC benutzt, also out of band multiprocessor Speicher update interface. Das muss man aufpassen dass dies nicht verwechelt wird. https://www.intel.com/content/dam/www/public/us/en/documents/white-papers/msg-signaled-interrupts-paper.pdf https://www.mouser.com/datasheet/2/38/XPCIe840_Product_Brief-8949.pdf Es gibt genug boards im Preis Segment von 11-12 Euro mit solchen Chips die das haben, da sind teilweise die Lieferkosten entscheidend dass man hier oder dort das Produkt bevorzugt. Auch gibt es diverse Mainboards, welche mit MSI/MSI-X probleme haben, oder Chipsets/Bridges , dies darf man nicht aus den Augen lassen, https://www.kernel.org/doc/html/v5.8/PCI/msi-howto.html Auch musst du den Adress Range der Karte beachten, ihn vom legacy in den memory Bereich verschieben, denn sonst werden kuenstliche delays eingefuehrt. Ob jetzt parallel oder Serial, das ist egal, nur der Pegelwandler von 0.7V zu 3.3V ist einfacher fuer high speed als der zu 10V, wo der Rise time und die threshold voltage schon jitter verursachen.
zur Software: hier habe ich was gefunden um einen PPS zu erzeugen: https://www.eevblog.com/forum/metrology/pps-output-using-linux-on-a-pc/
Macht es Sinn einem PC eine Genauigkeit von 1us aufdruecken zu wollen, obwohl er damit nichts anfangen kann ? Es gibt mehr oder weniger gar nichts im PC, das damit etwas anfangen kann. Ein Windows Desktop hat eine Zeitscheibe von 10ms, ein Windows Server eine von 50ms. Irgendwelche Hardware, welche das koennen soll, muss ausserhalb eines Windows sein. zB ein ATMega, oder ein PIC. Fuer erhoehte Anforderungen ein FPGA.
Flachtroll schrieb: > Macht es Sinn einem PC eine Genauigkeit von 1us aufdruecken zu wollen, > obwohl er damit nichts anfangen kann ? Ja, es geht um einen Linux PC welcher auch den PREEMPT RT Patch hat, da macht das Sinn. > Es gibt mehr oder weniger gar nichts im PC, das damit etwas anfangen kann. Doch, der Haupt-Usecase für diesen Rechner ist grandmaster für eine IEEE1588 Zeitsynchronisation. Eines der Ziele des Experiments ist zu kären wie weit man damit kommt und ob es überhaupt Sinn macht, d.h. ob der Aufwand für IEEE1588 den Vorteil gegenüber NTP Wert ist. Einer der Unterpunkte ist, wie hoch die Reaktionszeit eines PCs auf externe Ereignisse ist bzw. wie schnell mal Signale ausgeben kann, d.h. wie hoch jeweils die Latenzzeit ist. Michael
:
Bearbeitet durch User
> Bei einem Raspberry Pi ist PPS kein Problem, da kann man einen GPIO > nehmen und muss dem PPS Kernel-Modul nur die Pin-Nummer konfigurieren. Ich wuerde mal bezweifeln, dass die Qualitaet der an der Takterzeugung beteiligten Komponenten das wirklich hergibt. Ein Controller der von einem nachstimmbaren OCXO getaktet wird, waere wohl passender. Dann muesste man den Jittereintrag der durch die PLLs zur internen Taktversorgung hervorgerufen wird, evaluieren. Ich glaube, du stellst dir das alles zu trivial vor. Genaue Zeit ist eine grosse Herausforderung.
Michael D. schrieb: > grandmaster arbeiten und die Zeit per Netzwerk weitergeben. "Sehr GENAU" scheint mir etwas optimistisch, wenn ich nur an unterschiedliche CPU-Befehlsausführungszeiten und einen Ping mit 10ms denke. Das soll aber nicht heißen, dass es evtl. eine NTP-ähnliche Lösung geben könnte? https://de.wikipedia.org/wiki/Network_Time_Protocol Nützlich wäre jetzt evtl., die Differenzen zwischen Deiner Zeit und der NTP-Zeit längere Zeit auszuwerten, um grundsätzliche Fehler wie Schaltsekunden usw. zu erkennen.
oszi40 schrieb: > Michael D. schrieb: >> grandmaster arbeiten und die Zeit per Netzwerk weitergeben. > > "Sehr GENAU" scheint mir etwas optimistisch, wenn ich nur an > unterschiedliche CPU-Befehlsausführungszeiten und einen Ping mit 10ms > denke. Bei mir liegen die Pings im lokalen Netz je nach Rechner eher bei 100 bis 300 µs. Ist halt kein Windows. > Das soll aber nicht heißen, dass es evtl. eine NTP-ähnliche > Lösung geben könnte? https://de.wikipedia.org/wiki/Network_Time_Protocol IEEE1588 alias PTP macht das gleiche win NTP, nur sehr viel präziser. Für die hohe Genauigkeit erfordert es aber einen Netzwerk-Adapter mit Hardware-Zeitstempel, da die Durchlaufzeit durch den IP-Stack und selbst die Softare-Zeitstempelung im Receive-Interrupt zu latenzbehaftet ist. Wir sprechen dann aber auch von Genauigkeiten im Nanosekunden-Bereich.
:
Bearbeitet durch User
Rolf M. schrieb: > Bei mir liegen die Pings im lokalen Netz je nach Rechner eher bei 100 > bis 300 µs. Ist halt kein Windows. Kommt ganz darauf an, welche Hardware dazwischen ist. Trotzdem habe ich noch leichte Zweifel bei ns-Genauigkeit z.B. bei höherer Netzlast und eventuellen Paketverlusten.
oszi40 schrieb: > Kommt ganz darauf an, welche Hardware dazwischen ist. Ein Switch erzeugt eine gewisse Latenz, insbesondere wegen store-and-forward. Bei mehreren Switches erhöht sich das entsprechend. Hab grad mal hier in meinem Heimnetz etwas gepingt: Bei einer Verbindung über den eingebauten Switch eine Fritzbox plus einen zusätzlichen billig-Switch messe ich ca. 340 µs im Schnitt. Bei einem anderen Zielrechner, der direkt an dem Switch hängt (also ohne die Frizbox) messe ich ca. 70 µs weniger. > Trotzdem habe ich noch leichte Zweifel bei ns-Genauigkeit z.B. bei > höherer Netzlast und eventuellen Paketverlusten. Die sollten an sich keine Rolle spielen. Wenn ein Paket gesendet und auch empfangen wird, kann auf beiden Seiten der jeweilige NIC einen sehr genauen Hardware-Zeitstempel davon erzeugen. Daran ändern Netzlast und Paketverlust auch nichts, sofern die PTP-Pakete noch einigermaßen durchkommen.
Generell scheint das Synchronisieren über PPS ein größeres Problem zu sein. Wenn ich hier einen NTPd mit einem der Pools laufen lasse, fallen mir immer wieder Server auf, die stark vom PTB-NTP abweichen, sich aber mit Ref-ID .PPS. und Stratum=1 in den Vordergrund drängen wollen...
Εrnst B. schrieb: > Wenn ich hier einen NTPd mit einem der Pools laufen lasse, fallen mir > immer wieder Server auf, die stark vom PTB-NTP abweichen, sich aber mit > Ref-ID .PPS. und Stratum=1 in den Vordergrund drängen wollen... Habe ich auch gesehen. Ich denke, das liegt aber auch meiner asymmetrischen DSL Verbindung (50 MBit/s down, 10 MBit/s) up. Bei Delays im zweistelligen Millisekundenbereich ist die Aussagekraft von "offset" anzuzweifeln. Da hilft nur ein lokaler GPS Empfänger mit eigenem PPS. Michael
> billig-Switch messe ich ca. 340 µs
Von Arista gibt es "Low Latency Switche" die wenn ich mich
richtig erinnere auf Werte von ca. 500 ns kommen.
Das geht mit "Store and Forward" natuerlich nicht.
Aber "Cut Through" kann das.
Der TO sollte sich vielleicht auch mal Verfahren wie
"White Rabbit" ansehen...
Brownie schrieb: > https://blog.dan.drown.org/apu2-ntp-server-2/ > https://blog.dan.drown.org/tag/ntp/ Danke für den Tipp! Es gibt Intel I210 Netzwerkkarten, welche 4 SCP pins auf Stiftleisten rausgeführt haben: https://community.intel.com/t5/Ethernet-Products/What-is-the-ues-of-six-pins-in-Intel-i210-Ethernet-Apater/m-p/589286 Bei ebay: https://www.ebay.de/itm/274768954216?hash=item3ff9818368:g:zK4AAOSwbE5g-nu0 Michael
:
Bearbeitet durch User
Rolf M. schrieb: > Ein Switch erzeugt eine gewisse Latenz, insbesondere wegen > store-and-forward. Darum brauchst du ja auch einen Switch der IEEE1588 unterstützt. Wenn ihr IEEE1588 aka PTP nicht kennt, guckt es euch mal an, ist technisch sehr interessant, genau auch weil wir alle einig sind, dass Zeitsynchronisation nicht einfach ist. IEEE1588 ist die Grundlange unter anderem in diesen Standards: - EtherCat - LXI - AVB - TSN - AES67 - Profinet IRT Cartman schrieb: > Der TO sollte sich vielleicht auch mal Verfahren wie > "White Rabbit" ansehen... Das nimmt man, wenn IEEE1588-2008 (PTPv2) nicht mehr reicht. Ist mittlerweile auch in IEEE1588-2019 eingeflossen als High-Accuracy Erweiterung: https://ohwr.org/projects/wr-std/wiki/wrin1588 Brownie schrieb: > https://blog.dan.drown.org/apu2-ntp-server-2/ Sehr interessant. Wusste, das die Chips so etwas können aber nicht, wie weit das im Linux Kernel unterstützt wird.
Roland E. schrieb: > Das hängt von deinem Linux ab. Es gibt echtzeitfähige Linux. Das ist > Voraussetzung dafür, wiederholbar genau arbeiten zu können. Wie genau, > sagt dir dann das Linux. Naja! Linux ist, wie alle anderen unixoiden Betriebssysteme von FreeBSD bis MacOS grundsätzlich erstmal ein Time-sharing-OS! Und time-sharing-betriebssysteme eignen sich nun fuer alles, nur eben nicht für Echtzeitfähigkeit! Ich will damit sagen, dass ein "echtzeitfaehiges Linux" aus dieser Perspektive gesehen, ne ziemliche Bastelei und Gewurtschtel sein dürfte. Z.B. RSX-11 wäre ein klassisches Echtzeit-OS ( es muss ja nicht wie vor 40 Jahren auf PDP-11 Blech von DEC laufen ;-)
Christoph Z. schrieb: > Wusste, das die Chips so etwas können aber nicht, wie weit das im Linux > Kernel unterstützt wird. Was die Hardware in der Hinsicht kann, kann man unter Linux per ethtool -T herausfinden. Das sieht für den eingebauten Netzwerkadapter am PC z.B. so aus:
1 | Time stamping parameters for enp4s0: |
2 | Capabilities: |
3 | hardware-transmit |
4 | software-transmit |
5 | hardware-receive |
6 | software-receive |
7 | software-system-clock |
8 | hardware-raw-clock |
9 | PTP Hardware Clock: 0 |
10 | Hardware Transmit Timestamp Modes: |
11 | off |
12 | on |
13 | Hardware Receive Filter Modes: |
14 | none |
15 | all |
Für einen USB-Adapter (die das in der Regel nicht können) sieht es dagegen dann so aus:
1 | Time stamping parameters for enx00133ba015cc: |
2 | Capabilities: |
3 | software-receive |
4 | software-system-clock |
5 | PTP Hardware Clock: none |
6 | Hardware Transmit Timestamp Modes: none |
7 | Hardware Receive Filter Modes: none |
Allenfalls waere interessant was das Ganze soll, bevor an einer Loesung rumgedrueckt wird, die eh sinnlos ist, weil am Zweck vorbei. Nehmen wir mal an, wir haetten diesen Hypergenauen Zeitserver ... was kommt dann damit ? Diese Zeitstempel gehen an Windowssysteme ?
Pandur S. schrieb: > Nehmen wir mal an, wir haetten diesen Hypergenauen Zeitserver Wir nehmen nicht an, wir haben ihn. > Allenfalls waere interessant was das Ganze soll, bevor an einer Loesung > rumgedrueckt wird, die eh sinnlos ist, weil am Zweck vorbei. Es geht um Prozessautomatisierung. Um Abläufe genau zu synchronisieren und Daten zu erfassen kann man das entweder über einen verteilten Takt oder eben über genaue Zeitstempel machen. Ein weiterer Anwendungsfall ist das Thema Sequence of Events oder einfach nur Auswertung von verteilten Logs für die Fehleranalyse. Je nach Prozess reicht die Genauigkeit welche NTP liefern kann nicht mehr aus, da braucht man dann was besseres. Windows ist hier fehl am Platz. Eigentlich steht in meinem Eingangspost im ersten Satz nur was von Linux. Michael
:
Bearbeitet durch User
Fuer eine lokale Geschichte, wuerde ich mir den aufwenigen Mist sparen und das Signal per Hardware an Hardware verteilen, Also eigener Bus an die Messhardware. Was sollen aufwendige systeme ? Allenfalls zur lokalen Parametrisierung und visualisierung. Auch wenn das System sehr verteilt waere und man mit PPS arbeiten muesste uerde ich lokale Busse verwenden, ohne ueber Ethernet zu gehen. Das Ethernet wird wertlos sofern die Zeitstempel nicht maximal priorisiert waeren, heisst sonst nicht anderes liefe.
vlfrx kann aus den PPS pulsen an der Soundkarte die Zeit auf <100 ns genau ableiten. Da müsstest du "nur" noch eine Erweiterung für die Synchronisation mit der Systemzeit schreiben. http://abelian.org/vlfrx-tools/
> [PPS per GPS] Der PC soll dann als IEEE1588 time grandmaster > arbeiten und die Zeit per Netzwerk weitergeben. Solange sich alle an den "Großmeister" halten, ist es vollkommen egal, zu was der wie synchron ist.
foobar schrieb: > Solange sich alle an den "Großmeister" halten, ist es vollkommen egal, > zu was der wie synchron ist. In einer nicht idealen Welt kann mal leider keine Aussage über "alle" machen. Es wird sicher noch ein paar Rechner mit niedrigeren Anforderungen geben und geschlossene IoT Hardware, die nicht bei PtP mitspielt. Die unterstützen dann vielleicht nur NTP. Allerdings ist es sicher richtig, dass für Automatisierungaufgaben die PtP Timedomain zur NTP Timedomain nur so genau synchronisiert sein muss, wie die NTP Timedomain in sich, sprich ein gap von 5 ms wäre sicher verkraftbar. Wenn der PtP Timestamp um Minuten von der Wanduhr abweicht, dann ist das auch nicht gut. Michael
Flieger schrieb: > Fuer eine lokale Geschichte, wuerde ich mir den aufwenigen Mist sparen > und das Signal per Hardware an Hardware verteilen, Also eigener Bus an > die Messhardware. Was sollen aufwendige systeme ? Was es richtig aufwändig macht, ist, sich da selber was auszudenken und umzusetzen. PTP gibt's schon, ist genau dafür da und muss nur konfiguriert werden. > Das Ethernet wird wertlos sofern die Zeitstempel nicht maximal > priorisiert waeren, heisst sonst nicht anderes liefe. Nein.
Michael D. schrieb: > Es gibt Intel I210 Netzwerkkarten, welche 4 SCP pins auf Stiftleisten > rausgeführt haben: Die heißen natürlich SDP (Software-Definable Pins) und nicht SCP Pins. Michael
Hi, hier noch ein Link auf eine Master Thesis von 2013: "Hardware Assisted IEEE1588 Clock Synchronization Under Linux" von Bálint Ferencz. https://github.com/AaronWebster/igb-pps-guide Es geht speziell um die I210-T1 Netzwerkkarte und unter anderem wie man die SDP Pins für die Synchronisation Messungen konfigurieren kann. Er hat noch weitere Artikel geschrieben: https://scholar.google.com/citations?user=-1JxeGEAAAAJ&hl=en die meisten sind aber kostenpflichtig über IEEE paywall. Michael
:
Bearbeitet durch User
Michael D. schrieb: > SDP (Software-Definable Pins) Alles sehr schön, nur braucht jeder Befehl eine gewisse Zeit, die auch verschieden sein könnte. So ganz einfach wirds wohl nicht.
Flieger schrieb: > Fuer eine lokale Geschichte, wuerde ich mir den aufwenigen Mist sparen > und das Signal per Hardware an Hardware verteilen, Also eigener Bus an > die Messhardware. Die 70er Jahre möchten ihre GPIB Kabel zurück... Darauf gab es mehrere Trigger Pins für solche Zwecke. Dicke teure Kabel, Interface Chip eigentlich nur von NI produziert, maximal 15 Adressen, nur Trigger möglich aber keine Zeitsynchronisation etc.
oszi40 schrieb: > Alles sehr schön, nur braucht jeder Befehl eine gewisse Zeit, die auch > verschieden sein könnte. So ganz einfach wirds wohl nicht. Nachdem die Netzwerkkarte da nicht als dummes GPIO benutzt wird, gibt es keine Befehle. Die Pins werden von der Karte direkt aus ihrem internen Timer (SYSTIM) heraus angesteuert und der wiederum kann über PTP synchronisiert werden. https://www.mouser.com/pdfDocs/333016_I210_Datasheet_v_3_6.pdf Kapitel 7.8.3.3.3 "Synchronized Output Clock on SDP " und 7.8.3.2 "1588 Timer Registers: SYSTIM, TIMADJ and TIMINC"
Timing- und Synchronisierloesungen gibt es fuer jedes Budget, und jede Anforderung. Bisher wurden wir nur unterrichtet, dass es um ein verteiltes System geht, aber nicht ueber die Ausdehnung. Irgendwann kommt die Laufzeit rein. Den Zeitstempel iteressiert bei Echtzeitsystemen oft niemanden, sondern man benoetigt eher einen gemeinsamen Trigger, um ein Ereignis auszuloesen. Da gibt es Loesungen fuer zusammenhaengende Systeme, per Lichtfaser in den Femtosekunden Bereich hinunter. Die Frage nach dem Jitter kommt dann auf. Zeitstempel von extremhoher aufloesung werden bei nachtraeglichem Batchprozessing von aufgenommenen Daten verwendet, zb von Radioteleskopen auf verschiedenen Kontinenten
:
Bearbeitet durch User
Purzel H. schrieb: > Den Zeitstempel iteressiert bei Echtzeitsystemen oft niemanden, sondern > man benoetigt eher einen gemeinsamen Trigger, um ein Ereignis > auszuloesen. Naja, das ist ja irgendwie dann doch fast dasselbe, wenn man mehr als ein Ereignis nur alle heiligen Zeiten hat. Dann muss man anhand von Zeitstempel und einer Regel aus der Ereignisrate auf allen Devices einen sychronen periodischen Eventclock produzieren. Das gibts so bei professionellem Audio over IP (zB. Dante oder AES67) als auch bei professionellem Video (AFAIR hat zB. ARRI so ein System, um alle ihre Kameras via IP auf synchronen Shutter auch bei völlig krummen Frameraten zu bringen). Und die Anforderungen an die Synchronizität sind selbst bei langweiligen Audio mit 48-196kHz nicht ganz ohne. Der Unterschied der via PTP erzeugten Sampleclocks auf den verteilten Geräten sollte da deutlich kleiner als 500ns sein, damit der AoIP-Weg quasi einem analogen XLR-Kabel entspricht.
> Naja, das ist ja irgendwie dann doch fast dasselbe ..
Aber auch nur fast. Wenn ich Zeitstempel alle 10us, heisst 100kHz habe,
und mit 44kHz (oder 96kHz) sample, muss ich jeden einzelnen Punkt
vorwaerts interpolieren. Dann verteile ich doch besser gleich die 44kHz
(oder 96kHz), dann wird's einfacher.
Purzel H. schrieb: > Den Zeitstempel iteressiert bei Echtzeitsystemen oft niemanden, sondern > man benoetigt eher einen gemeinsamen Trigger, um ein Ereignis > auszuloesen. Echtzeitsysteme die z. B. auf EtherCAT basieren setzten eine andere Denkweise vom Entwickler voraus. Da durch die Verarbeitung und Ausdehnung Latenzen entstehen, die grösser wurden als das Zeitbudget geht man eher weg von Getriggertensystemen zu Zeitpunktgesteuerten Systemen. Dafür brauchen alle Aktoren eine synchronisierte Uhr. Die Steuerung rechnet dann aus, zu welchem Zeitpunkt welcher Aktor was machen muss und teilt dem Aktor mit, was er machen muss und zusätzlich wann er das tun soll. Klassicherweise hat ein Aktor einen Befehl bekommen und auch gleich ausgeführt. Gewisse Problemstellungen werden so massiv vereinfacht (z. B. Förderband mit synchronisierten Motoren), für andere passt dieser Ansatz nicht (schnelle Regler wo nicht mehr genug Zeit zur Verfügung steht eine Aktion in der "Zukunft" auszulösen).
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.