Sparkcube | Motor pfeift nur und wird heiß

Moin Moin, Frischling hier

ich hab das Problem mit meinem Drucker, dass seitdem ich die config angepasst habe, der vordere linke Motor pfeift und heiß wird. Der Motortreiber läuft auch heiß.
Die Motoren hab ich bereits umgesteckt und kann daher ausschließen, dass ein Treiber oder Motor defekt sein könnte.
Der Fehler müsste wenn von einem defekten Radds kommen oder von der Software.

Ich hoffe ihr könnt mir da auf die Sprünge helfen

config.h im Anhang.

Der Treiber steckt auf ext2=extruder1

Man sollte kurz erwähnen das es sich bei dem Kollegen um ein Sparkcube V1.1 XL handelt, welcher nun auf mABL umgerüstet wurde.
Vorher war der Motor mit am Z-Anschluss (2 Motoren steckbar/Spiegelung). Für das mABL muss er aber zwangsweise einen eigenen Treiber und Anschluss haben, so wie es bei Vincent in der Anleitung stand. Wir haben die Pin-Belegung 1:1 übernommen (aus der Pins.h)

Der hintere Motor auf Z läuft, der vordere rechte auf E3/Extruder2 läuft, nur der vordere linke auf E2/Extruder1 zickt.
Treiber wurde von E3 mal kreuz getauscht, Fehler bleibt. Steckt man den Motor wo anders drauf, läuft er ebenfalls....

erneut Verzweiflung Verzweiflung....

1-mal bearbeitet. Zuletzt am 27.07.17 11:44.

Hallo Smasha,



das klingt ersteinmal sehr nach falsch eingestelltem Strom an den Treibern. Sowohl bei dem neuen Treiber als auch bei dem der vorher zwei Motoren an den Steckern nebeneinander hatte musst du im Rahmen dieser Umstellung etwas neu einstellen.

Das hast du gemacht? Was und wie genau hängt vom Treiber und vom Motor ab lässt sich aber in der Regel mit Suchmaschine finden.

Viel Erfolg

Ralf

Nein. Die raps128 sind alle korrekt auf 0.9v eingestellt. Die last wurde auf 2 Motoren verteilt, somit war auch nur 50% kraft notwendig (spiegelung). An der stelle muss nichts geändert werden. Meine Vermutung liegt in der falschen ansteuerung der pins per Software. Ich habe das Gefühl das beide spulen gleichzeitig geschaltet werden.

Nur so nebenbei, es sind alle 6 Treiber raps128 und 5 sind (und waren) auf 0.9v ausser der extruder. Der läuft auf 1.3 weil auch dickerer motor. Vorher lief der Drucker in der Standard config ja. Jetzt ist halt der Umbau auf mABL und somit müssen die Motoren anders angesteuert werden.

Empfohlener Spannungsbereich: 0,8 bis 1,6 V. Das entspricht einem theoretischen Motor-Spitzenstrom von 0,73 - 1,46 A, Gleichung: I = k U mit k = 0,91 A/V.
Also dürften 0.9v wohl kaum zu einer extremen überhitzung am motor und Treiber führen. Die X und Y-Achse fahren auch so mit einem Motor jeweils auf 0.9v. Wohlgemerkt alles aktiv gekühlt. Der Fehler muss wo anders sitzen

Guten Smasha,


also die Motoren am Doppelstecker waren am RADDS parallelgeschaltet und sind somit bei gleichter Treibereinstellung mit dem halben Strom gelaufen mit dem der einzelne jetzt läuft. Das hätte ich geändert

Dreht denn der fragliche Motor überhaupt und macht dabei die Geräusche und Wärementwicklung?

Ralf

Wie gesagt, es macht keinen Unterschied ob der motor alleine an x, y, oder an der Spiegelung hängt. Er läuft, nur auf e3/extruder2 nicht. Er pfeift laut und wird innerhalb von 10 Sekunden heiss. Und es macht keinen Unterschied welcher Treiber auf e3/extruder2 ist. Alle laufen überall nur nicht auf dieser Position.

