veranderen tandem homing gedrag?

[bbg]

Op mijn portaalfrees zitten twee motoren voor de y-as en met elk hun eigen home sensor (y links, y2 rechts). In LinuxCNC heb ik tandem homing geconfigureerd met HOME_SEQUENCE = -1 voor zowel y als y2. De tandem-homing werkt zoals ik had verwacht van de LinuxCNC documentatie. Maar ik zou het gedrag graag willen veranderen (ik zal hieronder uitleggen waarom). Kan iemand mij tips geven over hoe ik dat kan doen?

OK, wat is het gedrag dat ik zie (en verwacht van de documentatie)? Bij het starten van de homing beginnen zowel y als y2 gelijktijdig te bewegen op zoek naar de triggers van hun eigen home sensors. Nadat zowel y als y2 de triggerpoints hebben gevonden, bewegen y en y2 synchroon naar de home positie. Lijkt logisch gedrag toch?

Wat gebeurt er echter als een van de home sensoren een vrij grote positie afwijking heeft ten opzichte van de andere? Stel dat home sensor y op 540 mm (machinecoördinaten) staat en home sensor y2 op 545 mm. Wanneer nu dual homing wordt gestart, gaat y naar 540 mm en gaat y2 naar 545 mm. Dus een verschil van 5 mm tussen y en y2. Als het portaal redelijk stijf is leidt deze 5 mm tot hoge krachten en momenten. Hmmmm ....

Het gedrag dat ik zou willen zien bij het starten van dual homing is:
1. y en y2 bewegen synchroon op zoek naar de trigger van de eerste home sensor y
2. Op de trigger van home sensor y wordt de positie van de sensor gebruikt om y in te stellen (in machinecoördinaten)
3. y en y2 beginnen sychroon te bewegen op zoek naar de trigger van de tweede home sensor y2
4. Op de trigger van home sensor y2 wordt de vereiste delta tussen y en y2 berekend uit de bekende posities van de home sensoren. De delta wordt dan alleen op y2 toegepast om het portaal haaks te zetten.
5. Daarna gaan y en y2 synchroon naar de home positie.

Kan dit gedrag op een andere manier worden geconfigureerd of geïmplementeerd? Iemand een paar tips / ideeën.

Bij voorbaat bedankt!

[Kars-cnc]

De vraag interesseert mij omdat ik voor de portaalfrees die ik aan het bouwen ben ook heb zitten denken of tandem homing geen (te) grote krachten op het portaal zou kunnen veroorzaken. Echter zoals jij het beschrijft snap ik het niet helemaal, als je y en y2 sensors 5mm uit elkaar triggeren dan is de delta toch ook 5mm? Ook met de methode zoals je beschrijft dat je zou willen wordt de brug 5mm geschrankt (of hoe dat ook heten mag) lijkt mij. Of begrijp ik je niet goed?

[bbg]

De vraag interesseert mij omdat ik voor de portaalfrees die ik aan het bouwen ben ook heb zitten denken of tandem homing geen (te) grote krachten op het portaal zou kunnen veroorzaken. Echter zoals jij het beschrijft snap ik het niet helemaal, als je y en y2 sensors 5mm uit elkaar triggeren dan is de delta toch ook 5mm? Ook met de methode zoals je beschrijft dat je zou willen wordt de brug 5mm geschrankt (of hoe dat ook heten mag) lijkt mij. Of begrijp ik je niet goed?

Dat shranken is precies wat ik wil voorkomen met het gedrag wat ik voorstel. Maar het is lastig om in woorden uit te leggen. Ik ga proberen een paar plaatjes te maken om het duidelijker te maken.

[benkr]

Als de brug scheef staat dan wordt dit gecorrigeerd naar de stand van de home sensoren.
Het is dus belangrijk dat de sensoren goed staan, daar staat of valt alles mee.
En 5 mm, ik heb Portjes portaal wel meer zien doen voordat het allemaal goed ging.
Als het fout gaat heb je wel weer een hele boel te stellen.

[serum]

Ik los het op door een snaar tussen beide assen te spannen die ik kan varieren in lengte aan beide kanten, waardoor de brug haaks gesteld kan worden. De brug staat uit zichzelf nu binnen 0,05 haaks. Dat laatste deel trek ik eruit door de ene kant van de koppelriem te verlengen en de andere kant te verkorten. Mijn motoren bewegen niet als ze enabled worden. Beide motoren zijn parallel aangesloten op 1 uitgang.

Parallel homen is voor mij niet nodig. Als 1 motor uit zou vallen (spanningsloos oid) zonder een alarm te geven loop je alsnog risico dat de brug krom trekt. Voor mij een reden om het op deze manier uit te voeren. Daarnaast werk ik met een 4 assige kaart en heb anders geen ruimte voor de 4e as.

