Мой первый станок с ЧПУ (25 фото + 1 видео)

Да не впервой , первый для себя .

Да наверное то , что ездил он медленно как для таких движков . Ну пока обкатка , то больше 3 м/мин не давал .

Ну , ок , найдите на рынке 4-ох осевой , с полем 1500*1000 и полем для поворотки в 1,2 м, с полноценной 4-ох осевой обработкой ну и нормальными комплектующими . Как может быть дешевле купить если продающий должен заработать ?

Вот и я про это )

Полгода чистой "сборки" , когда уже всё на месте и только болты крутить нужно )))

Примеры работ есть в комментариях.

С чего-то начинать нужно ?

Будет , на всё денег не хватает .

"Си шарп только в два раза медленнее си++ (есть куча тестов)"
Здесь вы неправы принципиально. Насколько абстрактный сишарп медленнее абстрактного сипипи, совершенно неважно. Важно, насколько велика разница в конкретных задачах.

вот для иллюстрации пример примитивного калькулятора на vba (да, макросы на vba я тоже писал, в т.ч. даже пару макровирусов, когда они ещё были способны размножаться. Плюс до сих пор несколько моих эппликейшынов эксплуатируются в разных организациях):
for i=1 to 1000000
text3.text=cstr(val(text1.text)+val(text2.text))
next i
т.е. берём текст из поля текст1, преобразуем в число, берём текст из поля текст2, преобразуем в число, складываем их, преобразуем в строку и помещаем результат в поле текст3, и так мильён раз.

Конечно, пример надуман, но он хорошо показывает типичную ошибку ООП-шников -- избыточное обращение к объектам. Если этот пример переписать вот так, он будет быстрее примерно в 100 ТЫСЯЧ раз:
a=val(text1.text)
b=val(text2.text)
for i=1 to 1000000
c=a+b
next i
text3.text=cstr(c)
Конечно, в реале такого выигрыша не получить, поскольку примеры весьма надуманы, но однажды, переделывая чужой "деловой" код (т.е. выполняющий реально полезные вычисления, а не пример или что-то подобное), я таким путём, закэшировав в переменных многократно применяемые свойства объектов, ускорил вычисления примерно в триста раз. Для прочих сред, будь то джава или сипипи, я подобных экспериментов не проводил, но из литературы знаю, что этот эффект есть в ЛЮБОЙ реализации ООП.

"Попробуйте сделать, например простейший САПР для рисования принципиальных схем."
Я сам не пробовал, но у меня в пользовании была САПР (сапр -- она, а не он!), как раз для рисования, только не принципиальных схем, а плат. Ессна, с функцией авторазводки. И написана была та САПР на бейсике, на компьютере ZX-Spectrum, где объём бейсик-программы ограничен десятью тысячами (без одной) строк, где никакого ООП не было. Там даже нормальных функций не было, только пара операторов gosub-return.

"хороший МК на АРМ может стоить 5 баксов"
один бакс или пять -- это некритично для малых партий. В реальном серийном производстве даже один против полутора -- огромная разница...

угу. я тоже писАл компоненты, но тут другое.
если заменить визуальный компонент просто объектом (экземпляром класса, реализованного штатными средствами vba), тормоза те же. потому что обращение к ЛЮБОМУ объекту намного медленнее, чем переменной. Более того: публичные переменные медленнее локальных, хотя здесь разница не столь драматична.
В vb.net эта тенденция сохраняется, хотя в полностью скомпилированном (в экзешник) приложении разница меньше, но она всё равно есть.

Джава -- это сама по себе мегажопа и зряшный пожиратель ресурсов... я уже говорил о "производительности" смартфонов на ведроиде...

