Бюджетный ТВ16, по возможности минимум телодвижений :)

[lyo 29]

, Денис Береговой написав:

не.

мы получаем 1мм с погрешностью в 1 микрон

0,0013 мм/крок * 1000 кроків = 1,3 мм

Щоб пройти 1 мм нам потрібно зробити

1 мм / 0,0013 мм/крок =~ 769 кроків

Де я помиляюся?

[Денис Береговой 1 177]

2 часа назад, lyo сказал:

Але фактично ми округлили значення кроку на 30%

В системе это все задается количеством импульсов на единицу перемещения.

Причем не целочислено, а с дофига знаками после запятой т.е. и теоретического микрона там не будет....

Железо даст в разы большую погрешность.

 

Вот фотки.

В визарде вводим соотношения шкивов, шаг винта после чего он генерирует ини файл. 

Открываем ини файл и смотрим что наше значение Скейл имеет 8 знаков после запятой!!!

 

Давайте на моем примере разберем.

14 зубов один шкив

40 зубов другой шкив

1/4 шага

винт 1,5мм

40/14*200(шагов)*4(режим 1/4 шага) = 2285,7142857142857142857142857143 импульсов на оборот.

Теперь разделим на 1,5 (шаг винта) и получим 1523,8095238095238095238095238095

 

давайте теперь по пропорции 

1523,8095238095238095238095238095                          -100%

1523,80952380952381 (из ини файла)                            -Х%

 

х=100,00000000000000003125%

Вот такая математическая погрешность будет....

 

Точность изготовления китайского ремня, китайских шкивов меньше, винт ТВ-16 по факту шпилька из строй маркета и многое другое....

 

 

Змінено 10 грудня, 2019 користувачем Денис Береговой

[lyo 29]

10 годин назад, Денис Береговой написав:

В системе это все задается количеством импульсов на единицу перемещения.

Причем не целочислено, а с дофига знаками после запятой т.е. и теоретического микрона там не будет....

Екзектлі.