Nur so am Rande, verstehe ich das richtig das du vorschlägst das ich nur den einen von den 3 z-motoren mit 0.45v betreibe und die anderen 2 mit 0.9v (Die so tadellos laufen). Es sind alles 1.5A Motoren. Somit würde der eine von den dreien nur 0.41A Strom bekommen, weniger als ein Drittel seiner Max. Leistung.
Du musst doch verstehen das dies nicht der Fehler sein kann. Ich verstehe den Sinn nicht hinter deiner These.

heiss werden in der beschriebenen Form kann der Motor nur von zuviel Strom. Das ist ein Motor / Treiberproblem - entweder falsch eingestellt oder defekt.

Die Beteiligung vom RADDS Board oder der Software ist ausgeschlossen denn diese Komponenten haben keinen Einfluss auf die Bestromung und somit die Wärmeentwicklung des Motors.

nein die Ströme sollten gleich sein bei allen drei Treibern nach der Umstellung nur eben bei dem Treiber der vorher 2 Motoren hatte sollte nach der Umstellung der halbe Strom genügen.

In der Anwendung auf der Z-Achse beim Sparkcube genügt übrigens bei weitem der halbe Nennstrom bei mir denn die Motoren haben hier wirklich kein nennenswertes Drehmoment zu erbringen.

Und so gering wie für den Betrieb ohne Schrittfehler möglich bestromt laufen sie dann auch am leisesten und am kühlsten.

Ich verwende keine Rapps Treiber mehr auf der Z-Achse - vielleicht fragst du mal bei sparklab nach welche Einstellung für die Z Motoren in deiner Anwendung empfohlen werden?

2-mal bearbeitet. Zuletzt am 28.07.17 03:33.

Das dubiose ist doch einfach das z hinten und z vorne rechts auf 0.9v laufen und funktionieren. Motor bleibt kalt, selbst der Treiber wird nicht nennenswert warm. Strom liegt dann bei 0.819A was sehr grob überm daumen gebrochen etwa der Hälfte entspricht. Schliesse ich den motor an den Treiber von vorne rechts an dann funktioniert er, klemme ich ihn wieder auf vorne links, ende. Nehme ich den treiber von vorne rechts (der ja grad ging mit besagtem motor) und klemme ihn auf die besagte treiberposition, wieder Ende.
Motor und Treiber laufen auf anderem steckplatz, das ist das unerklärliche. Damit sind doch Treiber und motor als fehlerquelle für mich ausgeschlossen, oder nicht?

also dazu fällt mir auch nicht mehr viel ein.

Ganz klar ist mir noch immer nicht ob der Motor überhaupt dreht und ob die Postition des fraglichen Treibers auf dem RADDS Board jetzt die ist die du zusätzlich neu besetzt hast? Dann käme noch in Frage das an dem neuen Steckplatz noch die falsche Auflösung eingestellt sein könnte?

Das taugt aber auch nicht für die Erklärung der schnellen Erwärmung.

Was mir auch schon mehrfach passiert ist, dass ich die Motorstecker zwischen den Treibern nicht exakt auf die 4 PINS bekommen habe sondern um einen PIN versetzt weil man es im Dunklen im halb umgekippten Drucker auch sehr schlecht sieht - das Fehlerbild wäre dann eher das der Motor gar nicht läuft - heiss geworden ist er dabei nach meiner Erinnerung nicht.

Ich guck mir gleich nochmal die Switche auf der Rückseite des radds an. Die Verkabelung passt. Treiber hatte ich auch abgezogen, nichts auffälliges zu sehen. Was mir aufgefallen ist, ist das er auch beim flashen der Firmware pfeift. Erst dunkel dann immer heller, dann so impulsweise hell. Wie gesagt, ich gucke mir das gleich nochmal an

