FSR Auto-Bed-Leveling-System
geschrieben von Glatzemann
|
Re: FSR Auto-Bed-Leveling-System 17. October 2016 09:05 |
Quote
Glatzemann
Eben habe ich - da dies ja schon mehrfach Thema war - eine neue Version der DEV-V2 Firmware auf Github veröffentlicht.
- Alle Sensor-LEDs flackern während der Endstop-Ausgang durchgeschaltet ist. Druck wird nicht angezeigt.
So könnte man auf den Anschluss einer zusätzlichen LED verzichten, wenn der Endstop-Status "extern" angezeigt werden soll.
Das wird heute Abend gleich mal getestet.
Die Idee mit den LED-Modi finde ich gut, aber warum flackern lassen als Anzeige für den Endstop-Ausgang? An/Aus wäre da doch besser, oder?
Gruß Pieps
|
Re: FSR Auto-Bed-Leveling-System 19. October 2016 03:52 |
Hey,
also bei mir ist das ganze eigentlich recht simpel, bin aber auch noch am tüfteln.
Mein Aufbau ist folgender (Sparkcube):
Habe eine Alu Grundplatte von Gonzoh, dann die gedruckten Hülsen geschraubt in welche ich zuerst den Sensor gelegt und dann eine Silikonscheibe drauf gelegt. Die Stempel werden an das Heizbett geschraubt und in die Stempel dann in die Hülsen gestellt.
So der Minimalaufbau. Einige arbeiten hier noch mit Federn oder noch komplexer. Das ist lediglich mein erster Aufbau. Keep it simple
Grüße
also bei mir ist das ganze eigentlich recht simpel, bin aber auch noch am tüfteln.
Mein Aufbau ist folgender (Sparkcube):
Habe eine Alu Grundplatte von Gonzoh, dann die gedruckten Hülsen geschraubt in welche ich zuerst den Sensor gelegt und dann eine Silikonscheibe drauf gelegt. Die Stempel werden an das Heizbett geschraubt und in die Stempel dann in die Hülsen gestellt.
So der Minimalaufbau. Einige arbeiten hier noch mit Federn oder noch komplexer. Das ist lediglich mein erster Aufbau. Keep it simple
Grüße
|
Re: FSR Auto-Bed-Leveling-System 19. October 2016 08:55 |
Ich habe nun auch die aktuelle Version DEV-V2 eingespielt. Läuft soweit problemlos. Momentan spiele ich gerade etwas mit der I2C Anbindung an Repetier. Habe den Branch von Pieps geladen und an die aktuellste Repetierversion angepasst. Ich habe sämtliche Änderungen die auch der I2C Patch enthält entsprechend ergänzt, bzw. überprüft. Kompiliert ist mit Arduino Studio 1.6.12. Jetzt habe ich folgende Probleme: ergänze ich den Befehl M920 in Repetier wird der String nach Befehlseingabe M920 nicht erkannt. Verwende ich den bestehenden Befehl M117 und ändere den Code entsprechend ab, klappt die I2C Kommunikation Richtung FSR Board. Die Rückmeldung vom FSR Board klappt leider gar nicht. Sobald ich den entsprechenden Code aktiviere bekomme ich alle 2-3s einen Reset durch den Watchdog, auch wenn ich ihn in der Configuration deaktiviere. Vielleicht sehe ich den Wald vor lauter Bäumen nicht 
Ansonsten habe ich bei mir noch eine Kalibrierung per M801 in die FSR Firmware eingefügt. Finde ich ganz praktisch, daher als Vorschlag für alle. Außerdem ein großes Lob an alle Beteiligten für das tolle Projekt
Anbei mein Code:
FSR Firmware:
Repetier: Commands.cpp
Repetier gcode.cpp
Repetier: FSR.cpp
1-mal bearbeitet. Zuletzt am 19.10.16 09:28.
Mein erster Drucker: Sparkcube XL, Sparklab Extruder, E3D V6 (ABS, PETG) + E3D lite (PLA) mit Skimmy´s Magnet-Schnellwechselsystem, FSR ABL, DPP, RADDS + RAPS 24V
Mein Zweiter: Thomas V2, [forums.reprap.org], Eigenbau Dual X, Linearführungen, Z-Achse mir Riemenantrieb, RADDS + RAPPS + DM542, 48V, Repetier
Ansonsten habe ich bei mir noch eine Kalibrierung per M801 in die FSR Firmware eingefügt. Finde ich ganz praktisch, daher als Vorschlag für alle. Außerdem ein großes Lob an alle Beteiligten für das tolle Projekt
Anbei mein Code:
FSR Firmware:
case 801: // Calibration
startCalibration();
break;
Repetier: Commands.cpp
//************** M117 Original *****************************
/*
case 117: // M117 message to lcd
if(com->hasString()) {
UI_STATUS_UPD_RAM(com->text);
#if JSON_OUTPUT && defined(WRITE_MESSAGES_To_JSON)
Com::printF(PSTR("{\"message\":\""),com->text);
Com::printFLN(PSTR("\"}"));
#endif
}
break;
*/
//***********************************************************
//************** M117 FSR Board I2C *****************************
case 117:
if(com->hasString()) {
FSR::i2cSendString(com->text);
Com::printFLN(PSTR("FSR I2C Command: "),com->text);
} else {
Com::printF(PSTR("No FSR Board command found"));
}
break;
//***********************************************************
case 920:
if(com->hasString()) {
FSR::i2cSendString(com->text);
Com::printFLN(PSTR("FSR I2C Command: "),com->text);
} else {
Com::printF(PSTR("No FSR Board command found"));
}
break;
Repetier gcode.cpp
case 'M':
case 'm':
{
M = parseLongValue(pos) & 0xffff;
params |= 2;
if(M > 255) params |= 4096; //255
// handle non standard text arguments that some M codes have
//*********************************************************************************** FSR I2C: M920 ergänzt *************
if (M == 20 || M == 23 || M == 28 || M == 29 || M == 30 || M == 32 || M == 36 || M == 117 || M == 920)
{
// after M command we got a filename or text
char digit;
while( (digit = *pos) )
{
if (digit < '0' || digit > '9') break;
pos++;
}
while( (digit = *pos) )
{
if (digit != ' ') break;
pos++;
// skip leading white spaces (may be no white space)
}
text = pos;
while (*pos)
{
//*********************************************************************************** FSR I2C: M920 ergänzt *************
if((M != 117 && M != 920 && M != 20 && *pos==' ') || *pos=='*') break;
pos++; // find a space as file name end
}
*pos = 0; // truncate filename by erasing space with null, also skips checksum
waitUntilAllCommandsAreParsed = true; // don't risk string be deleted
params |= 32768;
}
break;
}
Repetier: FSR.cpp
void FSR::i2cSendString( char *gcode) {
// initialize i2c bus wor writing
HAL::i2cStart(FSR_I2C_PORT << 1 | I2C_WRITE);
while (*gcode != 0) {
HAL::i2cWrite(*gcode++);
}
// Send a string termination
HAL::i2cWrite(0);
HAL::i2cStop();
//***************** Rückmeldung I2C **********************
// Awaiting at least a 0-Byte for no feedback.
// HAL::i2cStart(FSR_I2C_PORT << 1 | I2C_READ);
//
// uint8_t c = HAL::i2cReadAck();
//
// while(c != 0) {
// // Write out on Serial device
// HAL::serialWriteByte(c);
//
// // read next byte
// c = HAL::i2cReadNak();
//
// //HAL::pingWatchdog();
// }
//
// HAL::i2cStop();
//**********************************************************
}
1-mal bearbeitet. Zuletzt am 19.10.16 09:28.
Mein erster Drucker: Sparkcube XL, Sparklab Extruder, E3D V6 (ABS, PETG) + E3D lite (PLA) mit Skimmy´s Magnet-Schnellwechselsystem, FSR ABL, DPP, RADDS + RAPS 24V
Mein Zweiter: Thomas V2, [forums.reprap.org], Eigenbau Dual X, Linearführungen, Z-Achse mir Riemenantrieb, RADDS + RAPPS + DM542, 48V, Repetier
|
Re: FSR Auto-Bed-Leveling-System 19. October 2016 12:53 |
Ich habe gerade mal die Repetier/Master Änderungen in den Branch gezogen und noch Debug hinzugefügt, um besser zu erkennen, ob der Befehl auseinander geschnitten wird.Quote
twi127
Ich habe nun auch die aktuelle Version DEV-V2 eingespielt. Läuft soweit problemlos. Momentan spiele ich gerade etwas mit der I2C Anbindung an Repetier. Habe den Branch von Pieps geladen und an die aktuellste Repetierversion angepasst. Ich habe sämtliche Änderungen die auch der I2C Patch enthält entsprechend ergänzt, bzw. überprüft. Kompiliert ist mit Arduino Studio 1.6.12. Jetzt habe ich folgende Probleme: ergänze ich den Befehl M920 in Repetier wird der String nach Befehlseingabe M920 nicht erkannt. Verwende ich den bestehenden Befehl M117 und ändere den Code entsprechend ab, klappt die I2C Kommunikation Richtung FSR Board. Die Rückmeldung vom FSR Board klappt leider gar nicht. Sobald ich den entsprechenden Code aktiviere bekomme ich alle 2-3s einen Reset durch den Watchdog, auch wenn ich ihn in der Configuration deaktiviere. Vielleicht sehe ich den Wald vor lauter Bäumen nicht
Vorhin hatte ich das wieder, dass ein M920 M111 P6 auseinander geschnitten wurde und vermute Repetier dahinter. Ich bin dann kurzerhand auf die serielle Console von Arduino ausgewichen. Das klappte dann.
Wenn der I2C verpolt ist (SCL<->SLA), dann bleibt er beim Lesen hängen. Schreiben kann er aber eigentlich.
Habe es mit den aktuellen Sourcen geprüft. Bei mir läuft es. Aber vielleicht gibt es ja doch eine Konstellation, die Repetier aus dem Tritt bringt. Könntest du den aktuellen fsr-Branch auschecken und testen? Der hat auch die letzten Änderungen vom Repetier enthalten.
Gruß
Pieps
|
Re: FSR Auto-Bed-Leveling-System 19. October 2016 14:32 |
@ Roland: Danke. Pull Request ist gestellt.
@ Pieps:
Also ich habe nochmals alles getestet und deinen aktualisierten Fork heruntergeladen. Anschließend habe ich meine Config + Pin in das Verzeichnis kopiert und alles hochgeladen. Es funktioniert leider nicht mit M920. Kopiere ich den Code nach M117 hoch, klappt alles. Repetier scheint hier irgendetwas durcheinanderzubringen. Eigentlich sollte der Parser funktionieren, da ja M920 entsprechend in gcode.cpp ergänzt ist. Anbei mein Log hierzu:
Außerdem habe ich die I2C Rückinfo nochmals getestet. Mein I2C Anschluss passt. Pole ich um, klappt auch das Senden ans FSR Board nicht mehr, bzw. es wird gesendet, aber das FSR macht nichts. Nach wie vor hänge ich bei aktivem Code in einer Reset Schleife per Watchdog. Anbei das Log:
Ach ja, ich verwende ein RADDS Board.
2-mal bearbeitet. Zuletzt am 19.10.16 14:35.
Mein erster Drucker: Sparkcube XL, Sparklab Extruder, E3D V6 (ABS, PETG) + E3D lite (PLA) mit Skimmy´s Magnet-Schnellwechselsystem, FSR ABL, DPP, RADDS + RAPS 24V
Mein Zweiter: Thomas V2, [forums.reprap.org], Eigenbau Dual X, Linearführungen, Z-Achse mir Riemenantrieb, RADDS + RAPPS + DM542, 48V, Repetier
@ Pieps:
Also ich habe nochmals alles getestet und deinen aktualisierten Fork heruntergeladen. Anschließend habe ich meine Config + Pin in das Verzeichnis kopiert und alles hochgeladen. Es funktioniert leider nicht mit M920. Kopiere ich den Code nach M117 hoch, klappt alles. Repetier scheint hier irgendetwas durcheinanderzubringen. Eigentlich sollte der Parser funktionieren, da ja M920 entsprechend in gcode.cpp ergänzt ist. Anbei mein Log hierzu:
Außerdem habe ich die I2C Rückinfo nochmals getestet. Mein I2C Anschluss passt. Pole ich um, klappt auch das Senden ans FSR Board nicht mehr, bzw. es wird gesendet, aber das FSR macht nichts. Nach wie vor hänge ich bei aktivem Code in einer Reset Schleife per Watchdog. Anbei das Log:
Ach ja, ich verwende ein RADDS Board.
2-mal bearbeitet. Zuletzt am 19.10.16 14:35.
Mein erster Drucker: Sparkcube XL, Sparklab Extruder, E3D V6 (ABS, PETG) + E3D lite (PLA) mit Skimmy´s Magnet-Schnellwechselsystem, FSR ABL, DPP, RADDS + RAPS 24V
Mein Zweiter: Thomas V2, [forums.reprap.org], Eigenbau Dual X, Linearführungen, Z-Achse mir Riemenantrieb, RADDS + RAPPS + DM542, 48V, Repetier
|
Re: FSR Auto-Bed-Leveling-System 20. October 2016 13:00 |
Das Problem liegt im Code des Repetier-Host und dem Binary Protokoll. Dort wird der Ascii-Befehl geparst und dort steht natürlich nicht drin, dass M920 wie M117 Text als Parameter übergibt. Repetier-Host selbst nimmt daher den Befehl auseinander und sendet ihn so an das Arduino. (Gcode.cs). Das läßt sich aktuell nur umgehen, indem man auf ASCII-Protokoll umstellt.
Quote
twi127
@ Pieps:
Also ich habe nochmals alles getestet und deinen aktualisierten Fork heruntergeladen. Anschließend habe ich meine Config + Pin in das Verzeichnis kopiert und alles hochgeladen. Es funktioniert leider nicht mit M920. Kopiere ich den Code nach M117 hoch, klappt alles. Repetier scheint hier irgendetwas durcheinanderzubringen. Eigentlich sollte der Parser funktionieren, da ja M920 entsprechend in gcode.cpp ergänzt ist. Anbei mein Log hierzu:
Außerdem habe ich die I2C Rückinfo nochmals getestet. Mein I2C Anschluss passt. Pole ich um, klappt auch das Senden ans FSR Board nicht mehr, bzw. es wird gesendet, aber das FSR macht nichts. Nach wie vor hänge ich bei aktivem Code in einer Reset Schleife per Watchdog. Anbei das Log:
Ach ja, ich verwende ein RADDS Board.
|
Re: FSR Auto-Bed-Leveling-System 27. October 2016 13:58 |
Hallo zusammen,
im ursprünglichen Aufbau des FSR Systems (Hülse + Stempel + ggf Silikoneinlagen) war ich nicht glücklich. Der TriggerThreshold mit 40 war mir viel zu hoch. Ich konnte sehen, wie beim probing die Nozzle das Druckbett nach unten drückt und sich der Druckkopf ein wenig nach vorn neigt. Außerdem klappten vielleicht 50% der Messvorgänge, die anderen wurden durch ungewolltes Auslösen des Triggers, hervorgerufen durch die Bewegung der Achsen, unbrauchbar. Die Wiederholgenauigkeit war ebenfalls nicht befriedigend. So habe ich mir die letzten beiden Tage mal ein paar Gedanken gemacht und mal den Umgang mit SCad geübt.
Folgendes ist dabei herausgekommen:
Um zu diesem Ergebnis zu kommen, habe ich alle Tipps hier (vor allem Pieps Tipp, danke dafür) zusammen geworfen. Das eigentliche Gewicht des Heizbetts liegt nun auf dem Silikondämpfer. Dieser lässt sich mit Hilfe der Schrauben exakt kalibrieren, so dass ich nun auf allen 3 Sensoren einen Druck von ca. "550" habe. Außerdem schwankt der Wert maximal 3-4. Den TriggerThreshold habe ich nun bei allen 3 Sensoren auf 14 abgesenkt. Nun sehe ich, wie die Nozzle so gerade das Bett berührt, sich jedoch weder bewegt, noch das Bett nach unten drückt. Weiter habe ich keine Auslösung mehr beim Verfahren der Achsen.
Die Wiederholgenauigkeit finde ich ziemlich gut:
Probe 1: 4.25, 4.92, 4.98
Probe 2: 4.29, 4.95, 5.05
Probe 3: 4.25, 4.93, 5.02
and so on...
Da ich es nicht einschätzen kann, wäre ich für Hinweise dankbar, ob allgemein an den Teilen Bedarf besteht, dann würde ich sie natürlich zur Verfügung stellen.
Ich bin gerade ziemlich begeistert. Danke noch mal an Roland für diese super Umsetzung der Platine.
Gruß
Sven
1-mal bearbeitet. Zuletzt am 27.10.16 13:59.
im ursprünglichen Aufbau des FSR Systems (Hülse + Stempel + ggf Silikoneinlagen) war ich nicht glücklich. Der TriggerThreshold mit 40 war mir viel zu hoch. Ich konnte sehen, wie beim probing die Nozzle das Druckbett nach unten drückt und sich der Druckkopf ein wenig nach vorn neigt. Außerdem klappten vielleicht 50% der Messvorgänge, die anderen wurden durch ungewolltes Auslösen des Triggers, hervorgerufen durch die Bewegung der Achsen, unbrauchbar. Die Wiederholgenauigkeit war ebenfalls nicht befriedigend. So habe ich mir die letzten beiden Tage mal ein paar Gedanken gemacht und mal den Umgang mit SCad geübt.
Folgendes ist dabei herausgekommen:
Um zu diesem Ergebnis zu kommen, habe ich alle Tipps hier (vor allem Pieps Tipp, danke dafür) zusammen geworfen. Das eigentliche Gewicht des Heizbetts liegt nun auf dem Silikondämpfer. Dieser lässt sich mit Hilfe der Schrauben exakt kalibrieren, so dass ich nun auf allen 3 Sensoren einen Druck von ca. "550" habe. Außerdem schwankt der Wert maximal 3-4. Den TriggerThreshold habe ich nun bei allen 3 Sensoren auf 14 abgesenkt. Nun sehe ich, wie die Nozzle so gerade das Bett berührt, sich jedoch weder bewegt, noch das Bett nach unten drückt. Weiter habe ich keine Auslösung mehr beim Verfahren der Achsen.
Die Wiederholgenauigkeit finde ich ziemlich gut:
Probe 1: 4.25, 4.92, 4.98
Probe 2: 4.29, 4.95, 5.05
Probe 3: 4.25, 4.93, 5.02
and so on...
Da ich es nicht einschätzen kann, wäre ich für Hinweise dankbar, ob allgemein an den Teilen Bedarf besteht, dann würde ich sie natürlich zur Verfügung stellen.
Ich bin gerade ziemlich begeistert. Danke noch mal an Roland für diese super Umsetzung der Platine.
Gruß
Sven
1-mal bearbeitet. Zuletzt am 27.10.16 13:59.
In diesem Forum dürfen leider nur registrierte Teilnehmer schreiben.