Різниця в тому полягає, що Ви говорите про LinCNC, а я про самописний (мноюписний) від початку і до кінця софт. І не для ПК. І який, бажано, має бути максимально наближеним до риалтайму (хоча теж працює під лінухою, і я чудово знаю про всі пов'язані з цим недоліки). І тут ми згадуємо, що зайві мультиплікативні операції, та ще й зі змінними типу float, ну аж ніяк не сприяють швидкодії. І рука так і тягнеться до цілих... Ну, назвіть це справою смаку. Зрештою, це - мій власний код, заточений під конкретний проект (на відміну від універсального LinCNC), і мені хочеться щоб він був елегантським на мій власний хлопський розсуд. І якщо для цього мені потрібна пара шківів з передаточним числом кратним 3, то це - невелика ціна.

Та то таке. Топік цієї гілки,зрештою, не про це.

[Денис Береговой 1 177]

7 минут назад, lyo сказал:

Топік цієї гілки,зрештою, не про це.

 

ИМХО если резюмировать то вообще ничего страшного нет в том что соотношение шкивов не целочисленное, как могло бы показаться.

В контексте проекта подобного моему.

 

 

[lyo 29]

, Денис Береговой написав:

 

ИМХО если резюмировать то вообще ничего страшного нет в том что соотношение шкивов не целочисленное, как могло бы показаться.

В контексте проекта подобного моему.

Так, абсолютно.

В контексті Вашого проекту, це не має значення.

[andrysir1 264]

, lyo написав:

Ок, ми прийняли, що 1 крок дає нам подачу в 1 мікрон. Тепер нам треба пройти 1 мм, і ми кажемо нашому двигуну зробити 1000 

Трохи не так, чи можливо я Вас не розумію. Що означає" ми прийняли, що 1 крок дає 1 мікрон." Як видно з розрахунків Дениса, то ми лише визначили мінімальне переміщення тіла за 1 дискрету( імпульс, чи крок). Проте не факт, що тіло реально пройде цей шлях, але ми точно знаємо, що програмно все буде відпрацьовано якраз з цією точністю. І якщо ми маємо пройти 1 мм, то ми це кажемо не двигуну, а контролеру, ( бо є ще такий параметр, як швидкість), який має опрацювати задану відстань, і враховуючи параметри( ширину імпульсу, редукцію, швидкість, затримку при переходах іпульсу, і т.д) видає на мотор певну(результуючу) к-сть імпульсів, щоб пройти рівно 1 мм, розкладаючи ті імпульси на час, за який має тіло пройти той "злочасний" міліметр. І з розрахунків Дениса, ми лише точно знаємо, що він пройде його з точністю 1.3 мікрона( точність правда математична). 

Драйвер мотора ж не знає сам, за який час він має видати ті імпульси, він лише може в режимі мікрокроку, об'єднати вхідні імпульси (кілька коротших), аналізуючи ширину вхідного імпульсу та час, який проходить від початку першого імпульсу до початку другого в один повний крок мотора, і ті що залишилися не об'єднані, видати так, щоб поставити ротор в положенні між повними кроками.

Змінено 11 грудня, 2019 користувачем andrysir1

[Денис Береговой 1 177]

2 часа назад, andrysir1 сказал:

з точністю 1.3 мікрона( точність правда математична). 

то 1,3 микрна это я прикидывал при целочисленном задании параметра "скейл" (кол-во импульсов на единицу пути)

Т.е. если бы мы округляли до целого значения.

Потом, проверил, а там возможны занчения с 8ю занками после запятой. даже считать нет смысла что там за математическая погрешность...на 8 порядков еще точнее

Змінено 11 грудня, 2019 користувачем Денис Береговой

[Денис Береговой 1 177]

Время подходит к экодеру шпинделя, необходимого для синхронизации продольной подачи и шпинделя при циклах нарезки резьбы.

Как бы видится несколько вариаций:

 

1 С тыльной стороны ПБ на шпиндель повесить диск с одним отверсим (индексная метка/нулевая метка) + ардуиновскую оптопару. Этого будет достаточно, но такая система не будет отслеживать изменение частоты вращения и полжение шпинделя в рамках одного оборота. Во время работы при нарезке резьбы не думаю что частота вращения будет плавать в рамках одного оборота. Если все же будет то это черевато не равномерностью шага резьбы но опять же величины ИМХО таковы что шероховатость поверхности будет больше влиять....

 

2 Так же как и в варианте №1 с тыльной стороны на шпинделе диск с единственной индексной/нулевой  меткой +  через пасик на трении энкодер на 100 меток на оборот. Подобная схема отлично трудилась у Миши Аегиса на его монорельсовом ЧПУ. Увлекаться разешеним энкодера (более 100 меток на оборот) при считывании сигналов с ЛПТ порта думаю не стоит, по причине того что бы на больших частотах вращения не превысить пропускную способность ЛПТ порта компьютера. В ранних мануалах ЛинуксЦНЦ была прямая рекомендация использовать два канала, один с нулевой меткой, второй не менее 100меток на оборот. Потом не находил данную рекомендацию. Мачь, тот что под виндовс рабтает с одной нулевой меткой. Слышал что и Линукс ЦНЦ тоже норм работает с одной нулевой меткой, однако сам не проверял.

 

3 У меня в наличии несколько 100 меточных советских станочных энкодеров ВЕ-178. Они имею два канала А и смещеный  канал Б. Оба канала имеют выводы как основного так и инвертированого сигнала, и судя по всему инвертирование не програмное а железное (свой отдельный считыватель). Есть исполнения с тремя каналами А,Б и Зет (нулевая метка) Но стометочные с Зет каналом мне не попадались. Зато вскрытие показало что оптический диск унифицирован и имет таки "дорожку" с нулевой меткой, просто для ее установки не установлены оптоприемник. Идея такова, взять один оптопримник канала Б (основной или инвертированый не важно) и установить его в гнездо для считывания нулевой метки. Теоретически на выходе должен получить: Канал А основной, канал А инвертированый, канал Б основной и канал Зет (нулевая метка) По сути каналом Б можно жертвовать, он мне не нужен. Мне важенй получить один 100меточный канал и один канал с индексной/нулевой меткой.  Далее выточить два одинаковых по диаметру шкива и на трении пасиком подружить энкодер и шпиндель. Ну или же пименить какой то нежный зубчатый ремешек и два одинаковых зубчатых шкива.

 

У кого какие мысли на этот счет?

Особенно интересует мнение и рекомендации по поводу модернизации ВЕ-178, в электронике и схемотехнике я не шарю, действую и рассуждаю на уровне своей логики. 

В приложении принципиальная схема ВЕ-178 Там два варианта реализации с нулевой мтекой и без.

На фото видны внутренности двух разных  исполнения  ВЕ-178 оба без нулевой метки

 

 

Untitled1.pdf

Untitled0.pdf

[lyo 29]

23 години назад, andrysir1 написав:

І якщо ми маємо пройти 1 мм, то ми це кажемо не двигуну, а контролеру, ( бо є ще такий параметр, як швидкість), який має опрацювати задану відстань, і враховуючи параметри( ширину імпульсу, редукцію, швидкість, затримку при переходах іпульсу, і т.д) видає на мотор певну(результуючу) к-сть імпульсів, щоб пройти рівно 1 мм, розкладаючи ті імпульси на час, за який має тіло пройти той "злочасний" міліметр.

Якщо ми вже продовжуємо про це.. Я перепрошую, що саме Ви маєте на увазі під котролером? І звідки цей котролер (щоб воно не було) знає, як саме він мусить "опрацювати задану відстань" і видати ту саму "певну" кількість імпульсів, щоб пройти рівно 1 мм?

Якщо виходити з того, що ми кажемо комусь "протягни мені супорт на 1 мм", а далі воно вже якось само розрахує скільки імпульсів потрібно подати, то це одне. Ми використовуємо готове рішення і за нас вже хтось про це подбав.

Але, як я казав, я пишу власний софт. І ніякий чарівний контролер за мене не розрахує необхідну кількість імпульсів і їхній період. В моєму випадку це виглядає приблизно так. Я кажу: "На оцьому піні змінити рівень з низького на високий на таку-то кількість мікросекунд, після чого повернути низький рівень". І це буде один імпульс. І це буде один крок двигуна. І мені потрібно знати, на скільки просунеться різець за цей один крок. Не обов'язково в якості константи (хоча, як на мене, це - зручніше), цю відстань можна обчислювати з інших фізичних параметрів. І якщо у мене буде цифра типу 0,001315-і-ще-там-щось, то жити з нею можна, але вона ускладнює моє життя.

Втім, я повторююся

Просто ми про різні речі говоримо, тому, можливо, не розуміємо один одного.

 

[andrysir1 264]

3 години назад, lyo написав:

Якщо ми вже продовжуємо про це.. Я перепрошую, що саме Ви маєте на увазі під котролером? І звідки цей котролер (щоб воно не було) знає, як саме він мусить "опрацювати задану відстань" і видати ту саму "певну" кількість імпульсів, щоб пройти рівно 1 мм

 

В моєму розумінні контроллер- це апаратний, або програмний аналізатор, який працює за певними правилами, і на основі вхідних даних та внутрішніх параметрів і функцій, контролює і корегує видачу певних сигналів для інших пристроїв, які розуміють вихідний тип сигналу. В Вашому випадку імпульси. 

Тобто Ваш софт, в купі з желізом, на якому він буде стояти, і є тим контроллером. А логіку, закони, і функції для його роботи вже складаєте Ви. І те, як ви її складете буде залежати працездатність Вашого контролера.  В першу чергу ваш контроллер отримає інформацію куди, на скільки, як швидко рухатись, і вже він видасть імпульси( ті які потрібні) на інші пристрої.

P.S.  Сорі в автора теми за відступ від її суті. Більше не буду. Чесно. ????

[Денис Береговой 1 177]

3 часа назад, andrysir1 сказал:

Сорі в автора теми за відступ від її суті. Більше не буду. Чесно. ????

Я на все ровно смотрю, тема не моя она общая. Моя лишь ее инициация.

Т.е. можно хоть ссылки на барахолку, хоть анекдот не по теме рассказать, лишь бы правила форума не нарушались....

[lyo 29]

7 годин назад, andrysir1 написав:

В моєму розумінні контроллер- це апаратний, або програмний аналізатор, який працює за певними правилами, і на основі вхідних даних та внутрішніх параметрів і функцій, контролює і корегує видачу певних сигналів для інших пристроїв, які розуміють вихідний тип сигналу. В Вашому випадку імпульси. 

Тобто Ваш софт, в купі з желізом, на якому він буде стояти, і є тим контроллером. А логіку, закони, і функції для його роботи вже складаєте Ви. І те, як ви її складете буде залежати працездатність Вашого контролера.  В першу чергу ваш контроллер отримає інформацію куди, на скільки, як швидко рухатись, і вже він видасть імпульси( ті які потрібні) на інші пристрої.

P.S.  Сорі в автора теми за відступ від її суті. Більше не буду. Чесно. ????

Ну, якщо вже топікстартер не заперечує :-)