ich hatte zwar nen Fehler, aber nicht den, den ich erwartet hab. X und Y standen auf 1/8 (jetzt 1/64 so wie es soll)... der Rest auf 1/32, was technisch ja richtig ist, kann so bleiben wie es war (die 3 Z-Motoren und der Extruder sollen ja 1/32).
Was ich jetzt nicht verstehe ist, das er auf einer strecke von 13 mm den gesamten "Hardwareweg" abfährt und zwar irre schnell. Natürlich hab ich die Steps auf 1280 hochgestellt in der Firmware, aber es hatte keinerlei Auswirkungen (auch EEprom beachtet). vorher hatte ich 640 Steps, damit es korrekt lief.dann müsste ich ja theoretisch den wert vervierfachen oder???

1/8 = 640 (so war es vorher) , 1/16 = 1280, 1/32 = 2560, 1/64 = 5120 ????

Wenn ich heute Abend Zeit finde häng ich mal nen Bild an, die Kabel waren aber so alle Korrekt. Jeder Stecker saß auch fest und nicht daneben gesteckt. Ich hab so das Gefühl, das wenn ein Problem gelöst wird zwei neue kommen. Das Ding sollte Hydra-Cube heißen

1-mal bearbeitet. Zuletzt am 29.07.17 05:40.

kurzes Feedback, ich hatte es doch nicht falsch gejumpert..... ich hab nicht genau auf die Tabelle geachtet..... in der RADDS Doku ist sie sortiert nach M3,M2,M1. Ich hab natürlich M1 nach M3, M2 korrekt un M3 auf M1 gejumpert, man nennt das Spiegelverkehrt...
somit waren sie nicht auf 1/64 sondern auf 1/8 und somit 4x so schnell wie sie sein sollten.
Das Problem mit dem pfeifenden Motor hab ich allerdings immer noch nicht im Griff....

also der Unterschied zwischen 1/8 und 1/64 ist bei mir noch immer Faktor 8 falls das zur Aufklärung beiträgt.

korrekt, Asche auf mein Haupt

Nur mABL scheint nicht möglich bei dem Drucker/Board da ich einfach keinen Motor an der Schnittstelle des RADDS zum Laufen bekomme .....

Sooo,
mal wieder ein Stück weiter und auch nicht.

Des Rätsels Lösung liegt in dem unsauber verarbeiteten RADDS. Es befand sich Lötzinn unterm Dippswitch der kontakt zu Pin5 hatte.... Zudem sieht ein IC merkwürdig aus, als wäre ein mickriger Tropfen auf ihm. Rausgefunden hab ich das nur, da ich eine neues Radds verbaut habe........

Jetzt aber zum nächsten und hoffentlich letztem Problem:
Der Induktive Sensor kommt ja an die Signalleitung von Zmin. Ich betreibe den Sensor direkt mit 24V. Aus der Signalleitung kommen 2,5V raus. Mein Problem ist nun das Z-Probe State (g31) immer High anzeigt im Ruhezustand. Hab mal den Pullup auf 0 und 1 gestellt und Z_Probe_on_high auf 0 und 1. Der Wert bleibt trotzdem immer High, hingegen ein Auslösen zu LOW führt.

Zmin bleibt übrigens auch permanent low.

Was mach ich nun wieder falsch?!? Reichen die 2,5V nicht

nachtrag

#define ENDSTOP_PULLUP_Z_MIN false
#define ENDSTOP_Z_MIN_INVERTING true

#define Z_PROBE_PIN ORIG_Z_MIN_PIN
#define Z_PROBE_PULLUP 0
#define Z_PROBE_ON_HIGH 1

das hilft schonmal das zprobe korrekt auf high oder low schaltet, nur zmin bleibt immer noch unverändert auf low, was fatal beim homing wäre

für diejenigen die evtl. mitlesen:

Es ist völlig egal. Er homed obwohl zmin permanent low bleibt.
Mein Problem nun ist, das er x und Y korrekt homed (bei mir oben rechts - jeweils auf max, in meinem Fall 300mm). An der Position steht natürlich der Sensor über. Trotz eingestelltem Offset homed er Z einfach auf dieser Position und bricht dann mit Fehlermeldung ab.
Homed man manuell Z (G28 Z0) z.B. in der Mitte, macht er es auch. Nur wenn er damit fertig ist, fährt er das Bett ca. 2 mm hoch und drückt es in den Nozzle, ich muss dann selber wieder 2mm runter fahren ....
Und das 3. Problem - führe ich g32 aus, fährt er den Punkt an und löst instant aus und gibt den Fehler zurück, das die Probe schon getriggert hat.
Fahre ich das Bett runter (10-20mm) und fahre die Position schon vorher fast an, sagt er trotzdem das schon ausgelöst wurde, obwohl er in der Luft hängt. Mit G30 prüft er die Aktuelle Position immer korrekt

