FSR Auto-Bed-Leveling-System

Hallo,

Nochmal recht vielen Dank für die super Arbeit.
Hab sie FSR Sensoren in meinen Sparkcube seit dem letzten Wochenende erfolgreich in Betrieb genommen. Allerdings funktioniert die Endstopauslösung nur bei 2 Sensoren zuverlässig mit einem triggerThreshold von 75. Der 3. Sensor löst in 50% der Fälle bei diesen Wert zu spät aus sodass hier ein kleinerer Wert nötig wäre. Dann aber lösen die anderen 2 schon beim Verfahren der Druckplatte aus.
Ist es evtl. möglich einen Trigger für jeden Sensor separat einzurichten?

Zusätzlich möchte ich nun noch die LED-Beleuchtung in Betrieb nehmen.
Ich betreibe das FSR-Board mit 24V und habe noch LED-Stips für 12V herumliegen. Kann ich diese verwenden oder sollte ich mir welche für 24V besorgen?

Gruß Matthias

Hallo,
ich habe nun auch die Hülsen und Stempel bekommen und kann jetzt weiterbauen.

Bevor ich irgendwas kaputt mache, frage ich lieber?

Gibt es irgendwo eine Anleitung zur Inbetriebnahme bzw einen Anschlußplan? Wo ist bei den Platinen der Plus und der Minusanschluss (bei der Spannungsversorgung, den LED bzw dem Endstop Ausgang?

Gruß Wolfgang

Hallo Wolfgang,

ich bin gerade in exakt der selben Situation und habe gestern Abend schon einmal den mechanischen Aufbau gestartet und begonnen die Verbindungskabel an die Sensoren zu löten.

Bei Roland auf seiner Homepage habe ich einen Anschlussplan gefunden, allerdings scheint dies noch eine ältere Version zu sein...

Man könnte jetzt davon ausgehen, dass die Stromversorgung sich vermutlich nicht geändert hat - ist aber natürlich risky -

Wenn ich mich noch recht an meine verstaubten Digitaltechnik Vorlesung (~20 Jahre...) erinnere, kannst Du beim Anschluss der Diode nichts kaputt machen, da diese in eine Richtung sperrt (man sollte nur den Vorwiderstand nicht vergessen, der aber auf der Platine verbaut ist).

Also ich würde mich ebenfalls freuen, wenn uns beiden jemand weiterhelfen könnte.

@Roland: Mit welcher FW Version hast Du die letzten Platinen eigentlich ausgeliefert? Ist das die FW1.0 oder die 2.0DEV? Nach meinem Verständnis - wenn man zunächst nur ABL nutzen möchte - benötigt man nur Stromversorgung, 3 Sensoren, opt. 3 LEDs und muss den Endstop-Ausgang mir dem Radds verbinden. Die Radds FW (Repetier 92.9) konfiguriert man dann entsprechend wie wenn man einen induktiven Sensor verwenden würde, oder benötigt man hier auch Deine ABL Firmware von repraptools?

Danke,
Matthias

hier noch ein paar Bilder....








3-mal bearbeitet. Zuletzt am 15.06.16 05:25.

Das Problem hatte ich auch.

Dazu von hier

Quote
Glatzemann

Danke für den Hinweis mit repraptools.de. War mir noch garnicht aufgefallen, werde ich asap korrigieren.

Zum Anschluss bis dahin: Wenn das FSR Board (nur V1.0) vor dir liegt und der Stromanschluss links oben ist, dann ist die erste Schraubklemme +12V (oder mehr, siehe Beschriftung) und die zweite Klemme GND.

.. und dann von mir (weiter unten auf der Seite)

Quote
PLAbär

Den Poweranschluss hatte ich schon rausgemessen: Powerklemmen <-> StepDown Regler IN+ bzw. IN-.
Bei den LEDs hab ich geraten. Natürlich erstmal falsch. Wen es interessiert: Plus ist - wie bei Power - auch links.

Gruß
Lutz

Hi Leutz,
gleich vorweg: SORRY!

....ich wär dann jetzt soweit.....
Mechanik alles fertig,
Elektrik insofern auch, das FSR-Board ist an Z-Min angeklemmt.
wo ich jetzt hänge:
Software!
Bislang hatte ich immer Marlin auf meinen Druckern.
Ursprünglich war auf dem Delta jedoch Repetier (0.91.7), so eingerichtet, dass er zufriedenstellende Ausdrucke lieferte.
Bei Marlin find ich mich solala zurecht, bei Repetier fehlt mir aber jeglicher Plan.
Hat vlt jmd nen Link, wie ich die ABL-Geschichte mit dem FSR in Betrieb nehmen kann?
Danke schonmal
Grüße
seefew

---

Sehen ist nicht nur Augensache
Drucker:
seefew's Jenny

Ist das nicht genauso wie bei Ind./Kap. Sensor? Ich würde den Versatz zum Sensor (X/Y_PROBE_OFFSET_FROM_EXTRUDER) auf 0,0 stellen und Z_PROBE_OFFSET_FROM_EXTRUDER ggf. statt einen negativen Wert einen kleinen positiven Wert oder 0 geben.

Natürlich alles mit der Hand beim Resetknopf

1-mal bearbeitet. Zuletzt am 01.07.16 08:12.

vielen Dank für die Info, aber so weit bin ich noch nicht.
ich müsste erstmal wissen, wie ich in Repetier ABL einschalte und den entsprechenden Pin(Z_Min) dafür angebe?
Ach ja, falls wichtig: ist ein 2560/Ramps
Grüße

---

Sehen ist nicht nur Augensache
Drucker:
seefew's Jenny

Hallo Zusammen,

ich habe auch mal eine kleine Frage zum FSR ABLS.

Wenn ich alles auf den Schreibtisch lege, dann klappt das alles problemlos.
Im Drucker verbaut, geht's dann allerdings nicht mehr ...

Beschreiben wir das alles mal ...
Drucker: Sparkcube XL
Elektronik: RAMPS
"Halterungen" für die FSRs: Gefräst aus Kunststoff
FSR Sensoren mit je zwei Gummiplättchen 2mm "eingepackt"

Sobald ich jetzt einen Punkt antippe, dann kommt das Signal, geht aber nicht mehr weg.

Wie komme ich denn in den Debugmodus auf der Platine?

Ausgabe ist derzeit:
INFO:Welcome to FSR board Firmware v2 dev
INFO:loading eeprom configuration...
INFO:FSR board configuration version 4
INFO:longAverageBufferTime=5000
INFO:defaultEndstopMinHighMs=500
INFO:triggerThreshold=14
INFO:calibrationLedDelay=250
INFO:i2cSlaveAddress=77
INFO:coldTemp=20
INFO:hotTemp=120
INFO:alarmTemp=160
INFO:coldR=0
INFO:coldG=0
INFO:coldB=255
INFO:hotR=255
INFO:hotG=0
INFO:hotB=0
INFO:endstopHighActive=0
INFO:temperatureNominal=25.00
INFO:thermistorNominal=100000.00
INFO:thermistorBeta=4267
INFO:thermistorNumSamples=5
INFO:alarmOutEnabled=0
INFO:rgbOutEnabled=0
INFO:alarmHighActive=0
INFO:starting calibration
INFO:finished calibration
INFO:triggering endstop out
INFO:triggering endstop out

Grüße
Jürgen

@seefew, solange du keine 3 Motoren an Z hast und die einzeln steuern willst, müsste das ganze auch in Marlin laufen.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

@Wurstnase:
Äöhm? 3 Motoren an Z..? Delta
Aber Marlin wollte ich noch probieren, muss aber noch was abchecken, mglw hat der Mega nen Sachten weg.
Irgend was stimmt da nicht, wenn ich Home klappt, wenn ich einige Zeilen GCode für X, Y & Z laufen lass, geht´s auch,
wenn ich z.B. Z100 stelle danach X oder Y am Display verfahren will, hängt sich das Teilen....
Aber das ist ´n anderes Thema und gehört nicht hierher.
Mal sehen, wie´s ausgeht.
Grüße
seefew

---

Sehen ist nicht nur Augensache
Drucker:
seefew's Jenny

Hat jemand schon den I2C mit einem RADDS Board verbunden? Sollte doch ohne weiteres funktionieren, oder?

Ich habe in der Firmware gesehen, dass bereits auf dem I2C gehorcht wird und würde gerne das Ganze etwas erweitern, so dass per Layerwechsel die Farbe der LEDs sich ändern.

Ich habe mal Tests mit RADDS, FSR Board und I2C gemacht, allerdings habe ich da noch nichts produktives gemacht. Auf dem FSR Board kannst du halt die I2C Adresse per M-Code ändern. Wenn I2C verbunden ist, kannst du G-Codes und M-Codes an das FSR Board senden und bekommst entsprechende Status- und Debug-Meldungen zurück.

In Sachen Firmware-Integration (Repetier) bin ich leider nicht weiter gekommen. "Repetier-Roland" hat anscheinend kein Interesse daran, daß ich ihm einen Patch bereitstelle um das in die Firmware zu integrieren. Daher habe ich das nicht weiter verfolgt. Ich habe das allerdings in meiner eigenen Firmware eingebaut und gute Ergebnisse erzielen können (Konfiguration und Debug des FSR Board über das RADDS-Display).

Die Idee mit dem Farbwechsel finde ich allerdings ziemlich cool. Wenn du dich hier einbringen möchtest: Ich stehe gerne helfend zur Seite...

---

--
Microsoft MVP in den Kategorien DirectX/XNA * Visual C++ * Visual Studio and Development Technologies seit 2011

• Mein Erster (RAMPS 1.4, Selbstbau WolfStrap-Derivat mit Linearführungen, Wade Extruder und E3D lite6 Hotend)
• Cub44 (Selbstbau Dual Wire Gantry Derivat mit Zahnriemen und Linearschienen, RADDS 1.5 und DUE, Custom Hotend - E3D like, Compact Bowden Extruder)
• HexMax (sechseckiger Delta (eigenes Design) mit Druckraum 300mm Durchmesser und >=400mm Höhe, RADDS 1.5, 24V, Custom Hotend, Compact Bowden Extruder)
• P3Steel Toolson MK2 - Keine Zeit zum selbst planen ;-)

