Лазерная установка для засветки фоторезиста от AlphaCrow

[alex01981]

rv3bj писал(а):

Позиционирование будет происходить также как и сейчас с использованием компьютера. Я не говорил, что на установке можно будет и разводить и экспонировать платы. Компьютер всегда будет нужен для разводки, получения гербер файлов и создания .bmp файлов. Далее .bmp будет загружаться на SD карту и можно будет стартовать экспонирование. На первом этапе планируется загружать информацию на SD с помощью РС. В дальнейшем можно просто использовать интерфейс wifi на ESP32. Это не является первоочередной задачей. В общем аналогия с 3D принтером. Мы ведь разрабатываем дизайн в Компасе например. Затем формируем STL файл и переносим его на флешку и потом стартуем печать.

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

[rv3bj]

alex01981 писал(а):

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

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

Добавлено after 1 hour 39 minutes 52 seconds:

Seriyvolk писал(а):

По поводу отказа от ПИД-ов: моё мнение, что делать этого всё же не стоит.

Эта часть задачи, на мой взгляд, не является критической т.к. можно вполне обойтись другими средствами. Например просто увеличить размеры портала при необходимости засвечивать платы большого размера.
Я хочу объяснить свою позицию по всем вопросам данного проекта. Читая форум я вижу, что проблема с пропуском строк и остановками каретки в крайних положениях до сих пор у кого-то присутствует.
Вот я и решил попробовать свои силы. Сразу оговорюсь, что я не программист, я - железячник, немного умеющий программировать микроконтроллеры. Мне 76 лет. Для меня не стоит задача самоутверждения в новых областях. Я просто хочу попытаться помочь сообществу решить данную проблему. Я не беру на себя никаких обязательств. Как я и обещал, все мои наработки по данной теме будут открыты, так что любой желающий сможет использовать их для своих возможных усовершенствований.
Для программирования ESP32 Будет использоваться Arduino, для STM32 - CubeMX, CubeIDE и Keil.

[alex01981]

rv3bj писал(а):

Целью данной задачи является отказ от использования связи с компьютером только на этапе засветки фоторезиста. Ведь именно эта часть имеющегося процесса может работать не очень стабильно из-за невозможности обеспечить взаимодействие в реальном времени, используя Windows.

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

[rv3bj]

Спасибо за поддержку. Будем пробовать.

[susl]

rv3bj, забудьте про ардуино при обработке прерываний от энкодерной ленты, да и вообще при обработке любых прерываний.
Не удивительно, что у вас пропуски. С задачей чтения энкодера легко!!! справляется MEGA8 на частоте 8 Мгц, но писать надо на АСМе.
esp32 ... даже не знаю, должен тоже справиться. Ну по идее... с другим ПО. Если хотите могу поделиться кодом на МЕГУ8, сделаете
на макетке, там надо чип и пару резисторов и конд., потестите Энкодер.

[rv3bj]

susl писал(а):

rv3bj, забудьте про ардуино при обработке прерываний от энкодерной ленты, да и вообще при обработке любых прерываний.
Не удивительно, что у вас пропуски. С задачей чтения энкодера легко!!! справляется MEGA8 на частоте 8 Мгц, но писать надо на АСМе.
esp32 ... даже не знаю, должен тоже справиться. Ну по идее... с другим ПО. Если хотите могу поделиться кодом на МЕГУ8, сделаете
на макетке, там надо чип и пару резисторов и конд., потестите Энкодер.