Für diejenigen die mir netterweise noch weiter helfen möchten, hab ich einfach mal die Configuration.h angehängt.

Noch diese drei Probleme und ich darf evtl. (falls dann nicht 6 neue auftreten ) drucken

da werden dir wenige helfen können es sei denn Z-min ist der Fehler denn die Sparkcubes home üblicher Weise nach z-max

an welchen PINs hast du den Sensor und den Z Endschalter? Und wo am drucker ist letzterer montiert?

Der sensor ist zmin und z-probe zugleich. Mittels spannungsteiler auf zmin-endstop. Benutze repetiert Dev 1.0. Ab dort ist es möglich. Der Probe (npn induktiv sensor) ist direkt am x-carriage. Es gibt von Vincent direkt fertige Teile zum drucken um ihn zu montieren. Alles direkt vom sparklab

Ok, der Reihe nach ;-)

Quote
Smasha
Der sensor ist zmin und z-probe zugleich. Mittels spannungsteiler auf zmin-endstop. Benutze repetiert Dev 1.0. Ab dort ist es möglich. Der Probe (npn induktiv sensor) ist direkt am x-carriage. Es gibt von Vincent direkt fertige Teile zum drucken um ihn zu montieren. Alles direkt vom sparklab

Klar gibt es das Teil von Vincent/SparkLab, das war aber ursprünglich nur zum Leveln gedacht und nicht für ein Homing gegen den Sensor.
Das es jetzt funktioniert ist nur dank der neuen Repetier-Firmware möglich.

Quote
Smasha
Mein Problem nun ist, das er x und Y korrekt homed (bei mir oben rechts - jeweils auf max, in meinem Fall 300mm). An der Position steht natürlich der Sensor über. Trotz eingestelltem Offset homed er Z einfach auf dieser Position und bricht dann mit Fehlermeldung ab.

Das hat mein Interesse geweckt, ich habe den Guide gerade nochmal überflogen.
Da steht sinngemäß: Wenn du Glück hast ist dein Sensor immer über dem Bett.
Andernfalls muss die Homing-Order auf XYTZ, bei dieser Variante kannst du die Koordinaten für das Homing angeben.
Tatsächlich werden im Configurator ZHOME_X_POS und ZHOME_Y_POS erst dann sichtbar wenn man die Homing-Order auf XYTZ umstellt.

Den Rest sollte sich jemand ansehen, der einen berührungslosen Sensor verwendet und das Homing in Richtung Z-Min/Sensor macht, da bin ich also gleich doppelt raus.

Schau doch mal in diesen Thread oder häng dich da mit dran.
Wolfgang und Klaus haben es doch schon am Laufen und vielleicht noch ein paar Tips für dich.

2-mal bearbeitet. Zuletzt am 03.08.17 03:04.

---

Best regards / Viele Grüße
Till

Guter Hinweis, hab ich völlig überlesen. Werde ich gleich mal testen mit dem Homing

ok, folgendes passiert.
Er fährt x und y an, danach fährt er Z am Offset hoch (Habe x261 und y300 gemacht- somit am "0-Punkt" einfach 39mm links)
macht er wunderbar, bis er triggert. Sofort bricht er mit nem Error ab:

13:27:34.828 : Error:Activating z-probe would lead to forbidden xy position: 214.199996, 350.45
13:27:34.828 : RequestStop:
13:27:50.858 : fatal:Could not activate z-probe offset due to coordinate constraints - result is inaccurate! Printer stopped and heaters disabled due to this error. Fix error and restart with M999.
13:28:05.936 : X:300.00 Y:300.00 Z:0.000 E:0.0000

