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

1 2 3 4 5 4

mak Модератор Екатеринбург 6.3K 1.8K

Отв.60 11 Нояб. 16, 07:55

m16 прав, принципы построения систем в промышленности требуют разделять уровни
я тоже пошел по такому пути.
базовый контроллер на stm32 с rs485, can, rtc, sd, дополнительной мелкой eeprom под критические события.
использую FreeRTOS, экран 20х4, (графический нафиг не надо КМК).
и микросервер на qnx для взаимодействия с пользователем, логов и т.п.

sevpro Доктор наук Worldwide 769 281

Отв.61 11 Нояб. 16, 09:21

Tiny RTC I2C modulesm16, 11 Нояб. 16, 07:55

Стремная какая-то платка. R5, D1 я полагаю там стоят, чтобы в один прекрасный момент батарейка еб@нула. R4, тоже непонятно зачем, если батарейка не рванет так хоть жизнь ей укоротим?

m16 Модератор Тамбов 1.9K 1K

Отв.62 11 Нояб. 16, 09:24, через 4 мин

r4,r5,r6,d1 удалены

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

OFF Разносчиком вирусов может стать подключенный к Wi-Fi холодильник или другие бытовые приборы

Посл. ред. 11 Нояб. 16, 09:27 от m16

lesbeg Доктор наук Екатеринбург 657 459

Отв.63 11 Нояб. 16, 14:44

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

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

А тут он обеспечил минимальный функционал который работает везде. А интузиасты пущай пилят зоопарк клиентов каждый под свою платформу.Kotische, 10 Нояб. 16, 15:36

Так я сам об этом писал

Фронтендов может быть много - их могут писать энтузиасты под разные платформы, но при этом возможные баги фронта никак не влияют на бекенд.lesbeg, 09 Нояб. 16, 10:28

Это одно из достоинство грамотно сделанного открытого api.

Даже свой небольшой серверок написал на нативных сях, чтоб на дохлых армах работал.
С сервера выдаем только статику и javascript (что с точки зрения сервера тоже статика). Дальше все начинает крутиться на стороне веб приложения у клиента, мы же его подкармливаем информацией через websocket и отвечаем на конкретные запросы в формате json, который родной для javascript.ys1797, 10 Нояб. 16, 16:15

Имхо это велосипед. Со своим веб-сервером особенно.

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

Ну и еще интерфейс получается убогий невероятно. Делать так, чтобы потом переписывать под нормальный апач с мускулом и пхп и прочим блэкжеком не хочется.capsolo, 10 Нояб. 16, 16:34

Мускул не нужен. У сервера нет большого количества клиентов --> нам не нужны блокировки.
Нужен sqlite для хранения настроек и возможно логов и redis (или иное аналогичное nosql хранилище) для хранения сессий, кеша и текущего состояния колонны. Еще нужен брокер сообщений, типа rabbitmq. Т.о. будет достигнута очень высокая производительность и количество записей сократится (redis живет в озу). Над этим всем nginx (прокси) + gunicorn (wsgi сервер) + supervisor (запуск воркеров gunicorn) + python в качестве языка и какой-то его фреймворк (Flask или Django) -- приложение. Еще Ansible для развертывания и обновлений приложения (чтоб именно по-человечески автоматом обновлять). Я бы делал так

Но это, естественно, не про контроллер.

Тки пальцем в команду хороших специалистов - буду признателен, заранее искреннее спасибо!игорь223, 10 Нояб. 16, 15:26

А какие специалисты тебе нужны?

игорь223 Академик таганрог 30.5K 20.7K

Отв.64 11 Нояб. 16, 14:51, через 7 мин