susl, а где вы увидели, что я использовал ардуино для обработки прерываний в STM32 от энкодерной ленты? Вы все-таки внимательней читайте. Я написал, что на STM32 у меня нет никаких пропусков. Для программирование STM32 использовался Keil. Arduino использовалась для программирования ESP32. При проверке возможности обработки прерываний от энкодера в ESP32 появились пропуски. Было решено далее не пытаться решить это и перейти на STM32 в контроллере установки. ESP32 будет использоваться как управляющий контроллер верхнего уровня. Для его программирования будет использоваться ардуино. На ESP32 будет SD card reader, графический дисплей с тачскрином. В дальнейшем будет поднят WIFI. Кстати предложение забыть про обработку любых прерываний на ардуино звучит весьма странно. Возможно при программировании АТМеги могут быть какие-то ограничения. Но я давно не использую эти контроллеры, а ардуино сейчас поддерживает работу и с современными 32 битными контроллерами. Поддержка прерываний в ардуино есть и она работает. Писать на ассемблере я начал еще с середины 80-х годов прошлого века. Как пример могу привести написанный мной в соавторстве с Барчуковым пакет Микрон для компьютера РАДИО-86РК. Пакет включал тектовый редактор, ассемблер, дизассемблер, интерпретатор Бейсик. Все это писалось для Intel 8080.
Сейчас совсем другое время...

[susl]

Ну а второй уровень - не усложнение ли это???

[rv3bj]

susl писал(а):

Ну а второй уровень - не усложнение ли это???

Согласен - усложнение аппаратное. Программное для меня - упрощение. Железки сами по себе стоят недорого.
В дальнейшем кто захочет может упростить. Код будет открыт.

[susl]

А Какой уровень будет управлять лазером? верхний (esp) или нижний (stm)?

[Ruzik]

У меня плата от Рузика (если он не против)..

Да о чем речь.

Вложения

2021_HLDI .zip

(855.05 KiB) Скачиваний: 261

[rv3bj]

susl писал(а):

А Какой уровень будет управлять лазером? верхний (esp) или нижний (stm)?

Нижний конечно. Верхний посылает нижнему в буфер строки байты из растра, считанного из SD карты. Нижний по прерываниям от каждого перепада энкодеров считывает бит из буфера и если он 1, то зажигает лазер. Мощность засветки поначалу будет определяться балластным резистором. В дальнейшем будет регулироваться или таймером или шимом. В общем как сделано в оригинале. У меня пока нет оригинала, поэтому к сообществу есть просьба. Если у кого-то есть двухканальный осциллограф, а лучше логический анализатор, то подключите его к установке. Так чтобы первый канал и второй каналы были подключены к выходам энкодера, а третий к управлению лазером. Снимите трассы при различных уровнях засветки.
Кстати было бы интересно получить информацию, предаваемую от компа к оригинальной установке. Это проще всего сделать на ком порту каким либо сниффером. Это позволило бы просто повторить имеющийся протокол обмена. В таком случаю верхний уровень будет просто эмулировать компьютер и никакая доработка софта нижнего уровня не потребуется.
Насколько я помню SDimok так и писал свой верхний уровень, предварительно сняв сниффером трассы. Я к нему обратился за этими материалами, но он почему-то не отвечает. Наверное занят.
Конечно проще все это сделать на оригинальной проге верхнего уровня, работающей через ком порт. Просто сниффер для последовательного канала гораздо проще чем для USB.

[susl]

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




И поимеете все те же ошибки

[rv3bj]

susl писал(а):

И поимеете все те же ошибки

Ошибки от протокола не зависят.

[iliasam]

По поводу ошибок при передаче данных.
В своем варианте станка я реализовывал метод засветки, в котором мастером передачи данных является контроллер.
В котроллере при этом в ОЗУ выделены два буфера для хранения данных строк (та, что рисуется, и та, что заполняется к ПК).