Про спектрум вы немножко мимо. Я знаю, что для него писАли "в кодах", но не только и не столько; в основном коммерческий код для спектрума "буржуины" писАли на асме (а часто и на форте) и компилили на "больших" машинах. Конкретно упомянутая мной САПР (увы, забыл название) была написана именно на штатном бейсике и выполнялась в режиме интерпретации, внезапно ))) (про режим интерпретации не напрасное уточнение, для спектрума существует компилятор бейсика, компилирующий бейсик-программу, написанную штатным образом, во что-то типа псевдокода, выполняемое раз в двадцать-пятьдесят быстрее, чем из режима интерпретации).
Кстати о кодах. Я автор одних из трёх (сначала сам написал, потом узнал, что есть ещё две почти такие же), известных мне, "фоновых" часов для спектрума (вешаются на маскируемое прерывание поверх штатного обработчика, выводят на экран часы, не мешающие кодить и выполнять программы на бейсике, да в принципе, и некоторые usr-программы тоже. к сожалению, часы "встают" на время выполнения файловых операций и команды beep.). меньше 100 байт, так-то вот )))

Про ООП. Не надо меня агитировать за его полезность, я нифига не отрицаю полезность этого ИНСТРУМЕНТА -- но важно, что это именно инструмент, а не парадигма. По аналогии с реалом -- да, можно всё есть ножом, но разумнее использовать нож обычным образом, вместе с ложкой и вилкой.
Так и с ООП -- применять его нужно и можно там, где он нужен, и ненужно и нельзя там, где он не нужен. антипаттерн 110%. "Не нужно использовать что-то просто потому, что оно есть, или просто потому, что ты это умеешь."

про спектрум вы всё перепутали.
да, команды там однобайтовые. Жмёшь из режима "К" кнопку Р, получается команда PRINT, режим переключается в L. Команда в память записывается одним байтом (Старшая половина ascii, кроме псевдографики, вся занята кодами команд). Сделано это не для экономии памяти (48К, из них восемь экранных, пара служебных -- под программу на бейсике остаётся овердокуя), а для облегчения программирования (операторы вводятся одним нажатием кнопки) и упрощения интерпретатора (не нужно "распознавать" слово-оператор побайтово)
Однако, к компиляции это не относится.

Бейсик-код на спектруме реально можно компилировать (программа-компилер "загружается отдельно", в штатном ROM её нет), получается программа "в кодах", запускаемая функцией USR, как и программа, изначально написанная на асме. Выполняется такая компилированная программа значительно быстрее, чем просто интерпретируемая, запускаемая командой RUN, хотя и намного медленнее, чем изначально написанная на нормальном асме.

И таки да, никакое ООП абсолютно не нужно для написания интерпретатора (и компилятора тоже). Даже если язык, интерпретируемый или компилированный им будет ООПшным. Внезапно.

На таких комплектующих в Китае точно дешевле не будет , а допиливать напильником желание нету.

Да, очень странно что не на Сервоприводах

5 лет обслуживал парк ЧПУ с шаговыми моторами , проблем некогда не было , не понимаю почему я должен за серву переплачивать.

такое же мнение было пока на серву не перешел. скорость другая и режим работы. для меня теперь шаговые разве что для малых станков не более

это что за парк такой ??? даже 2000 года старинные станки на сервах

Фабрика по изготовлению МДФ фасадов.

секунде сори

а по поводу стоимости - я рынок хорошо знаю так как работа такая - с говном всяким возится - к слову мой станок плазменной резки мне обошёлся в 1000 $ с учетом покупки ручной плазмы за 400. правда я пошёл другим путём и делал на ремнях ( так как длинны стола 6 метров и рельсы обошлись бы РЕАЛЬНО ДОРОГО) ... тут конечно (у автора) в этом плане грамотнее . но ремней мне хватит примерно на 60 км резки без растяжки - при том что 60 км это надо год резать без остановки ...
так что помолчите АБАРМОТ если не владеете инфой... оффф топ

Мотры нема 23 и 34 сравнили ,очень интересно) У Ваших 30 кг*см у моих 86 момент на валу. Про китайские рельсы вообще молчу , мне доставку сразу показало в 1,5 раза дороже.

Снова таки ни валы с рельсами сравнивать и винт 16мм и 20 мм не очень корреутно))

Молчу-молчу , куда мне до таких спецов .

Спасибо !