А какие есть))) такие и пригодятся, счас время такое, что хорошая команда любая автоматом в красную книгу попадает(((

1. Пару веб сайтов нужно сделать, есть практически созревшие мысли, да и свой сайт допилить кое в чем, наверное
2. Автоматику могу заказать по предложенному тобой (мной) сценарию, и железо и софт
3. Програмку-приложение для ios/android тоже не мешало бы сделать, с хорошим функционалом и интерфейсом

ys1797 Доцент Санкт-Петербург 1K 339

Отв.65 11 Нояб. 16, 16:56

Имхо это велосипед. Со своим веб-сервером особенно.lesbeg, 11 Нояб. 16, 14:44

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

Мускул не нужен. У сервера нет большого количества клиентов --> нам не нужны блокировки.
Нужен sqlite для хранения настроек и возможно логов и redis (или иное аналогичное nosql хранилище) для хранения сессий, кеша и текущего состояния колонны.lesbeg, 11 Нояб. 16, 14:44

Мускул/не мускул, я с sql через фреймворк все равно все делаю, мне фиолетово в чем там храниться, хоть sqllite, хоть мускул, хоть оракл.
Получение текущего состояния - это тоже толпа разных скриптов. Можно один жирный - но неудобно подстраивать под разные задачи.
Сессии и кэши мне не очень нужны - это веб сервер на полтора человека а не на десятки тыщ.

Вот из полезностей есть еще неплохой проект smsd - прием отправка sms. Можно настроить sms управление и/или информирование. Поддерживает хренову тучу USB gsm свистков.

Но это, естественно, не про контроллер.lesbeg, 11 Нояб. 16, 14:44

А ну тогда да.
Контроллер проще обновить накатом нового имеджа.

lesbeg Доктор наук Екатеринбург 657 459

Отв.66 11 Нояб. 16, 19:23

Мускул/не мускул, я с sql через фреймворк все равно все делаю, мне фиолетово в чем там храниться, хоть sqllite, хоть мускул, хоть оракл.ys1797, 11 Нояб. 16, 16:56

Ты не понял того, что я написал. Нет нужды использовать распределенную СУБД для задач в которых мы:
1) в ней не нуждаемся, т.к. у нас нет 100500 клиентских запросов одновременно, нам не нужны блокировки, репликации и прочее.
2) ограниченны в ресурсах (ты понимаешь сколько памяти съест сам mysql?)

Вместо этого я предложил связку из локальной БД, например sqlite, для сохранения логов (их пишет только один воркер), настроек и прочих редкоизменяюшихся данных, а рядом с ней работает вторая nosql key-value БД сверхлегкий и сверхбыстрый redis. Он работает только с ОЗУ (нет питания -- нет данных), но работает очень быстро и создает 0% нагрузки на диск. В нем можно\хранить оперативные данные: сессии, кеш, текущее состояние системы (показания датчиков, мощность и прочее). Таким образом, архитектура будет работать быстрее (много быстрее mysql), создавать меньшую нагрузку. И это не сложнее в настройке, кстати, потому что, имхо, и sqlite и redis очень просты (в хорошем KISS смысле) и грамотно и секьюрно настроить их проще, чем один mysql сервер.

Получение текущего состояния - это тоже толпа разных скриптов. Можно один жирный - но неудобно подстраивать под разные задачи.ys1797, 11 Нояб. 16, 16:56

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

Сессии и кэши мне не очень нужны - это веб сервер на полтора человека а не на десятки тыщ.ys1797, 11 Нояб. 16, 16:56

Сессии нужны для сохранения состояние между http-запросами. Простейший пример -- аутентификация пользователя. Заходя на сайт ты один раз логинишся и в этот момент у тебя в браузере устанавливается сессия (используя куки, local storage или еще что-нибудь) о которой знает сервер (и хранит информацию о ней). Когда потом ты ходишь по сайту, то сайт на каждом запросе (переход по ссылке, обновление страницы) знает что ты залогинен. Если сессий нет -- будь добр логинится на каждом запросе. Второй вариант -- все могут всё явно не ок. Третий вариант (привет из 90-ых) -- http-авторизация средствами веб-сервера. Но у тебя же сервер самописный, http-авторизации там нет.

Про кеш писать столько же уже не буду -- считаешь не нужен, значит не нужен.

Покажи мне рабочий websocket сервер, к которому можно прикрутить кастомные данные на отдачу, тогда велосимед отправлю на свалку.ys1797, 11 Нояб. 16, 16:56

Есть такая штука -- github.com. Это git-репозиторий с элементами соцсети для разработчиков. Там множество open-source кода и по количеству звезд и форков можно понять насколько он хорош. Есть еше bitbucket.org похожий.

Я потратил 5 секунд времени на поиск вебсокетного вебсервера на гитхабе и открыл первую ссылку.

https://github.com/mattgodbolt/seasocks

Simple, small, C++ embeddable webserver with WebSockets support. Последнее изменение в коде 11 дней назад. 173 звезды, 27 форков-- проект 100% живой и рабочий. BSD лицензия. Я просто советую прочитать последнюю ссылку, чтоб в следующий раз свой веб-сервер не писать.

makh Профессор Sаmara 2.1K 1K

Отв.67 11 Нояб. 16, 20:09, через 47 мин

например sqlite, для сохранения логовlesbeg, 11 Нояб. 16, 19:23

Для наших данных, ИМХО, уместнее всего RRD. А события можно и традиционно в файл писать, их немного.

ys1797 Доцент Санкт-Петербург 1K 339

Отв.68 11 Нояб. 16, 20:22, через 14 мин

Ты не понял того, что я написал. Нет нужды использовать распределенную СУБД для задач в которых мы:lesbeg, 11 Нояб. 16, 19:23

Еще раз говорю, я не завязываюсь на конкретное sql хранилище, пускай будет sqlite.

Сессии нужны для сохранения состояние между http-запросами. Простейший пример -- аутентификация пользователя.lesbeg, 11 Нояб. 16, 19:23

Я знаю, это штатная фигня.

Но у тебя же сервер самописный, http-авторизации там нет.lesbeg, 11 Нояб. 16, 19:23

У меня самописный websocket сервер. Была там digest http авторизация. Отказался - хром ее не поддерживал, точнее он вообще не понимал 401 ответ на его попытку открыть websocket. Пришлось это соединение через хеш в куках авторизировать.

Я потратил 5 секунд времени на поиск вебсокетного вебсервера на гитхабе и открыл первую ссылку.lesbeg, 11 Нояб. 16, 19:23

Ни чем не лучше моего велосипеда. Причем это тоже "комплект для досборки и обработки напильником". Даже местами как-то не очень.
Я сделал на нативном Cи все и работает даже на at91rm9200 с 16 мгц.
На том же гитхабе есть еще на perl'е и php websocket сервер, но тоже монстры и требуют напильника.
Кстати, хорошая мысль, надо свою версию на тот-же гитхаб выкинуть.

lesbeg Доктор наук Екатеринбург 657 459

Отв.69 11 Нояб. 16, 21:54

Для наших данных, ИМХО, уместнее всего RRD.makh, 11 Нояб. 16, 20:09

Хз, нужно и можно исследовать. Я, честно говоря не работал с RRD, но плотно работал\ю с Zabbix для сбора и визуализации метр/ик и обдумывал вариант использования его для логов в нашей ветке. Но я посчитал, что для уровня raspberry pi это слишком жирно. Кроме того, zabbix лично мне доставляет массу проблем с интерполяцией данных -- он может тупо похерить несколько явно переданных метрик если таймстамп между ними минимален, а дельта выше матожидания -- тоже нужно инвестигировать вопрос о применительности к нашим колоннам.

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

У меня самописный websocket сервер. Была там digest http авторизация. Отказался - хром ее не поддерживал, точнее он вообще не понимал 401 ответ на его попытку открыть websocket. Пришлось это соединение через хеш в куках авторизировать.ys1797, 11 Нояб. 16, 20:22

Сам как думаешь, это специалисты Google не смогли реализовать стандарт или ты?

Ни чем не лучше моего велосипеда. Причем это тоже "комплект для досборки и обработки напильником". Даже местами как-то не очень.
Я сделал на нативном Cи все и работает даже на at91rm9200 с 16 мгц.ys1797, 11 Нояб. 16, 20:22

Есть книга Стива Макконела, мягко говоря весьма уважаемая в профессиональных кругах, называется "Совершенный код" и я очень, очень сильно советую ее тебе к прочтению. В этой книге Стив приводит пример когда его привлекают в качестве специалиста, чтобы починить программу которая не работала (над которой разработка работала больше года). Он ее починил. Руководитель старой разработки спрашивает: -- сколько времени тратит твоя программа на решение? Стив отвечает: 20 секунд. Руководитель старой разработки: -- я моя 2 секунды. Стив: Круто, но твоя не работает. Финальный тезис был простым (кроме того, что ранняя оптимизация корень многих зол) -- твоя программа может быть охуенной, но если она не работает, то всем пох. Потому что она неработает. И гугл хром не понимающий ответы самописного веб-сервера -- это не проблема гугл-хрома если чо.

ys1797 Доцент Санкт-Петербург 1K 339

Отв.70 11 Нояб. 16, 22:22, через 29 мин

И гугл хром не понимающий ответы самописного веб-сервера -- это не проблема гугл-хрома если чоlesbeg, 11 Нояб. 16, 21:54

Конечно не проблема, RFC для дураков же да?
Если что: https://tools.ietf.org/html/rfc6455

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

Есть книга Стива Макконелаlesbeg, 11 Нояб. 16, 21:54

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

Посл. ред. 11 Нояб. 16, 22:26 от ys1797

makh Профессор Sаmara 2.1K 1K

Отв.71 11 Нояб. 16, 22:41, через 19 мин

RRDtool is the OpenSource industry standard, high performance data logging and graphing system for time series data

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

$ ldd `whereis rrdtool`
/usr/local/bin/rrdtool:
        Start            End              Type Open Ref GrpRef Name
        0000000000400000 0000000000801000 exe  1    0   0      /usr/local/bin/rrdtool
        000000020e651000 000000020ea9f000 rlib 0    1   0      /usr/local/lib/librrd.so.3.0
        0000000208544000 00000002089cd000 rlib 0    2   0      /usr/X11R6/lib/libfreetype.so.18.1
        000000020cc7b000 000000020d0a7000 rlib 0    2   0      /usr/local/lib/libpng.so.13.0
        000000020e23c000 000000020e651000 rlib 0    2   0      /usr/lib/libz.so.4.1
        00000002037e2000 0000000203bf9000 rlib 0    2   0      /usr/local/lib/libart_lgpl_2.so.5.20
        00000002016cd000 0000000201af5000 rlib 0    3   0      /usr/lib/libm.so.7.0
        0000000204aee000 0000000204fd2000 rlib 0    1   0      /usr/lib/libc.so.62.0
        000000020c100000 000000020c100000 rtld 0    1   0      /usr/libexec/ld.so

~~capsolo~~ Профессор Зелик 5.3K 1.6K

Отв.72 11 Нояб. 16, 23:29, через 49 мин

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

Посл. ред. 11 Нояб. 16, 23:31 от capsolo

ys1797 Доцент Санкт-Петербург 1K 339

Отв.73 12 Нояб. 16, 00:09, через 40 мин

Коллеги. Вижу у вас большой опыт. Посоветуйте на чем под линухами проще написать приблуду, которая с одной стороны мониторит ком-порт, с другой складывает показания в бд а с третьей торчит на порту и обслуживает REST запросы, и транслирует их в ком-порт в виде команд.capsolo, 11 Нояб. 16, 23:29

На том, на чем умеешь. Я серьезно.

lesbeg Доктор наук Екатеринбург 657 459

Отв.74 12 Нояб. 16, 00:14, через 6 мин

Конечно не проблема, RFC для дураков же да?
Если что: https://tools.ietf.org/html/rfc6455ys1797, 11 Нояб. 16, 22:22

Уточни, как приведенная тобой ссылка доказывает, что гугл не соответсвует rfc, а ты соответствуешь, а то я этого не уловил?

Есть еще древняя ужастная история, в переводе называется "как мне не хватило одного байта" почитайте.ys1797, 11 Нояб. 16, 22:22

Почитал, но связи этого опуса с "Совершенный код", который изучают в MIT-е и Гарварде опять не уловил. Юмор юмором, но есть абсолютно адекватные рекомендации, которые например говорят, что в ядро linux вложенно 2 000 человеколет, поэтому изобретать заново ядро ос -- плохая идея, ибо у тебя нет такого времени, а у проекта и заказчика тем более. Веб-сервер это конечно не ядро ос, но, что-то мне подсказывает, что в тот же nginx и apache вложены не тысячи, но сотни лет, причем людей, которые знали что такое http-сессия и как работает web.

Коллеги. Вижу у вас большой опыт. Посоветуйте на чем под линухами проще написать приблуду, которая с одной стороны мониторит ком-порт, с другой складывает показания в бд а с третьей торчит на порту и обслуживает REST запросы, и транслирует их в ком-порт в виде команд.capsolo, 11 Нояб. 16, 23:29

python. Инфа 100%. То что ты описал -- моя работа

makh Профессор Sаmara 2.1K 1K

Отв.75 12 Нояб. 16, 01:31

На том, на чем умеешьys1797, 12 Нояб. 16, 00:09

Вся юниксацкая красота в этих словах лаконично описана есть. Бесконечность.

makh Профессор Sаmara 2.1K 1K

Отв.76 12 Нояб. 16, 01:32, через 2 мин

Бесконечное количество возможных оптимальных решений. Каждое в своем контексте .)

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

