Roboteq und PMG

Wie ich von Team Tsunami und Mike Lambert von Dantomkia erfuhr, sind bisher 5 dieser Kombinationen (RTQ-PMG, RTQ-LEM)abgefackelt, allein in Liverpool 2 !
Bisher weiß keiner genau warum, Paul nimmt an, die hohe Induktionsspannung der Scheibenläufer killt die FET´s. Anscheinend sind die Transsildioden zu langsam dafür.
Mit anderen Motoren gibt es bisher keine Probleme.

Sollte es bis Ende Juni keine Lösung für die Sache geben, werde ich nicht zur WM fahren, da ich es mir nicht leisten kann und will, nochmals neue Regler oder Motoren zu kaufen. Das wäre für mich allerdings auch das Ende vom Hobby, da sich das (ohnehin schon aberwitzige) Preis/Fun Verhältnis dann noch weiter verschlechtert.

Zitat

Anscheinend sind die Transsildioden zu langsam dafür.

Prinzipiell macht das Sinn, allerdings wage ich zu bezweifeln, dass der Grund in den Dioden selbst zu suchen ist. Ich würde verstärkt auf aufbaubedingte Streuinduktivitäten tippen, die die Dioden "langsam machen". Könnteste mal zwei Bilder (Bestückungsseite, Leiterbahnseite) des Roboteqs hier reinstellen?

Zitat

Original von Der Ingenieur Ich würde verstärkt auf aufbaubedingte Streuinduktivitäten tippen, die die Dioden "langsam machen". Könnteste mal zwei Bilder (Bestückungsseite, Leiterbahnseite) des Roboteqs hier reinstellen?

Das wurde von Paul Cooper auch schon vermutet. Dafür könnte auch sprechen, dass Roboteq vorschreibt, keinesfalls die Motoranschlusskabel zu kürzen oder zu verlängern. Die dürften sich da in einem Grenzbereich bewegen.
Layouts hab ich leider keine und ich will das teil aus Garantiegründen derzeit net aufschrauben. ich schau mal, ob die engländer vielleicht was haben.

Übrigens: super dass du wieder an bord bist! :jeah: :dafuer:

Uijeh, armer Helmut!
Da hast so tolle Mots u. Regler und dann wollen die nicht miteinander.... :xo: :kotz1: :heul:

Soweit mir bekannt, nur bei den PMG´s und LEMCOS. Alle anderen dürften problemlos funktionieren.

Hallo!

Ich fürchte auch, dass sich das problem nicht auf die schnelle lösen lässt. ich werde morgen mal technobots kontaktieren, vielleicht kann ich den Regler noch umtauschen gegen zwei NCC 120. er ist ja noch neu und wurde noch nie angeschlossen.
ein tausch der motoren wäre extrem aufwendig.

Empfehle als Sofortmaßnahme mit ziemlich hoher Erfolgschance:

-Über die Drain-Source-Strecke jedes einzelnen Endstufen-Fets (direkt an die Pins auf der Platinenrückseite) je einen bipolaren Transil vom Typ BZW06-48B (Bürklin, Bestellnummer 21S4380, ab 10 Stk. 0€26/Stk.). Damit ist jeder einzelne Fet von einer relativ kleinen (und schnellen) Schutzdiode mit optimal kurzer Anbindung geschützt. Kostet nicht viel, ist jederzeit garantiemäßig unsichtbar zu machen und funktioniert.

hallo erstmal alle zusammen ,.... ja bin auch wieder da (hi gra)

also bei speedos die über 550euro kosten wären ich mit experimenten die auf die garantie gehen koennten vorsichtig.

mir persoenlich waere das einfach zu teuer.ich kann mir vorstellen das ein umtausch versuch einfacher ist,... da das problem ja schon oefters aufgetreten ist.

Zitat