Andere Projekte: FSR Board (ABL-Sensor-Platine inkl. Firmware) * ThirtyTwo (32Bit RepRap-Firmware)

Quote
Glatzemann
Ich habe mal Tests mit RADDS, FSR Board und I2C gemacht, allerdings habe ich da noch nichts produktives gemacht. Auf dem FSR Board kannst du halt die I2C Adresse per M-Code ändern. Wenn I2C verbunden ist, kannst du G-Codes und M-Codes an das FSR Board senden und bekommst entsprechende Status- und Debug-Meldungen zurück.

In Sachen Firmware-Integration (Repetier) bin ich leider nicht weiter gekommen. "Repetier-Roland" hat anscheinend kein Interesse daran, daß ich ihm einen Patch bereitstelle um das in die Firmware zu integrieren. Daher habe ich das nicht weiter verfolgt. Ich habe das allerdings in meiner eigenen Firmware eingebaut und gute Ergebnisse erzielen können (Konfiguration und Debug des FSR Board über das RADDS-Display).

Die Idee mit dem Farbwechsel finde ich allerdings ziemlich cool. Wenn du dich hier einbringen möchtest: Ich stehe gerne helfend zur Seite...

Danke, dann werde ich RADSS und FSR schon mal verbinden. War mir wieder mal nicht sicher mit den 3,3 <-> 5V, wer hat was. Sollte aber mit dem DUE passen.