в ядро linux вложенно 2 000 человеколетlesbeg, 12 Нояб. 16, 00:14

Если бесконечное количество обезьян посадить за бесконечное количество пишмашинок, одна из них раньше или позже напишет Гамлета (с)

Линупс не единственная, и, в определенном смысле, далеко не лучшая юникс-подобная система.

Посл. ред. 12 Нояб. 16, 01:44 от makh

~~capsolo~~ Профессор Зелик 5.3K 1.6K

Отв.77 12 Нояб. 16, 01:45, через 13 мин

Да научиться не проблема на чем угодно писать. Обвес мне нужен. Работа с серийным портом, запросы к бд, парсер-упаковщик JSON или XML. В питоне это все есть. Потому спасибку и влепил.

makh Профессор Sаmara 2.1K 1K

Отв.78 12 Нояб. 16, 02:06, через 21 мин Автор был пьяный

В питоне это все естьcapsolo, 12 Нояб. 16, 01:45

А так же в перле, пхп, сишечке, и исчо тысча названий.

Скрытый текст

man cu, man nc (nc.openbsd на линупсах), man ksh .) Jedem das seine ,)

lesbeg Доктор наук Екатеринбург 657 459

Отв.79 12 Нояб. 16, 13:38

Вся юниксацкая красота в этих словах лаконично описана есть. Бесконечность.makh, 12 Нояб. 16, 01:31

Если бесконечное количество обезьян посадить за бесконечное количество пишмашинок, одна из них раньше или позже напишет Гамлета (с)makh, 12 Нояб. 16, 01:32

Это perl-way и эта идиома не бесспорна. perl-way противопоставлен pythonic-way, который утверждает, что нужно строить решение, а не самовыражаться в коде, потому:

>> python -c "import this"

Тринадцатая метафора.

There should be one -- and preferably only one -- obvious way to do it -- Должен существовать один -- и, желательно, только один -- очевидный способ сделать это.