Вышел NoRT CNC Control 0.4

Параллельно с написанием кода я уже использую станок под его управлением.

Видосик бы, просто работа + нештатные ситуации, обрыв и восстановление электросети, вылет usb порта при запинании ногой штура. =) Будет шплюсик к популярности, самоделкины любят именно глазами посмотреть же. Пусть не сразу на софт, но на его работу.

У меня два станка под linuxcnc. Работают как часы. Lpt правда. Есть примочки какие?

Ну и я за ранее, как чпушник, ставлю плюсик за труды.

Запишу завтра

Мой проект предназначен как раз для отхода от использования lpt. Шаговиками у меня рулит стандартная девборда stm32f103 с минимальной обвязкой типа max232 для com порта (но в планах добавить работу через usb) и опторазвязкой концевиков. Это позволяет обходиться без rt ядра на компьютере и не зависеть от скорости работы usb lpt, если с ноута работаешь

Умоляю, сделай ещё и can. Или хотябы задел под него, чтобы я потом сделал. Просто привода с телеметрией по can'у и интерфейсом stepdir разработали тут мои друзья и я уде почти уговорил их открыть. Вместе с твоим поделием это будет открытый стек и для взрослых станков, чего так не хватает.
Там, павда, нужно больше осей. И вагон всякого нереалтаймного типа СОЖ, смена инструмента и пр.

RS485/422 не менее взрослый, дальнобойный и помехоустойчивый. Но в отличии от CAN не требует соответсвующего программного стека и, к тому же какой-нибудь MAX485 просто вешается вместо MAX232.

Хорошо

Интересно. А можешь рассказать чуть подробнее? Что у них за девайс. Ну и есть трудность в том, что у меня то can не использунтся, соотв не на чем отладить.

Rs485 он полудуплексный. Это вносит свои ограничения

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

Иногда на меня «нападают» мысли типа «надоела эта культура потреблядства». И в качестве альтернативы в голове всплывает мир, где больше 50% населения - компетентные инженеры, которые дома спокойно делают нужные детали и из них готовые устройства для потребления. И не ведают про запланированное устаревание, делают всё надёжным насколько могут... И вместо «нужны мильёны чтобы построить завод и наладить производство» просто публикуешь чертежы абстрактного ионного двигателя/водородного генератора/чего угодно в формате любого опенсорсного CAD'a. И пишешь новость на тематическом сайте/канале в любимом мессенджере. И готово: новое изобретение готово экспансироваться на мир без вбухивания денег и краудфандинга - у всех желающих есть умения и производственные мощности для внедрения этих чудо-машин.

Да, это всё мечты про «справедливый мир» без запатентованных корпораций, жутко медленного внедрения инженерных инноваций и прочего современного безумия. Зато если хоть одна инопланетная цивилизация внедрит у себя такое и не доведёт своих инженеров до состояния «все сошли с ума, построю машину судного дня», то она выиграет во всех технологических и космических гонках и сделает все «патентованные цивилизации с мега заводами» аутсайдерами, не позволив этой заразе захватить бОльшую часть пригодных для жизни планет. Заполняя космос инженерами, а не «эффективными менеджерами».

RS485/422 не менее взрослый, дальнобойный и помехоустойчивый. Но в отличии от CAN не требует соответсвующего программного стека

возьми напильник вместо станка с ЧПУ и ебашь - чего уж там

Выглядит интересно, но тестов у петоновской части похоже вообще нет, что угнетает, да и у сишной негусто.

Какой нибудь сайт или описание у них есть?

Несколько тестов есть, но в целом ты прав. Нужно больше тестов

CAN тоже. Хочется полного дуплекса - есть RS422, тот же RS485 но по двум парам.

возьми напильник вместо станка с ЧПУ и ебашь - чего уж там

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

А как связан ethernet и чпу?

А как связан ethernet и чпу?

напрямую никак, но в принципе он прав. Ethernet будет проще на стороне PC вместо CAN и по всем параметрам на голову выше CAN. CAN дешевле когда у тебя десятки или сотни миконтроллеров.

А как связан ethernet и чпу?

Точно так же, как RS232 и ЧПУ, как CAN и ЧПУ. Способ обмена данными. CAN в этом списке далеко не самый привлекательный претендент. На порядок сложнее RS232 и на порядок укушеннее и медленнее чем Ethernet. Если уж заморачиваться со стеком, то Ethernet-IP гораздо предпочтительнее CAN хотя бы потому, что есть готовые надёжные стеки разного размера и назначения.

Не кажется, или общаться с каждым микроконтроллером через ethernet (кстати, наверно имеется ввиду еще и tcp/udp/ip, а не чистый ethernet) это слишком сложно?

Плюсую RS422. Вообще, USB хорошо работает на таких конструкциях, но если расстояние надо побольше ничто не побьет RS232 (нормальный а не огрызок) и RS485/RS422. Можно делать стремный интерфейс по 2м RS485 (AVRщики знают) с full-duplex. А еще хорош ethernet. CAN можно гонять тоже, но это уже будут пакеты, и может быть куча разного странного в зависимости от чипа.

С каждым MCU - сложно, но для твоей задачи очень даже нормально.

s/Тем самым этот/Таким образом, этот/

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

общаться с каждым микроконтроллером через ethernet (кстати, наверно имеется ввиду еще и tcp/udp/ip, а не чистый ethernet) это слишком сложно?

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

Не кажется, или общаться с каждым микроконтроллером через ethernet (кстати, наверно имеется ввиду еще и tcp/udp/ip, а не чистый ethernet) это слишком сложно?

Там нет ничего сложного. У меня в профиле найдёшь рабочий пример отправки UDP пакетов (да, можно, например, напрямую в syslog сервака писать осмысленный текст) на PIC18F1320 bit-bang'ом без какого-либо контроллера вообще.