Die Stellen im Repetier habe ich schon gefunden. Ich habe deinen Pull-Request nicht mehr gefunden, verstehe aber auch, wenn so etwas ungern aufgenommen wird. Jeden Befehl möchte ich eigentlich auch nicht parallel übers I2C jagen. Ich könnte mir etwas der Art mit G/M-Code vorstellen

//M908 P "address"  S "value" : Set stepper current for digipot (RAMBO board)

//M909 I "I2Cadress" S "stringcode"

Ich bin mir dabei aber nicht sicher, ob der Parser dazu angepasst werden müsste. Das würde ich gerne vermeiden, um wirklich so wenig wie möglich im Repetier-Code zu verändern, so dass ggf. ein Trivial-Patch reichen würde.

Ich schau mal am Wochenende wie weit ich komme.

EDIT: Eckige Klammen im Codeblock ersetzt.

1-mal bearbeitet. Zuletzt am 27.07.16 08:13.

Welche Version vom FSR Board hast du? Die Version 0.9 gibt es in 3.3V und 5V. Die Version 1 gibt es nur noch mit 3.3V, also kein Problem. Die ist so ausgelegt, daß auch 5V von einem RAMPS das FSR Board nicht zerstören :-)

Ich hatte für Repetier auch noch keinen Pull-Request gemacht, sondern vorher ganz brav versucht mit ihm abzustimmen, ob und wie sowas umgesetzt werden könne. Ich wollte halt vermeiden, daß ich etwas entwickele, was nachher nicht passt. Leider habe ich darauf nie irgendwelches Feedback bekommen (auf andere Dinge schon)...