Передача данных выглядит примерно так:
1. ПК отправляет на контроллер команду - "запуск экспозиции", в ней передаются различные параметры изображения, в том числе - количество строк. После этого контроллер сам становится "мастером" шины, то есть может отправлять запросы на ПК.
2. Если хотя бы один буфер контроллера пуст, контроллер отправляет на ПК запросы - "Передать данные строки номер N".
3. ПК, получив запрос "Передать данные строки номер N", отправляет на контроллер нужную строку.
4. Если контроллер за определённый промежуток времени не дождался заполнения нужного буфера своего ОЗУ, то он отправляет запрос на ПК "Передать данные строки номер N" еще раз.
5. Если буфер заполнен, то он выводится на экспозицию.
6. Когда строки экспозиция завершена, буфер помечается, как пустой, счетчик отрисованных строк увеличивается.
7. Когда все строки отрисованы, экспозиция прекращается, контроллер перестает быть "мастером".

Таким образом, всем процессом экспозиции управляет контроллер, который точно знает, какие строки он отрисовал, и шлет соответствующие запросы на ПК.
При нарушении связи контроллер просто еще раз отправляет запрос на передачу нужной строки. Экспозиция в этот момент приостанавливается, но это никак не влияет на качество изображения.

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

[alex01981]

Ну тогда проще реализовать флаг готовности, что контроллер готов к приёму новой строки. Отрисовал строку послал команду что он её отрисовал.

[iliasam]

Так тоже можно сделать, только важно, чтобы контроллер передавался номер отрисованной строки.
Но что ПК должен делать, если он не получил ответ от контроллера?
И причин может быть две - данные строки не дошли до контроллера, и строка не отрисована, либо - данные дошли, строка отрисована, но подтверждение не дошло до ПК.
ПК в таком случае может отправить дополнительный запрос - "передать статус текущей строки", контроллер отправляет ответ, и ПК по нему решает - отправлять данные заново, или начинать экспозицию следующей строки.

[iliasam]

UART, особенно через USB, особенно в Windows - это явно не та вещь, которая будет работать продолжительное время со 100.00% надежностью.
Так что лучше перебдеть, и реализовать качественную коррекцию ошибок в протоколе.

[alex01981]

iliasam писал(а):

UART, особенно через USB, особенно в Windows - это явно не та вещь, которая будет работать продолжительное время со 100.00% надежностью.
Так что лучше перебдеть, и реализовать качественную коррекцию ошибок в протоколе.

HLDI давным давно работает напрямую по USB без UART.

[pvu]

Ни одна, действительно работающая, вещь не полагается на 100% надёжную связь и отсутствие сбоев. Просто протоколы должны предусматривать восстановление работоспособности из сбойных состояний. А протоколов намечается минимум 2. И повторять протокол hldi не логично, это протокол общения с нижним уровнем (НУ). А между программой (ВУ) и есп32 (СУ) другие события по идее. Вот с разработки функциональных требований и протоколов надо бы и начинать и не здесь, а на каком нибудь гитхабе. И вообще даже в нынешней реализации никаких требований к реалтаймовости ОС нет. Не стоит использовать этот тезис для определения пригодности ОС. Будет софт ВУ собираться под любую популярную ОС - прекрасно.
Переделывать установку по приколу - норм! Из-за пропуска строк вот это странно. Кто проверил тезис о влиянии висящих ног неподключенного UART?

[Gennadii40]

Давненько задумывался над таким станочком. Даже собрал все запчасти, да ума не хватило написать программу. НЕ УМЕЮ потому что. Пытался научиться, да видать мозги уже не те. Мне 62 уже. Ну да ладно... А тут готовый проект!!! Буду делать значит. Перечитал почти все страницы. Было очень интересно отследить все перипетии проекта. Хочу вставить свои 5 копеек в проект. Тут как то обсуждался вопрос насчет массы каретки и проблем с выбегом. Там сам лазер, основание и камера. Ну так вот, предлагаю камеру сделать сьемной. В процессе печати камера не участвует совсем. Болтается без дела. Применяется только вовремя установки заготовки по реперным отверстиям. После камеру можно отвести по направляющей и начинать печать. Лазер и камера могут прикрепляться между собой с помощью небольшого магнитика. После облегчения выбег каретки естественно уменьшится. Уменшится и перегрев двигателя.