Pagina 1 van 1

oplossing gevraagd

Geplaatst: 11/03/24, 12:40
door Hardy
Ik zoek eigenlijk een oplossing voor een klein probleem waar ik al heel lang mee zit, mijn beide printers met dubbele Z-as voor het bed gaan bij het starten van een print altijd eerst een klein stukje naar beneden, dat zou op zich geen probleem zijn omdat ik dat wel softwarematig in de gaten kan houden door de eindstand wat hoger in te stellen, maar wanneer aan het eind van een print de motoren worden uitgeschakeld, dan kan ik handmatig het bed vrij makkelijk naar beneden drukken en dat gebeurt dan ook regelmatig bij het schoonmaken of verwijderen van een print, hierdoor stoot bij een volgende print opdracht de Z-assen/bed tegen de motor koppeling met daarbij behorende herrie.
Ik heb zowel in Marlin als Klipper geen oplossing kunnen vinden waarmee ik kan voorkomen dat bij het starten van een print het bed niet eerst stukje naar onderen beweegt, maar gewoon direct naar de bovenste nul positie.

Re: oplossing gevraagd

Geplaatst: 11/03/24, 13:12
door Rob52
Ik begrijp het probleem niet helemaal. Zakt je bed dan zo vreselijk ver naar beneden dat je helemaal onderop komt? Of maak je altijd zulke hoge prints dat je zo ver naar beneden eindigt? Ik kom met het bed bijna nooit zover naar beneden dat ik de bodem raak. Ook niet met schoonmaken. Er zit ook genoeg weerstand in de motoren. Maar goed als het bij jou zo is gaan we daar even van uit.

Ook bij die van mij gaat het bed eerst een stukje naar beneden. Tenminste bij de start van de print. Maar wanneer ik voor de print eerst een auto homing doe dan gaat het bed direct omhoog zonder dat het eerst naar beneden gaat. Daarna gaat hij voor de print begint dan wel weer eerst een stukje naar beneden maar dat mag dan geen probleem meer zijn. Als dat bij jou ook zo is, je weet maar nooit, niet alle printers werken precies hetzelfde, dan zou je in je startcode eerst een autohome instructie kunnen opnemen. Misschien dat het daarmee is opgelost.

Re: oplossing gevraagd

Geplaatst: 11/03/24, 13:17
door Banditoz
Dit is dan neem ik aan als de motoren uitgeschakeld worden. Volgens mij kun je dit soms oplossen door iov gewone z-as moeren (meestal die messing gevallen) te vervangen voor een versie met een extra geveerd stukje (noemen ze anti-backlash). En anders de z-as schroeven vervangen voor een versie die een fijnere draad heeft. Ik weet dat de eerste ender 5 orinters ook het bed naar beneden zakte als deze uit staan. Bij de 5 pro die ik heb zit er een versie op die meer steps per mm nodig heeft. Deze zakt nooit.

Re: oplossing gevraagd

Geplaatst: 11/03/24, 13:50
door Hardy
Rob52 schreef: 11/03/24, 13:12 Zakt je bed dan zo vreselijk ver naar beneden dat je helemaal onderop komt?
dan zou je in je startcode eerst een autohome instructie kunnen opnemen. Misschien dat het daarmee is opgelost.
Ik hou best nog wat ruimte over wanneer het bed beneden is, maar het loopt allemaal wel erg licht, ik heb ook relatief zware bedden, maar ze bewegen niet vanzelf, de print oppervlakken zijn op het bed geplakt, dus niet verwijder baar, daardoor druk ik wel makkelijk het bed met de hand naar beneden, de suggestie van extra autohome instructie ga ik nog even proberen, in ieder geval alvast bedankt.

Re: oplossing gevraagd

Geplaatst: 13/03/24, 17:57
door henryschippers2023
Is er inmiddels voortgang in het project

Re: oplossing gevraagd

Geplaatst: 13/03/24, 21:56
door Hardy
henryschippers2023 schreef: 13/03/24, 17:57 Is er inmiddels voortgang in het project
Nee, nog niet, maar ik vraag mij af of het wel wat wordt, in mijn start Gcode staat al het auto home commando waarbij de Z eerst een stukje zakt, en dat moet ook wel voor wanneer het bed al boven is, ik denk dat ik toch elektronisch/softwarematig iets moet verzinnen met een extra endstop die registreert wanneer het bed per ongeluk toch helemaal beneden is waardoor alleen dan eerst de Z-steppers een zetje omhoog krijgen voordat het echte homen begint.

Re: oplossing gevraagd

Geplaatst: 14/03/24, 07:46
door PrintEngineer
Is het misschien een optie om in de firmware een knop te definiëren met daarachter de code M17 (enable steppers). Dan kan je die knop gebruiken om de motoren onder spanning te zetten tijdens het verwijderen van het object. De meeste printers hebben tenslotte ook al een knop (op het display) met de functie DISABLE STEPPERS

Re: oplossing gevraagd