Die servo's zijn verrekte sterk, daar is mijn aluminium bruggetje niet tegenop gewassen.

Waarom zou je in jouw voorbeeld beide motoren niet tegelijk laten zoeken naar hun sensoren? de scheefgang die er inzit is in beide gevallen gelijk. Je voorkomt dit niet door eerst een sensor te negeren en later juist te willen gebruiken. Het effect blijft precies hetzelfde.

[bbg]

Dit is de homing procedure die ik gedachten had. Dan ben je veel onafhankelijker van toleranties op het plaatsen van de home sensoren. Hoop dat het hiermee wat duidelijker is wat ik voor ogen heb.

[bbg]

Als de brug scheef staat dan wordt dit gecorrigeerd naar de stand van de home sensoren.
Het is dus belangrijk dat de sensoren goed staan, daar staat of valt alles mee.

Precies, en ik zou graag wat toleranter worden voor de positionering van die sensoren. Gewoon een procedure waarbij er grote toleratanties mogelijk zijn die in SW gecalibreerd kunnen worden.

Waarom zou je in jouw voorbeeld beide motoren niet tegelijk laten zoeken naar hun sensoren? de scheefgang die er inzit is in beide gevallen gelijk. Je voorkomt dit niet door eerst een sensor te negeren en later juist te willen gebruiken. Het effect blijft precies hetzelfde.

De scheefgang voor homing zit er inderdaad al in en kan je niet voorkomen. Maar wat ik wil voorkomen is dat de brug onnodig scheef wordt getrokken omdat de homing sensoren niet op precies dezelfde plek zitten.

[benkr]

Als je niet van je sensoren uit wil gaan als referentie, waar wil je dan wel van uit gaan?
Je brug staat scheef dus dat is geen goed gegeven, hoe wil je dan de berekening doen?

[Kjelt]

Dit is de homing procedure die ik gedachten had.

Dat is ongeveer dezelfde als EdingCNC het doet met het verschil dat deze na detectie heel langzaam weer terug gaat totvdecsensor weer verbreekt en dat is het home punt.
Wat doet LinuxCNC dan anders ? Houdt er met de plaatsing van de homing sensoren ook rekening mee dat als de brug aan een kant van de sensoren staatvaltijd een sensor nog aktiveert omdat de regeling anders bij een koude start niet weet waar de brug staat en deze altijd dezelfde kant op stuurt.

[Sven]

In linuxcnc geef je de positie op van de sensoren, als onderdeel van het maken van de configuratie.
Ik heb het vermoeden dat je de configuratie niet kan maken zonder eerst de brug haaks te stellen.

Als dat eenmaal gedaan is dan haal je met homen de laatste snippers onzuiverheid er uit.
Je kan er een scheef gesteld systeem niet mee rechthomen.

Op zich is er misschien wel kracht genoeg om de daarvoor benodigde weerstand te overrulen maar daar wordt je machine niet zuiverder van.

Kort gezegd, ik heb het vermoeden dat je een probleem probeert op te lossen dat er niet is.

Of vanaf de andere kant geredeneerd:
Ik heb dubbele aandrijving maar enkele homing.
Als er iets mis gaat dan staat mijn portaal mechanisch scheef, de wrijving in bevestiging wordt overruled.

Als ik er maar voor zorg dat de motoren in opstart positie staan (dus niet in een microstep positie) dan kan ik daarna het portaal weer vastzetten en dan is ie elke keer na het homen gewoon weer ok.

[DaBit]

Ik snap wat je wil, maar het is niet zo te configureren volgens mij. En opzich ook niet nodig als je de homeswitches dicht genoeg bij elkaar zet, wat ook geen drama is:

- Trek halshow open, en mik een watch op de twee homeswitch inputs. halmeter kan ook.
- Jog met de machine nog niet gehomed tot je 1 van de homeswitches ziet triggeren in halshow.
- Verplaats de tweede switch tot die ook triggert. Nu zitten ze in ieder geval niet ver genoeg meer uit elkaar om voor gedonder te zorgen.
- Meet de haaksheid, en stel de laatste honderdsten bij door de HOME_OFFSET aan te passen.

Als je een hele stijve brug hebt die zwaar problemen zou hebben met scheefstand dan is die tandemhoming overigens ook niet nodig. Bij mij staat de brug haaks op het moment dat ik de prik van de motoren af haal en ik moet met honderden Newtons aan een kant duwen om beweging in een meetklok te krijgen. Ik heb dus gewoon maar 1 homeschakelaar.

