kommunikationstimeout hoch setzen ?
hallo,
ich habe einen sparkcube v2 der auf z-max home macht. wenn er also auf home geht kommt es zu timeout warnungen alle 4 sekunden und anschliessend zu checksum error (wrong checksum). das homen auf z-max dauert ja auch etwas länger.
nun habe ich testweise den kommunikationstimeout auf 90 sekunden hoch gesetzt und es kommen keinerlei fehlermeldungen mehr.
nun frage ich mich aber ob das so einfach geht oder ob ich nur ein problem irgendwo habe und das so umgehe bzw ausblende.
eine andere frage ich das der drucker beim verbinden mit dem odroid etwas ballert. anscheinend die treiber (rads128)
ich habe die default einstellungen beim drucker einrichten übernommen. die firmware ist repetier.
kann man dieses ballern oder rumpeln beim start abstellen bzw umgehen ?
ich habe einen sparkcube v2 der auf z-max home macht. wenn er also auf home geht kommt es zu timeout warnungen alle 4 sekunden und anschliessend zu checksum error (wrong checksum). das homen auf z-max dauert ja auch etwas länger.
nun habe ich testweise den kommunikationstimeout auf 90 sekunden hoch gesetzt und es kommen keinerlei fehlermeldungen mehr.
nun frage ich mich aber ob das so einfach geht oder ob ich nur ein problem irgendwo habe und das so umgehe bzw ausblende.
eine andere frage ich das der drucker beim verbinden mit dem odroid etwas ballert. anscheinend die treiber (rads128)
ich habe die default einstellungen beim drucker einrichten übernommen. die firmware ist repetier.
kann man dieses ballern oder rumpeln beim start abstellen bzw umgehen ?
Comments
Die liste der langsamen Befehle steht in repetier.xml im firmware Ordner:
das ist die voreinstellung und gibt die warnungen aus. ein hochsetzen auf 60s reicht nicht aus. erst mit etwa 90s kommen keine warnungen mehr. die firmware ist die aktuelle repetier (1.04)
wenn ich M105 filtern deaktiviere kommen beim homen wie vorrausgesagt alle 2s busy meldungen
wenn ich einen druck starte fährt das heizbett oder die z-achse auf max. in der konsole wird busy angezeigt alle 2s. keine fehlermeldung. wenn er z-max erreicht hat und wieder hoch fährt um den druck zu starten kommt keine busy meldung und die o.g fehlermeldung kommt. also auf den weg von z-max richtung z-min.
ich lasse nach druckende immer ein G28 machen damit ich nicht immer warten muß das er den ganzen weg runter und wieder rauf fährt. starte ich einen neuen druck wird erstmal aufgeheizt und die busy meldungen kommen. nach dem homen fährt er richtung z-min und das ganze geht von vorne los.
es fehlen also busy meldungen
steps per mm sind bei z 1600 nach sparklap vorgabe. den rest muß ich später beantworten.
aber für den weg von z-max nach z-min braucht er bestimmt 45s
in der liste der unterdrückten meldungen taucht aber ein G31 garnicht auf. ist es dann nicht richtig das er eine fehlermeldung ausgibt ?
ist das F1200 zu schnell ?
das sind 2 meter die sekunde...kann das richtig sein ?
board ist radds 1.6 mit arduino duo und rads128 treibern
Was ist denn der exakte gcode in cure hier?
Reduziere z max feedrate mal auf 50mm/s. Das ist realistischer. Wenn er es manuell schon mit busy quittiert scheint er es ja richtig machen zu wollen.
wenn ich den cura code starte kommt
habe gerade gesehen das im eprom ein komma bzw punkt steht also 2.000.
wenn ich also manuell G1 Z10 F2000 starte geht es über cura kommt aber timeout warnungen
Unterschied ist aber auch manuell sendest du gen G move der wird gespeichert und wie du an dem wait siehst werden weitere befehle erwartet. Da ist also kein busy und muss auch nicht.
Wenn du den Druck startest kommen ja noch jede menge Befehle hinterher und der Puffer ist voll. Dann sollte ein busy kommen wenn er etwas länger braucht. Ich weiß aber immer noch nicht was cura da jetzt stehen hat im gcode. Ich seh nur nach dem timeout den log. Das Problem passiert aber davor:-)
vor der fehlermeldung steht das im log
hier ist der cura code ohne geschwindigkeitsangaben
z-max feedrate 2.000 mm/s (homing 2.000 mm/s)
y feedrate 60 mm/s (homing 60 mm/s)
acceleration x und y je 800, z 100
das homen auf max macht ja auch nicht die fehler sondern von max auf druckbeginn. von max fährt er wie in cura angegeben auf z15 und auf diesen weg kommen die timeouts wenn ich nicht auf über 60s timeout stelle.
als board habe ich ein radds 1.6 mit arduino duo und rads128 treibern
ich nutze den programming port. die feedrate ist zu gering ? kann ich natürlich erhöhen aber die z-achse ist knapp 20 cm hoch. warum unterschiedlich x und y feedrates kann ich nicht sagen. die firmware wurde on sparkcube hoch geladen
wenn ich manuell von z max G1 Z10 F2000 eingebe läuft alles sauber durch. dieselbe geschwindigkeit im startcode von cura ergeben warnungen. die timeouts kommen nach 4 sekunden.
ist schlechter Stil weil da die Geschwindigkeit fehlt. Hab noch mal im Quellcode nachgesehen und ein G4 würde definitv busy senden. Passe also mal den start so an:
G4
G4
und sieh mal ob dann ein busy im log steht (ack aktiv).
Beim parsen der seriellen schnittstelle steht eigentlich:
bufferLength >= GCODE_BUFFER_SIZE meint wenn bereits ein Befehl gepuffert ist den nächsten nicht mehr zu parsen und busy zu senden.
Kann es sein das du ping pong aktiviert hast bei den Verbindungseinstellungen? Könnte sein das dies verhindert das firmware mehr sendet und daher kein busy kommt in dem Fall. Ich teste ja immer ohne ping pong.
ansonsten hat es mit
G4
G4
schon soweit funktioniert das er ohne warnungen und mit busy meldungen von z-max auf druckhöhe gefahren ist. :-)
nach erreichen der höhe kam aber wieder die warnungen
nachdem ich den startcode so abgeändert habe
G4
G4
G4
G4
G4
kamen keine warnungen mehr aber das ganze wurde sehr langsam
habe den dann auf
und alles löppt :-)
aber warum macht dieser code ärger
G4
G4
dieser aber nicht ?
G4
G4
Nächste Zeile bewegt Y sehr langsam weil hier F3000 fehlt was bei der anderen der Fall ist.
Deine Tests zeigen aber auch das die busy Logik offenbar nicht so läuft wie ich das geplant hatte. Sobald ein Befehl einfach von sich aus langsam ist wird dies nicht korrekt erkannt. G4 ist eine Krücke weil er auf das ende der Bewegungen wartet mit busy meldung explizit eingebaut. Gut für dich jetzt erst mal als Übergangslösung. Muss aber dennoch mal nachsehen warum es nicht automatisch triggert. Weiß ja jetzt wie ich es auslösen können sollte.