Kess auf 150A getuned ... twilight ist damit in Liverpool gefahren ... ich vermute aber mal, dass der Regler damit am Limit fährt. Auch was ich bisher von Kess mitbekommen habe, fehlen da intern Schutzdioden usw.
Die Kess sind einfach für die Bosch ausgelegt.
Halte ich daher nur bedingt geeignet für die Perms!

Diese Annahme gründet sich leider nicht auf irgendwelche Fakten. Tatsache ist: Bei 150A wird jeder FET mit 50A belastet. Das ist viel, ist bei guter Kühlung aber machbar. In Twilight stecken zu diesem Zwecke acht (!) Lüfter. Schutzdioden? Sorry, irrelevant. Dioden können keinen Strom begrenzen, sondern nur eine Spannung. Und die ist die gleiche, egal bei welchem Strom. Abgesehen davon kenne ich beide Versionen - da fehlt nichts.
Ob die Sickings die Tortur dauerhaft überleben, ist noch nicht raus. Tatsächlich sind ja auch schon hinreichend von den Dingern abgebrannt, aber auch ohne Scheibenläufer dran.

Nachtrag: Nicht zu vergessen ist, das Kees selbst seit einiger Zeit mit zwei Bosch an einem auf 150A aufgedrehten Regler fährt.
Fest steht jedenfalls eines: Ist der Sicking bei 120A standfest, ist er's bei guter Kühlung bei 150 auch.

So, ich hab das Ding jetzt doch aufgeschraubt, leider ist nur dei Platineoberseite sichtbar, ansonsten hätte ich die gesamten FET´s demontieren müssen. Mit diesen ist nämlich die Platine im Gehäuse befestigt :kotz1:

Ja, ist doch wunderbar!
Wie es aussieht, sind alle Fet-Anschlüsse an Durchkontaktierungen unmittelbar vor den Transistoren geführt. Da kann man sogar von oben, ohne Demontage, Transils drauflöten.

Jo, ich werd´das auch tun, wenns keine kompetenten gegenstimmen gibt, wird leider die einzige lösung sein. Auf die garantie muss ich halt pfeifen

was mich beim Design des Controllers extrem ankotzt, ist, dass die Platine in einer Nut des Gehäuses geführt ist (0,3 mm Spiel, nachgemessen) und linksund rechts durch die Blauen Winkel ebenfalls nicht spielfrei gehalten wird. d.H. Beschleunigungskräfte der Platine und Kräfte an den Anschlusskabeln (natürlich ohne Zugentlastung!!) werden großteils durch die Befestigungsschrauben der FET´s aufgenommen, die Kräfte in die PIN´s eingeleitet. Ist bei einem Controller, der für Kamproboter konzipert wurde, eigentlich ein Armutszeugnis!
Wenn der Designer der Elektronik genauso gut drauf ist wie sein mechanischer Kollege, dann besteht durchaus Grund zum Pessimismus.... :heul:

Das ist eine ziemlich berechtigte Kritik. Man könnte darüber nachdenken, ob man die Platine nicht irgendwie verkeilt. Tatsächlich werden die Durchkontaktierungen die Beschleunigungskräfte nicht dauerhaft lustig finden.

Klar werd ich was beilegen, und auch zugentlastungen für die kabel einbauen. Sollte aber bei einem 600 euro Teil (damals noch alter dollarkurs) eigentlich nicht notwendig sein

Das Problem bei allen diesen Motorsteuerungen ist, dass sie nicht wirklich konsequent durchentwickelt sind. Das gilt für alle - von 4QD über Sicking bis Roboteq, von den Halb-Selbstbaukonzepten à la OSMC ganz zu schweigen.
Das ist auch kein Wunder, da die absetzbaren Stückzahlen einfach zu gering sind, um so ein Ding an allen Ecken "rund" zu machen.
Ich denke, wir werden uns damit abfinden müssen, dass Motorsteuerungen für unsere Anwendungen auch auf die Dauer evolutionären Charakter haben werden, getreu dem Microsoft-Prinzip: Das Debugging erfolgt beim Kunden.