Kalkuliert er den Probe Offset jetzt noch irgendwie mit da rein??
#define Z_PROBE_X_OFFSET 37.5
#define Z_PROBE_Y_OFFSET -50.45

Ich werde einfach mal fürs homing y auch reduzieren. Vielleicht liegt da der Hund begraben.

Im übrigen vielen vieln Dank für den Hinweis @ microfortnight

Und direkt das Ergebnis:

Jap. er fährt die Z-Home-Offset an (x261 y249) und fährt danach den Z_Probe_offset an, sprich an der Position fährt er dann zusätzlih nochmal 37,5 nach links und 50.45 nach hinten.
Quasi doppel gemoppelt, aber egal, damit kann man arbeiten. Somit brauch ich kein mühseeliges Script mehr und kann mir die Mitte zum Homen errechnen.

Was bleibt ist, das er nach dem homen das bett immer noch 1.5 - 2 mm in das Nozzle presst. Er fährt halt nach erfolgreichem homing einfach hoch und ich weiß nicht warum.

Aber langsam ist ein Ende endlich in Sicht

nochmaliger Nachtrag.

Das mABL funktioniert mal so gar nicht. Er misst die Punkte, levelt, aber so das nur die zwei vorderen Motoren sich wirklich gut ausbalancieren, nur hinten hab ich das Gefühle läufts falsch rum. Es wird immer schlimmer, bis es dann irgendwann kracht.
Ich hab dann abgebrochen und manuell hinten ausgerichtet bis es passte (per G30 dauern geprüft, abschließend mit G29 ausgemessen - Ergebnis: 14.034 - 14.035 - 14.013 - per Hand find ich das schon gut XD).

Das Hauptproblem danach bleibt immer noch, das wenn ich was drucken möchte, er automatisch homed. X ab am Rand, kein Problem, Y nach hinten, kein Problem. Z läuft nun in die Mitte, Z-offset X&Y werden beachtet, er tastet, findet den punkt, fährt dann ein Stück nach oben, dann (glaube) 10 mm runter und fährt alle Achsen gleichzeitig auf den Ursprungspunkt.
Woher kommt dieses hochfahren?!?!?! Das versaut mir alles. Er drückt den Nozzle ins bett, dadurch blockieren die Motoren und das Bett verzieht sich wieder, das regt mich so auf.....
Evtl. mach ich später die Config nochmal im Firmware Tool komplett neu ... wenn mich wieder die Arbeitswut packt, bin grad einfach nur deprimiert, hänge seit 3 Tagen dran und komme einfach nicht ans Ziel.

doppelpost ...

1-mal bearbeitet. Zuletzt am 04.08.17 06:26.

dann musst du halt die beiden vorderen Motoren in der Drehrichtung der Korrektur invertieren - wenn das das einzige Problem ist?

Grundsätzlich schein das so gedacht das der hintere mittelere Motor ein Fixpunkt ist und nur vorn korrigiert wird - das ist bei meinem auch nicht anders und im Code kommen auch nur zwei Ausgleichsbewegungen vor soweit ich mir das erschließen konnte.

1-mal bearbeitet. Zuletzt am 04.08.17 07:01.

Grundsätzlich ist es wichtig, dass die Reihenfolge der Motoren konsistent ist.

Motor 1 ist fest, Motor 2 (Features -> Extra Motor Drivers -> Motor Driver 1) wird zur Korrektur genutzt, Motor 3 (Extra Motor Driver 2) wird zur Korrektur genutzt.
In der gleichen Reihenfolge (Features -> Z-Probing -> ) Motor position 1, 2 und 3



Die Config von Vincent bildet das passend ab, 1 hinten, 2 und 3 vorn.

Wenn das alles stimmt muss man wirklich nur noch bei Bedarf die Richtung der Korrektur-Motoren drehen (Features -> Extra Motor Drivers -> Motor Driver X -> Invert Direction Signal)

Kannst du nochmal die aktuelle Configuration.h anhängen wegen des Homingproblems?

---

Best regards / Viele Grüße
Till