Mein Plan war ungefähr folgender:

In Repetier werden zwei neue M-Codes eingeführt: Start-I2C-Communication und End-I2C-Communication. Paramter ist die Slave ID. Sobal der Start-Code gesendet wird, werden alle folgenden Befehle - bis zum End-Code - auf I2C umgeleitet. Eigentlich eine ganz simple Sache und im Grunde genommen das gleiche Vorgehen, wie es auch beim beschreiben einer SD-Karte im Arduino/Shield gemacht wird.

---

--
Microsoft MVP in den Kategorien DirectX/XNA * Visual C++ * Visual Studio and Development Technologies seit 2011

• Mein Erster (RAMPS 1.4, Selbstbau WolfStrap-Derivat mit Linearführungen, Wade Extruder und E3D lite6 Hotend)
• Cub44 (Selbstbau Dual Wire Gantry Derivat mit Zahnriemen und Linearschienen, RADDS 1.5 und DUE, Custom Hotend - E3D like, Compact Bowden Extruder)
• HexMax (sechseckiger Delta (eigenes Design) mit Druckraum 300mm Durchmesser und >=400mm Höhe, RADDS 1.5, 24V, Custom Hotend, Compact Bowden Extruder)
• P3Steel Toolson MK2 - Keine Zeit zum selbst planen ;-)

Andere Projekte: FSR Board (ABL-Sensor-Platine inkl. Firmware) * ThirtyTwo (32Bit RepRap-Firmware)

Quote
Glatzemann
Welche Version vom FSR Board hast du? Die Version 0.9 gibt es in 3.3V und 5V. Die Version 1 gibt es nur noch mit 3.3V, also kein Problem. Die ist so ausgelegt, daß auch 5V von einem RAMPS das FSR Board nicht zerstören :-)

Ich hatte für Repetier auch noch keinen Pull-Request gemacht, sondern vorher ganz brav versucht mit ihm abzustimmen, ob und wie sowas umgesetzt werden könne. Ich wollte halt vermeiden, daß ich etwas entwickele, was nachher nicht passt. Leider habe ich darauf nie irgendwelches Feedback bekommen (auf andere Dinge schon)...

Mein Plan war ungefähr folgender:

In Repetier werden zwei neue M-Codes eingeführt: Start-I2C-Communication und End-I2C-Communication. Paramter ist die Slave ID. Sobal der Start-Code gesendet wird, werden alle folgenden Befehle - bis zum End-Code - auf I2C umgeleitet. Eigentlich eine ganz simple Sache und im Grunde genommen das gleiche Vorgehen, wie es auch beim beschreiben einer SD-Karte im Arduino/Shield gemacht wird.