Усе нижчевикладене є моїм власним ІМХОм і не претендує на те, щоб бути істиною в останній інстанції.

Власне, зазвичай контролером називають саме апаратний пристрій, який керує якимось іншим пристроєм (як правило - периферійним, з точки зору центрального процесора (ЦП), але бувають і виключення).

Софт, який керує котролером периферійного пристрою, називають драйвером цього пристрою.

Але, як майже будь-яка класифікація, це все - дуже умовно і має масу застережень. Наприклад, у випадку однокристальних систем це, вочевидь, не працює. Як і в моєму випадку.

 

7 годин назад, andrysir1 написав:

  В першу чергу ваш контроллер отримає інформацію куди, на скільки, як швидко рухатись, і вже він видасть імпульси( ті які потрібні) на інші пристрої.

Так, якщо цей гіпотетичний котролер отримує інформацію від когось іншого, наприклад від ЦП, і має програму-драйвер, яка ним керує. В цьому випадку, програмуючи ЦП, ми можемо абстрагуватися від "низького рівня" керування контролером і зосередитися на "високому рівні" складання логіки роботи нашого периферійного пристрою в цілому. А програма-драйвер контролера вже сама розрахує скільки імпульсів і якого періоду слід подати.

Приблизно так працює LinCNC. Вам не потрібно паритися розрахунками довжини імпульсу і керувати безпосередньо рівнями сигналу на контактах, до яких підключається драйвер крокового двигуна (step, rev, en). За Вас це вже зробили.

