Pull to refresh

Comments 39

А вот бонусом было-бы неплохо сборку и демонстрацию работы, самой аппаратной части. :-)
Ну, пока есть только промежуточные видео, снятые в процессе работы над проектом :) В принтер я ее пока еще не интегрировал, жду второй такой комплект, чтобы одну плату можно было вставить в принтер, а со второй продолжать возиться на столе около компа, подключив отладчик.
Вот видео с тестом движения оси — www.youtube.com/watch?v=lr3uIkM4YtM
А вот видео с демонстрацией эмуляции печати — www.youtube.com/watch?v=ob9bVc12w_o
И 20-минутный ролик с демонстрацией интерфейса и пояснениями голосом, по состоянию на начало сентября — www.youtube.com/watch?v=jGwTHx8fFaE :)
Отлично! Ждём продолжения!
Счетчики часов наработки компонентов принтера обновляются в EPROM только по окончании или прерывании печати файла.

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

Статьи потрясающие! Огромная и очень интересная работа проделана, и не менее интересно и тщательно описана. Спасибо за такое увлекательное чтение!
Спасибо за отзыв :)
В случае пропадания питания данные потеряются.

Это да, но я намеренно проигнорировал этот момент. При пропадании питания во время печати потеря пары часов счетчиков будет наименьшей из бед :) Да и случается это достаточно редко, чтобы оказать какое-то влияние, превышающее погрешность :)
Но в принципе можно сделать сохранение во время печати, например, раз в час. Ресурс перезаписи этой EPROM вроде бы позволяет не слишком стесняться в частоте сохранения данных.
Ресурс же только при стирании расходуется. Есть умные алгоритмы записи, уменьшающие его частоту.
Да, есть, но что-то мне претит писать кольцевую запись для этой бздюльки с несколькими сотнями байт данных :)
Наверное, действительно сделаю сохранение счетчиков во время печати каждый час.
Разве нельзя 8 раз писать по одному (разному) биту в один и тот же байт?
Получится та же кольцевая запись, только с битовым, а не байтовым сдвигом :)
Ей проще управлять. Выделяешь 3 байта под локальный счетчик на 24 часа. Когда заполняется — инкриментируешь глобальный. В итоге перезапись памяти не чаще, чем раз в сутки вне зависимости от сценария использования.
Да, о таком не подумал. Спасибо, возьму на заметку на будущее :)
Хотя у той же 24c16 нет отдельной операции стирания, оно производится автоматически во внутреннем цикле записи байта или страницы.
Ну да, решение аппаратно зависимое. Но если честно, я вообще плохо понимаю, как в таком случае сделать «размазывание износа». Нужно же как-то обновлять актуальные адреса или хотя бы инвалидировать старые записи.
Есть метод записи структур (записей) данных по «кругу». В начале каждой записи идет байт (ну или два/четыре) с идентификатором записи. В EPROM выделяется какая-то область, кратная размеру записи. Программа прыгает по записям в EPROM, пока не находит максимальный идентификатор записи, после которого идет пустой блок или запись с меньшим идентификатором (кроме случая перехода от MAX к MIN, например от 255 к 0 при однобайтовом номере). В новой записи идентификатору присваивается значение найденного максимального + 1 и эта запись сохраняется после найденной. И так оно все пишется по кругу в выделенной области.
Ну и чтение актуальной записи происходит так же — ищется запись с максимальным идентификатором, она и считается актуальной.
Как-то отбросил эту идею. Но, видимо, для маленькай памяти преемлема, когда есть ресурсы просканировать всю флэшку.
Ну, всю флэшку и не обязательно сканировать :) Можно хранить «круг» на 5 записей, например. Или на 50. Смотря насколько хочется растянуть ресурс флэшки.
ЗЫ: это не мое изобретение, это давно известный способ экономии ресурса перезаписываемой памяти :)
В какой-то момент возникает желание организовать ротацию целых страниц или их групп, и тогда дело приобретает некрасивый оборот)
Не совсем понял о чем Вы :)
От размера сохраняемых записей скорость работы этого алгоритма не зависит, только от количества в ротации :)
Я пользовался таким способом, вполне быстро работает :) Но смысл в нем есть только если данные пишутся очень часто. Ну, например, если я буду делать возможность продолжения печати после сбоя питания, когда текущее состояние должно сохраняться каждые несколько секунд, то скорее всего этот способ и использую.
И если данные имеют заранее известный константный размер.

