eddy_em

Понемногу монтирую на телескопах «Астро-М» пускатели для аварийного отключения нагрузки от ИБП (инверторов). Окончательным этапом будет завязать это все на датчики грозы, чтобы при приближении грозы ближе ~5км все внешнее поотключать.
Казалось бы: что тут такого — пускатель воткнуть? А фактически выходит минимум рабочий день на один телескоп. С серверным шкафом вообще три дня возился. А на телескопах нужно проложить линию питания инверторов (сейчас они включаются тупо в розетку, и нужно очень внимательно следить, чтобы вилку правильно вставить, иначе будут "спецэффекты"), проложить к нагрузке (компьютер и маршрутизатор) линию от бесперебойника, отдельную линию (напрямую от ИБП) — к оптическому преобразователю (который в "сетевом" шкафу, а не коробке управления).
По основному зданию протянул RS-485 обычной витой парой, но сдается мне, что "обмедненный алюминий" — плохая идея. Сегодня тестировал реле в подкупольном — отзывалось через раз. Хотя туда идет достаточно короткий шнурок, в шкаф значительно длиннее. На концах, естественно, воткнул терминаторы по 120 Ом. А из шкафа три оптических преобразователя по оптоволокну связывают внешние купола с общей шиной. Кончается шина в электрощите на 8-канальном блоке реле (для управления тремя пускателями, чтобы отключать питание из щитовой).
Обнаружил сегодня, что начинает "сыпаться" жесткий диск на сервере (а там производится вся обработка изображений). Да и, как оказалось, все-таки аккумуляторы "стоечного" ИБП почти померли: буквально через минуту после тестового отключения ИБП сказал "я помер", инициируя отключение слушающих его по NUT. А после того, как в нагрузке остался лишь главный метеокомпьютер (он и будет все мониторить и включать/выключать) и основной маршрутизатор в стойке, ИБП радостно пискнул и показал 55%. Но дальше аккумулятор очень медленно разряжался, показывая мне, что минимум часов на шесть еще хватит (хотя, это еще бабка надвое нагадала, хватит ли взаправду). Но там адские аккумуляторы: два здоровых короба, где собрано по 20 обычных (7А·ч) "упсовых" аккумулятора. Дичь какая-то: туда и лезть-то страшно! Хоть постоянка — это вам не переменка, и шарахнет не так сильно, но все равно неприятно. А цена… Готовые от 80 до 100тыр за штучку, причем ни у кого нет в продаже. Если же собирать из обычных, где-то тысяч под 40 за коробок получится. Хоть выкидывай этот ИБП и ставь обычный инвертор + один-два "гелевых" аккумулятора на 100-150А·ч.
К сожалению, вопрос ИПБ — вечный вопрос! Ведь каждые 2-3 года обязательно нужно аккумуляторы менять. А куда старые девать? Да и цена вопроса достаточно высокая, если касается "серверных" ИБП. На том же Ц-1000 "с нуля" ИБП держал около 10 часов (и часа 3-4, если при этом еще и телескоп с куполом работают). А сейчас уже едва час выдерживает с минимальной нагрузкой…

Ну, а что до управления… Про NUT я уже написал. Как увидел, что метеокомпьютер тоже отключился, когда ИБП решил, что он — труп, сразу же удалил NUT из автозапуска. И вообще, надо его будет снести за ненадобностью. В сети нашел простой пример, как по SNMP получать сведения от ИБП, так что, буду сам мониторить. С помощью libssh по ключам можно логиниться рутом на удаленных машинах и запускать "poweroff". Пинговать в течение какого-то времени, а затем выключать питание. На релюшках есть входы через опторазвязки, туда можно подключить концевик, управляющий осушителем — контролировать, закрыт ли купол. Правда, в старых системах управления астросибовскими куполами нет вотчдога, т.е. если компьютер отключится, закрыть купол не получится. Надо подумать, как это сделать. Я все больше склоняюсь к тому, чтобы написать свою прошивку (хоть трассировка на плате и ужасная). В оригинале и разрешающий сигнал с частотников не снимается, когда двигатели не вращаются (на телескопе 2 я решил эту проблему "приблудой", которая через реле управляется; правда, это лишило возможности открвать/закрывать телескоп с кнопок), и еще кой-какие косяки есть.
Главное, чтобы во время работы не помер пускатель…

