#? @rf @ru
Почему ни один обоссанный интерпретатор гкода не умеет ограничивать ускорение линейной функцией от текущей скорости?
Это же универсальное свойство шаговиков. У линейных осей робота, движимых электромоторами, ускорение пропорционально моменту, момент пропорционален току через обмотки электромоторов, ток пропорционален разности напряжения питания и противо-ЭДС мотора, противо-ЭДС мотора пропорциональна скорости его вращения. Если ограничивать движение максимальной скоростью и максимальным ускорением, как это в klipper сделано например, вместо функции от скорости, проёбываешь и более высокое возможное ускорение на низких скоростях, и более высокую возможную максимальную скорость при длительных перемещениях.

@L29Ah@qoto.org @rf@mastodon.ml @ru@lor.sh Может, потому что никому нахер не нужно, потому что выигрыш мизерный, причём ценой времени оператора.

А может, потому что не умеют нормально в матан.

Я так понимаю, это надо только при быстрых перемещениях, а на тех станках, где это занимает большую часть времени и нужна производительность, это решено кардинально — введением обратной связи.

Follow

@vovanium Оператор-то тут причём, семантика г-кода не меняется, так же как и со скоростью-ускорением - один раз настроил и всё.
Вот обратная связь это действительно нетривиально, и с железной, и с софтверной стороны, но конечно это лучшее решение.
@rf @ru

· · xmpp_gate · 1 · 0 · 0

@L29Ah@qoto.org @rf@mastodon.ml @ru@lor.sh Оператор тут при том, что он будет это настраивать. У тебя предельное ускорение, раз уж ты на этом выигрывать решил, зависит от массы заготовки и оснастки, которые эти шаговики будут тягать.

Sign in to participate in the conversation
CleverLibre Social

CleverLibre Social is an inclusive social instance for open discussion, learning, and community.
All cultures welcome.
Hate speech and harassment strictly forbidden.