Ich habe die 1.0 Variante. Schön, dass RAMPS auch geht. Da habe ich noch eins rumliegen und kann besser spielen.

Wie schon erwähnt habe ich keine Ahnung, was es im Detail bedeutet jeden Befehl über I2C zu pusten. Da I2C-Start/End recht schnell geht und nur wenige Befehle für das Board gedacht sind, würde ich die Sache mit dem Spezielbefehl bevorzugen. Das könnte dann auch für weitere I2C - Geräte genutzt werden.

Eigentlich wollte ich dieses Wochenende ein paar Zeilen Code schreiben. Ich hab aber dann erst mitbekommen, dass es noch gar keinen Code für RGB-Leds gibt. Also kurz den Code geschrieben. Ausprobieren? Die RGB-Leds haben 12V. Ich muss erst noch einen Stepdown auf 12V reinbauen, da ich nur ein 24V Netzteil im Drucker habe. Das probiere ich die nächsten Tage aus und würde einen Pull-Request in den DEV-Zweig machen, wenn es funktioniert.

Heute habe ich den ganzen Tag damit verbracht, die Kommunikation in Repetier einzubauen. Leider erfolglos. Da der EEPROM mit an I2C hängt, habe ich zunächst mal ein Oszilloskop rangehängt. Die Kommunikation beim M502 auf dem DUE kann ich sehen. Nur wenn ich versuche irgendetwas zu senden, passiert schlicht nichts. Da muss ich mich wohl noch mehr in die HAL Klasse einarbeiten.

Wie wieder mal so wenig Zeilen so einen Ärger machen können...

Ich melde mich wieder bei Erfolgen.

Viele Grüße

Pieps

Im dev Zweig ist doch LED Code drin?!? Der wird doch schon fleißig eingesetzt und getestet...

Hast du die I2C Pins auf dem RADDS genommen, die oberhalb der Endstops liegen?

---

--
Microsoft MVP in den Kategorien DirectX/XNA * Visual C++ * Visual Studio and Development Technologies seit 2011

• Mein Erster (RAMPS 1.4, Selbstbau WolfStrap-Derivat mit Linearführungen, Wade Extruder und E3D lite6 Hotend)
• Cub44 (Selbstbau Dual Wire Gantry Derivat mit Zahnriemen und Linearschienen, RADDS 1.5 und DUE, Custom Hotend - E3D like, Compact Bowden Extruder)
• HexMax (sechseckiger Delta (eigenes Design) mit Druckraum 300mm Durchmesser und >=400mm Höhe, RADDS 1.5, 24V, Custom Hotend, Compact Bowden Extruder)
• P3Steel Toolson MK2 - Keine Zeit zum selbst planen ;-)

Andere Projekte: FSR Board (ABL-Sensor-Platine inkl. Firmware) * ThirtyTwo (32Bit RepRap-Firmware)

Ups... muss ich noch mal nachschauen. Hatte mich schon gewundert.

Ja die SLA/SLC - Pins genau unter der Sicherung bzw. über den Endstops (Min).

Klassiker. Ich habe vergessen den Branch anzugeben beim clonen. Jetzt habe ich auch Color - Klassen

:-D

Würde vorschlagen, daß ein neuer M Code eingeführt wird, mit dem man die Farbe (Parameter R G und angeben kann und ob die LED an oder aus sein soll (S1 und S0 beispielsweise)...

---

--
Microsoft MVP in den Kategorien DirectX/XNA * Visual C++ * Visual Studio and Development Technologies seit 2011

• Mein Erster (RAMPS 1.4, Selbstbau WolfStrap-Derivat mit Linearführungen, Wade Extruder und E3D lite6 Hotend)
• Cub44 (Selbstbau Dual Wire Gantry Derivat mit Zahnriemen und Linearschienen, RADDS 1.5 und DUE, Custom Hotend - E3D like, Compact Bowden Extruder)
• HexMax (sechseckiger Delta (eigenes Design) mit Druckraum 300mm Durchmesser und >=400mm Höhe, RADDS 1.5, 24V, Custom Hotend, Compact Bowden Extruder)
• P3Steel Toolson MK2 - Keine Zeit zum selbst planen ;-)

