27 МОСКОВСКАЯ ВСТРЕЧА
Форум самогонщиков Сайт Барахолка Магазин 27 МОСКОВСКАЯ ВСТРЕЧА

Re: Автоматика для работы под вакуумом - выбор платформы

Форум самогонщиков Автоматика
1 2 3 4 5 3
m16 Модератор Тамбов 1.9K 1K
Отв.40  10 Нояб. 16, 09:27
Нравится тебе это или нет, но мир не просто идет - ЛЕТИТ в этом направлении.игорь223, 10 Нояб. 16, 06:02
   мир то летит, и с не меньшей скоростью развивается вэб-зло.   мне не нравится то что связь с внешним миром хакают челы с не добрыми намерениями обходя мыслемые - немыслемые защиты. сейчас дроид ломают как два пальца об асфальт. с дроидных смартфонов с установленным приложением сб-онлайн обнуляют карточки. одно дело когда  у тебя с карты  бабки сняли другое дело когда вмешиваются в производственный процесс . здесь финал может быть намного печальней.
   умный дом это отдельная пестня. со "умным" счётчиком вообще зашибись - в доме/квартире пропадает эл-во и тут же приходит смс/звонок с предложением перечислить бабки. как тебе перспектива?
   причём в последнее время я наблюдаю случаи не чистого хака а договорняка. поясню. собираются три чела : чел из gsm конторы, чел из банка и собсно хакер которому первые два значительно упрощают 102-й способ отъёма денег у порядочных  граждан за свою долю.
игорь223 Академик таганрог 30.5K 20.7K
Отв.41  10 Нояб. 16, 09:42, через 16 мин
Издержки прогресса.

Глобальное потепление, загрязнение атмосферы, болезни и ломка имунной системы людей, рост психических отклонений, терроризм и техногенные катастрофы.
Точнее говоря - плата за прогресс, обратная сторона медали.

Парнишка вон на тесламобиле расшибся насмерть...куда деваться, хочется человечеству бухими ездить не за рулем, а с телочкой на заднем сиденье - а если есть потребитель, то есть и тот, кто извлекает прибыль, удовлетворяя потребность.
)))
POLE Научный сотрудник Питер 2.6K 1.2K
Отв.42  10 Нояб. 16, 10:07, через 25 мин
Прогресс хорошо.
Хакеры злодеи - плохо.
Хочется напомнить одну важную вещь в нашем деле - ремонтопригодность без навязчивого сервиса.
Ну типа - обнаружил неисправность - заменил или отключил (обошел) и работает. Лучше без остановки процесса.
Я за прогресс, но как-то на работе мне сказали, что мною предлагается решение типа "мерседес", а в регионах на нем "ездить не смогут" им нужен "запорожец" или "телега".
Винокуры должны быть готовы пользоваться предлагаемой автоматикой (понимать и управлять).
сообщения удалены (4)
Kotische Академик Саратов 8.1K 2.5K
Отв.43  10 Нояб. 16, 13:54
платформа очертания никак не приобретет  ...игорь223, 10 Нояб. 16, 13:39
То есть как это?!  Непонимающий
Ты же сам сказал что утебя уже всё намази, на базе планшета.
capsolo Профессор Зелик 5.3K 1.6K
Отв.44  10 Нояб. 16, 14:42, через 49 мин
Первое звено - УК - выход по уарт.
Второе звено - СК - отдает наружу web, выход по ethernet
Третье звено - пользовательский комп, планшет, да что угодноKotische, 09 Нояб. 16, 14:35
Это самое правильное. Наш проект имеет эту архитектуру. Пока мы правда на этапе УК УлыбающийсяУК - Нана на материнке со всем необходимым блэкджеком и дамами. Торчит наружу серийником.
СК пока думаем за NodeMCU, но не ясно справится ли она одновременно и с локальным интерфейсом и с веб сервером.
lesbeg Доктор наук Екатеринбург 657 459
Отв.45  10 Нояб. 16, 15:11, через 29 мин
Ибо УК это реалтаймовая железка. Там хренова туча специфики и сложностей.
Пихать слишком сложный функционал на реалтаймовскую железку - очень плохая идея!Kotische, 09 Нояб. 16, 17:22

