Насколько там нужны именно аналоговые входы? Ибо для считывания данных чудится что границы сработки диодов проще было бы подстроить доп.резисторами, а в прошивке сделать обработку прерываниями
Опрос ножек в одном цикле с делеем - тоже странновато выглядит
Если честно, то я не уловил необходимости складывать все данные в бд, а потом грузить ее выборками и апдейтами, причем с locked_until (выше уже писали про for update skip locked, хотя это решение тоже имеет подводные камни).
На мой вкус бд имеет смысл только для отложенных сообщений, и приправляется сверху exponential backoff и, при необходимости, лимитом на количество попыток. И ещё можно подумать и переложить очередь ретраев на редис - он с этим работает сильно быстрее чем постгря
Оно умеет в несколько разных режимов сна, а на платах обычно выведена не только ножка с +5, но ещё и +3.3, которая идёт прямо в чип.
Другое дело что с активной вафлей аппетиты у есп вроде как до 100мА (по другим данным- 300 и выше), так что кажется что батарейки может и не хватить. Ещё момент - при напряжении ниже какого-то порога запись во флеш может этот самый флеш убить
Создадим интерфейс UserProvider, в котором будет метод User()
И всё равно у пакета осталась связка со storage/users - хотя бы потому, что там описан возвращаемый тип данных.
Допустим, мы хотим передать вместо сущности Postgres сущность Redis. Чтобы соответствовать данному интерфейсу, нам придется реализовать все его методы, даже если они не используются.
Хм... storage/users/postgres, storage/users/redis... на мой вкус так и задумывалось, что все эти сущности реализуют интерфейс storage/users.Storage. Или, как минимум, в storage/users должно быть два интерфейса - Data и, например, Cache. Тогда users/postgres и users/mysql реализуют интерфейс Data, а users/redis - интерфейс Cache. А иначе может быть как-то ни разу не очевидно зачем нужна такая вот странная структура
users.go: Файл с реализацией интерфейсов для работы с пользователями.
Разрешите доколебаться: это не реализация, это описание
По опыты работы с "моделью чпу фрезера 1:43" типа cnc3018:
Совет #1: делать не на шариковых подшипниках, а на пластиковых скольжения. Может это имеет отношение только к фрезерным станкам (пыль, вибрации, ...), но пластик требует сильно меньше ухода и намного легче меняется
Совет #2: опоры стола делать не по краям, а сместить чуть ближе друг к другу (не вспомню точный термин, но вроде это из техмеха, задача о минимизации прогиба листа)
Совет #3: сделать ручную подстройку высоты лазерной головы при помощи винта и какого-нибудь элемента скольжения (да хотя бы те же валы с короткими подшипниками)
Совет #4: (у самого пока руки не дошли, но собираюсь) использовать не grbl, а FluidNC на esp32
Канал результатов в последнем примере (другие не смотрел) можно делать небуферизованным - это сэкономит немного памяти.
Для объединения ошибок есть errors.Join
Для вычисления "время с момента Х" есть time.Since
При заранее известном размере пула проще сразу запустить Х рутин, в которых читать канал с урлами, ибо запуск рутин тоже не бесплатная операция, а их тут по одной ка каждый урл
Выше по комментариям был вопрос про лазерные станки и пара комментариев про гидроабразивные. Вкратце - используются, но стоят совсем не хоббийных денег.
Думаю в масляной/водяной ванне можно использовать и фрезерные станки с алмазными фрезами, но это очень медленно
Если "онлайн карта" - это тайловая (спутник, например) - то автор статьи уже ответил - в целом османд может их скачивать и показывать в оффлайне. Но, на мой вкус, именно для скачивания карт и рисования треков удобнее пользоваться более специализированными инструментами, например - сас-планета
Для создания - в настройках "новый профиль" и тип навигации выбрать нужный.
А ещё можно пойти по пути, указанному на видео, только не сращивать треки, а для каждого прогона между точками выбирать тип навигации.
Ну т.е. выбрать начальную точку, для первой линии тип навигации, например, автомобиль. Потом переключить тип навигации на "линия, только для следующего сегмента" и выбрать вторую точку. Повторять до получения желаемого трека )
Насколько там нужны именно аналоговые входы? Ибо для считывания данных чудится что границы сработки диодов проще было бы подстроить доп.резисторами, а в прошивке сделать обработку прерываниями
Опрос ножек в одном цикле с делеем - тоже странновато выглядит
Мде. А потом у людей возникает вопрос "что такое переменная и зачем оно надо".
И тупняк на собеседовании в качестве ответа на вопрос с переполнением типа
Если запрос возвращает ошибку, то конкретное сообщение кафки уходит в очередь ретраев (редис или постгря, или отдельный топик - не особо важно).
Меня смущает сама идея организации ещё одной полноценной очереди из постгри.
Если честно, то я не уловил необходимости складывать все данные в бд, а потом грузить ее выборками и апдейтами, причем с locked_until (выше уже писали про for update skip locked, хотя это решение тоже имеет подводные камни).
На мой вкус бд имеет смысл только для отложенных сообщений, и приправляется сверху exponential backoff и, при необходимости, лимитом на количество попыток. И ещё можно подумать и переложить очередь ретраев на редис - он с этим работает сильно быстрее чем постгря
Оно умеет в несколько разных режимов сна, а на платах обычно выведена не только ножка с +5, но ещё и +3.3, которая идёт прямо в чип.
Другое дело что с активной вафлей аппетиты у есп вроде как до 100мА (по другим данным- 300 и выше), так что кажется что батарейки может и не хватить. Ещё момент - при напряжении ниже какого-то порога запись во флеш может этот самый флеш убить
Беларусы несколько удивились этому комментарию, например.
Импульсный преобразователь, например. Но для ручной пайки в ограниченном пространстве совсем там слишком много обвязки.
И всё равно у пакета осталась связка со storage/users - хотя бы потому, что там описан возвращаемый тип данных.
Хм... storage/users/postgres, storage/users/redis... на мой вкус так и задумывалось, что все эти сущности реализуют интерфейс storage/users.Storage. Или, как минимум, в storage/users должно быть два интерфейса - Data и, например, Cache. Тогда users/postgres и users/mysql реализуют интерфейс Data, а users/redis - интерфейс Cache. А иначе может быть как-то ни разу не очевидно зачем нужна такая вот странная структура
Разрешите доколебаться: это не реализация, это описание
Да, если три фазы - то у 8266 банально не хватит аналоговых входов. Можно, наверное, поизвращаться и как-то три zmpt на один вход коммутировать, но...
А за ссылку статью спасибо, интересно
А зачем пихать два мк, если 8266 отлично справится и самостоятельно?
Каст интерфейса без проверки... А может не надо так, уважаемый автор..?
Если стол из алюминиевого профиля и чисто под лазер - то сдвиг опор может и не актуален.
По опыты работы с "моделью чпу фрезера 1:43" типа cnc3018:
Совет #1: делать не на шариковых подшипниках, а на пластиковых скольжения. Может это имеет отношение только к фрезерным станкам (пыль, вибрации, ...), но пластик требует сильно меньше ухода и намного легче меняется
Совет #2: опоры стола делать не по краям, а сместить чуть ближе друг к другу (не вспомню точный термин, но вроде это из техмеха, задача о минимизации прогиба листа)
Совет #3: сделать ручную подстройку высоты лазерной головы при помощи винта и какого-нибудь элемента скольжения (да хотя бы те же валы с короткими подшипниками)
Совет #4: (у самого пока руки не дошли, но собираюсь) использовать не grbl, а FluidNC на esp32
Канал результатов в последнем примере (другие не смотрел) можно делать небуферизованным - это сэкономит немного памяти.
Для объединения ошибок есть errors.Join
Для вычисления "время с момента Х" есть time.Since
При заранее известном размере пула проще сразу запустить Х рутин, в которых читать канал с урлами, ибо запуск рутин тоже не бесплатная операция, а их тут по одной ка каждый урл
Кстати да, это первое о чем подумалось.
Четыре оси (xyz + поворот) М03/04 Sxxx - подача и отвод припоя, M07/08 - продувка.
Плюс, если поизвращаться, можно попробовать в зону пайки тыкать термопарой и (наверное) решить проблему с зажевыванием припоя на полигонах.
Выше по комментариям был вопрос про лазерные станки и пара комментариев про гидроабразивные. Вкратце - используются, но стоят совсем не хоббийных денег.
Думаю в масляной/водяной ванне можно использовать и фрезерные станки с алмазными фрезами, но это очень медленно
Если "онлайн карта" - это тайловая (спутник, например) - то автор статьи уже ответил - в целом османд может их скачивать и показывать в оффлайне.
Но, на мой вкус, именно для скачивания карт и рисования треков удобнее пользоваться более специализированными инструментами, например - сас-планета
Будет, но очень криво.
Так что, повторюсь, такие треки лучше отрисовать на осм.орг, и тогда навигация будет работать корректно
Со своей колокольни я б, наверное, гуглил в сторону отдельных приемников, подключающихся по otg/bt...
Для создания - в настройках "новый профиль" и тип навигации выбрать нужный.
А ещё можно пойти по пути, указанному на видео, только не сращивать треки, а для каждого прогона между точками выбирать тип навигации.
Ну т.е. выбрать начальную точку, для первой линии тип навигации, например, автомобиль. Потом переключить тип навигации на "линия, только для следующего сегмента" и выбрать вторую точку. Повторять до получения желаемого трека )