Путь в 3D печать своими руками

Преамбула:
И так появилась мысль, она немного не здоровая но все таки … Так как эта мысль родилась давно вот набрался смелости и решил её озвучить публично, некоторые люди заинтересовались и было решено сделать данный пост.

Суть:
Разработка универсально решения для разработки ЧПУ в том числе и 3D принтеров на базе Raspberry Pi, с главной концепцией сэндвича по принципу промышленных ПК причем на стандартной шине самой малины.

Тип проекта : OpenSource + Donate
Стадия: Концепция
Разработчики:Ищутся

Составные части :
Shield – Плата для подключения ЧПУ периферии, предполагается использовать идеологию как в RAMPS, с съемными драйверами, так же изначально плат будет две основная и дочерняя, основная будет иметь систему обеспечения питанием + драйверы шаговиков и концевики, втоаря будет заниматься только ШИМ регулированием и датчиками температуры, таким образом можно будет не меняя концепции менять количество экструдеров или осей или количество датчиков температуры.
Firmware – прошивка для двух MCU основной и дополнительной платы, функционал разделен
Software – главная задача это реализация полнофункционального драйвера ядра люникса, для работы с платой, и написание простой проги для парсинга и печати G-кода

На текущий момент планируется функционал :
Экраны и тач панели либо через стандартный интерфейс малины либо через HDMI, а так же все прелести сетевого функционала люниха.
В качестве ОС будет использована официальная версия Ubuntu все остальное будет компилится из исходников, на более поздней стадии стандартный дистрибьютив.
Функционал основной платы :
MCU ATMega 128/256
8 осей (8 шаговиков)
16 конечников для шаговиков
8 аналоговых датчиков, для всяких измерителей типа толщина нити и прочее
8+ необозначенных выходов
8+ необозначенных входов
Функционал доп платы:
MCU ATMega 8…64
6 шимов с PID регулированием один из которых имеет дублирующую развязку под 220 вольт, 3 из которых будут аппаратными ( возможно вообще поставить внешние ШИМы)
6 комплектов аналоговых датчиков для температуры
Дополнительные дискретные входы и выходы , для управления питанием и охлаждением

Общее:
Обмен между малиной и платами происходит по SPI интерфейсу , с использованием всего одного вывода для разрешения приема.
На уровне ОС планируется реализация драйверов ядра . в плоть до виртуального порта с парсером G кода.
По совместимости предполагается ориентироваться на Marlin так как это самый описанный и доступный проект

P.S. Обсуждаем решаем а лучше подписываемся под проектом нужны:
Кодер под люних
Кодер под AVR
Электронщик

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

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

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

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

По мне, так очень важно ответить на вопрос "а зачем?", провести анализ рынка готовых изделий, обсудить концепцию с самого начала. А именно: кому это нужно, кто этим сможет пользоваться и исходя из этого выбирать формфактор проекта. На примере рампс+ардуино:
а) появилась большая (это важно) ниша любительской 3д печати = потребность в продукте "управляющая электроника", которую с лихвой удовлетворяет сейчас Китай
б) есть среда программирования МК arduinoIDE с очень низким порогом вхождения и без необходимости вникания в тонкости работы с МК = возможность создавать гибкие и настраиваемые под себя программные оболочки
В итоге мы получили классическую связку, обладающую двумя основными качествами для массового использования: дешево и просто.
Что я хочу сказать: формат опенсурс тут не прокатит просто потому что маловостребовано, а кушать всем хочется и работать за дарма на энтузиазме нормальный программист или технарь не будет. А без кадров качественный продукт не выпустишь, только костыли.
И да: универсальные вещи всегда хуже чем заточенные под решение одной задачи. Как лыжи: есть для классики и для конька, а вот универсальные и не туды и не сюды, хотя едут.

Faster писал(а): тоесть вытаскиваем всю математику из меги и обслуживание экрана и обслуживание сети и обслуживание файловой системы ..

как пример... у меня вот так... OctoPrint на OrangePI+ 2E (можно обычную PI PC, но просто эта уже была в наличии)
Все файлы хранятся на ней... она же отправляет на печать... работает по wi-fi, которую сама же и поддерживает... + вместо флешки использую EMMC самой апельсины...
Вот и получается то, что Вы и хотели...
32-х битная электроника DUO будет заниматся только печатью того Г-код'а, который ей подсовывает моя апельсина... и нафиг не нужны ни какие экраны и флешки которые суют постоянно туда-сюда чтоб что-то записать на нее, а потом распечатать... все в браузере...

А отдельную мегу на нагреватели / отдельную на шаговики / отдельную на концевики / отдельную еще на что-то (надеюсь правильно понял ваш посыл)... это явно херня откровенная...

Чиффа писал(а): универсальные вещи всегда хуже чем заточенные под решение одной задачи

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

У меня была идея использовать плату на stm32 и рампс (только надо сделать переходник с меги 2560). Есть возможность программировать эти платы через ардуино иде, а значит можно и прошивку портировать.

wolfs_SG писал(а):
Вот и получается то, что Вы и хотели.

неее, тут идея сделать шилд к пи или апельсинке, причем сам микрокомпьютер будет интерпретировать g-код. Тут тонкость в том, что микрокомпьютеры не заточены под системы реального времени.

Не силен в структурах компьютеров и операционных систем, поэтому это мнение, а не утверждение: заставить работать компьютер как микроконтроллер нереально. Операционная система многозадачна и ей плевать, что ваш код нужно исполнять в строгоопределенные моменты времени. Например для перемещения с заданной скоростью надо подавать импульсы заданной частоты. Насколько эта частота будет стабильна в условиях сложной системы приоритетов? Для этого есть МК.

Чиффа, Ты сильно в вопросе не разбираешься ... все делается и собственно контроллер MCU как мега или STM это просто процессор в комплекте с памятью оперативной флэш т епромом ... тоесть это процессор + + + и еще и порты ввода вывода , но посути это тот же компьютер ...

Идея сендвича в том чтобы жестко разделить аппаратку и програмку ... тоесть там где требуется математика все возложить на 32 ато и 64 бита процессор которому эти вычисления так фон ... можно и с енсор вешать и все что хочешь даже музыку слушать и камеру подключит к притеру сразу и еще ресурсов останется дозаднецы

А MCU использовать как платы расширения в компьютере ..

Приехал тут умножитель шины для малинки : В общем это совершенно стандартный расширитель просто паралелит всю шину вот и думаю на его базе вертикально строить платы расширения

Faster, ну, я и не говорил, что разбираюсь
Не видел таких решений, сделал вывод о их невозможности.
Тогда такой вопрос: насколько хватает ресурсов меги? Слышал, что могут притормаживать на больших скоростях в 3d печати. Правда, нет?

Чиффа, Не для этого тема , но помеге ... если чисто 3д печать то роесурс есть но когда касается дело обслуживания дисплеев тонны лишнего кода для совместимости .. то в общем то ресурса нет