Если УК -- контроллер, то согласен на 100%. Но она может быть компьютером (pcduino, raspberry pi). В этом случае у нас именно компьютер с полноценной осью. Наверное можно qnx поставить, тогда тоже будет real-time. А реальное время, кстати, для управления колонной необходимо?

А вот если кому сильно захочется рулить из под мака или линуксов - не проблема, веб очень хорошо стандартизирован и переносим между какими угодно платформами.Kotische, 09 Нояб. 16, 17:22


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

Например, ios-ное приложение может использовать push notifications чтобы уведомить пользователя о каком-то событии, win-приложение сможет вывести диалог на экран, а что сможет сделать вебовский апп, жизнь которого ограничена вкладкой браузера.

В России практически исчезают структуры и отдельные специалисты, реально способные учавствовать в проектах создания таких систем. Скажем, за реализацию системы организации мелкосерийного производства я был готов заплатить несколько миллионов рублей, влегкую. Именно за выстраивание и наладку БД, на основе любого ПО.
игорь223, 10 Нояб. 16, 06:02

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

Со специалистами все в точности до наоборот. У нас есть школа, есть вузы и есть масса практиков. Иными словами у нас есть хорошие токари, но токарные станки делают в MIT-е, который в ссылке выше только на 6 месте.

Скажем, за реализацию системы организации мелкосерийного производства я был готов заплатить несколько миллионов рублей, влегкую. Именно за выстраивание и наладку БД, на основе любого ПО.
Закупки, учет и анализ материалов, планирование выпуска продукции, контроль этапов производства, отслеживание перемещений, распределение побригадно и по людям, формирование зарплат, брак и списания...короче говоря - стандартная для любого производства рутина, заточенная под нужды конкретного производства.
Так вот.
Ни за миллион, ни за пять, ни за десять - мы просто не нашли реальных исполнителей!!!
игорь223, 10 Нояб. 16, 06:02

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

Аналогичная ситуация в сфере написания сайтов!!!игорь223, 10 Нояб. 16, 06:02

А эта отрасль для разработчиков (исключая лидеров рынка) сейчас в упадке, потому что последние года для большинства компаний источником прибыли является сео и контекстная реклама, а не собственно разработка. Последняя рассматривается скорее как инструмент привлечения клиента и подсадки его на сеошную иглу и зачастую убыточна. Многие ушли с лоу- и мидл- костового вебдева.

Вторая историческая проблема этой отрасли -- конкуренция с теми, кто с объявлений на столбах обещает сайт за 5, 10, 20-ть тысяч в сочетании с непониманием заказчиками рынка и процесса разработки. Язык PHP (на котором написаны 70-80% сайтов, в т.ч. и твой) завоевал популярность потому что просто и имеет очень низкий порог входа. Но этот достоинство стало и его проклятьем, потому что через этот порог перелилось много всякого разного и появились профессиональные термины типа "говнокод", "быдлокод" и куча производных от них. Соответственно, цена на услуги по рынку (даже у фрилансеров) может отличаться на порядок и более и заказчик, который не хочет вникать в процесс и оценивает будущий результат по фотошоповскому дизайн-макету часто не понимает такого разбега.

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