Andere Projekte: FSR Board (ABL-Sensor-Platine inkl. Firmware) * ThirtyTwo (32Bit RepRap-Firmware)

Aktuell habe ich M921 verwendet. S=0 => off, S=1 K= B= V=. Wenn KBV nicht verwendet setzt es alle auf 255. S=2 die Heizbettvariante.

Ich überlege noch ob ich mit - und + bei den Variablen arbeite, ohne hart setzen, sonst im Wertebereich addieren oder subtrahieren. Dann könnte man einfacher die Scripte bei Layerchange erarbeiten.

Auf Github habe ich einen Pullrequest im dev-v2 branch gemacht.

Es gibt ein neues Kommando, mit dem die RGB-Leds ein/aus geschaltet werden können und auch auf eine bestimmte Farbe gesetzt werden können.

M921 S<0|1|2> K"redValue" V"greenValue" B"blueValue"

S=0 => off
S=1 => set color. Any color not set will be set to 255.
S=2 => use thermistor

S1 ohne weitere Parameter schaltet weißes Licht ein. S2 den Thermistor. Den Thermistor konnte ich leider nicht mehr testen, da ich versehentlich beim Umbau 12V drauf gelegt habe. Hat nur den Thermistor-Port gekillt.

Anbei ist der Repetier-Patch für die I2C-Kommunikation. Der ist noch nicht so weit aufbereitet, dass man ihn an Repetier schicken könnte.

Funktioniert auch mit der aktuellen 0.92 im Repetier-Verzeichnis mittels:

patch -p4 < pfad_zum_patch

ACHTUNG! Ich habe versehentlich meine Configuration.h eingecheckt. Die Frage "Reversed (or previously applied) patch detected! Assume -R? [n] n" mit "n" beantworten. Die Frage danach "Apply anyway? [n] " auch mit "N" beantworten.

Ihr könnt dann mit dem Kommando

M920 < FSR_Befehl >

jeden Befehl an das FSR-Board schicken. Aktuell ist die I2C Adresse noch fest auf 77 (default im FSR-Board).

Also Beispiel RGBLed an

M920 M921 S1

Ich hatte Anfangs Probleme damit, das nach dem ersten Ausführen der Befehl hinter M920 nicht mehr gefunden wurde. Ich kann den Fehler aber nach einem Update auf Arduino 1.6.10 nicht mehr reproduzieren. Sollte jemand bereit sein zu testen und den Fehler noch haben, meldet euch bitte.

Next Steps:
Ich werde noch einen Rückkanal einbauen, damit alle Antworten vom FSR-Board auf der Serial-Console des Arduino zu sehen sind. Auch die Erweiterung des M921 Befehls + und - als Addition / Subtraktion zu erkennen fehlt noch.

Quote
iceman1306
Statt am Sparkcube ist sie nun am Hexagon V2 gelandet. I

Hallo Iceman,

kannst Du eventuell beschreiben, wie due es im HexagonV2 verbaut hast, Ich würde auch gerne auf ABL erweitern.#

Gruß
Christian

@Pieps: Gefällt mir sehr gut und ich habe den Pull-Request bereits in den DEV-V2 Branch gemerged (und die readme.md noch angepasst, damit der Befehl auch dokumentiert ist). Das mit dem Thermistor werde ich nochmal durchtesten. Ich denke hier wäre noch eine kleine Erweiterung fällig, so daß nach einem Reset des FSR Board der Status der LED-Kontrolle erhalten bleibt (sprich sollte im EEPROM gespeichert werden). Die Farbe der LED könnte man dort auch noch speichern, aber wenn die häufiger geändert wird, dann müsste man sich noch mal Gedanken machen, wie man ein Wear-Levelling für das EEPROM einbaut, damit dieses nicht zu schnell erschöpft.