Geplaatst: 14/03/24, 12:17
door Hardy
Ook een idee, maar daar moet je dan wel weer aan denken om dat in te schakelen, en mij kennende🤦‍♀️🤔

Re: oplossing gevraagd

Geplaatst: 14/03/24, 18:57
door Puffeltje
En de bewuste code M17 opnemen in je end g-code?

Re: oplossing gevraagd

Geplaatst: 14/03/24, 19:49
door Hardy
Puffeltje schreef: 14/03/24, 18:57 En de bewuste code M17 opnemen in je end g-code?
Dat is geen goed idee, dan blijven de motoren en bij behorende drivers altijd bekrachtigt, wat natuurlijk niet de bedoeling is, vooral wanneer ik pas een paar uur later bij de printer kom om het geprinte eraf te halen

Re: oplossing gevraagd

Geplaatst: 15/03/24, 08:45
door PrintEngineer
Misschien heb ik het niet goed begrepen of verkeerd uitgelegd wat ik bedoel. De knop met daarachter code M17 (logische naam zou zijn ENABLE STEPPERS) kan je zoals ik dat in gedachten heb alleen inschakelen vanaf het display, of eventueel ook als instructie gegeven vanaf een computer. Via het display schakel je de motoren natuurlijk bewust in en kan je dan de print verwijderen zonder dat het heatbed zakt. Als je klaar bent druk je weer op de knop DISABLE STEPPERS (die zit vaak al in de firmware) en zet je dus de motoren ook weer bewust uit. Om het als eindinstructie in de g-code te zetten lijkt mij idd geen goed idee. Dan loop je de kans dat de stepper drivers in rook opgaan

Re: oplossing gevraagd

Geplaatst: 18/03/24, 13:13
door Puffeltje
Als je de drivers correct hebt ingesteld aan de hand van je motortype moet de driver dit echt wel aan kunnen. Als je een grote print doet van meerdere (tientallen) uren is dat ook geen probleem voor de drivers. Maar zoals je het nu uitlegt met activeren-print losnemen-deactiveren is dat een werkwijze welke m.i. goed kan werken.

Toegevoegd in 10 minuten 14 secondes:
een andere optie is om de printoppervlakken niet vast op je printer te hebben (zoals je nu hebt). Het verwijderen van je print met printoppervlak zal dan niet te veel druk op je printbed geven zodat hij erg veel omlaag zakt.

Even verder denkend en voortbordurend op het idee van PrintEngineer: maak een macro welke de relatieve modus in stelt, het bed dan 5 centimeter omhoog beweegt, en daarna de relatieve modus weer uitschakeld. Mogelijk loop je hier dan wel tegen het probleem aan dat bij aanschakelen van de printer deze zijn z-as nog niet gehomed heeft en de relatieve verplaatsing niet accepteerd. Het is misschien een poging waard.

Re: oplossing gevraagd

Geplaatst: 18/03/24, 19:19
door Lourens
Dat het bed eerst naar beneden beweegt of (afhankelijk van het soort printer) de nozzle omhoog is natuurlijk een veiligheidsvoorziening.
Als om wat voor reden dan ook, je nozzle op het bed staat, en je gaat dan zonder die van het bed af te halen bewegen, zet je een mooie 'handtekening' op je printoppervlak.

Ik denk echter dat er binnen klipper wel een mogelijkheid is voor datgene wat je zoekt.
In mijn RatRig-printer is er namelijk een macro gemaakt die de X, Y en Z-positie overruled, en dan vastzet alsof er net een 'homing' is uitgevoerd.
Als ik na deze macro de (aangeraden) homing daadwerkelijk uitvoer, gaan de X en Y-as direct homen zonder eerst het bed omlaag te draaien.

[gcode_macro SET_CENTER_KINEMATIC_POSITION]
description: FOR DEBUGGING PURPOSES ONLY. Sets the internal printer kinematic state to the center of all axes regardless of actual physical position.
gcode:
RESPOND MSG="WARNING: ONLY USE SET_CENTER_KINEMATIC_POSITION FOR DEBUGGING PURPOSES. YOU'RE OVERRIDING THE INTERNAL POSITIONING STATE OF THE PRINTER. PROCEED WITH CAUTION AND DO A PROPER G28 WHEN DONE."
SET_GCODE_VARIABLE MACRO=MAYBE_HOME VARIABLE=is_kinematic_position_overriden VALUE=True
SET_KINEMATIC_POSITION X={printer.toolhead.axis_maximum.x / 2} Y={printer.toolhead.axis_maximum.y / 2} Z={printer.toolhead.axis_maximum.z / 2}


Als jou configuratie de andere hierin gebruikte variabelen kent, zou je de Z uit dit voorbeeld kunnen gebruiken.
Als die niet bekend zijn, laat dat dan even weten, dan ga ik daar nog naar op zoek.

Re: oplossing gevraagd

Geplaatst: 19/03/24, 19:04
door Hardy
Bedankt, ik ga hier wel eens even naar kijken, wie weet is dat wat.