P.S. Потихоньку по мере монтажа еще и зарисовываю, что я там наделал. Потом нужно будет в Qelectrotech схемки нарисовать. И какую-нибудь документацию написать. Эх, как же лень документацией заниматься!
P.P.S. А в каком-нибудь фашистсом пиндостане меня бы уволили за "overqualified work".

Сегодня решил лазанью сделать: что-то давно я ее не готовил…
Болоньезе (без сельдерея, не добавляю его вообще) несколько банок в прошлом году накрутил. Полез за фаршем, а кусок маловат. Решил "разбавить" свëклой. Вполне вкусно получилось. Свекольного вкуса нет, все "по-классике" (моей). Правда, еще и бешамель без масла делал: внезапно оказалось, что сливочного масла в доме нет. Ну и ладно. Все равно съедобно.

Уже несколько раз у разных продавцов покупаю очки для пайки и прочих работ (т.к. я уже не только близорукостью страдаю, но и дальнозоркостью; да и катаракта потихоньку развивается). И в рюкзаке таскать надо (мало ли, на малых телескопах что делать), и дома, и на работе в двух местах минимум. Беру "нулевки" и слабые плюсы (+0.5, +0.75, +1). Для пайки мелочи лучше всего +0.5 подходит (ну, а LQFP я уже больше пары лет как паяю под "микроскопом").
Но вот что неудобно: все эти очки по 100-150 рублей за штучку имеют ужасно узкие оправы. Как минимум на сантиметр уже оправы моих очков "для дали". И больше минут 10-15 в них не посидишь: виски сдавливает, голова болеть начинает.
Ну неужели китайцам сложно эти "копеечные" очки и с нормальной оправой делать, а не только на лилипутов?

Решила дочка к завтрему сделать каждому однокласснику по значку с изображением енота той или иной военной специальности. И попыталась это сделать при помощи "шедеврума". И таки что бы вы думали? Получила картинки в фашистской форме с фашистскими флагами на рукаве! Вся техника была аналогичной: вертолеты, винтовки…
Ну, прямо "шедеврально" яндекс в лужу сел! Или это попытка диверсии?

Про добавление китайской CMOS Toupcam в свою CCD_capture я уже писал, с тех пор пытаюсь добавить эту камеру в deprecated (но пока другой нет) версию astrovideoguide (ссылку не даю, т.к. до сих пор так и не запушил: нечего коммитить, не работает).
Максимум, что я мог из нее выжать в CCD_capture, было около 30 (даже чуть больше) кадров в секунду. А в "астровидеогиде" на экспозиции 50мс у меня по кадру в три секунды, да и то, после 5-6 кадров "уходит в себя" и перестает выдавать изображения. Сижу, пытаюсь понять, как один и тот же код может так по-разному работать. Странно еще, что я "заказываю" по 100 изображений (trigger event), ничего не отменяю, но не вижу сообщений о том, что отрабатывает EventCallback. Такое впечатление, что оно там не в отдельном потоке крутится, а как конечный автомат работает!
Вот до чего доводит невозможность посмотреть исходники чужих библиотек… Ну вот что стоило китайцам взять, да выложить их? Боятся, что фашисты по судам затаскают (судя по тому, что на "астрофоруме" мне подкинули документацию на подобную камеру с фашистского сайта, китайцы, не мудрствуя лукаво, просто сперли кодовую базу)?
UPD: нашел проблемные места, заработало. А в диких подвисаниях в случае проблем я сам виноват: в ccd_capture у меня экспозиция в секундах, а здесь — в миллисекундах. Вот и выжидал я не 50мс + 2 на "всякий случай", а 52 секунды!