Такий підхід має масу переваг. Але він має і один істотний  недолік: в моєму випадку він не працює. Бо у мене не ПК і не LinCNC.

У мене і ЦП і контролер - одне і те саме. І у своїй програмі, коли мені потрібно посунути супорт на певну відстань, я так і пишу: "на контакт, під'єднаний до входу step крокового двигуна, подати логічну 1 на стільки-то мікросекунд, зняти логічну 1, повторити цей цикл таку-то кількість раз".

Якось так.

 

[lyo 29]

12 години назад, Денис Береговой написав:

Время подходит к экодеру шпинделя, необходимого для синхронизации продольной подачи и шпинделя при циклах нарезки резьбы.

Как бы видится несколько вариаций:

 

1 С тыльной стороны ПБ на шпиндель повесить диск с одним отверсим (индексная метка/нулевая метка) + ардуиновскую оптопару. Этого будет достаточно, но такая система не будет отслеживать изменение частоты вращения и полжение шпинделя в рамках одного оборота. Во время работы при нарезке резьбы не думаю что частота вращения будет плавать в рамках одного оборота. Если все же будет то это черевато не равномерностью шага резьбы но опять же величины ИМХО таковы что шероховатость поверхности будет больше влиять....

 

 

Якщо мова іде лише про нарізання різьби, то в цій гілці:

топікстартер припустив що одного імпульсу на оберт шпінделя цілком достатньо для досягнення цієі мети. І на практиці це довів.

Я також можу це підтвердити. Дійсно, в межах одного оберту шпинделя навряд чи RPM так просяде, що доведеться коригувати швидкість подачі. Ну, принаймні, якщо Ви не збираєтеся нарізати різьбу з кроком 10 мм. Але тут вже кроковий двигун навряд чи потягне. А обчислювальне навантаження зростає буквально на два порядки (1 переривання для обчислення RPM на оберт шпинделя, чи 100).

Мої експерименти показали, що повторне попадання заходу різьби цілком задовільне. Але. На моє здивування, також зіткнувся з тим, що топікстартер вищезгаданої гілки назвав "брязкотом контактів" оптопари. Коли значення розрахованого RPM раптом сплесками скаче на порядки. Беручи до уваги, що опропара не може мати брязкоту контактів, думаю, що це наводки у проводі від оптопари. Планую замінити його на екранований.

 

 

 

[aegis 1 266]

7 часов назад, lyo сказал:

топікстартер припустив що одного імпульсу на оберт шпінделя цілком достатньо для досягнення цієі мети. І на практиці це довів.

 

ок. а тепердивіться що ви втратили. тупа фізика.

шпіндель вийшов на сталий режим обертів, енкодер зчитує єдину мітку з певною частотою. починаєте різання, оберти просіли. через 1 оберт ЧПК починає бачити, що оберти , що оберти змінилися, але діяти ніяк не може. 1 оберт - бачить "зміщення", але система не реагує, бо по одній цифрі може бути і просто плавання обертів. ще через 1 оберт чпк зможе підтвердити, що оберти просіли. воно побаче зміну швидкості, але не може рорзрахувати прискорення. для цього потрібно мати "статистику" ще одного оберта. після цього можна починати розраховувати прискорення, рахувати як швидко треба взаємодіяти і змінювати подачу. це все теж проходить не миттєво, аде у вас є час "сервоцикл".

і в результаті у вас буде плаваючий крок. сам через це проходив. буде сильно помітно на великих подачах. великі оберти через енерційність зменшують вплив. так само позитивно впливає і більша потужність мотору (збільшення обертового моменту).

працює, але є нюанси. мені не сподобалося. саме через це я на лінукс з мача перейшов щоб користуватися енкодером хоча б на 100 міток. що дало змогу різати внутрішню трапецію 16*4

[ole21 59]

23 часа назад, Денис Береговой сказал:

по поводу модернизации ВЕ-178

Если канал Б не нужен, достаточно переставить ОБА фотодиода на канал Z, и перемычками вернуть их на канал Б.

После этого Б будет читаться как Z.

23 часа назад, Денис Береговой сказал:

инвертирование не програмное а железное (свой отдельный считыватель)

Не совсем так.

Инвертирование действительно "железное", но реализовано именно инвертором. Второй же считыватель (фотодиод) не принимает поток от диска энкодера , а компенсирует синфазные помехи. (Похоже работает витая пара).

[Денис Береговой 1 177]

1 час назад, ole21 сказал:

синфазные

Спасибо, если честно я не все слова понял.

Но Вы подтвердили мои измышления, просто  переставить местами "приемник" оставив его скомутированым на старые дорожки.

Единственная пока для меня не понятка, это то что имеем два свободных для этого гнезда. Одно прям на против нулевой метки, а второе повыше, рядышком с диодами канала А или Б.

 

