Hallo Zusammen, Ich habe 4 Elektromotoren mit integrierten Steuergeräten und Leistungselektronik die über CAN ansteuerbar sind. Diese Vier Motoren möchte ich über einen zentralen Mikrcontroller ansteuern, der gleichzeitig das HMI ist, also die Usereingabgen und Sollwerte verarbeitet und auf die Busse abschickt. Da leider alle Vier SG die selben CAN IDs haben, sowie die Sollwerte für jeden Antrieb unterschiedlich sind kann ich diese nicht auf den selben CAN - Bus hängen und muss daher die Ansteuerung spliten. Ich hätte jetzt an folgende Architektur gedacht: Beaglebone Black (HMI und MAIN - Schleife für Fahrtregler), und dazu das MiroBus Cape http://www.mikroe.com/click/mikrobus-cape/ sowie 4 CAN - Bus Controller http://www.mikroe.com/click/can-spi-5v/ Die Frage ist nun, mal unabhängig vom gewählten Master - Rechenraster, kann ein Beaglebone Black über den SPI überhaupt schnell genug die MCP2515 CAN - Controller abfragen um 10ms Botschaften auf den Bussen zu empfangen / Senden? Auf dem Cape würden 3 MCP2515 auf den SPI0 und 1 MCP2515 auf dem SPI1 hängen. Weiterhin bin ich mir nicht sicher, ob das BeagleBoneBlack für solch eine Zeitkritische Anwendung generell die richtige Plattform ist, oder ob ich nicht gleich einen anständigen uC verwenden sollte, der für solche Aufgaben ausgelegt ist. Evtl. lässt man den Fahrtregler und die Busansteuerung auf einen uC laufen, der dann lediglich mit dem BBB als HMI Frontend die Sollwerte über einen Bus gesendet bekommt. Was denkt ihr?
Andreas G. schrieb: > Was denkt ihr? Das es möglich sein sollte, die vier Motoren auf unterschiedliche CAN-IDs zu konfigurieren.
Gast
#4527129
Rudolph R. schrieb: > Andreas G. schrieb: >> Was denkt ihr? > > Das es möglich sein sollte, die vier Motoren auf unterschiedliche > CAN-IDs zu konfigurieren. Das vermute ich auch. Aber dazu müßte Andreas mal den Typ der Steuergeräte sagen. Ich kann mir nicht vorstellen, daß es bei Steuergeräten keine Möglichkeit der ID-Auswahl gibt. (Was nicht bedeuten soll, daß es nicht vielleicht so "intelligente" Hersteller gibt, die das fest verdrahten...) :-) Eventuell geht es nicht mit Jumpern oder Drehschaltern, sonder nur mit einer Konfigurationssoftware.
Hi Leider ist ein umkonfiguriern der Can IDs seitens hersteller nie vorgesehen gewesen. Daher wurden diese direkt in die sw compiliert und die daher fest. Im ursprünglichen Setup gibt es immer nur eine Maschine je Bus. Grüße Andreas
Mittels geeigneten Analogschalter den Bus umschalten.
Gast
#4527698
Andreas G. schrieb: > Leider ist ein umkonfiguriern der Can IDs seitens hersteller nie > vorgesehen gewesen. Daher wurden diese direkt in die sw compiliert und > die daher fest. Im ursprünglichen Setup gibt es immer nur eine Maschine > je Bus. Ich, an Deiner Stelle, würde aus Deinem Fehlkauf lernen, die 4 Schrott-Teile zurück geben (mit dem deutlichen Hinweis - warum) und mich nach einem Hersteller mit guten Produkten umsehen. Alles andere ist russisch improvisierter Bastelkram.
Andreas G. schrieb: > Leider ist ein umkonfiguriern der Can IDs seitens hersteller nie > vorgesehen gewesen. Dann dürfte das vermutlich der weltweit einzigste Hersteller sein, der CAN nicht verstanden hat.
Eigentlich wollte ich nicht über die Inkompetenz des Herstellers sprechen, sondern darum, ob ein Beagleboneblack in der Lage ist, 4 CAN - Busse an seinen SPI mit je Bus insgesamt 15 Botschaften zu bedienen wobei 4 der 15 Botschaften in einem Raster von 10ms kommen müssen und ob dann noch ein "Echtzeit" (Echtzeit = zeitlich Deterministisch) Fahrtregler/steller am Beaglebone Black gerechnet werden kann, der die Sollwerte berechnet.
Wieso keinen MUXer der den CAN zwischen den 4 Motoren umschaltet? Oder gleich einen Controller mit 4 CANs nehmen...
Andreas G. schrieb: > Eigentlich wollte ich nicht über die Inkompetenz des Herstellers > sprechen Wie wäre es wenn du mal über den Namen des Herstellers sprechen würdest?
Andreas G. schrieb: > Eigentlich wollte ich nicht über die Inkompetenz des Herstellers > sprechen, Verstanden, das sah aber erstmal so aus, als ob Du das falsche Problem lösen möchtest. Und da man Software ändern kann und Du weder den Hersteller noch das Produkt genannt hast, würde ich jetzt weder ein Software-Update noch einen Hack der Hardware ausschliessen wollen. Fabian F. schrieb: > Wieso keinen MUXer der den CAN zwischen den 4 Motoren umschaltet? Das ist nicht nur elektrisch eklig, dazu bräuchte man mindestens auch noch vier zusätzliche Controller als CAN-Knoten, damit es nicht die ganze Zeit Bus-Fehler hagelt. Dann könnte man auch gleich vier Stück ATMega16M1 oder so nehmen die per CAN mit dem Motor-Treiber sprechen und auf der anderen Seite per SPI oder UART an den Haupt-Controller angebunden sind.
Der LPC2294 hat 4 CANs.
Gast
#4528126
Wenn schon SPI, dann nehme 4x MCP2515 als CAN controller (plus Transceiver natürlich). Ob es die geforderte Timings einhält muss mann probieren. MfG PICfan
PICfan schrieb: > Wenn schon SPI, dann nehme 4x MCP2515 als CAN controller (plus > Transceiver natürlich). Ob es die geforderte Timings einhält muss mann > probieren. > > MfG > PICfan So wäre die Architektur aus meinem ersten Post aufgebaut Den lpc2294 hab ich heute auch schon gesehen. Bei olimex gibt's den schon fertig auf einem egal Board...
Andreas G. schrieb: > Was denkt ihr? Nimm besser dsPIC33FJ64GP802, pro Bus einen. Deine Messages kannst Du dann immer noch per SPI transportieren, aber der dsPIC wird Dich durch lokales RAM und lokale Weiterverarbeitung dabei entlasten. Dann sollte auch 1MBit/s auf jedem Bus möglich sein. fchk
Frank K. schrieb: > Dann sollte auch 1MBit/s auf jedem Bus möglich sein. Wenn die Datenrate einstellbar wäre, dann könnte man auch die IDs einstellen... Wäre ja jetzt ein interessanter Zufall wenn die nich genannte Datenrate 1MBit/s betragen würde, es wurde ja nicht mal erwähnt ob LowSpeed oder HighSpeed...
Gast
#4528367
Statt mit Sturköpfigkeit den Thread zu blockieren, könnte man das Problem mal ein bisschen spezifizieren. Wie hoch ist die Busgeschwindigkeit? Was sind das für Motoren/Steuergeräte (Typ/Hersteller)? Was für Datenmengen werden über den Bus geschickt? ... nur um mal eine grobe Orientierung über das Problem zu bekommen.
Frank K. schrieb: > Andreas G. schrieb: > >> Was denkt ihr? > > Nimm besser dsPIC33FJ64GP802, pro Bus einen. Deine Messages kannst Du > dann immer noch per SPI transportieren, aber der dsPIC wird Dich durch > lokales RAM und lokale Weiterverarbeitung dabei entlasten. Dann sollte > auch 1MBit/s auf jedem Bus möglich sein. Ich würde auch nicht auf die SPI-CAN Teile setzen. Ich persönlich würde zu einem kleinen STM32 raten und den dann viermal. Geht aber mit dem dsPIC bestimmt genauso. Dann hält man sich auch die Möglichkeit offen bei Echtzeitproblemen die zeitkritischen Routinen auf den Controller auszulagern. Matthias
Frank K. schrieb: > Nimm besser dsPIC33FJ64GP802, pro Bus einen. Warum 4 MCs verschwenden, wenn es MCs mit 4 CANs gibt? Meinst Du, der LPC2294 schaffts nicht.
Gast
#4528818
Eine Möglichkeit wäre auch, einen (bzw. insgesamt dann 3-4) µC mit 2 CANs zu benutzen als Brücke. Also Haupt-µC <-CAN-> Bridge-µC <-CAN-> seltsame Motorsteuerung Der Bridge-µC empfängt die Nachrichten des Haupt-µC indem er auf einer individuellen Adresse lauscht und gibt sie dann an seine jeweilige Motorsteuerung weiter.
Peter D. schrieb: > Frank K. schrieb: >> Nimm besser dsPIC33FJ64GP802, pro Bus einen. > > Warum 4 MCs verschwenden, wenn es MCs mit 4 CANs gibt? > Meinst Du, der LPC2294 schaffts nicht. Der LPC2294 ist halt ein recht großes Monster. Und nicht mehr der frischste (10 Jahre, noch ARM7TDMI). Würde ich in neuen Projekten nicht mehr einsetzen. Und ob der Controller den (zugegeben) absoluten Worst-Case (4x1MBit/s bei hoher Buslast) noch korrekt verarbeiten kann wäre ich mir nicht 100% sicher bevor ich das nicht hätte laufen lassen. DMA scheint der ja auch nicht zu haben der bei SPI/UART helfen könnte. Von daher würde ich auch eher auf vier günstige Controller (z.B. STM32F042) setzen. Läuft ja eh das gleiche Programm in allen. Matthias
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.