Можно поставить на проц микроаккумулятор и делать запись только при пропадании питания (ну и спокойно спать ложиться. может быть, даже получится вообще обойтись без сброса оперативы, если архитектура материнки позволяет радикально урезать потребление). В теории может даже и конденсатора в блоке питания хватить, если быстро все мощные потребители отрубать при просадке глубже определенной, но это не очень надежно.
Даже можно небольшой объем критичных данных (80 байт) хранить в бэкап-регистрах часов, они будут сохраняться и при питании от часов батарейки :)
В данном случае схемотехника материнки совершенно не предусматривает никакого управления питанием, увы.
Но вообще, я согласен, что это всё блажь. В идеале уметь детектировать и корректно обрабатывать power fail.

p.s. Также помимо времени печати я бы вел статистику времени простоя.
Вообще есть мысль попытаться сделать продолжение печати после сбоя питания. Сначала я считал, что это невозможно. Если на платформе уже имеется частично напечатанная модель, то платформа просто не сможет опуститься к концевику — она упрется напечатанной частью в дисплей. А значит не сможет и определить свое реальное положение, чтобы продолжить печать ровно с того места, где она была прервана. Но потом мне подсказали мысль, что в случае сбоя по питанию платформу можно хомить по верхнему концевику. Это, конечно, не так точно, но в большинстве случаев должно позволить продолжить прерванную печать :)

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

Вот это уже достаточно хорошая причина, согласен :)
А. Я назвал дисплеем тачскрин. Хотя вряд ли он должен ломаться.
А-а, ну интерфейсный дисплей тоже живет очень долго. Может только уплывать тач, но его можно перекалибровывать.
Есть драйвера tmc2209 и похожие, там есть опция определения фазы обмотки в которой находится мотор.
При хоминге и срабатывании датчика определяется фаза мотора и мотор доворачивается в заданную целую фазу. Получается что при хоминге вал мотора всегда в одном положении в полной фазе.
Повторяемость максимально допустимая и определяется точность мотора. Это позволяет снять проблему рестарта печати при потере питания.
Тут драйвер впаян в плату, так что заменить его без паяльника и перерезания дорожек не выйдет.
Но главное — проблема в том, что после того, как часть модели уже напечаталась, хомиться стандартно по нижнему концевику нельзя, иначе платформа раздавит напечатанным куском модели дисплей засветки. А хомиться после отключения питания придется в любом случае, т.к. неизвестно в каком положении остался двигатель после пропадания питания.
Ну на будущее, будете знать что есть удобные драйвера.
А вобще не обязательно хомиться по нижнему.
При старте можно хомиться по верхнему, а потом опускаться в рабочее положение.

Вот для примера повторяемость положения после парковки в полной фазе обмоток. Тоесть парковка всегда в одном и том же положении шага.

Парковка между измерениями безсенсорная, не люблю концевики :)

Ну и просто видео про безсенсорную парковку при упирания каретки в палец :) но с винтом по Z и экраном так не прокатит, с винтом слишком большое усилие в экран будет.

Ну на будущее, будете знать что есть удобные драйвера.

Я знаю о них :)
При старте можно хомиться по верхнему, а потом опускаться в рабочее положение.

Можно, конечно, но верхний получается не таким точным. Температура изменилась на 5 градусов и стальной винт оси Z при длине 200 мм удлинился на почти 0.02 мм из-за теплового расширения — а это уже почти толщина слоя.
но с винтом по Z и экраном так не прокатит, с винтом слишком большое усилие в экран будет.

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

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

Да, я выше писал об этом. Просто это не слишком критичные данные, редкая потеря части данных не страшна. А батарейка изначально на плате не стоит, это я на свою плату сам ее прилепил :)
Отличная статья! В настройки можно вынести такой параметр, как время засветки слоя. При замене полимера на более или менее светочувствительный, эта фича сможет здорово помочь
Все настройки печати — время паузы, время засветки, высота и скорость подъема/опускания платформы — будут доступны в настройках из окна печати файла :) Я даже думаю добавить туда отключение антиалиасинга и сохранение всех внесенных изменений обратно в файл :)
Присоединяюсь к восторженным отзывам: прекрасная статья с превосходной подачей!
Andy_Big, надеюсь Вы отправили её на конкурс Хабра «Технотекст 2020»?
У Вас явный талант, пишите ещё!
На сегодня мой лимит заряда для голосования исчерпан, но завтра обязательно поставлю плюс в Вашу карму.
Вдогонку:
Да, кстати, дизайнер из меня еще более фиговый, чем программист...
Не скромничайте, замечательный дизайн, на мой взгляд.

В тексте было несколько ошибок — направил их Вам через Ctrl-Enter.
В тексте было несколько ошибок — направил их Вам через Ctrl-Enter.

Спасибо, обязательно исправлю :)
Спасибо большое за отзыв :)
надеюсь Вы отправили её на конкурс Хабра «Технотекст 2020»?

Я не настолько наглый :))))
Sign up to leave a comment.

Articles