Просто вебдевоский рынок нижней ценовой категории еще не созрел. Именно рынок, а не специалисты.
игорь223 Академик таганрог 30.5K 20.7K
Отв.46  10 Нояб. 16, 15:26, через 16 мин
lesbeg, не буду спорить про токарей, про интеграторов и про разработчиков ПО, про врачей, милиционеров, чиновников и футболистов - оффтоп это.
Видимо, я просто невезучий по жизни на хороших разработчиков человек; или характер скверный; или планка завышена...
Тки пальцем в команду хороших специалистов - буду признателен, заранее искреннее спасибо!
Kotische Академик Саратов 8.1K 2.5K
Отв.47  10 Нояб. 16, 15:36, через 11 мин
Я не противник веб-технологий ни разу, более того, я считаю, что если клиентское приложение будет в единственном экземпляре, то оно обязано быть именно вебовским аппом. Но у таких приложений есть один маленький минус -- они не используют возможностей платформы, которых с каждым годом становится только больше.lesbeg, 10 Нояб. 16, 15:11
Полностью согласен.
Я сам больше люблю толстые клиенты, а веб-мордами пользуюсь от безвыходности.
Реализация API в рамках веб-протокола, как сделано например у transmission-daemon.
Если под твою платформу портирован толстый клиент то ты получаешь все удобства пользования нативным приложением.
Но если такого нет то можно использовать веб морду. Она менее удобна зато работает везде.

Если стандартизировпть и опубликовать API то все заинтересованные умельцы смогут клепать интерфейсики под любую свою платформу.

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

А тут он обеспечил минимальный функционал который работает везде. А интузиасты пущай пилят зоопарк клиентов каждый под свою платформу.
briareus Бакалавр Москва 62 39
Отв.48  10 Нояб. 16, 16:03, через 27 мин
думаем за NodeMCU, но не ясно справится ли она одновременно и с локальным интерфейсом и с веб серверомcapsolo, 10 Нояб. 16, 14:42

Это смотря какой веб-сервер будет. Если просто N значений по интерфейсу отдавать - справится, имхо.
Я, помнится в самом начале знакомства с esp8266 ~пятью клиентами завалил сервер, который должен был отдавать график на несколько сотен точек на svg.
ys1797 Доцент Санкт-Петербург 1K 339
Отв.49  10 Нояб. 16, 16:15, через 13 мин
А реальное время, кстати, для управления колонной необходимо?lesbeg, 10 Нояб. 16, 15:11

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

Например, ios-ное приложение может использовать push notifications чтобы уведомить пользователя о каком-то событии, win-приложение сможет вывести диалог на экран, а что сможет сделать вебовский апп, жизнь которого ограничена вкладкой браузера.lesbeg, 10 Нояб. 16, 15:11

Я уже давно использую websocket сервис и игрался с webrtc. websocket решает задачу реалтаймового вывода информации web приложению.
Даже свой небольшой серверок написал на нативных сях, чтоб на дохлых армах работал.
С сервера выдаем только статику и javascript (что с точки зрения сервера тоже статика). Дальше все начинает крутиться на стороне веб приложения у клиента, мы же его подкармливаем информацией через websocket и отвечаем на конкретные запросы в формате json, который родной для javascript.

По поводу веба и мелких систем на основе только флеш памяти. Если поставить весь огород из mysql (или sqlite), как хранилище + php-fpm/perl, как "язык" веб программирования + nginx (как http сервер). возникает проблема в виде перехода через некоторое время карт памяти в режим "read only" в связи с тем, что лимит циклов перезаписи исчерпался (около 200 тыщ вроде) и контроллер в карте памяти просто тупо отключает запись на нее. У меня уже два таких экземпляра на 32 ГГб валяются.
По этому или разделять ОС - на внутреннюю флеш, а динамику на карту памяти или писать на SATA, или вообще по интернету на яндекс диск или дропбокс.

Вообще у нас в стране странное дело творится. Вон в питере есть адские заводы, но чугунную станину для того-же CNC просто никто не льет, народ таскает из Китая. Бред какой-то.
Сделать корпус для устройства в котором отверстия совпадали с чертежом, а дизайн не вдавливал в депрессию невозможно. Выручает опять, только Китай.

