Форум РадиоКот

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

bitwood
Если уже занялся, то лучше на мой взгляд (писал раньше), чтобы стол крутился, как запись лазерного диска.
2 репера всего нужно будет, это центр платы (отверстие), на него сажаем плату и еще один по краю платы, например слева внизу. Дисбаланса не будет, плата же по центру стоит. Да даже если и будет дисбаланс, ни чего страшного.

Думал думал, насчет вращающегося стола с платой, это только на первый взгляд кажется проще, дело в том что фокус лазера надо удерживать по высоте с точность не хуже 0.025мм, а заготовки обычно более кривые как их на растягивай, надо прижимать к стеклу и через него просвечивать, причем надо иметь возможность двусторонней засветки, т.е. надо сжимать плату вакуумом между двух стекол, причем платы могут быть сильно разные, от 0.2мм до 2мм. Да можно таки сделать стеклянный вращающийся стол, но конструктивно это будет гораздо труднее чем два одинаковых блока экспонирования с стеклянной гранью каждый между который просто зажимается плата.
И если цент вращения будет в пределах платы то это даст огромную неравномерность удельной мощности засветки, у центра линейная скорость будет в два порядка меньше чем на периферии. Мощность можно скорректировать, но скорость нельзя, поэтому эта система будет работать не так быстро как было бы возможно.
Сейчас конструкторская мысль устаканилась на вращающемся на поверхности прижимающего стекла диске, ось которого линейно проходит вдоль платы. Это просто и избавляет от танцев с бубном при выставлении строной параллельности плоскости вращения объективов и платы. Т.е. плата с одной стороны стекла - объективы с другой, расстояние жестко фиксировано. И не требуется тяжелая рама, нагрузка небольшая поэтому для поднятия диска над стеклом на аэростатике достаточно аквариумного насосика.

Сделать сложно - не наша цель, надо добиться требуемых характеристик наиболее простыми способами.

А наш критик из Казани как всегда жесток и объективен
Уж точно никто не будет учитывать потребности отдельных участников в радиусных линиях растра и одновременной обработки двух файлов и коррекции по всем отверстиям.

bitwood писал(а):наш критик из Казани как всегда жесток и объективен

Это не жестокость. Это, надеюсь, здоровый скептицизм и трезвый взгляд на реальности жизни. Такие проекты поднимаются или на диком (в хорошем смысле) "интузазизме", или за хорошую оплату. Энтузиаста можно ждать долго. Наиболее реалистично сбрасываться и заказывать - я в начале марта заикался об этом, но желающих не нашлось.

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

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

Размер каждого из двух блоков 300х550х150мм. Плата будет прикладываться к грани 300х550мм. Просто квадратный закрытый ящик, можно будет использовать и по одному, засвечивая две разные платы независимо. Т.е. идея именно в том что диск Ф250мм должен скользить по листу стекла и это решает многие проблемы.
ЗЫ
Даже появится Автор, то он наверняка не станет внедрять радиусные линии и поддержку двух файлов.

Можно разбить задачу на части.
Отдельно - парсер герберов и перевод в растр,
возможно с выравниваем по реперам.
Отдельно контроллер, кинематика, математика.
У пользователя selenur , уже есть зачатки этого парсера,

Спойлер

http://radiokot.ru/forum/viewtopic.php?f=8&t=143139

он его точит под векторную систему (cnc), но тот же парсер
можно переделать и под растр.
Если каждый будет изобретать станок под себя, будет долго.
У кого то получиться, кто то бросит.
Софт желательно писать на чем то общедоступном - ни QT ни форт,
а например C#, java, rad studio.
Можно даже отдельными модулями сделать. Запускаешь экзешник с параметрами,
и гербер конвертиться в растр, или в G-code, в зависимости от параметров.
Другой экзешник, отправляет растр на печать (либо на HLDI, либо на роторную установку, либо на полигональный принтер).
Во всяком случае, HLDI позволяет печатать bmp файлы, и отдельный конвертер вполне увяжется с ним.
В общем мое мнение - установка должна быть модульной.