У меня ВЕшек насобиралос малехо. 3шт 100меточных, два из них точно рабочие третий не уверен, и один 1024 метки с нулевой меткой на работоспособность не проверял.

 

Если Вы в этом разбираетесь, может Вам было бы интересно (не бесплатно) оказать услугу перекомутировать все стометочне и проверить/отремонтировать остальные. Мне они нужны будут для следующих проектов. Если есть интерес или возможность предлагаю перейти в личку.

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

 

[aegis 1 266]

В 10.12.2019 в 23:47, lyo сказал:

І тут ми згадуємо, що зайві мультиплікативні операції, та ще й зі змінними типу float, ну аж ніяк не сприяють швидкодії. І рука так і тягнеться до цілих...

саме тому люди і ставлять спецмікрухи, які для цього мають модулі. вони можуть обраховувати енкодери з величезною швидкістю, робити прорахунки з плаваючою точкою і тп. ви просто взяли не те за основу. у знайомого був досвід, коли енкодер з величезною роздільною здатністю (щось там біля 5лямів імпульсів) не міг коректно опрацьовуватися кфлопом. задачу вирішила маленька плата-перетворювач япс, на якій стоїть спецмікруха, яка заточена робити швидкі розрахунки і тп. саме тому я рекомендую вкладатися в маленьку платку 7i92 за смішну ціну а не в дорожчий комп з меншим латенсі, який всеодно не догоняє

[Денис Береговой 1 177]

Базовые инструментальные блоки готовы, далее уже можно индивидуальные под конкретные задачи делать по потребности и желанию

 

Фусик, "мастер на все руки" фрезерует, сверлить, резьбы нарезает, а в это время у порога одиноко стоит напольная сверлилка 2Б118, легкая а посему не дорогая и гадает впустят ее в веселую но тесную компанию мастерской или она здесь "транзитом"?... 

[Денис Береговой 1 177]

14 минуты назад, aegis сказал:

7i92

Ага, лежит такая Меса для следующего проекта, там частота генерации импульсов поболее будет (сервы)

По памяти 92дол. цена.

[aegis 1 266]

44 минуты назад, Денис Береговой сказал:

Базовые инструментальные блоки готовы, далее уже можно индивидуальные под конкретные задачи делать по потребности и желанию

 

Фусик, "мастер на все руки" фрезерует, сверлить, резьбы нарезает, а в это время у порога одиноко стоит напольная сверлилка 2Б118, легкая а посему не дорогая и гадает впустят ее в веселую но тесную компанию мастерской или она здесь "транзитом"?... 

красиві блоки вийшли, запустиш шліфовку будуть ще красивіші (майже як мої ). я теж скоро покажу свій новий такарний. трохи побільший і крутіший, але це нюанси. на любий верстат знайдеться робота

Денисе, звиняюсь, що в тему лізу із своїми інсайдерськими фотками, просто нема вже сили тримати все в секреті але тему ще рано відкривати

[Денис Береговой 1 177]

55 минут назад, aegis сказал:

Денисе, звиняюсь, що в тему лізу із своїми інсайдерськими фотками,

Ничего страшного, нормально. Анонс ажиотажа никому не повредит.

У тебя высковалютный проект - все с нуля, перспективен как готовый коммерческий продукт на рынке.

Мой же проект, можно рассматривать как концепт, для апгрейда или восстановления некомплектных станков.

[aegis 1 266]

11 минуту назад, Денис Береговой сказал:

Мой же проект, можно рассматривать как концепт, для апгрейда или восстановления некомплектных станков.

або для "спробувати". я перший токарний чпк будував в далекому 11 році. з того часу багато досвіду з'явилося, тому і роблю значно краще ніж було

[Денис Береговой 1 177]

10 минут назад, aegis сказал:

або для "спробувати". я перший токарний чпк будував в далекому 11 році

Г.ы. подошли просто к одному с разных сторон.

ЧПУ портальный фрезер делал 2008-2009г

А токарник только сейчас....