Хорошо, хоть образцы плат можно в резоните заказать, а не ждать месяцами из поднебесной.
capsolo Профессор Зелик 5.3K 1.6K
Отв.50  10 Нояб. 16, 16:34, через 20 мин
По поводу веба и мелких систем на основе только флеш памяти. Если поставить весь огород из mysql (или sqlite), как хранилище + php-fpm/perl, как "язык" веб программирования + nginx (как http сервер). возникает проблема в виде перехода через некоторое время карт памяти в режим "read only" в связи с тем, что лимит циклов перезаписи исчерпался (около 200 тыщ вроде) и контроллер в карте памяти просто тупо отключает запись на нее. У меня уже два таких экземпляра на 32 ГГб валяются.ys1797, 10 Нояб. 16, 16:15
Ну и еще интерфейс получается убогий невероятно. Делать так, чтобы потом переписывать под нормальный апач с мускулом и пхп и прочим блэкжеком не хочется.
makh Профессор Sаmara 2.1K 1K
Отв.51  10 Нояб. 16, 17:54
проблема в виде перехода через некоторое время карт памяти в режим "read only" в связи с тем, что лимит циклов перезаписи исчерпалсяys1797, 10 Нояб. 16, 16:15
У энергонезависимых устройств проблема решаема. Условно говоря -- при загрузке делаем RAM-партишн, на который клонируется /var, карта остается RO. При выгрузке, уж неважно, пользователь ли halt сказал, аварийный сигнал с бесперебойника, или еще что случилось -- перемонтируем карту RW и клонируем туда /var из RAM.
ys1797 Доцент Санкт-Петербург 1K 339
Отв.52  10 Нояб. 16, 19:11
Ну и еще интерфейс получается убогий невероятно. Делать так, чтобы потом переписывать под нормальный апач с мускулом и пхп и прочим блэкжеком не хочется.capsolo, 10 Нояб. 16, 16:34

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

У энергонезависимых устройств проблема решаема. Условно говоря -- при загрузке делаем RAM-партишн, на который клонируется /var, карта остается RO. При выгрузке, уж неважно, пользователь ли halt сказал, аварийный сигнал с бесперебойника, или еще что случилось -- перемонтируем карту RW и клонируем туда /var из RAM.makh, 10 Нояб. 16, 17:54

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

Выход в виде записи на халявный yandex disk через их webdav вижу как наиболее оптимальный по затратам.
m16 Модератор Тамбов 1.9K 1K
Отв.53  10 Нояб. 16, 20:40
У энергонезависимых устройств проблема решаема. Условно говоря -- при загрузке делаем RAM-партишн, на который клонируется /var, карта остается RO.makh, 10 Нояб. 16, 17:54
Все равно лотерея, у кого-то 100 тыщ циклов выдерживает, у кого-то 91 миллион циклов - лотерея.
Немного помогает файловая система yaffs2, но неудобство, что ее десктопы не понимают.ys1797, 10 Нояб. 16, 19:11
   ребят, вы о чём? имхо из мухи слона раздуваете. то что однажды-дважды у сервисного контроллера/компостера отрубиться питание и мы потеряем часть лога и потеряем связ с "внешним миром"  да и хер с ним. главное чтобы рабочая лошадка - УК после рестарта адекватно отработал и делается это чисто программно.
   для примера. я гоню в гараже на автопилоте дистилляцию и ректификацию по алгоритму : залил-включил-ушёл-пришёл-забрал. после нескольких отключений  эл-ва я переписал алгоритм. крайние настройки и текущий режим работы хранятся в eeprom , после рестарта - настройки заливаются из eeprom в раму, анализ текущих температр и процесс идёт своим чередом, замечу, резервные источники не пользую + в автономке 50л гидроакумулятор исключает прорыв паров спирта после откючения эл-ва.
makh Профессор Sаmara 2.1K 1K
Отв.54  10 Нояб. 16, 22:15
хер с нимm16, 10 Нояб. 16, 20:40
Логи терять низя. Разбор полетов должен быть. С именем и фамилией (с) у каждого аварийного события.

