Wir haben eine Maschinensteuerung in der Firma die wurde vor 20 Jahren selbst entwickelt und auf FPGAs realisiert. Funktioniert bisher ohne Probleme. Teil davon ist eine Art von selbst entwickelter Feldbus der allerdings nur zwei Teilnehmer hat: Master + Slave Der Master sendet Positionssollwerte an den Slave. Jetzt soll es eine Achse mehr sein, also noch ein Slave also ein zusätzlicher Busteilnehmer. Eigentlich ist es auch einfach per FW Update möglich das Busprotokoll zu ändern, sodass nachhher auch die alten Maschinen mit der neuen FW laufen können. Jetzt sind aber manche FPGAs sehr klein: Altera Cyclone 2 mit 5kLE. Also muss es einfach sein. Mein Gedanke war wir machen etwas vom Prinzip ähnliches wie EtherCAT, also der Frame läuft seriell durch alle Teilnehmer durch und geht wieder zum Master retour. Jeder Teilnehmer hat aber nur einen Rx+Tx also nicht zwei wie bei EtherCAT. Die Teilnehmer wären daher in einem logischen Ring verschaltet. Dieser kann mit T-Stücken erweitert werden: MASTER >----------> SLAVE 1 <--- ----< | | | ----> SLAVE2 ------< Signalübertragung geht differentiell über Übertrager mit 13.3Mbps mit einem 3b/4b Code um Takrückgewinnung und Gleichanteilsfreiheit zu ermöglichen. Leitungscodes für 3 Bit Daten wären: 0 0011 1 0110 2 0111 oder 1000 3 1001 4 1011 oder 0100 5 1100 6 1101 oder 0010 7 1110 oder 0001 IDLE 0101 START 1010 Ein Frame wird also so übertragen: IDLE - START - FRAME - IDLE Am Ende des Frames gibt es einen CRC und 0-2 Padding Bytes damit die Anzahl Bit durch 3 teilbar sind. Sonst besteht ein Frame aus beliebig vielen Paketen im Format Adresse (16 Bit), Länge (16 Bit), Daten (Länge*8 Bit) Jeder Slave kann auf eine oder mehrere Adressen ansprechen (Adressen sind im Slave gesetzt). Findet er ein Paket das ihm gehört liest er die Daten (meistens Sollwerte) und kann sie durch eigene Daten (z.B. Istwerte) ersetzen. Ich denke das lässt sich relativ schlank in den bestehenden FPGAs realisieren und wir können damit den Bus der alten Maschinen erweiterbar machen. Was haltet ihr davon bzw. habt ihr eine bessere Idee? CAN scheidet aus weil zu langsam (10Mbps sollten es werden) und zu störanfällig (nicht galvanisch getrennt). EtherCAT scheidet aus weil die IP zu gross für den FPGA ist und jeder Teilnehmer 2 Rx+Tx Paare benötigt und nur eines vorhanden ist.
Klingt erstmal alles ganz vernünftig. Aber ein FW-Update brauchst du doch auf jeden Fall, weil jeder FPGA in der Daisychain in der Lage sein muss, die für ihn bestimmten Daten zu erkennen und den Rest zu ignorieren, was bei einer PTP-Verbindung nicht notwendig ist. Passt diese Erweiterung denn in die kleinen FPGAs hinein?
Füllst du die Leitung permanent mit IDLE? Bei zwei Slaves brauchst du Ruhezeitung zum Umschalten. Auch muss sich die CDR auf den anderen Slave synchronisieren. Beachte auch Kabellängen und den Fehlerfall, wenn beide Slaves treiben.
Die entscheidenden Fragen sind: -wie lang soll das sein ? -wie gestoert ist die Leitung? Ich würde einfach ein Bit als Teilnehmerkennung 0/1 hinzufügen und das Korrekturbit im Leitungs-Code anpassen. Wäre dann ein 4/5. Noch besser, man setzt das Korrekturbit komplementär und nutzt 4/6. Die Bits dann z.B. an Position 1 und 4 -> 2,3 sowie 5,6 wären dann die alten Bits. Man könnte auch die Bits vorn an stellen und illegale Codes 11 und 00 nehmen, dann wäre das der Synch-Marker und die Synchs würden sich um 2 bits von den legalen Codes unterscheiden. Brauchst halt 20Mbps.
Vancouver schrieb: > Klingt erstmal alles ganz vernünftig. Aber ein FW-Update brauchst du > doch auf jeden Fall, weil jeder FPGA in der Daisychain in der Lage sein > muss, die für ihn bestimmten Daten zu erkennen und den Rest zu > ignorieren, was bei einer PTP-Verbindung nicht notwendig ist. Passt > diese Erweiterung denn in die kleinen FPGAs hinein? Ja, ein FW Update wird zwingend sein, ausser jemand möchte auf dem alten Stand bleiben. FW Update Funktion gibt es aber bereits. Ob es noch Platz hat muss ich noch ausprobieren, der kleine FPGA steuert zwei DC-Motoren und liest deren Encoder ein. Da sollten die 5kLE dem Gefühl nach reichen. Klakx -. schrieb: > Füllst du die Leitung permanent mit IDLE? > Bei zwei Slaves brauchst du Ruhezeitung zum Umschalten. Auch muss sich > die CDR auf den anderen Slave synchronisieren. > > Beachte auch Kabellängen und den Fehlerfall, wenn beide Slaves treiben. Ja, zwischen den Frames wird die Leitung mit IDLE gefüllt. Alle 1ms sendet der Master einen Frame. Wenn ein Slave keinen Link am Rx erkennt sendet er selbst am Tx einen Frame mit seiner ID damit der Master eine Fehlermeldung anzeigen kann wo der Unterbruch zu suchen ist. Beide Slaves können ja schon zur selben Zeit treiben, jede Leitung ist ja immer noch ein Punkt-zu-Punkt Link. Der Ring ergibt sich erst durch die Daisy-Chain. Damit sollte auch nur der Abstand zwischen zwei Teilnehmern physikalisch begrenzt sein. Danach wird das Signal ja wieder aufbereitet. Leitungslänge zwischen zwei Slaves wäre ca. 10m shielded twisted pair. Bernd schrieb: > Die entscheidenden Fragen sind: > > -wie lang soll das sein ? > -wie gestoert ist die Leitung? > Es sollte sicher bis 10m funktionieren, bisher sind die Leitungen max. 5m lang. Störungen gibt es vor allem durch ESD vom Bearbeitungsprozess. Ist zwar alles geerdet aber die bisherige nicht isolierte differentielle Übertragung stösst schon manchmal an ihre Grenzen. Daher würde ich mit der Umstellung gleich einen DC-freien Code wählen und in die neuen Maschinen Übertrager einbauen. > Ich würde einfach ein Bit als Teilnehmerkennung 0/1 hinzufügen und das > Korrekturbit im Leitungs-Code anpassen. Wäre dann ein 4/5. Noch besser, > man setzt das Korrekturbit komplementär und nutzt 4/6. Die Bits dann > z.B. an Position 1 und 4 -> 2,3 sowie 5,6 wären dann die alten Bits. > Man könnte auch die Bits vorn an stellen und illegale Codes 11 und 00 > nehmen, dann wäre das der Synch-Marker und die Synchs würden sich um 2 > bits von den legalen Codes unterscheiden. > > Brauchst halt 20Mbps. Das verstehe ich nicht ganz. Teilnehmerkennung hätte ich absichtlich nicht vorgesehen sondern alles über einen globalen Adressraum gemacht. Ein Frame enthält ja immer Daten für mehrere Frames bzw. wird von mehreren Frames als Antwortkuvert genutzt.
Vancouver schrieb: > Klingt erstmal alles ganz vernünftig. Ja, finde ich auch. Sich auf 3b/4b zu beschränken ist etwas unkonventionell aber ist sicher viel kleiner als volles 8b/10b. Der Rest ist ja dann nur noch ein register file und ein CRC. Michi schrieb: > Leitungslänge zwischen zwei Slaves wäre ca. 10m shielded > twisted pair. Michi schrieb: > Ist zwar alles geerdet aber die bisherige nicht isolierte differentielle > Übertragung stösst schon manchmal an ihre Grenzen. Daher würde ich mit > der Umstellung gleich einen DC-freien Code wählen und in die neuen > Maschinen Übertrager einbauen. Was setzt ihr da den bisher ein? Vielleicht lässt sich da ja ohne all zu grossen Umbau weiter nutzen. In einer Leistungselektronikanwendung (IGBTs mit 80 kHz, 400 V und 140 A) habe ich gute Erfahrung gemacht mit einem galvanisch isolierten RS485 Netz. Läuft stabil bei 25 Mbit/s über 14 m shielded twisted pair. Natürlich weiter wenns langsamer ist. Mit einem isolierten RS485 Tranceiver von NVE: https://www.nve.com/webstore/catalog/product_info.php?products_id=427 Michi schrieb: > Am Ende des Frames gibt es einen CRC und 0-2 Padding Bytes damit die > Anzahl Bit durch 3 teilbar sind. Sonst besteht ein Frame aus beliebig > vielen Paketen im Format Vielleicht hilft es dir ein CRC zu wählen, das nicht 8 oder 16 bit ist sondern 6 bit oder so. Coopman hat da ein gutes Vergleichspaper dazu.
Christoph Z. schrieb: > 3b/4b zu beschränken ist etwas unkonventionell aber ist sicher > viel kleiner als volles 8b/10b. ??? 3/4 ist schlechter als 8/10, weil man 80% /75% Bruttodaten übertragen muss.
Vielen Dank allen schon mal für die konstruktiven Kommentare! Es scheint ich habe mal keinen offensichtlichen Denkfehler und werde es wohl ausprobieren. Die Alternative ist nur alles von Grund auf neu zu machen und auf EtherCAT zu wechseln. Die Kompatibilität wäre dann dahin dafür stünde dann die Tür zu FSoE offen und in Zukunft könnte man auch Safety integrieren. Aber der Zertifizierungsaufwand schreckt mich ab und ohne FSoE hat EtherCAT nur noch den Vorteil, dass man Standardkomponenten integrieren kann. Also lieber abwärtskompatibel als standardkonform. Christoph Z. schrieb: > Was setzt ihr da den bisher ein? Vielleicht lässt sich da ja ohne all zu > grossen Umbau weiter nutzen. Bisher gibt es zusätzlich zu Rx/Tx noch einen Clk. Dieser läuft aber nur mit 1/20 der Bitrate, also mit 500kHz. Die 20 Bit zwischen 2 steigenden Flanken sind ein Frame. Der Slave muss immer mit 1 Bit Verzögerung antworten. Laufzeitverzögerungen sind statisch korrigiert. Es ist also eher etwas wie SPI. Die Clockleitung würde ich gerne loswerden weil die Synchronisation von Clock und Daten über mehrere Meter unzuverlässig erscheint. Mit mehreren Teilnehmern dann sowieso. Gibt also leider nicht viel, das man mitnehmen kann. Das gute ist, dass ein Grossteil der FW auf einem separaten uC des Master läuft und ich nur den FPGA Teil ändern würde und das Interface zum uC nicht anpassen müsste. Dafür natürlich alle FPGAs. Christoph Z. schrieb: > In einer Leistungselektronikanwendung (IGBTs mit 80 kHz, 400 V und 140 > A) habe ich gute Erfahrung gemacht mit einem galvanisch isolierten RS485 > Netz. Läuft stabil bei 25 Mbit/s über 14 m shielded twisted pair. > Natürlich weiter wenns langsamer ist. > > Mit einem isolierten RS485 Tranceiver von NVE: > https://www.nve.com/webstore/catalog/product_info.php?products_id=427 > Das Ding klingt interessant. Hast du den RS485 mit mehreren Teilnehmern oder nur PTP betrieben? Christoph Z. schrieb: > Vielleicht hilft es dir ein CRC zu wählen, das nicht 8 oder 16 bit ist > sondern 6 bit oder so. Coopman hat da ein gutes Vergleichspaper dazu. Danke für den Tipp! Der FRAME kann bei 10Mbps und 1ms Buszyklus bis zu 10kb gross sein. Also fast so gross wie ein Ethernet Frame mit seinen 1500 Byte. Dachte daher an 32 Bit CRC, die fallen im Verhältnis zu 10kb nicht ins Gewicht und ermöglichen nach https://users.ece.cmu.edu/~koopman/crc/ eine Hammingdistanz von 6. Soweit ich es sehe braucht es im FPGA für den CRC einfach nur ein entsprechend langes Register + XOR. Das scheint mir auch bei 32 Bit nicht schlimm. Oder habe ich etwas übersehen was für ein kürzeres Polynom sprechen würde?
Michi schrieb: > mit der Umstellung gleich einen DC-freien Code wählen > und in die neuen Maschinen Übertrager einbauen. Für solchen einen Zweck und zwar wirklich für exakt so einen Zweck habe ich einem ehemaligen Kunden vor nunmehr über 25 Jahren schon S/PDIF empfohlen. Das kann man mit Microcontrollern bewerkstelligen, weil es dafür fertige Audio-Chips zum "Pfennig"-Preis gibt. Ja, damals hatten wir noch Mark und Pfennig :-) Ich würde das auch heute noch empfehlen und und ich sage das als FPGA-Entwickler, der einst Controller und Chips aus seinen privaten Design rausgeworfen hat und es mit eigenem VHDL-S/PDIF macht. :-) Christoph Z. schrieb: > In einer Leistungselektronikanwendung (IGBTs mit 80 kHz, 400 V und 140 > A) habe ich gute Erfahrung gemacht mit einem galvanisch isolierten RS485 > Netz. Läuft stabil bei 25 Mbit/s über 14 m shielded twisted pair. Genau so eine Anwendung war das. Hochdreckiges Maschinenumfeld. Man hat erst gestutzt, als ich mit einer "Audioschnittstelle" angekommen bin, hat es dann aber getestet und bejaht, u.a. auch aus Kostengründen. Das empfohlene S/PDIF gibt es als optisch und AES/EBU mit RS422. Dafür gibt es Treiber, Koppler und Chips zu (inzwischen) "Cent"-Preisen. Die sind nochmal billiger, als damals. Optisch kann man ein 96kHz-S/PDIF ohne weiteres 20m optisch führen, wenn man nicht gerade die allerbilligsten PolyProp-Pseudolichtleiter benutzt. Mit einer richtigen Glasfaser sind da GB möglich. Elektrisch über RS422 sind 50m by 192kHz typisch. Das sind 12,8 MBit brutto. Auch in Hochstromumgebungen kann man das sicher machen, weil der verwendete Code sehr eng bandbegrenzt ist. Der Nachteil ist nur, dass das Protokoll offen liegt. Man muss also mit der USER-Schicht sichern. Aber es soll ja ohnehin eine Sicherungsschicht hinein, dann kann man es auch user-codieren. Ich würde das mal für 384kHz durchrechnen und ausprobieren. Da sind ca. 18Mbps Nutzdaten möglich und die Module gibt es für 5,99 zu kaufen. Beschickt mit I2S und einem simplen Schieberegister. Es braucht nicht einmal einen FPGA. Am Ausgang kann man immer noch einen 485-Bus aufbauen, wenn man will. Zwischen 2 FPGAs habe ich das als Pseudo-S/PDIF mit FPGA Core auch schon bis knapp an 1 Gb betrieben. 300Msps Nutzdaten. Der 1b2b-BMC ist derart gut zu sampeln und zu rekonstruieren, dass du den praktisch nicht stören kannst. In einer Testanwendung lagen direkt neben der Datenleitung mehrere Kabel, in denen >1kA Pulsströme flossen und zu hörbaren Schwingungen der Gehäusewand führten. Bei einem längeren Leitungscode muss man mit dem Spektrum aufpassen, wo man landet. Wenn man das so baut, ist die CDR super einfach und sicher und man braucht auch keinen CRC mehr zu Rekonstruktion, sondern nur noch als Prüfcode.
Bernd schrieb: > Christoph Z. schrieb: >> 3b/4b zu beschränken ist etwas unkonventionell aber ist sicher >> viel kleiner als volles 8b/10b. > ??? > > 3/4 ist schlechter als 8/10, weil man 80% /75% Bruttodaten übertragen > muss. Ich meinte kleiner im Sinne von weniger Logikelemente im FPGA. > Bisher gibt es zusätzlich zu Rx/Tx noch einen Clk. Dieser läuft aber nur > mit 1/20 der Bitrate, also mit 500kHz. Ich meine was nutzt ihr auf Layer 0, also für diese erwähnte differenzielle Übertragung. Ist das schon RS485/RS422 oder was anderes? > Das Ding klingt interessant. Hast du den RS485 mit mehreren Teilnehmern > oder nur PTP betrieben? Das war mit bis zu 20 Clients. Aber nur Broadcast, also es gibt einen der sendet Reglersollwerte die alle anderen brauchen. Alles andere, Parameter, Zustand, Firmwareupdate etc. läuft über EtherCAT aber wir brauchten halt 12.5 us Zykluszeit und noch viel weniger Verzögerung. EtherCAT ist gut und schnell aber irgendwann ist da halt auch Schluss :-) > Oder habe ich etwas übersehen was für ein kürzeres > Polynom sprechen würde? Nein, hast du schon alles richtig verstanden. Der Hinweis war gemeint, dass das Runden auf 3 bits vielleicht Effizienter wird mit einem Polynom das nicht n*8 bit lang ist (Vielleicht 6 bit oder 15 bit oder so). War nur so eine Idee.
Michi schrieb: > Der Ring ergibt sich erst durch die Daisy-Chain. serielle Daisy Chain ist bewährt und robust. Ein früher Vertreter ist https://de.wikipedia.org/wiki/Interbus. Prinzipiell muss man überlegen, ob man direkt Bit für Bit (mit einem internen Clock Verzögerung) weiterleitet oder ob man Byte- oder Block-weise weiterleiten möchte um ggf. Bytes zu verändern (Bspw. für eine automatische Adressierung). Der Sinn Deiner "Clock" erschließt sich mir noch nicht, vielleicht habe ich was überlesen. Den Bit-Takt gewinnt man aus den Flanken (notfalls mit Bit-Stuffing), den Telegramm-Beginn mit speziellen Pattern und den Pattern-Beginn durch geeignete und genügende Idlepattern, gefolgt von einem geeigneten Startpattern (wie bei Dir). Die (bei Dir m.E. nicht notwendige) Clock wird prinzipiell nicht schlechter, weil sie ja ebenso durchs FPGA durchgeleitet/aufbereitet würde. Gruß
J. S. schrieb: > Für solchen einen Zweck und zwar wirklich für exakt so einen Zweck habe > ich einem ehemaligen Kunden vor nunmehr über 25 Jahren schon S/PDIF > empfohlen. Das kann man mit Microcontrollern bewerkstelligen, weil es > dafür fertige Audio-Chips zum "Pfennig"-Preis gibt. Ja, damals hatten > wir noch Mark und Pfennig :-) Ich würde das auch heute noch empfehlen > und und ich sage das als FPGA-Entwickler, der einst Controller und Chips > aus seinen privaten Design rausgeworfen hat und es mit eigenem > VHDL-S/PDIF macht. :-) Das 1b/2b BMC klingt auch interessant. Dann bräuchte ich zwar 20Mbps aber vielleicht ist die hohe Flankenrate ein Vorteil bei der Taktrückgewinnung und natürlich nicht der lästige Faktor 3. Muss mal schauen welche ICs es damit gibt. Vieles scheint schon älter zu sein. Aber der FPGA ist ja vorhanden also wäre es auch kein Problem das selbst zu implementieren. Christoph Z. schrieb: > Ich meine was nutzt ihr auf Layer 0, also für diese erwähnte > differenzielle Übertragung. Ist das schon RS485/RS422 oder was anderes? Habe das Schema gerade nicht da aber es ist ein einfacher Differentialtreiber wie der SN65LVDS1. Die Leitung ist aber immer getrieben also nicht wie bei RS485 teils hochohmig. Bruno V. schrieb: > Der Sinn Deiner "Clock" erschließt sich mir noch nicht, vielleicht habe > ich was überlesen. Den Bit-Takt gewinnt man aus den Flanken (notfalls > mit Bit-Stuffing), den Telegramm-Beginn mit speziellen Pattern und den > Pattern-Beginn durch geeignete und genügende Idlepattern, gefolgt von > einem geeigneten Startpattern (wie bei Dir). Die (bei Dir m.E. nicht > notwendige) Clock wird prinzipiell nicht schlechter, weil sie ja ebenso > durchs FPGA durchgeleitet/aufbereitet würde. Die Clock ist wohl historisch. War wohl mal als reines SPI gedacht und hat dann nicht funktioniert und so kam es dann. Es gibt auch noch eine CS Leitung. Ich würde all das in Zukunft weglassen und den Takt rückgewinnen.
J. S. schrieb: > Da sind ca. 18Mbps Nutzdaten > möglich und die Module gibt es für 5,99 zu kaufen. Beschickt mit I2S und > einem simplen Schieberegister. Es braucht nicht einmal einen FPGA. Am > Ausgang kann man immer noch einen 485-Bus aufbauen, wenn man will. Hallo, hast Du ein Beispiel für so ein Modul? Irgendwie habe ich nicht die richtigen Suchworte gefunden, aber die Idee gefällt mir für Anwendungen wo man Entkopplung möchte aber SFPs ein bisschen übertrieben wären.
Michi schrieb: > Klakx -. schrieb: >> Füllst du die Leitung permanent mit IDLE? >> Bei zwei Slaves brauchst du Ruhezeitung zum Umschalten. Auch muss sich >> die CDR auf den anderen Slave synchronisieren. >> >> Beachte auch Kabellängen und den Fehlerfall, wenn beide Slaves treiben. > > Ja, zwischen den Frames wird die Leitung mit IDLE gefüllt. Alle 1ms > sendet der Master einen Frame. Wenn ein Slave keinen Link am Rx erkennt > sendet er selbst am Tx einen Frame mit seiner ID damit der Master eine > Fehlermeldung anzeigen kann wo der Unterbruch zu suchen ist. Beide > Slaves können ja schon zur selben Zeit treiben, jede Leitung ist ja > immer noch ein Punkt-zu-Punkt Link. Der Ring ergibt sich erst durch die > Daisy-Chain. Damit sollte auch nur der Abstand zwischen zwei Teilnehmern > physikalisch begrenzt sein. Danach wird das Signal ja wieder > aufbereitet. Leitungslänge zwischen zwei Slaves wäre ca. 10m shielded > twisted pair. Tut mir leid, aber ich versteh das Konzept nicht mehr. Oben sieht die Zeichnung wie ein geteilter Kanal aus. Jetzt sagst du, dass du eine P2P Verbindung zu jedem Slave hast. Dagegen spricht, dass du o.g. nur ein TX+RX hast: Michi schrieb: > Jeder Teilnehmer hat > aber nur einen Rx+Tx also nicht zwei wie bei EtherCAT. Wie sollen zwei Slaves gleichzeigt senden? Ring oder Daisy-Chain? Eine bessere Zeichnung könnte helfen deine Topologie zu verstehen.
Klakx -. schrieb: > Wie sollen zwei Slaves gleichzeigt senden? Ring oder Daisy-Chain? Time Slot System?
Jörg schrieb: > hast Du ein Beispiel für so ein Modul? Schau mal I2S <-> S/PDIF Interface auf EBAY. Ich hatte da mal welche gekauft, dann später vom Händler eine größere Stückzahl für einen Kunden direkt bezogen. Als Einzelteil mit Steuern liegen die heute etwa beim Doppelten. Suche mal nach ES9032 et al. / Ganz komfortabel "DIR9001". Du brauchst allerdings nur den Chip. Andererseits lässt sich S/PDIF auch gut aus dem PC heraus testen: PCM2702 USB IF zu 7,99 oder ES 9038, oder direkt in Analog pcm5102
Klakx -. schrieb: > Wie sollen zwei Slaves gleichzeigt senden? Ring oder Daisy-Chain? Beides (wie zur Empfangskontrolle auch üblich): Michi schrieb: > Der Ring ergibt sich erst durch die Daisy-Chain.
:
Bearbeitet durch User
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.