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:
1
MASTER >----------> SLAVE 1
2
<--- ----<
3
| |
4
| ----> SLAVE2
5
------<
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:
1
0 0011
2
1 0110
3
2 0111 oder 1000
4
3 1001
5
4 1011 oder 0100
6
5 1100
7
6 1101 oder 0010
8
7 1110 oder 0001
9
IDLE 0101
10
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.
-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.
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.
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.
-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.
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.
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.
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.
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.
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.
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?
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. :-)
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.
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.
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.
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.
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.
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.
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.
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:
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