По-отдельности все четыре в своей "мультиплате" проверил. Т.к. использовал преобразователь 485+232 на CH340, быстрей 2Мбод проверить не вышло, нужно на pl2303 искать, или, что проще — два интерфейса между собой соединить.
А мне вчера дипсик как раз почти и сказал, что ошибка у меня в ДНК, когда я ему в отчаянии подсунул файл usart.c с вопросом: почему у меня четыре из пяти интерфейсов работают, а пятый в blocking_handler уходит. А вот нечего в 2 часа ночи код писать: я перепутал каналы rx/tx DMA для него, поэтому и уходило, т.к. обработчик прерывания был на rx (где он не нужен и прерывание не вызывается).
Еще мне дипсик посоветовал кольцевой режим DMA на прием использовать. Увеличил буфер до 1кБ, в итоге даже на больших скоростях данные туда-сюда без потерь просвистывают (а с блокировкой на время пересылки в USB, понятно, терялись на скоростях свыше 115200).
Как себя ведет ядро, я вообще уже не понимаю: мой tty_term после того, как откроет порт и отправит настройки, еще раз запрашивает реальные настройки шины и их отображает. Я натыкал кучу отладочного вывода, и вижу, что вообще get_linecoding ни разу не вызывался! Зато вижу, что как только воткнул железяку, несмотря на то, что ни к одному интерфейсу терминалы не подсоединены, ядро тут же отправляет set_linecoding на дефолтные настройки + set_control_line_state на DTR/RTS! А то я не мог понять: с чего бы у меня при включении, пока я еще ни одного терминала не открыл, на всех каналах U[S]ART разрешен!
Как говорится, «о, сколько нам открытий чудных»!.. Возможно, таки стоит не "классический CDC" сделать, а опять эмулятор PL2303. Плюсом есть то, что кернельный модуль ему при отключении честный break посылает (а у CDC надежда лишь на set_control_line_state с нулем), а также оно в маздае почти не работает.
Но таки надо будет подумать, как организовать проверку способностей железки при полной загруженности последовательных интерфейсов. А позже-то я еще и CAN с SSI добавлю…

P.S. Наткнулся на то, что пока тестировал 485, а 232 бездействовал, стоящий на плате MAX3232 сильно раскалился. Надо проверить: то ли чип бракованный, то ли где-то коротит (хотя, оба канала 232 работают). У меня подобное и на этой плате с ch340 бывало: туда ведь запилили сразу и 232, и 485. И бывало, что включишь 485, а он не работает, приходится еще раз переподключать. А потом работаешь себе с 485, а железяка раскаляется: греется MAX3232. А иногда вообще холодная…

Интересно, когда наступит тот день, когда ИИ на вопрос очередного погромиста "where is mistake?" ответит: "in your DNA!"?

Обнаружил пару косяков, почему у меня сразу не уходили сообщения с interrupt-driven каналов: я разрешил прерывания IDLE только на DMA-driven. В итоге, пока полбуфера не накопится, ничего в USB не выводилось. Поправил.
На больших скоростях выявил, что что-то приводит к "зависону". Однако, при отключении "шибко шустрого" интерфейса все опять работает, надо в gdb смотреть.
Потом обнаружил, что у меня не распаяны предохранители, питающие DC-DC на интерфейсы (а то думаю: DMA отработало нормально, а на выходе шиш — осциллографом смотрел). Подпаял перемычки из жилок МГТФ.
Воткнул преобразователь USB-232 на пятый интерфейс (interrupt-driven). Работает. Т.е. в интернетах не врали, что обычными оптопарами можно развязать 232 (точней, развязывается U[S]ART, а дальше с оптопар уже идет сигнал на MAX3232). Радостно заорал "Ура!". И тут же понял, что так не бывает!
ОК, проверил на DMA-driven канале: не работает (точней, работает TX с USB, но не работает RX с 232). Радостно заорал: "Ага!".
Отлаживаю, чего у меня за косяк с приемом. В терминале вижу (да-да, натыкал "отладочных printf'ов", можно сказать), что нет прерывания IDLE. Либо не пропаял Rx, либо… Ищу дальше.

Я раньше никогда не делал "полноценного" USB-CDC (т.е. когда берет из USB и отправляет в U[S]ART, и наоборот), а лишь использовал его как средство "общения" с МК. А тут… Нарисовал три функции: конфигурация порта, старт и стоп (где вообще USARTx->CR1=0).
Поотлаживал: почему-то логика общения ПК с CDC вообще ненормальная: сначала шлется DTR/RTS, а лишь затем — set_linecoding. Но это — цветочки! Прошлые настройки порта хранятся в ядре. И если ты повторно открываешь порт со старыми настройками, никакого set_linecoding не будет. Что интересно, get_linecoding я вообще не видел. Т.е. ядро считает, что порт УЖЕ по дефолту будет на 9600 работать.
Вот и думаю, как поступать: либо в функции "стоп" только останавливать U[S]ART, не сбрасывая настройки, либо же и в set_clstate, и в set_linecoding проводить (т.е. иногда - дважды) всю тряхомудию. Первый вариант означает, что еще и нужно будет заранее вызвать конфигуратор с дефолтными скоростями.
Ну, да ладно: пока нужно отладить косяк с USB (почему-то МК отправляет данные из кольцевого буфера порта в USB лишь когда что-то по этому же USB получает; а на интерфейсе конфигурации, который "ненастоящий" CDC, такого нет).