Перейти к содержанию

    

kolobok0

Участник
  • Публикаций

    1 208
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о kolobok0

  • Звание
    практикующий тех. волшебник

Контакты

  • Сайт
    http://www.6461530.ru
  • ICQ
    0

Посетители профиля

5 308 просмотров профиля
  1. видел и такие, и немного другие. через ключи подключают инверторно ёмкостную нагрузку и вход АЦП мк (через согласующую развязку и иже). получается что с мк можно задавать разную частоту переключения. По мне - вот этот подход даёт шире манёвр при эксперименте. я смотрел уже готовые буржуинские платы парогенераторов. можете туда глянуть. там очень активная среда (не только вода бывает в баке). по поводу перходников на большое давление - лучше всего то, что под это заточено... например свечи автомобильные эээээ наверное дизельные если 25атм...
  2. ну вот это не понятно. (может не так понял я - хз). обычно, при решении любой задачи изучается для начала ранее накопленный опыт человечеством. а уж потом, пропуская через свои знания чужие решения - либо учишься учитывать те аспекты которые пробежали мимо, либо понимать что ты первый обратил внимание на что то новое... возвращаясь к баранам. как тут сказали выше - как правило используют не один штырь. но...(куда уж без него? :) ) подают не одно полярное напряжение. либо это переменка с БП, либо своя схема переключения полярности - по разному бывает. и чем агрессивнее среда и ниже требования к материалов зондов - тем, как я понимаешь это актуальней. даже при микро токе ключа сработки. как то так (круглый)
  3. Нет не нормально. 1) Как тут прозвучало - объективные средства контроля (ваершак в данном случае, будет более правильным средством) 2) Смотреть программку по обслуживанию UDP. Профилировать код, если своё или сваливать временные поинты в лог. 3) Что говорит пинг на этот комп? Используется ли асинхронный доступ к сокету? Наверное (если свой код) имеет смысл сделать минимум-миниморэ балванку и выложить на профильных форумах. как то так, для начала... (круглый)
  4. У Вас тактовая камня сколько? Если предположить, что большинство МК это сотни мГц, а писюк - единицы гигагерц...то вот Вам и есть этот порядок просадки. Если Вы пихаете в передатчик изернета не в рукопашную, а полуавтоматом - то расходы на подготовку пакетов минимальна(по секрету - вы можете отправлять с железки и по максимуму 65к :) на IP уровне. правда это немного не по фэншую но явных ограничений в RFC не было вроде как.) (круглый)
  5. инженер-электроник STM 32

    хз. ЧИССО по опыту... скажу так - нормальный инженер сможет всё. Есть только предпочтения и скорость вхождения в тему. удачи вам (круглый)
  6. Пока пишешь на одном писюке, один проект, с одним функционалом - не заметно. как только вылезаешь из штанишек - то начинаешь упираться в компиляторы, оси, инструментарий и прочую хрень. Лучше уж один раз изучить инструментарий и "забыть его", чем всякий раз дописывать очередной костылёк под ту или иную изменившуюся хрень. Более чем один комп, выросла команда - кто под форточками сидит, кто предпочитает линукс. Кто пафосно запускает студии кто правит в нотепаде код. Кто то возится с отладкой - кто то "пишет без багов", кто то предпочитает TDD - кто то об этом даже не задумывался. В cmake вы указываете что вам нужно получить, а как - это проблемы cmake. Он корректно всё подготовит для "любой" оси. И собственно в окружении по использованию инструментария у вас ничего собственно и не измениться. что уменьшает человеческий фактор и экономит часы... как то так ЗЫ По началу я так-же скептически относился к этому. Попробовал - профит очевиден. Проект под форточки и линукс...
  7. make или cmake(для универсальной, под разные оси) предназначен как раз для операций компилирования, задания рабочих каталогов, зависимостей файлов от результата, вызов команд на сборку и других операций - всё это позволяет делать. попроще make конечно же, точнее сказать он прост в настройках - всё ровно как лом. но cmake более прост в запуске если понять логику по сэмплам. т.е. если с программированием на ты или около - то можно смело поюзать cmake. какие-то настройки cmake (более глубокие) - имхо покопаться немного придёться. Но зато он много чего делает интуитивно на автомате. 1) ищит все компиляторы что у вас есть на машине 2) понимает почти на автомате что прилинковывать и как собирать. 3) и т.д. ... знакомиться лучше с любым опен-соурс мультиплатформенным проектом собираемый cmake. вам понравится :) В не зависимости make or cmake основные вехи 1) описание в текстовом файлике зависимостей исходников от таргет целей(получаемых объектников и уже объектники от бинаря) 2) настройка правильных вызовов необходимых компиляторов-линковщиков 3) дополнение необходимых телодвижений по ходу пьесы - копирование, создание, удаление...make только у вас будет заточен на конкретную ось - например форточки...
  8. +1 ну.... в общем-то да. я что то воспринял как более фундаментальный заход на тему... make или если универсальный - cmake так-же не плохая игрушка = справится с перечисленными ТС задачами...
  9. То что Вы спрашиваете относится к части девопса и должно по идее интегрироваться в общий схемотоз работы разработчика-коллектива-подразделения с учётом интеграции до и после этого процесса. Т.к. ваша задача сборки не висит в воздухе - то нужно исходить из того что Вы юзаете в качестве хранения исходников, планы на развитие, общее понимание этой механики внутри коллектива и ... и много чего ещё. Например если у вас гитлаб - то наверное можно рассмотреть его родное CI/CD (правда халявный вариант имхо - сыроват). Если нужна просто молотилка которая на все случаи жизни - то возможно имеет смысл заюзать CI типа Jenkins-а или похожее. Но это не сам компилятор или скрипт, это больше облочка над шэлами-мавами-скриптами-батч_пакетами и прочая шняга. Причём за минимум телодвижений можно сделать сразу понты - печать, натификация, интеграция, графики, логи, артифакты и прочая хрень. Но надо вникнуть в дух этой фигни, с наскока не получиться увы... И ещё... То что Вы перечислили - мааааалая часть того, что пои идее должно происходить на фазе до-во_время-и_после_сборки. Если почитать популярные словосочитания TDD, CD, CI и т.д. и т.п. то сама по себе эта ниша досfтточно глубокая и широкая. Не использовать опыт ранее накопленный - проигрывать на рынке. Использование - траты на изучение или получение как результата. тут вот всё индивидуально. и ещё... Если Вам кажется, что всё что написал выше это перебор - то прочтите этот пост через 5-10 инсталяций вашего продукта у крупных заказчиков, когда возрастут объёмы, время сократиться а функционала будет нарощено на порядки). Думаю Вы уже не будете столь категоричны :)
  10. Frontend<->backend interface

    Смотреть в сторону REST, JSON, Web-Socket
  11. Я бы смотрел в стандартные возможности этого свича. Если он умеет посредством вэб морды общаться - там делоффф на пару дней(или есть доки на его API). Прелесть - Вы ничего физического из допов не ставите. Минус - заточка на этот свич(протокол). (круглый)
  12. Подозревать - это не одно и то-же что "быть уверенным". Посему выскажу следующее мнение: - лучше всего это подключиться к интерфейсу самого счётчика (или заменить его на такой счётчик (типа "меркурия 230")). Обычно это RS485. Сразу оговорюсь - обратите внимание, что питание интерфейса внешнее т.е. помимо линии данных, необходимо озаботиться и питанием самого интерфейса (делали явно дилетанты эти счётчики - апсолютно НЕ практично). - обычно энергетические компании не используют дистанционное сканирование. Хотя если такое есть - то интегрироваться в их систему будет проще (имхо конечно-же). - если сами захотите сканировать, то в гугле куча инфы по интерфейсам подобных счётчиков. - если лень самим или нет спецов - то можно обратить внимание на готовые интерфейсные решения на рынке - см. bolid и иже (вплоть до крохоборов с "облаками" и другими обдуриловки клиентов). Кстати счётчики отдают гораздо больше инфы чем ток-напряжение по фазам. Рекомендую глянуть юайные софтинки которые умеют работать со счётчиками. С уважением (круглый)
  13. Сразу оговорюсь: 1) эпоксидка 2) НЕ пром вариант 3) Есть ПОБОЧНЫЙ эффект Про пузырьки все уже высказались - тут вряд ли, что либо новое добавлю. В авиамоделизме применяется - вакуумирование - центробежная сила По поводу разжижения(в том числе и снижение рисков саморазогрева) - очень замечательно подходит(для ЭПОКСИДКИ) это спирт. до 50% можно вливать. Да, сначала побелеет (есть вода естественно в спирте), далее после интенсивного размешивания становится менее тягуч до состояния воды. Время отвердевания увеличивается (не намного). Но при этом побочный эффект - усадка (естественно). Ну и отгезия. Кстати эпоксидка имеет отгезию и усадку до месяца (это по паспорту). С уважением (круглый) ЗЫ Стаж работы с ЭДП более 30 лет, если что...
  14. Корова немного не моя :) Пока фаза сбор инфы. И одна из них - возможно ли изготовить магнит с радиальной намагниченностью. Вот тут выше подсказали, что да возможно. Буду благодарен за посыл по общему вектору... или любую другую инфу наполняющую копилку знаний ... С уважением (круглый)