Piotr Rakowski pisze:Interpolacji kołowej w moim programie nie ma i nie będzie. To jest zupełnie niepotrzebne. Większość CAMów programowo ustala kwantyzację krzywych w zależności od np. prędkości posuwu i obrotów wrzeciona (czyli tzw. posuwu na ząb), co robię także i ja w eduCAD i cncCAD.

Absolutnie się z tym nie zgodzę interpolacja kołowa to podstawa gdy mam nóż aktywny ruch jest płynny a przeciwieństwie do ścieżki gdzie tej interpolacji nie ma.

Piotr Rakowski pisze:A inni, którzy korzystają z np. Corela najczęściej przechodzą przez format PLT, a ten także w wykonaniu Corela jest skwantyzowany, gdyż/bo/ponieważ* w Corelu nie ma pojęcia łuku - wszystko jest krzywą.

tak i nie
Mam na ukończeniu program do generowania g-codu i robię właśnie exporty z Corela do plt i masz racje tam nie da się zapisać interpolacji, ale już jak zrobimy export do pliku .ai czy .eps to już zupełnie inna bajka i w niedługiej przyszłości będziemy pisać taki interpreter do .ai żeby można było generować interpolacje kołowe bo z plików .plt nie jest do do końca wykonalne.

Piotr Rakowski pisze:Natomiast jesli masz stały przekos bramy, związany np. z nieprecyzyjnym wykonaniem, czyli przekos do pewnego stopnia stały

To lepiej już nic nie robić jak ma się taki problemy

Witam Piotrze
Nie rozumie jakim sposobem miałbyś to rozwiązać przez g-code przecież zmiany kąta mogą powstać po wyluzowaniu silników jeżeli są jakieś naprężenia które spowodują niekontrolowane przemieszczenie jednej strony bramy. Jak dla mnie jedynym rozwiązaniem jest podejście do tematu od strony sterowania i umieszczenie 2 krańcówek dla obu końców bramy. ale muszą działać niezależnie wiec obie osie Y musiały by być sterowane niezależnie z własnego step/dir tak żeby można było kontrolować dany silnik i krańcówkę. Oczywiście lepszym rozwiązaniem będą 2 liniały nie trzeba będzie się za każdym razem przemieszczać do krańcówki, ale ogólnie rozwiązanie mało przydatne przynajmniej u mnie nie ma takich problemów.