die Frage richtet sich an alle grbl Spezialisten unter euch. Gibt es einen Grund warum die Softwareentprellung nur für den homing-cycle implementiert ist? Wenn ich das richtig verstanden habe ist das so?
Ich habe das Problem dass ich beim hard-limit Fehltriggerungen habe, selbst wenn ich garkeine Kabel und Schalter angeschlossen habe. Es scheint mir so als ob in meinem EM-Umfeld die Leiterbahnen des CNC-Shields und des Arduinoboards ausreichen eine Fehltriggerung der offenen Eingänge auszulösen. Insbesondere dann wenn ich z.B. preisgünstige Netzteile in der Umgebung ein- und ausstecke. Das lässt sich sehr gut reproduzieren auch dann wenn ich direkt an die Limitpins Kondensatoren anschließe.
Ich Frage mich was ich dagegen tun kann. Die Schalterkabel habe ich mit Tiefpassfilterung entstört. Das kann ich mit meinem einfachen DIY oszi recht gut darstellen.
Mit einer Softwareentprellung wären die restlichen Störungen durch Netzteile, elektrostatischen Entladungen in der Umgebung, etc. mit sicherheit vollends rauszufiltern. Die dadurch entstehende Schaltverzögerung von zusätzlich einigen Millisekunden sollte eigentlich kein Problem sein.
VG,
Florian
Störung der Schrittmotoren ohne Entprellung
Schalterkontakt ohne Entprellung
Bei laufenden Motoren mit Entprellung und Schalterkontakt. Man kann hier schön sehen, dass das Rauschen gefiltert wurde und beim Schalterkontakt sich der Kondensator mit seiner typischen Entladekurve entläd.
Re: grbl - keine Softwareentprellung bei hard limit
Also,
die Softwareentprellung ist sehr wohl für hard-limits implementiert. Diese muss allerdings in der config.h auskommentiert (Zeile 472) werden. Anschließend muss das ganze dann neu über die Arduino IDE geflasht werden. In Verbindung mit einer kleinen Änderung an meiner hardwareseitigen Filterung der Schalterkabel läuft das ganze bis jetzt absolut wasserdicht.