Запросы на функционал LuckyBox

Я заказал РМВ-К, на следующей неделе обещали выслать, ещё неделю на доставку. Но в программировании слаб – бейсик в школе тридцать лет назад учил, после этого с программированием связан не был

самую прогрессивную работу по Шпоре 

Спорный вопрос, как и сам мистер по продаже бесполезных прибамбасов Шульман.

Шпора желательна при ректификации. В начале отбора тела ФЧ можно и до 2-х снизить, постепенно к концу поднимая в 2,5-3 раза

Народ, я знаю прекрасно алгоритм отбора “по шпоре”. Но не могу я его сейчас культурно “вкорячить” без правок в web интерфейсе. Все это будет только уже в версии с глобальными изменениями с полноценным удаленным облачным управлением.

Petrozelikaps писал(а):

глобальные изменения железа так же потребуются?

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

Константин писал(а):

4. Алгоритм работы клапана исходя из его реальной вычисленной или введённой величины отбора в мл./час (а не какие-то проценты от какого-то времени).

Поддерживаю , выставить время открытия клапана , удобнее , чем ловить и высчитывать % от периода . Время нужно с десятыми . Ещё раз напомню за время периода на головах , там 30сек максимум , сделайте 600сек , для периодического отбора . По 4му каналу – если с запилом WEB вилы , сделайте его “хвостовым” прямо в прошивке , пусть просто включается на 96°С в кубе , на него реле прицепим и управление с клапана тела на другой клапан перекинем (или просто сбросят в другую тару ) .Кому нужна другая Т перехода , смогут в прошивке исправить (сами или с вашей помощью ) , если не нужен будет, в процессе не выбирать его , и все дела

Клапан для нижнего узла отбора (в канале CH4) и силовой блок от Вольки (РМВ-К UART) реализовал. Немного еще погоняю сам, и выдам исходники пока только сюда для теста народом. Если все ок и без замечаний, обновлю исходники на GitHub.

p.s. Хотелки, требующие вмешательство в web, естественно не делал, выше объяснял почему. В принципе на прошлой неделе довольно сильно продвинулись в реализации взаимодействия облако – контроллер. Так что пока основное свободное время именно этому посвящено, там уже и будем всевозможный расширенный функционал добавлять.

Антоха писал(а):

Свет в конце тоннеля хоть немножко брезжит?

Не так быстро как хотелось бы, но лучики уже пробиваются 🙂 Если сильных завалов по работе не будет, думаю скоро выдадим на тест поиграться с дистилляцией и удаленным управлением через облако. Пока для отладки будет только классическая дистилляция, как увидим что все работает (интерфейс взаимодействия с пользователем), дальнейшее продвижение в реализации алгоритмов пойдет гораздо быстрее. Прошивка естественно будет сильно отличаться. Из основных отличий, реализован совершенно другой подход к выбору/назначению датчиков или устройств для процесса. Не будет больше классической вкладки определения датчиков и устройств. Для той же дистилляции, можно будет создать несколько вариантов конфигураций (с последующим выбором любого варианта из созданных), и для любой этой конфигурации выбирать свои датчики температуры с их назначением (не будет такого что датчик в кубе должен быть именно Т1), а клапана или датчики безопасности подключать к любому каналу и просто указывать где именно он сидит. Все эти варианты конфигураций хранятся в облаке, сам контроллер помнит только последний выбранный вариант для работы. Тем самым уходим и от той же жесткой привязки только к 8-ми датчика температуры (они могут быть совершенно разными физически в разных алгоритмах, просто в конкретном алгоритме их не более 8-ми), и плюс память контроллера не засираем кучей разнообразных алгоритмов (как у нас в ректификации к примеру сейчас). Это только часть плюшек, более подробно думаю Павел в будущих видосах покажет очень скоро 😉