Ethernet-IP-UDP кстати даже попроще CAN будет. Ни коллизии на шине не надо разрешать, ни со всякими remote frame или как их там разбираться.

В случае ошибки crc, кадр шлется по новой. В остальных случаях пока что остановка.

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

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

Вот этого вот совсем не надо. Ненадёжно, непредсказуемые лаги, потери и т.д.

С гаджетов через WiFi можно рулить компом, который по проводам в контроллер G-Code шлёт.

Udp не гарантирует порядок пакетов

Ненадёжно, непредсказуемые лаги, потери и т.д.

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

С гаджетов через WiFi можно рулить компом, который по проводам в контроллер G-Code шлёт.

Зачем ? сделать буфер побольше на стороне контроллера и всё.

Требования к качеству соединения при закачке интернета и при управлении железом различаются на порядки

сколько качаю с инета через WiFi

Когда качаешь - тебе плевать, приедет пакет через 10mS или через 1000mS. А деталька окажется запоротой.

Зачем ? сделать буфер побольше на стороне контроллера и всё.

Как буфер поможет от постоянной помехи, например?

ЗЫ: Да и рулить станком с гаджета - это тупо _неудобно_. Хотеть этого могут только те, кто сам ни разу не пробовал. Даже на фоне хайпа с IoT люди всё-же предпочитают для включения/выключения света физический выключатель на стене а не ковыряние в телефончике.

требования к качеству соединения при закачке интернета и при управлении железом различаются на порядки

да ну нафик - расскажи тем кто работает на удаленке

Когда качаешь - тебе плевать, приедет пакет через 10mS или через 1000mS. А деталька окажется запоротой

накапливай буфер и потом начиная пилить, в идеале - полностью заливать задание

рулить станком с гаджета - это тупо _неудобно_

это более близко к реальности

накапливай буфер и потом начиная пилить, в идеале - полностью заливать задание

Это могут быть сотни мегабайт вообще-то.

это более близко к реальности

Это вообще даже рядом с реальностью не стояло. Впрочем, обычно объяснять бесполезно, это надо чтобы пациент сам попробовал, обплевался и таки образумился. «Хочу умный дом без выключателей, чтоб с ипхона всем рулить!!!!11111». А потом по-новой ремонт, чтобы таки поставить с таким энтузиазмом удалённые выключатели.

Заливать задание? Ну вот например в stm32f103 20 кб озу. Полностью туда все команды задания не влезут. Поэтому у меня задание на перемещения формируется из исходного g-code на компьютере, а потом отдается в микроконтроллер. В нем есть буфер команд, 10-20 команд влезает

Ну вот например в stm32f103 20 кб озу

внешняя память не катит ? да и на stm32f103 свет клином не сошелся

В микроконтроллерах памяти столько и есть обычно. Внешняя память - существенное усложнение.

Да в чем смысл заливать все перемещения в него? Пускай вся программа хранится на компьютере, где памяти гигабайты. А в МК понемногу выдавать команды.

Состоялся новый релиз разрабатываемой мной системы управления фрезерным станком с ЧПУ.

Удачи с проектом. Нужная вещь (для спецов). Видосик бы еще посмотреть...

Внешняя память - существенное усложнение

мне всегда казалось что механика и электропривод в данной теме куда более сложная и дорогая часть как и материал от запоротой детали, смысл экономить на памяти для буфера ?

Да в чем смысл заливать все перемещения в него?

чтобы свести ошибки рантайма к минимуму

Расскажи, как ты прикрутишь да хоть 200 мб озу к микроконтроллеру?

Расскажи, как ты прикрутишь да хоть 200 мб озу к микроконтроллеру?

а в чём сложность хоть пару гигов прикрутить если процессор позволяет ?

1. Это не так то просто. Нужно разрабатывать куда более сложную печатную плату. Разводить плату под ddr я как то не хочу.

2. Процессоры, позволяющие это, достаточно сложны и подразумевают использование ОС типа линукса. А это сразу ставит проблемы для реалтаймовости. Смысл использования МК в том, чтобы сделать код, работающий на голом железе и добиться гарантированного времени обработки всего

3. Все это существенно дороже чем девборда за 150 рублей

1) купить готовую уже не вариант в 21 веке ? разработать нужно будет только плату расширения под свои нужды

2) да мало ли кто и что подразумевает - RTOS-ы для cortex-a и даже bare metal sdk есть

Но это конечно уже совсем другой уровень - я не знаю ваши цели.

При желании это наверно можно, но это дороже и увеличивает порог вхождения. Сейчас для того, чтобы воспользоваться моим проектом, достаточно копеечной девборды. И код легко портировать на другую архитектуру, т.к. аппаратно зависимого кода там немного и он весь в 1 файле.

Ничто не мешает второй конец Ethernet воткнуть не в комп, а в точку доступа Wi-Fi (собственно, и так скорее всего будет уходить провод в какой-нибудь свитч как минимум).

Можно прикрутить SD-карту или, если хочется красиво, но сложно, соответствующие чипы ПЗУ. Те же 3Д-принтеры часто имеют режим печати с SD-карты, чтобы не зависеть от глюков компа. Только у них обычно нужно втыкать карточку в комп, закидывать g-code, втыкать карточку в принтер. Что неудобно. А если бы можно было закидывать файлы на карточку по USB/Ethernet и по ним же отправлять в печать, то было бы идеально. Отправил задачу на исполнение в станок - всё, комп можно перезагружать, сеть может падать, но станок будет работать. При этом, разумеется, в любой момент можно снова подключиться и посмотреть прогресс выполнения, внести изменения в рантаймовые настройки и т. д.

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

Мне что-то подсказывает, что нужно знать только некоторое разумное количество следующих команд.