Мой первый станок с ЧПУ

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

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

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

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

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

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

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

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

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

Диод не предохранитель. При прочих равных характеристиках в диоде "посильней" (например, по обратке или по мощности или по прямому току) - ничего плохого. Вот только хз что там за цепь, что понадобилось конденсатор ставить "для пиковых сбросов" паралелльно диоду, который по обратке максимум 10Вольт а по прямому току - 15..40 мА

Вот именно, хз что там за цепь. Но из опыта могу сказать (я по образованию инженер-разработчик систем СЧПУ, имею реальный опыт работы в заводском КБ), если где-то в станочной промавтоматике горят диоды, вариантов два: или их жжёт какой-то неисправный элемент (примерно так, как глючный контроллер моста жжёт мостовые транзисторы в частотнике, открывая их одновременно), или это реальная ошибка разработчика, и диоды взяты "без запаса". Второе крайне маловероятно на серийной технике, легко находится и, самое главное, обычно не ограничивается одним конкретным диодом, схожих по устройству цепей обычно много, а ошибка будет везде. Вывод: ситуация по первому варианту (кстати, такое реально бывает часто). Вывод2: нужно не диод менять на более мощный, а искать, почему он сгорел.

зы. Д9И держит обратку до ста вольт.

ой да ладно вам, спайсы ))) я спайсов не застал, начал работать -- не было, ушёл на пенсию -- не было )))

все эти САПР ужасно развращают разработчика, ага.

да, ускоряют, но и развращают.
Раз вы программером трудитесь, очевидно, вам знакома современная парадигма "программирования-и-тестирования", когда качество кода определяется просто "нагрузочным тестированием"? Не буду о сложном, но укажу лишь, что качество такой проверки всецело зависит от качества написания теста.
дополнительно укажу на тот факт, что современное "классическое" программирование (на практически любом языке) явно тяготеет к принципам ООП, в 99% случаев без всякой нужды и во вред здравому смыслу.
Плюс ещё одна проблема современного программирования: рост числа "прокладок" и "обёрток" между железом и реальным кодом.

Всё это приводит к неразумной трате ресурсов (мс ворд для дос по функционалу ничуть не хуже мс ворд 2010, но требует для нормальной работы В ТЫСЯЧИ РАЗ меньше памяти и в сотни раз меньше тактовой частоты ЦП), чудовищному росту объёма кода и капитальнейшему падению надёжности.

Без САПР же таких проблем нет, я для микроконтроллеров пишу на Forth, и программы, внезапно, ВСЕГДА просто работают. С первого раза. Вот без шуток. Читаю ТЗ, беру бумажку и пишу прогу на форте. Через *цать часов с бумажки набираю готовый код, компилю, прошиваю и всё работает. Без проблем, без ошибок, без стресс-тестирования.

Парадигма ООП изначально предназначена для "модельного" описания сущностей, попадающих под определение объекта. Например, примером хорошего ООП может служить такая штука: пишем программу диспетчерского контроля, например, лифтов. в ней есть объект-контейнер "микрорайон", в нём набор объектов класса "дом", имеющих свойства, отображающие данные, получаемые от оборудования в этом доме, и имеющих методы, реализующие отправку команд оборудованию в этом доме. Подобная система "прозрачна" и наглядна, и позволяет легко масштабировать её, добавляя новые объекты-дома.
Это хорошее, грамотное и годное применение ООП.

А есть и другое ООП, тупое и бессмысленное. Например, в ПХП (грешен, говнокодил на пыхе по фрилансу когда-то) одно время была распространена такая методика создания "библиотек", в виде файла с классом, содержащим методы, являющиеся функциями библиотеки. Вот это -- куёвое, неправильное ООП, за которое все применяющие его обязательно попадут в Ад. Ибо "объекта" как такового этот класс не описывает, а библиотека может и должна быть, в реалиях ПХП, представлена совсем иначе.

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

Ещё одно, внезапно: ООП часто не только не улучшает понятность и читабельность кода, но и, во многих случаях, наоборот значительно усложняет его. Особенно в сях и пыхе.

На Ассемблере я не просто писАл, я на нём до сих пор (как и любой форт-кодер) иногда пишу.
А тридцать лет назад я вообще непосредственно в машинных кодах писАл, было дело. Пишешь прогу на листочке мнемониками асма, а потом, по табличке соответствий, предварительно пересчитав абсолютные адреса в страничные, где нужно, забиваешь в память эвм нужные цифры по порядку... 1,1,0,201,194,0... примерно так.

ТСП и графика... Вы уверены, что правильно понимаете, что такое МК? девайсы с ТСП и графикой обычно содержат, по сути, не МК, а полноценные "однокристальные микроЭВМ", если использовать привычный мне термин. Разница нечёткая, но в общем случае можно делить, как раз, по признаку наличия слоя абстракций в программе. например, чип атмега -- это МК, а ардуина на таком же чипе (несмотря на схемную, в принципе, идентичность) -- это уже микроэвм, ибо кодится не асмом и не нормальными сями, а через абстракции. и атмега, на которой за каким-то хреном крутится линукс -- это тоже не МК, а микроэвм...

насчёт прокладок -- да, конечно, несколько прокладок обоснованы. Но не до такой степени, как сейчас, когда прокладками набит не только уровень железо-ось, но и уровень ось-прикладной_код.
взять тот же дотнет, или джаву: там два или три промежуточных прокладки от юзеркода к винАПИ, насколько я помню. Причём прокладки эти замедляют приложение на порядок, а то и на два.

Да чё далеко ходить: у меня смартфон на ведроиде в тысячу раз быстрее (по частоте. 20Мгц и 2ГГц) и имеет в полтысячи раз больше оперативки (2Мб и 1Гб), чем мой настольный комп четверть века назад... и при этом, сука, прикладные задачи вроде элементарного калькулятора выполняет медленее, чем та "трёшка". Именно из-за ублюдочной джявы. А ведь на той трёшке у меня 95ая винда нормально шла, йопта! Не та, конечно, что OSR2 весом в 47мегабайт, а та, что просто "95", весом в 18 мегабайт. Вот ОСР2 да, на трёшках тупила жёстко, нормально работала только на 486, причём обязательно требовала минимум двух мегабайт оперативной памяти. Первая же 95ая ругалась, но запускалась на одном метре озу.

ЗЫ. компилятор Си может и хорош, более важно, что ему скормить: нормальный код или кашу из юзеркода, стороннего кода библиотек и реализации абстракций.

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

вот для иллюстрации пример примитивного калькулятора на 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 мм не очень корреутно))

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

Спасибо !