GRBL Controller habe ich mir gerade nochmal angeschaut. Der experimentellen 3.6.2 Version von mir fehlten noch ein paar DLL's so dass die nur auf meinem Entwicklungs PC aber nirgendwo sonst lief. Ich habe das jetzt behoben und eine statisch gelinkte Version 3.6.2 zum Download bereitgestellt. Wer möchte kann das mal testen. Wie gesagt: Testversion: Ohne Garantie :-)
Ich hatte Pulverkuss angeboten mir das Setup mal anzuschauen. Er hat es mir per Paket geschickt und ich möchte hier mal ein paar Erkenntnisse teilen:
1) Die Motoren sind offenbar falsch gelabelt. Es handelt sich von den Abmessungen (51mm Länge) und Anzahl der Kabel (4) um die 218er Motoren die aber ein Typenschild von den 240ern (6 Kabel, 56mm Länge) tragen. Das Mysterium wäre also mal geklärt.
2) Das Stromkabel vom Netzteil zum GRBL Controller Board war verzinnt. Das ist ungeschickt und kann zu Spannungseinbrüchen führen.
Nachdem das Kabel abgekniffen und nur verdrillt auf die Klemme gelgt wurde, liessen sich auch 2A an den Treibern einstellen.
Was dennoch immer wieder zu beobachten ist: Häufig: Bei Anlaufen mehrere Motoren gleichzeitig (Start eines G-code Fräsprogramms) kommt es zum Neustart von GRBL, zu erkennen an dem Versionsstring, den GRBL beim Start schickt.
Selten: meldet GRBL dabei auch einen Lesefehler aus dem EEPROM: ERROR 7: "EEPROM read failed. Reset and restored to default values".
Im Anschluss sind dann die GRBL Parameter alle verstellt und die Motoren laufen nicht mehr (Da besagte Dafaults offenbar die Steps/mm Werte für alle 3 Achsen auf 0 stellen)
All das deutet darauf hin, daß die Spannungsversorgung des Atmega 328PB hier nicht stabil ist und beim Start von mehreren Motoren unter die Mindestspannung sinkt, bei der der Atmega noch funktioniert.
Das Thema ist definitiv kein Problem der Steuersoftware.
Ich konnte auch die Probleme mit der GRBL Controller Steuersoftware nachvollziehen, das Programm kommt mit Neustarts von GRBL gar nicht gut zurecht. Am besten liess sich mit Universal G Code Sender das Problem einkreisen.
Kommen wir zur eigentlichen Analyse: Ich habe leichte Verbesserungen erzielen können als ich den C12 Kondensator bestückt habe. Allerdings lief es auch noch nach entfernen des Kondensators noch besser. Eventuell reicht es da schon dass das Via verzinnt ist um Verbesserungen zu sehen. Das Entfernen des 7805 zeigte erstmal keine Veränderungen.
Den größten Einfluss sah ich an den Klemmen und am Kabelquerschnitt. Mit einem 1qmm Kabel vom Netzteil zur ATX Klemme lief es sehr instabil und ich sehe auch den EEPROM Fehler, mit einem 2.5qmm Kabel lief es besser.
Bei dem mitgelieferten Kabel hängt es sehr davon ab wie sauber das Adernende aussieht und wie der Kontakt ist.
Kurze Zeit darauf fing das Board dann allerdings an, ständig neu zu starten, auch der Versuch den Flash Inhalt über die ISP Schnittstelle zu prüfen oder neu zu schreiben schlug fehl. Offenbar war nun der Atmega 328BP defekt. Nach dem Tausch des Atmega lief das Board wieder stabil.
Ich nehme an, daß der Atmega einen ESD Schuss abbekommen hat und dadurch empfindlich auf die Spannungsversorgung reagiert hat. Solche Schäden können auch die anderen Merkwürdigkeiten erklären die Pulverkuss beobachtet hat. Also: Die Elektronik immer schön vorsichtig behandeln und auf statische Aufladung achten beim Hantieren!
Ein paar Dinge die ich bei der Analyse gelernt habe:
Die TB67S109 scheinen sich an den 5V vom Arduino zu bedienen wenn auf der VMOT Leitung nicht genug Strom kommt. Das widerum kann dann am Arduino zu einem Einbruch der Versorgungsspannung führen. (Das ist aktuell eine unbewiesene Theorie)
Wenn der 7805 nicht bestückt ist, dann wird der Atmega nur mit etwa 4,6V versorgt. Die 5V vom USB laufen erst über eine Diode an der etwa 0,3-0,4V abfallen. Da der Atmega mit 16 MHz läuft, braucht er laut Datenblatt mindestens 4,3V um stabil zu laufen. Die BOD Fuse ist allerdings auf 2,7V eingestellt, so dass die Brown Out Detection, die Fehlfunktionen bei Unterspannung durch einen Reset des Atmega verhindern soll nicht ganz optimal funktionieren kann.
Ist der 7805 bestückt, so liegen 5V am Atmega an, was deutlich optimalere Betriebsbedingungen für den Atmega sind. Die Aussage dass der Atmega vorrangig vom USB versorgt wird ist demnach nicht korrekt.
Die Platine hat durch den unbestückten C12 möglicherweise keinen niederohmigen Kontakt an dieser Stelle, wenn die Bohrung nicht verlötet ist.
Der Querschnitt und der Anschluss des Kabels vom Netzteil an der Klemme vom GRBL Controller Board sollte möglicht optimal sein. 2-2.5 qmm scheinen bei 2A Wicklungsstrom empfehlenswert zu sein. Das Kabel nicht verzinnen und möglichst vollständig und bis zum Anschlag in die Klemme einführen und fest verschrauben.
Häufige Neustarts von GRBL und der EEPROM Fehler (7) können auch ein Hinweis auf einen defekten oder geschädigten Atmega sein. -> wer kein TQFP löten kann, um das ggf. selbst durch Austausch des Atmega's zu beheben, sollte extra vorsichtig beim Umgang mit dem GRBL Controller board sein und auf statische Auflagung achten.
Soweit mal die Erkenntnisse bis hierher.. Das Board schicke ich an Pulverkuss zurück. Lasttests konnte ich keine machen, bin also gespannt ob es mit dem tausch des Atmega jetzt läuft wie es soll.
das ist ja mal eine wissenschaftliche Abhandlung. Nein im Ernst, ich finde das super, das sich da jemand so reinhängt und hilft. Ich selber könnte es vermutlich nicht so gut. Mir würde da auch die Zeit weglaufen. Sicher hast Du das Ganze nicht in 30 min. geschafft.
Ergänzend zu Deinen Feststellungen möchte ich noch was hinzufügen. Zunächst einmal hast Du vollkommen recht, dass man auf statische Entladungen/Aufladung auchten muss und auch auf das mutwillige manuelle verschieben der Achsen und damit das Drehen der Motoren extrem achten muss. Beides ist schädlich für die Elektronik.
Was den C12 angeht, so kann ich Deine Feststellungen verstehen, aber schwerlich mit dem Layout begründen. Auf der Oberseite ist Plus-Seite (linker Pin) des C12 mit dem POWER Strang, also 12-24V verbunden. Auf der Unterseite dort gar nicht. Auf der Minus-Seite von C12 ist der Pin hauptsächlich mit der Unterseite verbunden, hat auf der Oberseite noch Minus an ein Widerstandsnetzwerk zum Ansteuern der MOSFETs. Hier fließt nicht viel Strom. Ein Durchlöten der beiden THT-Löcher sollte nach meinem Dafürhalten keine Verbesserung oder Verschlechterung bringen?!? Zumal die Schrittmotortreiber ja je einen eigenen Puffer-Kondensatoren haben.
Oberseite:
Unterseite:
Grundsätzlich kommt die Betriebsspannung (24v für Motoren) natürlich von der Buchse und wird auf der Oberseite so großflächig wie möglich über die Kupferfläche geführt. Es gibt dort stellen, wie z.B. die Doppelbuchse von Z-MOT oder auch die blau gekennzeichneten Pfeile, wo die Kupferflächen eng werden. Das war bisher kein Problem. Allerdings wurde das Board auch bei den Tests nie mit einem TB67S109 geteste! Vielleicht ist hier dann auch mal Zapfenstreich für POLOLU-Treiber?
Das mit der 5V Betriebspannung und der Diode ist natürlich richtig, und war aus meiner Sicht die einzige Lösung, um eine weitere Kodierbrücke zu vermeiden. Zumal dann vermutlich noch mehr Probleme durch Fehlbedienung zu befürchten wäre.
Ich habe nun ein paar weitere Anregungen für ein ev. Redesign der Platine.
Summa sumarum scheint es mir dann doch an einem defekten Prozessor gelegen zu haben? Und daran, dass meines Erachtens das Board und die POLOLU-Treiber für NEMA23 Motoren nur noch bedingt geeignet sind. Hier ist dann einfach der Formfaktor für beides zu klein. Testweise könnte man eine dicke Litze unter der Platine mal mit allen VMOT-Anschlüssen der Treiber und dem Plus Pol der Versorgungs-Buchse verbinden. Masse ist ja die komplette Unterseite der Platine. Wobei wir da, wie ich gerade gesehen habe, auch nicht immer sehr gut unterwegs sind. Auch hier könnte man mal mit Litze nachhelfen! Ist nur ein Versuch wert.
Also crix, Dir nochmal vielen herzlichen Dank, zumindest von meiner Seite aus.
ja, ich denke auch dass es von Anfang an ein halblebiger Atmega war. Das passt am besten zu den teils merkwürdigen Phänomenen. Und ja, die im Falle Nema23 hohe Leistung auf dem engen Raum halte ich auch für nicht optimal.
Für das eventuelle Redesign: Vielleicht kann man die 5V Spannungsversorgung für Atmega und Treiber trennen, so dass der Atmega nicht durch das beeinträchtigt werden kann was auf VMOT passiert.
Und für Nema23 vielleicht ein GRBL Controller Board XL für Externe dann passiv gekühlte Treibermodule.
Die Verstärkung der Klemmen und auflöten einer Litze hatte ich glaub ich glaub ich auch schonmal in diesem oder einem anderen Thread vorgeschlagen. Das wäre noch eine Option wenn es mit dem neuen Atmega immer noch Probleme gibt. Mangels Kühlung konnte ich nicht lange testen.
Ich habe nun heut wieder alles zusammen bauen können. Das Kabel der 24V Spannungsversorgung wurde vergrößert (wie du vorgeschlagen hast.)Die Enden nicht verzint. Die Software hast du von 1.1f auf 0.9f zurück geflasht. Nun, es läuft zwar ein kleines Stückchen besser (vom Gefühl her) aber das gelbe vom Ei ist es nicht, muß ich leider sagen. Der Versatz beim Fräsen entsteht immernoch. Das Entladen oder was es auch immer ist, passiert weiterhin. Wie gehabt am Y Motor.
Einen Reset der Grundeinstellungen konnte ich bis jetzt nicht feststellen (das schein gefixt zu sein)
Ich finde die Rückgabe des Boards hier mehr alls passend bzw den Austausch gegen etwas funktionierendes im Bezug auf den kompletten Kauf des Elektrokits mit Nema 23 und den FYS TB67S109.
Freut mich dass es wenigstens etwas gebracht hat. Den Versatz habe ich nicht gesehen, konnte aber auch mangels kühlung nie wirklich lange testen.
Ich habe die Firmware 0.9 wohl versehentlich aufgespielt, habe einfach von einem meiner Boards das Flash kopiert, da der Atmega nach dem Tausch natürlich nackt war. Kannst Du ggf. wieder auf 1.1 hochflashen, aber ob das bei dem Versatz was bringt, wage ich zu bezweifeln.
Für eventuellen Umtausch musst Du Dich an Ronald wenden, ich hab wie gesagt mit dem geschäftlichen Teil nichts zu tun. Ist schon sehr merkwürdig das Phaänomen.. wäae sicher interessant das mal mit einem anderen GRBL Controller Board zu testen ob es am Board hängt oder an der Verkabelung oder den Motoren (die ja falsch gelabelt waren).
Für mich wäre auch noch interessant wer hier im Forum mit genau der Zusammenstellung- GRBL Board 2.02+FYS TB67S109 Treiber+die Nema 23 was am laufen hat und ob das funktioniert.
Sind ja mehrere 100 Bausätze verkauft laut Roland...
Also nun die direkte Frage an Roland. Ich würde das Elektrokit gern tauschen lassen da es nicht funktioniert bzw zur Not auch zurückgeben.
@Crix
Welche Komponenten nutzt du? GRBL Nano Board+DRV8825+Arduiono Nano V3+Nema23?
Ich hatte ursprünglich einen Arduino Uno plus DRV8825 auf dem GRBL Shield, das war aus der Zeit vor dem GRBL Controller Board. Ich habe dann TB6560 Module direkt an den Arduino Uno angeschlossen. Steht im Forum beschrieben, ich habe meinen Aufbau damals dokumentiert.
Anmelden