[lyo 29]

14 години назад, aegis написав:

ок. а тепердивіться що ви втратили. тупа фізика.

шпіндель вийшов на сталий режим обертів, енкодер зчитує єдину мітку з певною частотою. починаєте різання, оберти просіли. через 1 оберт ЧПК починає бачити, що оберти , що оберти змінилися, але діяти ніяк не може. 1 оберт - бачить "зміщення", але система не реагує, бо по одній цифрі може бути і просто плавання обертів. ще через 1 оберт чпк зможе підтвердити, що оберти просіли. воно побаче зміну швидкості, але не може рорзрахувати прискорення. для цього потрібно мати "статистику" ще одного оберта. після цього можна починати розраховувати прискорення, рахувати як швидко треба взаємодіяти і змінювати подачу. це все теж проходить не миттєво, аде у вас є час "сервоцикл".

і в результаті у вас буде плаваючий крок. сам через це проходив. буде сильно помітно на великих подачах. великі оберти через енерційність зменшують вплив. так само позитивно впливає і більша потужність мотору (збільшення обертового моменту).

працює, але є нюанси. мені не сподобалося. саме через це я на лінукс з мача перейшов щоб користуватися енкодером хоча б на 100 міток. що дало змогу різати внутрішню трапецію 16*4

Так, гадаю, що розумію, Ви маєте на увазі. Але. Ох... збирався писати багато, але, як кажуть наші друзі американці  зе поінт із. По-перше, якщо Ви самі пишете софт, ніхто не забороняє Вам обробляти просідання RPM навіть у рамках одного оберту. Алгоритм - Ваш.

Ну і по-друге, так, згоден, на великих подачах похибка може бути істотною. І знову - але. Ми, в рамках цього топіку, говоримо про ТВ-16 з китайським (слеш - радянськими) кроковиками на подачах.

Так, я цілком усвідомлюю, що в металообробці я - лише аматор. І я експериментував лише з кроками різьзьби до 2,5 мм. Результати були, на мій хлопський розсуд, цілком задовільними. А більший крок різьби, в моєму випадку, не витягує кроковий двигун поздовжньої. Припускаю, що на більших кроках різьби, одного імпульсу на оберт шпинделя було б замало. Власне, це застереження я згадував у своєму пості.

З повагою

[lyo 29]

9 годин назад, aegis написав:

саме тому люди і ставлять спецмікрухи, які для цього мають модулі. вони можуть обраховувати енкодери з величезною швидкістю, робити прорахунки з плаваючою точкою і тп. ви просто взяли не те за основу. у знайомого був досвід, коли енкодер з величезною роздільною здатністю (щось там біля 5лямів імпульсів) не міг коректно опрацьовуватися кфлопом. задачу вирішила маленька плата-перетворювач япс, на якій стоїть спецмікруха, яка заточена робити швидкі розрахунки і тп. саме тому я рекомендую вкладатися в маленьку платку 7i92 за смішну ціну а не в дорожчий комп з меншим латенсі, який всеодно не догоняє

Упс. І тут я зрозумів, що мені краще взагалі заткнутися :-)

Жартую.

Я це зрозумів набагато раніше.

Сорі, але я тут розпатякував лише базуючись на своєму досвіді, здобутому в процесі роботи над цілковито хобійним проектом.

Шіт! І знову ж таки - але.

Так, я - аматор у металообробці. Проте, колись, багато років тому, коли я ще був студентом... Звучить як почато казки :-) "Коли Windows ще були версії 3.1..." :-) Втім, ми дійсно писали проги, які виконували розрахунок короткоперіодичного руху літака у трьохвимірному просторі, і які мусили працювати в рамках 64 кБайт. Кіло-факінг-байт!  І вони працювали. Ну, як студентські поробки, але!

Щось я загнався у п'ятничну тему.

Прошу вибачення у топікстартера і переходжу у режим читача.

Змінено 13 грудня, 2019 користувачем lyo