Marlin aufm Mightyboard

  • Moin!


    Langsam wird es zeit für mich auch was zu geben als nur zu nehmen.
    Dank diesem und anderen Foren konnte ich mich gut einarbeiten ins Thema und besitze mittlerweile 2 funktionierende Bizer!


    Ich möchte euch gerne zeigen wie ich Marlin auf das Migthyboard gebracht habe. Es ist nicht leicht und sollte auch erstmal nur von erfahrenen Nutzern umgesetzt werden.


    Je nach feedback, kann man auch eine Anleitung für Anfänger vorbereiten.


    Für die erfahrenen, die es nicht erwarten können Marlin aufm Migthyboard zu haben, etwas quick and dirty.


    Hier stelle ich mein Quellcode bereit von Marlin 2.0 von ende Dezember.


    Nutzt als Umgebung Platformio! Arduino IDE weicht bei den libraries ab! Die Display library braucht einen Patch zur Pinbelegung. Wenn Ihr Platformio verwendet ist dies bereits in meiner ZIP enthalten.


    Es sind folgende Anpassungen nötig:

    Im Benutzerverzeichnis liegt der Ordner von Platformio in die Ihr die Datei pins_arduino.h aus der ZIP rein kopieren müsst.

    Der genauer Pfad:

    %USERPROFILE%\.platformio\packages\framework-arduinoavr\variants\mega


    Jetzt sollte das compilieren schon funktionieren.

    Es sind sämtliche Parameter in der Marlin config von euch zu Prüfen und auf euren Drucker anzupassen. Ins besondere die steps, pid werte, ggf Bett größe usw.


    Voreingestellt ist es auf einen Extruder aber auch 2 habe ich getestet (ohne zu drucken).
    Meine beiden boards haben einen Atmega 1280 drauf. Der Speicher reicht nur für die Basics.
    Hatte auch mal spaßeshalber ein reprap discount glcd angeschlossen und es funktionierte.


    Hoffe ich habe bis hierhin nichts vergessen und Ihr könnt auch was damit anfangen!


    Die bereitgestellte config ist nicht Plug and Play!

    Ich hafte auch nicht für schäden am Gerät und Umgebung!


    Gruß

    Jens

    PS: Ich habe es nicht geschafft die Datei hier im Forum oder Filebase zu laden, verzeiht mir daher bitte den Link
    https://mega.nz/#!wdUSnCgB!x3j…sknDyYWZnYQ9j8Ef_cEtDk9aw

  • Hallo dermm,

    könntest Du bitte erklären wie Du das Display ans laufen bekommen hast, sowohl Original als auch reprap discount glcd? Bei Letzerem insbesondere welche pins wo anklemmen, wahrscheinlich auf dem Steckplatz für das breite Flachbandkabel?

    Kompilieren der Firmware funktioniert, jedoch zeigt das Display nur die 2 Weissen Balken...

    Tastendrücke werden angenommen, zumindest Mitteltaste. Bedienung über Pronterface klappt auch so weit.

    Jetzt noch Display und ich muss die Hardware nicht umbauen...


    Gruß, Barisov

  • Hallo Barisov.


    Leider habe ich erst jetzt mitbekommen das du geschrieben hast. Obwohl alle Benachrichtigungen aktiviert sind, kam keine Email.


    Jetzt bin ich ja da. Das dass Display nicht funktioniert liegt sehr wahrscheinlich an der (New)Liquidcristal 1.3.4. Ein Update der Library schmeißt den Patch raus. Das Display wird über ein Schieberegister angesteuert. Der Patch korrigiert die Pin Belegung am Register.


    Ich vermute das die gepatchte Lib am falschen Ort liegt. Such mal nach dem Ordner auf deinen PC und ersetze den durch den aus der ZIP. Kann erst Später genauer forschen da ich gerade Unterwegs bin.


    Einen meiner beiden Drucker habe ich letzten Monat auf Klipper umgestellt. Das läuft Bombe auf der Kiste. Der Zweite folgt sobald ich mal dazu komme die Motorkabel zu erneuern.


    Das Grafik Display hatte ich am breiten Flachkabel Anschluss aufm Board mit einfachen Jumper Kabeln angeschlossen. Welcher Pin wohin habe ich mir damals aus den Datenblättern und der Datei "pins_MIGHTYBOARD_REVE.h" abgeleitet und nicht weiter dokumentiert,


    Gruß

  • Hallo Dermm,

    habe inzwischen selbst das Problem gelöst, Lösung ist halbwegs universell.

    In der New Liquid Cristal library ist das 74595 Shift Register als Standard drin.

    Um nicht in der Library pachen zu müssen, übergebe ich die Parameter über den Aufruf des Konstuktors.


    In der ultralcd_HD44780.cpp wie folgt ändern:


    #elif ENABLED(SR_LCD_3W)


    // 3 wire latching LCD SR


    LCD_CLASS lcd(SR_DATA_PIN, SR_CLK_PIN, SR_STROBE_PIN, SR_EN, SR_RW, SR_RS, SR_D4, SR_D5, SR_D6, SR_D7);// Die Parameter werden in der Reihenfolge übernommen



    In der pins_MIGHTYBOARDREVE.h


    wie folgt ändern / hinzufügen:(ab #define SAV_3DLCD):


    #define SAV_3DLCD

    #define SR_CLK_PIN 35 // PC2

    #define SR_DATA_PIN 34 // PC3

    #define SR_STROBE_PIN 33 // PC


    //New liquidcrystal uses 74H595 SR as default!

    // for original CTC-lcd HD44780 with HEF4094 shift-register, definition of

    // LCD-Pin to SR-Output; SR-Out count begins at "0"!

    // for other Shift-Register type change values according to its Pinout

    #define SR_EN 3 //4094 Pin 7, QP3 - LCD Pin 6(EN)

    #define SR_RW 2 //4094 Pin 6, QP2 - LCD Pin 5(RW)

    #define SR_RS 1 //4094 Pin 5, QP1 - LCD Pin 4(RS)

    // unused: //4094 Pin 4, QP0

    //http://www.geeetech.com/wiki/images/2/28/MakerBot_Replicator_Interface_REVB_Schematics_and_Fab_Files.pdf quotes the use of HEF4094 connected as follows:


    #define SR_D4 4 //4094 Pin 14, QP4 - LCD Pin 11(D4)

    #define SR_D5 5 //4094 Pin 13, QP5 - LCD Pin 12(D5)

    #define SR_D6 6 //4094 Pin 12, QP6 - LCD Pin 13(D6)

    #define SR_D7 7 //4094 Pin 11, QP7 - LCD Pin 14(D7)

    // https://playground.arduino.cc/Code/LCD3wires/ uses the following Pinout

    // which makes much sense because there are no wire crossings:

    //#define SR_D4 7 //4094 Pin 11, QP7 - LCD Pin 11(D4)

    //#define SR_D5 6 //4094 Pin 12, QP6 - LCD Pin 12(D5)

    //#define SR_D6 5 //4094 Pin 13, QP5 - LCD Pin 13(D6)

    //#define SR_D7 4 //4094 Pin 14, QP4 - LCD Pin 14(D7)


    Die Pindefinitionen können natürlich auch wo anders stehen, macht aber denke ich in der Boarddefinition Sinn.


    Gruß, Barisov

    The post was edited 1 time, last by Barisov: Code farbig markiert ().

  • Ja, Klipper ist eine feine Sache... Da ich im Moment fünf Drucker für eine Schule betreue, die alle laufen müssen, bleibt es erst mal bei Marlin. Da bin ich halbwegs drin, Marlin auf dem Bizer wollte ich nur, damit ich Replicator G oder den Zwischenschritt mit dem x3g Konverter nicht brauche. Habe übrigens auf dem Board den C20 nachgerüstet, jetzt ist das Softwareupdate kein Problem mehr. Vorher hing die ganze Zeit ein mysmartUSB dran, das mit dem Resetknopf hat genervt. Wenn ich mal die Zeit finde, baue ich auf Ramps um und verkaufe das Mightyboard komplett mit Kabeln, Thermistoren LCD...

    24V Ramps habe ich noch rumliegen.


    Gruß, Barisov

    The post was edited 1 time, last by Barisov: Schreibfehler x3g berichtigt ().

  • Anzeige:
  • Über die Art der Einbringung hatte ich auch nachgedacht. Habe mich letztendlich für Patchen der Library entschieden da diese bei mir nicht automatisch aktualisiert wird. So ist der Marlin Code näher am Original und kann leichter aktualisiert werden.


    Ich versteh immer noch nicht was alle gegen das Board haben. Ramps ist klar universeller aber ab Werk kann es deutlich weniger. So wie ich es sehe haben die damals schon die Technik von heute verbaut (abgesehen von der CPU Leistung). Verstellbare Motorströme usw.
    Der einzige Grund, der mir einfällt das Board abzustoßen, ist der Software Support. Für den sorge ich selber.


    Der C20 ist bei meinen seit der ersten Woche über ein Kippschalter nachgerüstet. Meinen mysmartUSB brauchte ich für was anderes. Über Schalter deshalb weil och damals noch viel mehr gebastelt habe und jedes umstecken oder jeder Wackler am USB sorgte für einen Reset.

  • Das Board als solches finde ich ja auch nicht schlecht, bietet viele Optionen, auch wenn man ein paar Bauteile nachsetzen muss um alles zu nutzen. Massiv stört mich der ATMega 1280 bzw. dessen geringer Speicher. Um den zu tauschen fehlt mir das notwendige Lötwerkzeug und vor allem Übung. Mit 2560 drauf wäre das ein sehr gutes Board...


    Um noch mal zum Ursprung zurückzukehren:

    das mit der gepatchen Library bzw wie man die wohin kopiert habe ich noch nicht geschnallt.

    Oder passt das bei VStudio sofort wenn ich damit das entpackte Verzeichnis bearbeite/kompiliere?

    Wäre halt interessant für die Leute die Platformio auf Atom betreiben (wie ich). Bei mir war es so, das er beim ersten Compilerlauf erst mal die Librarys runtergeladen hat. Ich denke, das hat dann die gepatchte Version überschrieben.


    Gruß, Barisov

  • Unter VSCode war es bei mir reproduzierbar Plug and Play. Keine Änderungen an den Libraries notwendig.Klar lädt er beim Import oder Compilerlauf fehlende Libraries nach aber bei mir erkannte er die vorhandene und überschrieb diese nicht.

    VSCode erkennt aber sehr wohl Aktualisierungen und bietet diese an. Was sein kann, ist das es ein Update der (New)Liquidcristal existiert und installiert wird.


    Hast du denn nach der Automatischen Installation der (New)Liquidcristal, die vorhandene mit der aus der ZIP Datei mal überschrieben? Die Ordner müssen ja irgendwo greifbar sein. Dann müsste es reichen diesen zu finden und zu ersetzen.


    Hab mal nachgeschaut. In der LiquidCrystal_SR3W.cpp hatte ich nur die Zeilen, 104, 111, 118 und 126 - 129 angepasst. Das sind die Zeilen in denen steht wie das Display am Schieberegister angeklemmt sind.


    Laut https://docs.platformio.org/en…ymanager/ldf.html#storage gehört demnach die LCD Lib in einem Verzeichnis Namens "lib_dir". Habe tatsächlich einen Privaten Ordner von VSCode falsch gedeutet.

    Könnte das einer Testen in dem er den ".piolibdeps" Ordner in "lib_dir" umbenennt?

    The post was edited 2 times, last by dermm ().

  • Hab mal drübergeschaut:

    mit Platformio/VSCode/Win10 versucht die frisch entpackten Dateien zu compilieren.

    1. Compiler-Fehler: Bedsize passt nicht, im Quellcode geändert, der Fehler ist weg.

    2. Compiler-Fehler: SlowI2Cmaster Library fehlt. In platformio.ini nachgetragen,

    https://github.com/stawel/Slow…Master/archive/master.zip (unter lib_deps=)

    Folge: Compiler läuft durch!


    Ich habe jetzt rausgefunden woran es bei mir (wahrscheinlich) gelegen hat:

    Unter Platformio/Atom/OSX gab es bei mir am Anfang einen Compilerfehler

    der nicht wegging. es kam jedoch die Empfehlung die .pio* Verzeichnisse zu löschen, habe ich gemacht,

    Dann hat er die Libs neu geladen (und der Patch war weg), allerdings klappte dann (auch hier Fehler 1 und 2 beseitigt das compilieren. Dafür aber nur die 2 Balken im Display.


    Bin jetzt nicht der Profi-Programmierer, aber (gerade wenn man Code weitergibt) sollte man das ganze möglichst gut dokumentieren, damit es nachvollziehbar bleibt. Gerade bei der Verwendung von Libraries sollte man diese nicht direkt patchen, sondern die Schnittstellen die bereitgestellt werden auch im Sinne des Erfinders nutzen. Dafür ist ja hier (Newliqudcrystal) extra die Möglichkeit gegeben, die Pins "von außen" zu übergeben. Hat den Vorteil, das man bei Updates der Libraries nicht immer wieder patchen muss.


    Minimale Änderung des Quellcodes (in ultralcd_HD44780.cpp)


    #elif ENABLED(SR_LCD_3W)


    // 3 wire latching LCD SR

    // Pinbelegung für Schieberegister ([[Data, Clock, Strobe]Mightyboard Pins],[[EN, RW, RS, D4, D5, D6, D7]

    // BitNr. Schieberegister an Eingang LCD]) hier für 4094 wie im Bizer verbaut

    LCD_CLASS lcd(SR_DATA_PIN, SR_CLK_PIN, SR_STROBE_PIN, 3, 2, 1, 4, 5, 6, 7);


    Und Fertig... Sollte dann auch mit neueren und ungepatchten Versionen der Lib funktionieren.


    Gruß, Barisov

    p.s. Vielleicht kann man noch eine Ebene höher ansetzen, da wo lcd() zum ersten mal aufgerufen wird. habe gerade nicht die Zeit das zu prüfen. Mir ist nicht ganz klar, ob ultralcd_HD44780.ccp Teil vom Marlin Quellcode oder auch schon eine Lib ist.

  • Der ganze Quatsch ist nicht mehr nötig...

    Im Marlin bugfix2.0.x ist jetzt der original-Quellcode von Sailfish für das Display integriert...

    So wie ich das verstanden habe wird Sailfish nicht mehr weiterentwickelt???


    Gruß, Barisov

  • Anzeige:
  • Die ist der Marlin Quellcode. Bei einem Update des Codes ist es weg.


    Der ganze Quatsch ist nicht mehr nötig...

    Im Marlin bugfix2.0.x ist jetzt der original-Quellcode von Sailfish für das Display integriert...

    So wie ich das verstanden habe wird Sailfish nicht mehr weiterentwickelt???


    Gruß, Barisov

    Leider nein. Dort ist der Temperaturfühler Bug ausgemerzt (das ist bei meiner Version auch drin) aber das Display läuft dort über ein Workaround. Soweit ich das verfolgt habe, nehmen die einfach die Lib aus dem Sailfish repository. Genauer gesagt muss diese selber besorgt werden. Es kann funktionieren, viele meldeten Probleme beim einbinden.


    Sailfish wurde lange nicht mehr gepflegt. Für Tod wurde es noch nicht erklärt.

  • Ich hatte mich auch mal an das Thema gewagt, hat mich zwei Abende gekostet das ganze so zum Laufen zu bringen damit der Build-Prozess durchläuft und das Display funktioniert, aber ohne diese Seite hätte ich es gar nicht erst gewagt glaube ich.


    Ein bisschen unsicher bin ich mir noch was die ganzen Einträge hier drin angeht da jeder sich das zurechtgebastelt hat wie er es braucht.


    Ich nutze Atom/Platformio auf Win10 mit der Zip oben von Mega.


    Folgende Fehler sind bei mir aufgetreten:


    Bed size falsch, habe ich so angepasst:


    Code
    1. #define X_BED_SIZE 230
    2. #define Y_BED_SIZE 150
    3. #define X_MIN_POS 0
    4. #define Y_MIN_POS 0
    5. #define Z_MIN_POS 0
    6. #define X_MAX_POS 230
    7. #define Y_MAX_POS 150
    8. #define Z_MAX_POS 150


    Wenn ich mich nicht irre hat der CTC Bizer 230x145x150, ist also 5 mm zu groß. Momentan habe ich noch einen Homing Fehler sobald ich das manuell starte. Also das Homing auf einer Achse läuft erfolgreich ab, danach wird mir angezeigt dass das Homing gescheitert ist und ich einen Reset machen soll. Ich gehe davon aus dass ich eine der anderen Optionen hätte ändern müssen nachdem ich den Nullpunkt von der Mitte weggeschoben habe. Erst mal kein Drama.

    Update: Nein, einfach eigene Dummheit weil ich den X-Endstop immer händisch ausgelöst habe da der Schrittmotor nicht drauf war. Marlin erwartet nach dem ersten antasten und wiederholtem anfahren dass man wieder Kontakt zum Endstop hat was bei mir beim manuellem Auslösen nicht der Fall war.


    Dann die fehlenden SlowSoft Library in der platformio.ini eingetragen:


    https://github.com/stawel/Slow…Master/archive/master.zip


    Diese Quelle sollte man glaube ich nicht nehmen wegen anderer Bauteilebestückung vom Mainboard: https://github.com/felias-fogg/SlowSoftI2CMaster


    Dann noch wie angegeben die pins_arduino.h im Benutzerverzeichnis ersetzen wie beschrieben und der Buildprozess läuft durch nur wie oben beschrieben mit den zwei Streifen im Display. Was ich dann nicht verstehe ist wo die Unterschiede zwischen den drei Lösungen sind:


    1. in mightyboard_reve.h:

    und in der ultralcd:HD44780.cpp:

    Code
    1. LCD_CLASS lcd(SR_DATA_PIN, SR_CLK_PIN, SR_STROBE_PIN, SR_EN, SR_RW, SR_RS, SR_D4, SR_D5, SR_D6, SR_D7);

    oder stattdessen 2. in ultralcd_HD44780.cpp:

    Code
    1. #elif ENABLED(SR_LCD_3W)
    2. LCD_CLASS lcd(SR_DATA_PIN, SR_CLK_PIN, SR_STROBE_PIN, 3, 2, 1, 4, 5, 6, 7);

    oder 3. einfach die offizielle Marlin 2.0x bugfix nehmen und mightyboard reve, CTC Display und den Rest anpassen wie man es braucht/nutzt.


    Bei Lösung 1 und 2 musste ich folgenden Code in der UltraLCD unmittelbar unter dem veränderten löschen:

    Code
    1. #if PIN_EXISTS(SR_STROBE)
    2. , SR_STROBE_PIN
    3. #endif
    4. );

    Ansonsten gabs immer einen Fehler wegen unqualified ID usw. Leider sind meine Programmierkenntnisse zu schlecht um das zu verstehen. Ich habe mir entsprechende Programmierbeispiele angeschaut und ansatzweise verstanden, bis ich das wirklich raus hätte ist wahrscheinlich ne Woche vorbei. Also einfach nach trial and error rumprobiert und gemerkt dass löschen hilft. Nicht sehr professionell, aber ich will einfach nur dass die Kiste läuft.


    Warum ich eigentlich zu Marlin wollte ist weil ich vom Thermocouple weg wollte, mir ist einer kaputt gegangen und ich hatte noch nen Hotend mit NTC 3950 rumliegen, sobald ich in der configuration.h von -2 auf 13 umstelle bekomme ich neue Fehler dass es kein wait for hotend gibt:

    Code
    1. Marlin\src\gcode\temperature\M104_M109.cpp:139:26: error: 'class Temperature' has no member named 'wait_for_hotend'

    Keine Ahnung ob das von der Elektronik vom Board her überhaupt geht was ich vorhabe. Kann mir das jemand sagen? Ansonsten bleibe ich halt bei einem Single-Extruder.


    Ich würde das ganze gerne etwas noobfreundlicher zusammenschreiben wenn mir jemand noch mal auf die Sprünge hilft. Lösung 3 wäre theoretisch am leichtesten wenn man eine passende configuration.h für das Gerät hat. Ich meine da hatte ich auch wieder etliche Fehler gehabt und werde noch mal schauen ob ich das zum Laufen bringe.

    • Gäste Informationen
    Hallo. Gefällt Dir dieses Thema im CTC-Forum und du möchtest etwas dazu schreiben? Dann melde dich bitte an. Hast du noch kein Benutzerkonto im CTC-Forum, dann registriere dich bitte. Nach der Freischaltung kannst Du dann das Forum uneingeschränkt benutzen.


Werde Teil des Forums.

Hallo. Gefällt Dir das CTC-Forum und du möchtest mitmachen? Dann melde dich bitte an. Hast du noch kein Benutzerkonto im CTC-Forum, dann registriere dich bitte. Nach der Freischaltung kannst Du dann das Forum uneingeschränkt benutzen.