Auch die Lösung für Repetier finde ich so ganz gut. Eigentlich gefällt mir die so sogar noch fast besser als meine Idee :-) Jetzt müssen nur noch die Meldungen vom FSR Board irgendwie "durchgeschliffen" werden und dann ist es rund :-)

---

--
Microsoft MVP in den Kategorien DirectX/XNA * Visual C++ * Visual Studio and Development Technologies seit 2011

• Mein Erster (RAMPS 1.4, Selbstbau WolfStrap-Derivat mit Linearführungen, Wade Extruder und E3D lite6 Hotend)
• Cub44 (Selbstbau Dual Wire Gantry Derivat mit Zahnriemen und Linearschienen, RADDS 1.5 und DUE, Custom Hotend - E3D like, Compact Bowden Extruder)
• HexMax (sechseckiger Delta (eigenes Design) mit Druckraum 300mm Durchmesser und >=400mm Höhe, RADDS 1.5, 24V, Custom Hotend, Compact Bowden Extruder)
• P3Steel Toolson MK2 - Keine Zeit zum selbst planen ;-)

Andere Projekte: FSR Board (ABL-Sensor-Platine inkl. Firmware) * ThirtyTwo (32Bit RepRap-Firmware)

Quote
Glatzemann
@Pieps: ... Ich denke hier wäre noch eine kleine Erweiterung fällig, so daß nach einem Reset des FSR Board der Status der LED-Kontrolle erhalten bleibt (sprich sollte im EEPROM gespeichert werden). Die Farbe der LED könnte man dort auch noch speichern, aber wenn die häufiger geändert wird, dann müsste man sich noch mal Gedanken machen, wie man ein Wear-Levelling für das EEPROM einbaut, damit dieses nicht zu schnell erschöpft.

Also der Startstatus wird ja aus dem EEPROM gelesen.(Constructor RGBLed.cpp)

state = Configuration::getRgbOutEnabled() ? Manual : Heating;

Die Farbe der LED speichern. Mhhh. will man das wirklich? Ich habe mir bisland vorgestellt:

1. Drucker im Leerlauf, aus oder weiß an.
2. Aufheizen. Thermistoranzeige
3. Drucken erste Layer. Hell weiß für gute Sicht aufs Objekt.
4. Ab n-ten Layer. Wechsel in eine andere Farbe. Z. Bsp. grün. Je näher letzter Layer je mehr in die Farbe rein.
5. Druckende = 1.

Oder hast du andere Ideen bei der Verwendung?

Quote
Glatzemann
Auch die Lösung für Repetier finde ich so ganz gut. Eigentlich gefällt mir die so sogar noch fast besser als meine Idee :-) Jetzt müssen nur noch die Meldungen vom FSR Board irgendwie "durchgeschliffen" werden und dann ist es rund :-)

Ja, hier fehlt noch der Listener für den Rückkanal. Da ich im anderen Projekt gerade nicht weiter komme, werde ich das mal in Angriff nehmen.

Arghh... Ich habe die Zeile voll übersehen

Ich sag nur:

Eigentlich ist die Lösung so schon optimal... Die Farbe muss eigentlich nicht gespeichert werden...


Mit dem Rückkanal wäre echt genial...

---

--
Microsoft MVP in den Kategorien DirectX/XNA * Visual C++ * Visual Studio and Development Technologies seit 2011

• Mein Erster (RAMPS 1.4, Selbstbau WolfStrap-Derivat mit Linearführungen, Wade Extruder und E3D lite6 Hotend)
• Cub44 (Selbstbau Dual Wire Gantry Derivat mit Zahnriemen und Linearschienen, RADDS 1.5 und DUE, Custom Hotend - E3D like, Compact Bowden Extruder)
• HexMax (sechseckiger Delta (eigenes Design) mit Druckraum 300mm Durchmesser und >=400mm Höhe, RADDS 1.5, 24V, Custom Hotend, Compact Bowden Extruder)
• P3Steel Toolson MK2 - Keine Zeit zum selbst planen ;-)