Вообще как-то неконструктивно. Забываем, и я в том числе, что каждая задача имеет бесконечное количество возможных решений, каждое из которых будет оптимальным в некоем определенном контексте. А то кому-то мерещится девайс для серийного производства, кому-то линупсацкий дист, кому для квартиры, кому для гаража, кому для ведроида. Контекст разный у всех, без исключения. Надо бы найти некий минимум общих моментов, и на этой основе формулировать задачу, потенциально покрывающую максимум хотелок. А правильно сформулированная задача есть алгоритм ее решения. Т.е. по програмной части останется перевести с русского на некий алгоритмический.
capsolo Профессор Зелик 5.3K 1.6K
Отв.55  10 Нояб. 16, 22:22, через 7 мин
makh, коллега м16 очень правильно написал. Контроллер "рабочая лошадка" всему голова. Ему обьяснили чем надо заниматься в ближайшее время - он это и делает. Вырубили ему все, потом врубили - он вспомнил чем занимался, запустил порядок включения оборудования и в тот же режим вышел. Хоть в Америке президент сменился, хоть третья мировая - ему по барабану. Он отберет головы, переключится на подголовники и соберет их в отдельную тару, ну а дальше по тексту. Ему в самом начале уже все обьяснили что надо делать. Если придут какие - то корректировки с планшета и вайфайного блютуса - ну скорректирует. Если беда - сигнал. Мыло, пуш уведомление, смс вот жвер.
m16 Модератор Тамбов 1.9K 1K
Отв.56  10 Нояб. 16, 22:56, через 34 мин
Логи терять низя. Разбор полетов должен быть. С именем и фамилией (с) у каждого аварийного события.makh, 10 Нояб. 16, 22:15
я размышлял над этим. самое простое решение - под ошибки в УК на I2C(SPI) повесить eeprom , организовать в ней кольцевой буфер и сбрасывать туда коды ошибок с текущими параметрами процесса. ошибка пропадания электроэнергии вычисляется легко - если при старте контроллера считанный из eeprom флаг начала процесса был установлен установлен .
А то кому-то мерещится девайс для серийного производства, кому-то линупсацкий дист,makh, 10 Нояб. 16, 22:15
НО, общее решение для всех кому что мерещится есть управляющий контроллер с открытым протоколом обмена . согласись логи - графики для регулярного использования нужны исключительно при проведении экспериментов с новыми изделиями, проведения опытов, исследования различных режимов работы . а когда у тебя процесс отлажен они нах не нужны.

Добавлено через 39мин.:

кстати, если внешнюю eeprom взять пожирнее , то можно туда и лог писать скажем раз в минуту. а в случае надобности слить в комп по  уарту через терминалку затем в экселе проанализировать процесс. и никакие доп программы не нужны.
makh Профессор Sаmara 2.1K 1K
Отв.57  11 Нояб. 16, 00:09
на I2C(SPI) повесить eeprom , организовать в ней кольцевой буфер и сбрасывать туда кодыm16, 10 Нояб. 16, 21:56
А рядом пришлось бы присоплить RTC, ибо что есть событие без даты/времени?
когда у тебя процесс отлаженm16, 10 Нояб. 16, 22:56
С одной стороны -- да, конечно.
С другой -- и при отлаженных процессах, если вдруг что-то пошло нештатно, картинки радикально помогают с диагностикой. Аварии могут предшествовать некие неаварийные отклонения в работе оборудования, на которые гуманоид обратит внимание сразу, если будет смотреть на визуал, а не на цифирьки.

Kotische Академик Саратов 8.1K 2.5K
Отв.58  11 Нояб. 16, 00:44, через 36 мин
А рядом пришлось бы присоплить RTC, ибо что есть событие без даты/времени?makh, 11 Нояб. 16, 00:09
А совсем более рядом CMOS озушку с батарейкой (Non Volatile Random Access Memory по ихнему),
или научиться программировать энергосберегающий режим микроконтроллера,
в котором он 1мкА потребляет и может от литиевой батарейки несколько лет
поддерживать состояние своей памяти.
m16 Модератор Тамбов 1.9K 1K
Отв.59  11 Нояб. 16, 07:55
А рядом пришлось бы присоплить RTCmakh, 11 Нояб. 16, 00:09
разумеется. я заложил в свой девайс Tiny RTC I2C modules. два в одном - rtc + eeprom