[bbg]

Als je niet van je sensoren uit wil gaan als referentie, waar wil je dan wel van uit gaan?
Je brug staat scheef dus dat is geen goed gegeven, hoe wil je dan de berekening doen?

Ik wil wel de bekende positie van de sensoren als referentie gebruiken. Echter ik wil niet de brug onnodige scheeftrekken omdat de sensoren niet (fysiek) op dezelfde plaats zitten. Dat doet de standaard homing in LinuxCNC namelijk wel (zoals ik het begrijp). Die heeft de volgende procedure:






Dus zelfs als de brug haaks staat dan wordt de brug scheef getrokken tijdens het homen als de sensoren niet netjes dicht bij elkaar staan. Dat zou ik eigenlijk willen voorkomen.

Dit is de homing procedure die ik gedachten had.

Dat is ongeveer dezelfde als EdingCNC het doet met het verschil dat deze na detectie heel langzaam weer terug gaat totvdecsensor weer verbreekt en dat is het home punt.
Wat doet LinuxCNC dan anders ? Houdt er met de plaatsing van de homing sensoren ook rekening mee dat als de brug aan een kant van de sensoren staatvaltijd een sensor nog aktiveert omdat de regeling anders bij een koude start niet weet waar de brug staat en deze altijd dezelfde kant op stuurt.

Hierboven staan de plaatjes hoe LinuxCNC dat standaard doet. EdingCNC homed dan zoals ik had voorgesteld? Want dat is dan inderdaad anders dan LinuxCNC.

Dat langzaam weer terug gaan doet LinuxCNC ook maar heb ik uit de beschrijving gelaten. De home sensoren op mijn machine zijn inderdaad zo geplaatst dat ze "voor of na" de sensor aangeven. Dus met een koude start (zou) het altijd goed moeten gaan.

Ik snap wat je wil, maar het is niet zo te configureren volgens mij. En opzich ook niet nodig als je de homeswitches dicht genoeg bij elkaar zet, wat ook geen drama is:

- Trek halshow open, en mik een watch op de twee homeswitch inputs. halmeter kan ook.
- Jog met de machine nog niet gehomed tot je 1 van de homeswitches ziet triggeren in halshow.
- Verplaats de tweede switch tot die ook triggert. Nu zitten ze in ieder geval niet ver genoeg meer uit elkaar om voor gedonder te zorgen.
- Meet de haaksheid, en stel de laatste honderdsten bij door de HOME_OFFSET aan te passen.

Als je een hele stijve brug hebt die zwaar problemen zou hebben met scheefstand dan is die tandemhoming overigens ook niet nodig. Bij mij staat de brug haaks op het moment dat ik de prik van de motoren af haal en ik moet met honderden Newtons aan een kant duwen om beweging in een meetklok te krijgen. Ik heb dus gewoon maar 1 homeschakelaar.

Blij dat je snapt wat ik wil. Ik blijk namelijk niet zo effectief in het uitleggen Dat zegt meer over mij dan over de lezer.

Ik had gehoopt dat het makkelijk te configureren zou zijn maar helaas niet. Ik denk dat ik eerst ook maar eens met 1 home sensor begin en dan eens ga kijken hoe groot het probleem is. Als de sensors te veel uit elkaar staan kan ik eventueel nog slobgaten in 1 van de vaantjes maken om te stellen. Ik heb nog niet gemeten aan de stijfheid van de brug. Maar het voelt behoorlijk stijf (en dat triggerde dit onderwerp dan ook).



Volgens mij moet het wel te maken zijn in LinuxCNC. Eerst homen met 1 home sensor. Dan de 2de sensor op de probe ingang en met G38 die opzoeken. Dan offset uitrekenen en bij de encoder positie van y2 optellen. Maar dat gaan we later nog wel eens uitzoeken....

[serum]

Ah! platgeslagen wil je dus de positie van beide homingsensoren kunnen opgeven en deze verschilsom gebruiken in de berekening om de portaal recht te stellen.

technisch zou ik zeggen dat het moet kunnen dmv een macro, Je moet op een homing sensor aan een ingang hangen die je kan pollen. En dan niet via een standaard homing sequence, maar ik denk eerder via een macro. In eding kan je subroutines aanroepen en kan je met M code een uitgang uitlezen.

[Kjelt]

Hierboven staan de plaatjes hoe LinuxCNC dat standaard doet.
EdingCNC homed dan zoals ik had voorgesteld? Want dat is dan inderdaad anders dan LinuxCNC.

Ja zie onder.
De link/band tussen master en slave as wordt pas NA stap 3 verbroken en na stap 4 weer hersteld.