Andere Projekte: FSR Board (ABL-Sensor-Platine inkl. Firmware) * ThirtyTwo (32Bit RepRap-Firmware)

Hallo,

da ich aktuell nicht weiter komme mal einen kurzen Stand zum I2C Rückkanal.

Die Idee war Serial nach Wire umzuleiten. Beide sind ja von Stream abgeleitet. Soweit die Theorie. Leider lässt die Wire-lib keine mehrfachen print(..) oder write(..) zu. Es wird schlicht immer der letzte Befehl übertragen.

Einen Puffer hatte ich versucht, aber selbst 256 Bytes würden für die gesprächigen Befehle nicht reichen.

Daher bliebe nur die twi.c und Wire.cpp selbst zu implementieren. Aktuell finde ich dafür aber nicht die Ruhe, das zu Implementieren.

Eine alternative wäre noch den 2. seriellen Anschluß zu verwenden.

Viele Grüße

Pieps

Du meinst auf Seite des FSR? Das kann standardmäßig immer auf I2C schreiben. Nur wenn ein FTDI angeklemmt ist, soll es auf Serial schreiben.

Ich werde nach meinem Urlaub mal alle Ausgabebefehle kapseln und eine Erkennung machen, ob der FTDI angeklemmt ist. Dann kann man besser damit entwickeln.

---

--
Microsoft MVP in den Kategorien DirectX/XNA * Visual C++ * Visual Studio and Development Technologies seit 2011

• Mein Erster (RAMPS 1.4, Selbstbau WolfStrap-Derivat mit Linearführungen, Wade Extruder und E3D lite6 Hotend)
• Cub44 (Selbstbau Dual Wire Gantry Derivat mit Zahnriemen und Linearschienen, RADDS 1.5 und DUE, Custom Hotend - E3D like, Compact Bowden Extruder)
• HexMax (sechseckiger Delta (eigenes Design) mit Druckraum 300mm Durchmesser und >=400mm Höhe, RADDS 1.5, 24V, Custom Hotend, Compact Bowden Extruder)
• P3Steel Toolson MK2 - Keine Zeit zum selbst planen ;-)

Andere Projekte: FSR Board (ABL-Sensor-Platine inkl. Firmware) * ThirtyTwo (32Bit RepRap-Firmware)

Nein, es geht um zwei Probleme der Wire-Lib. Eins wird hier diskutiert. Das ist das Problem, das ich oben gemeint habe. Das Problem ist im Slave-Mode zu schreiben.

Wire.write("11111");
Wire.write("2222");

Wird 2222 übermittlen.

Ein zweites Problem ist der kleine Buffer von 32 Zeichen. Den müsste man erhöhen.

Zum Thema I2C Kommunikation habe ich gerade bei Marlin:Configuration_adv.h folgendes gefunden. Auch eine interessante Lösung.

/**
 * TWI/I2C BUS
 *
 * This feature is an EXPERIMENTAL feature so it shall not be used on production
 * machines. Enabling this will allow you to send and receive I2C data from slave
 * devices on the bus.
 *
 * ; Example #1
 * ; This macro send the string "Marlin" to the slave device with address 0x63 (99)
 * ; It uses multiple M155 commands with one B arg
 * M155 A99  ; Target slave address
 * M155 B77  ; M
 * M155 B97  ; a
 * M155 B114 ; r
 * M155 B108 ; l
 * M155 B105 ; i
 * M155 B110 ; n
 * M155 S1   ; Send the current buffer
 *
 * ; Example #2
 * ; Request 6 bytes from slave device with address 0x63 (99)
 * M156 A99 B5
 *
 * ; Example #3
 * ; Example serial output of a M156 request
 * echo:i2c-reply: from:99 bytes:5 data:hello
 */

// @section i2cbus

//#define EXPERIMENTAL_I2CBUS