Z-probing scripts en gebufferde controllers?

[wd73]

Een ietwat cryptische titel:-)
Ik heb een vraag waar ik geen antwoord op kan vinden:

Ik gebruik al geruime tijd Mach3 voor het aansturen van mijn CNC portaalfrees, i.c.m. een oude PC en een LPT Break out board.
Nu wil ik wellicht overstappen naar besturing via ethernet, maar wil wel mijn vertrouwde Mach3 blijven gebruiken.
Ik heb een hoop automatische scriptjes in Mach3 voor probing (Z hoogte, buiten- en binnenkanten van een hoek, midden van rond gat etc)
Dat werkt prima omdat bij het proben de PC het signaal van de probe schakelaar ontvangt en meteen stopt met sturen van pulsen over de LPT poort.
Met een ethernet controller wordt output gebufferd begrijp ik, dus als mijn Z-probe de touch plate raakt, stuurt de PC geen nieuwe signalen meer, maar gaat de probe nog even verder door omdat de buffer met commando's in de controller nog niet leeg is?
Als dat inderdaad zo zou zijn, dan werken al mijn handide probe scriptjes dus niet meer met een ethernet controller?
Klopt dat?

Noot; Mijn interesse gaat uit naar een UC400ETH of UC300ETH controller van cncdrive.com. Handig omdat de boel dan snel om te bouwen is omdat de controller een LPT poort als output heeft tbv mijn huidige BoB.

[Tolp2]

Geen recente ervaring met Mach3, maar vanuit LinuxCNC met mijn huidige project loop ik tegen dezelfde overweging aan. Het hangt in het geheel af van de diepte/grootte van de buffer. In mijn geval is is de loop 1 ms, dus in het ergste geval duurt het dus 2~3 ms voordat de probe stilstaat:

• probe raakt iets en stuurt een signaal
• signaal gaat naar de PC [worst-case: 1 ms na rigger]
• PC verwerkt het signaal [worst-case: 2ms na trigger]
• de stuurkaart start met remmen van de stappen-motor [ worst-case: 3ms na trgger]

Laten we aanhouden dat je niet met 10 m/min aan het proben bent, maar dat dit eerder in de orde van 600 mm/min ligt (puur omdat dit makkelijk rekent). Dan beweeg je dus iedere milliseconde dus 600 / (60 *1000) = 0.01 mm. Dus de travel na het triggeren is dus 0.03 mm + de lengte die je nodig hebt om af te remmen. Die laatste heb je met een BOB ook. Dus ik denk dat je gewoon je scripts kan gebruiken.

Wat je wel in de gaten moet houden is dat met een buffer je mogelijk een vertraging van het signaal krijgt. De afwijking in de meting in bovenstaand voorbeeld zal ongeveer 0.01 mm bedragen. dit komt door dat de timing van de touch een random variabele is.

[spikee]

Een drive zoals b.v. delta kan de positie opslaan (met heel weinig latency) voor b.v. probing.
Dit zou je dan via rs485 o.i.d. kunnen uitlezen.

https://filecenter.deltaww.com/Products ... 210201.pdf
Connect de probe naar iedere drive, probe iets -> lees via modbus de X,Y,Z waarde uit en print dat ergens in je interface.

Ik heb overigens geen idee hoe dat werkt bij b.v. linuxcnc i.c.m. een Mesa. Daar zit een fpga in in. Die kan in-principe dit synchroon capteren. of dat ook gebeurt? geen idee.

[skillalot]

Mach 3 slaat de probe coördinaten in variabelen op, die moet je in je script gebruiken voor de positie, niet de positie waar de machine op stopt.
Moet je even googelen dan vind je zo wat ik bedoel.

[wd73]

Dank voor jullie reacties.
Als die buffer inderdaad maar 1 of 2 ms is, dan valt het wel mee denk ik.
Zou er graag nog meer over lezen maar kan maar weinig vinden over dit probleem / uitdaging.

@skillalot; De waarde die Mach3 opslaat als triggerpoint is niet de exacte juiste positie, dat is nu net het hele probleem.
Mach3 ontvangt het signaal te laat van de controller.