Чем Qt не нравится? Она вроде открытая для open source проектов (lgpl).
И имхо такие проекты надо делать на C++.
Весело будет, если C# или Java захочет посреди передачи строки в контроллер мусор пособирать.
Я бы софт написал, но станок раньше осени у меня не будет времени сделать.

tihohod писал(а):Чем Qt не нравится? Она вроде открытая для open source проектов (lgpl).

Завтра придет другой автор, и придется ему портировать на другую платформу.
На C++ согласен, но QT несколько специфичен.

Ну так Qt кросплатформенная и есть. Хотя мне ближе wxWidgets.

Во первых: Что касается C# то программы которые я делал, работают с winXP до win10 и под линуксом, через вайн. 99% пользователей моих программ не знакомы с линуксом в принципе.
Во вторых: Нужно отделить мухи от котлет, QT это не язык программирования, а программа для написания кода на языке Си, Qt нормальная среда разработки, мульти-платформенная, по удобству разработки с visual studio конечно не сравнится, но для небольших программ вполне пригодна.
В третьих: человек который согласился вам написать софт, не может хорошо владеть всеми языками, и средами разработки, и время разработки сильно может увеличиться, если он будет делать это в незнакомой, или малознакомой среде.
В четвертых: C# хорош очень сильно тем, что использует microsoft framework в котором есть сотни тысяч готовых функций для работы с изображением, математикой и прочим, что позволяет бросить все силы на разработку именно интерфейса и архитектуры программы, и не писать с нуля, или искать готовые исходники с кодом, как это иногда приходится делать на Си, но этот жирный плюс имеет и оборотную сторону, что требует пользователю у которого меньше чем windows7 выкачивать и ставить этот framework.
фуххх вроде выговорился

tihohod писал(а):Весело будет, если C# или Java захочет посреди передачи строки в контроллер мусор пособирать.

тут такое дело: единственная критичная к быстродействию часть - то, что называется motion control, т.е. чтение энкодера, непосредственное управление моторами и рабочим органом (==лазером). Это можно и в данном случае нужно делать на стороне контроллера в любом случае. А пользовательский интерфейс и закидывание паской задания в буфер контроллера не так чтобы требовательны. В природе вообще существуют браузерные вебморды для управления мозгами станков (для smoothieware и machinekit точно, тако же для ардуинских 3д принтеров), и какбе ничо, достаточно, чтобы осями подрыгать и файл отправить на исполнение.

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

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

Добавлено after 3 minutes 18 seconds:

selenur писал(а):QT это не язык программирования, а программа для написания кода на языке Си, Qt нормальная среда разработки

так-то Qt - это набор библиотек для C++. Не программа и не среда разработки.

selenur писал(а):В четвертых: C# хорош очень сильно тем, что использует microsoft framework

зависит от) я бы наоборот сказал, что он этим плох)

selenur писал(а):в котором есть сотни тысяч готовых функций для работы с изображением, математикой и прочим

сотни тысяч библиотек с функциями есть и для C, и для C++, и для явы, и для питона не показатель

Все функции framework собраны во едино, и есть подробная документация msdn. Для подключения библиотеки достаточно прописать одну строку.
В си вначале нужно найти в интернете, их может быть не мало, но как понять какую использовать? потом проанализировать код, как ей пользоваться, если нет примеров или документации.
На скорости разработки всё это сильно сказывается, когда мне приходится получить стабильный код за короткое время, т.к. у всех всёгда так горит, чтоб прям срочно.

Манипуляциям с гербером в управляющей программе делать нечего.

Ну а как же идея поворота и сдвига по реперным точкам, чтобы растр формировать под конкретное расположение платы на столе?
В текущей реализации, как я понял, растр делается на PC и запихивается в контроллер построчно, что имхо правильно. Без этого пришлось бы ставить или доп. озу под весь растр платы или брать контроллер с большим флешем под код парсера гербера.

tihohod писал(а):Ну а как же идея поворота и сдвига по реперным точкам, чтобы растр формировать под конкретное расположение платы на столе?

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

tihohod писал(а):В текущей реализации, как я понял, растр делается на PC и запихивается в контроллер построчно, что имхо правильно

но передавать и хранить в контроллере одну строку - уже неправильно. Даже у обычного grbl на сравнительно тупой ардуйне есть буфер команд

arkhnchul писал(а):единственная критичная к быстродействию часть - то, что называется motion control, т.е. чтение энкодера, непосредственное управление моторами и рабочим органом (==лазером). Это можно и в данном случае нужно делать на стороне контроллера в любом случае.

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

позвольте и мне слово держать
По поводу M$ FrameВорков и прочих ДыркоНетов, тут я против

Во-первых прозвучала здравая мысль о том, что нужна веб морда - это есть хорошо в том плане, что морда будет работать везде, в том числе есть возможность работать в сети - это раз, во вторых УП можно отдать только командные функции,аля это уже будет не УП а кнопочник(как интерфейс, будь он на Qt или вообще кнсольное приложение) то есть получаем 3х звенную структуру:
Морда(Qt/или же на каком нибудь билдере/Командер текстовый)
Сервер(то что принимает настройки, данные для печати[вектор|Растр|G-code|принтерный формат, забыл как называется],команды, следит за оборудованием, Лазер-часами, читает диагностику со станка, предоставляет веб-интерфейс, который может так же принять какой нить файлик)
так же сервер посылает команды на станок и заполняет буфер печати. буфер нужно реализовать таким образом, что если вдруг в сервер попала сосулька, станок при посторном включении сказал серверу где он остановился, и была возможность продолжить печать, это важный момент в плане экономии времени и ресурсов.
Сам станок/принтер/гравер, как хотите. принимает настройки от сервера, принимает данные для печати в буфер, разумеется в буфере нужен какой то индекс, чтобы была возможность продолжения печати после аварийного останова сервера.

Что мы имеем, : связь по Ethernet - сам по себе интерфейс стандартизован, хорошо описан, есть описание протоколов. что нам даёт - шировкие возможности по модульности системы, производительный канал связи, масштабируемость.
разделение на интерфейс, обработчик и исполнитель

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

По поводу модульности Сервера, - всеми лапами и хвостом ЗА.
Парсеры, конверторы, вычислители(можно же печатать как линейно, подуге, полосами, диагналями, вектором) - всё в отдельные модули. если идёт отладка одного модуля, она не мешает работу линейной печати. и обновляется модуль а не вся программа. если отлажен модуль печати, то пофигу какие ошибки в парсере Gerber, это проблемы парсера. к тому же получится так, что если есть спец по печати на дуге - он занимается своим модулем, если есть спец по сетевым протоколам - он занимается проблемой передачи данных между звеньями, ни кто не кому не мешает. нужно забыть про монолитность и реализовывввать модульную структуру как ПО так и аппаратной части.

От себя могу предложить работу по коммуникации по сетевому интерфейсу, при наличии свободного времени(желание есть и большое).

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

ну или можно каждому идти своим путём , что разумеется малоэффективно.

ЗЫ
БЫл и есть такой принтер KIPCON, принтер промышленный формата A0, разработки 20 летней давности имел возможность с ним работать. дак вот там была реализована такая система принтер -[scsi]- сервер win2000(сервер печати) - куча ПК в промышленной сети. Что хочу сказать. Железка была разработана 20 лет назад,тогда ни кто не знал что понапридумывают мелкомягкиеи сообщество, и по сей день с любой машины(форточки/линукса), он может корректно принимать данные на печать, единственное что пришлось запросить написание драйвера печати на win7для клиентских машин. поэтому модульность системы это правильно, да это сложнее, но возможностей гораздо больше, можно реализовать разные методы и способы печати.

arkhnchul писал(а):как будто нет библиотек для манипуляции теми же герберами

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

Коллеги! Кто может провести ценный научный эээксперимент? Надо выяснить насколько стекло гасит УФ лазер, т.е. засветить фотомаску частично напрямую, частично через кусок обычного оконного стекла толщиной 4...6мм, чтобы оценить разницу. Ну очень надо для дела!

Ну а насчет софта - не ничего лучше просто составленной программы на Си, хотя не все это понимают