Ткни нормальный ссылок, чтобы без зауми. Так сказать основной популярный документ для быстрого начала использования.PavelSaratov, 01 Февр. 18, 17:28
Нет у меня таких ссылок. Я с гитом работаю со второй половины нулевых, соответственно у меня очень давно не было нужды в чтении подобной литературы. Для старта стоит освоить хотя бы: git pull, git push, git status, git checkout, git branch, git add, git merge. И еще важно научится в файл .gitignore, поскольку исключение локальных сущностей файловой системы из репозитория -- частая задача (н-р, нередко сервис атакуется через атаку на репозиторий разработчика, поэтому мы не хотим вываливать наружу реквизиты доступа к чему-то там, которые могут быть прописаны в коде).
Если бы система давала четко следующие вещи - цены бы ей не былоPavelSaratov, 01 Февр. 18, 17:28
Павел, то что ты написал относится к DevOps. Стоить загуглить это слово. Я такого единого решения не знаю и вряд ли оно есть, т.к. противоречит unix-way и рабочему процессу разработки. ys1797 совершенно правильно написал, что нужна не единая система, а интерфейс над экосистемой. Правда я не понимаю зачем он нужен, т.к. если все делать по-взрослому, то многие задачи не пересекаются в одном человеке потому что рабочие процессы так построены. Разработчик не развертывает код в продакш и ему фиолетовы логи. А системному инженеру фиолетово на diff конкретного файла. А qa-инженеру фиолетово и на логи и на diff и т.д.
1 Всегда версия с датой.PavelSaratov, 01 Февр. 18, 17:28
И github и bitbucket показывают дату изменения напротив каждой сущности. Но если хочется всегда строго дату, а не "2 years ago \ 5 hours ago", то нужно поднимать свой хостинг репозиториев .
2 Легкость сравнения наглядного текущей версии и предыдущей, вплоть до битовой операции (ну тупо буква в строчке на C изменена).PavelSaratov, 01 Февр. 18, 17:28
git diff?
3 Легкость накатить на новую машину всю струкутру проета.PavelSaratov, 01 Февр. 18, 17:28
ansible \ docker \ vagrant \ fabric или что-то иное для управления конфигурациями.
4 Кто накатил версиюPavelSaratov, 01 Февр. 18, 17:28
Решается правами и логами. В первую очередь в голову пришла Kibana. Может быть Zabbix.
6 Возможность поднять эту систему вообще изолировано от интернета на простом NAS на каком-нибудь предприятии
Собственный хостинг системы контроля версий нужен. Все остальное в интернете не нуждается. Еще посмотри на GitLab, у них может быть что-то похожее.
Но основной совет -- гуглить DevOps. Начинать нужно с рабочих процессов, а не решений.
PavelSaratov
Доктор наук
Саратов
622 80
Отв.1101 02 Февр. 18, 14:41
Правда я не понимаю зачем он нужен, т.к. если все делать по-взрослому, то многие задачи не пересекаются в одном человеке потому что рабочие процессы так построены
В АСУ ТП сильно пересекаются. Когда остановка завода стоит от xxx долларов, внезапно все переключается на - доверяешь ты человеку или нет. В любом случае спасибо за информацию, буду изучать.
gindos
Студент
Южно-Сахалинск
39 12
Отв.1102 02 Февр. 18, 14:49, через 8 мин
Ткни нормальный ссылок, чтобы без зауми.PavelSaratov, 01 Февр. 18, 17:28
В него достаточно просто отправлять любые метрики откуда угодно и он прост в развертывании. Но возможно придется поплясать с их визуализацией. Мы в своей практике отправляем в заббикс метрики об упавших асинхронных (rabbitmq и celery) задачах и о elapsed time успешно завершенных. Kibana (особенно над Elasticsearch) конечно подходит лучше, о чем я и написал.
gol_avto
Доцент
Москва-Серпухов-Анапа
1.4K 473
Отв.1104 02 Февр. 18, 15:29, через 10 мин
отправляем в заббикс метрики об упавших асинхронныхlesbeg, 02 Февр. 18, 15:20
Коллеги. Здесь тема про автоматизацию ректификации. Давайте не флудить.
SedoY
Профессор
Новосибирск
5.1K 2.2K
Отв.1105 02 Февр. 18, 20:29
Когда остановка завода стоит от xxx долларовPavelSaratov, 02 Февр. 18, 14:41
сталкивался, трое суток в полной мобилизации. врагу не пожелаю. совет один начальственным работникам (тем кто решения принимают) семь раз подумать потом ещё столько же и еще и посоветоваться с теми кто ЗНАЕТ (с тем кто готовит решения для принятия), а не слушать немцев(и тд)... и только потом сделать.
PavelSaratov
Доктор наук
Саратов
622 80
Отв.1106 03 Февр. 18, 03:32
Зафлудили - согласен. Тем не менее спасибо всем поучаствовавшим.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.1107 03 Февр. 18, 04:00, через 28 мин
Нормально. Для основной темы я использую гипертекст. Так что такие (полезные) отвлечения нам совсем не помешают. Вообще-то, системы контроля версий - штука полезная в любом деле. Мне, например, очень часто, при работе с текстами, очень не хватает "штатных тупых и линейных возможностей undo-redo". Бывает статья совсем "не клеится" и с текстом работаешь несколько месяцев. В результате - куча бифуркаций (ветвлений), начинаешь сохранять промежуточные файлы, сочинять вроде бы осмысленные на первых порах имена... И все равно многое теряется. И детальная история, и, естественно, undo-redo в каждой ветке/файле... Приходится многое "пересочинять" по-новой. А вот текущее обсуждение git навеяло мыслишку попробовать его в качестве "ветвистого органайзера" для текстов и Mind Maps ;). Или, может быть, поискать на досуге что-нибудь более специализированное...
OldBean
Доцент
Красноярск
1K 1.4K
Отв.1108 03 Февр. 18, 05:42
17.3. Вариант Lite. Силовые модули
Ну хорошо. Вернемся к теме. Речь пойдет о силовых модулях для варианта LITE. Чтобы не наступать на те же грабли (которые "материализовались" при работе нескольких, "нагруженных" собственными проблемами, тинек на шине i2c), разработка следующего (силового) модуля была проведена тоже "по канонам": макет -> тестирование -> коррекция, если нужно -> печатная плата -> окончательное тестирование.
Унифицированный силовой модуль состоит из двух функциональных узлов: 1) твердотельное реле (ТТР) на базе симистора (BTA16) и моськи с нулем (MOC3083) и 2) "думатель" на базе микроконтроллера ATMega328p. Задача ТТР - непосредственно заниматься нагрузкой. Подключать ее к сети или отключать. В нужное время. Этот узел совершенно стандартный. Взят прямо из datasheet на моську. Много раз изготавливался. Поэтому никакого смысла макетировать ТТР нет. Поэтому при макетировании займемся только мозгами.
У "мозгов" силового модуля четыре задачи: 1) управлять твердотельным реле по алгоритму, зависящему от задачи, 2) "слушать" линию Zero и прерываться, если нужно, при поступлении фронта импульса на этой линии (сигнал формирует детектор нуля), 3) слушать линию Int, если это нужно по логике задачи и 4) общаться с малинкой по шине i2c для получения инструкций и параметров. Тестирование этого функционала было сделано на макете, подробное описание которого приведено в данном топике. В принципе, поскольку все уже проверено и работает достаточно стабильно, можно не повторять эти тесты и сразу перейти к изготовлению силовых модулей на перчатных платах. Но, если возникнет желание потренироваться в макетировании, программировании на Си и питоне, можно использовать этот топик в качестве подробной инструкции для очередного тренинга. Итак...
17.3.1. Вариант Lite. Силовые модули. Макет
Схема макета и вариант его реализации показан на рисунке ниже. Ненавязчивая автоматизация ректификационной установки. Автоматика. Данный макет - это мозг силового модуля в чистом виде (т.е. без ТТР), к которому добавлено парочка светодиодиков (к пинам PB0 и PB1) для дополнительной индикации правильности работы модуля с линиями Zero и Int. Естественно, эти линии, наряду с линиями i2c, нужно подключить к макету.
Текст тестовой прошивки приведен ниже Скрытый текст
В обработчике прерываний модуля TWI обрабатывается только одно событие - прием байта от малинки. В случае контроллера ТЭНа - это процент от номинальной мощности ТЭНа, который должен обеспечить контроллер. В случае клапана отбора - это тоже процент от максимальной скорости отбора (если понядобятся десятые доли процента - потом в протокол обмена прикладного уровня добавим еще один байт). Ну а если это контроллер контактора или клапана воды (т.е. бинарное/релейное исполнительное устройство), то ненулевой байт означает "включить", а нулевой "выключить". Первым силовым модулем будет контроллер контактора. Поэтому в тесте на макете реализуем именно этот случай: при приеме ненулевого байта мы зажигаем светодиодик, подключенный к пину PD0 (параллельно светодиодику моськи в силовом модуле), а при приеме нулевого - тушим.
В обработчике аппаратных прерываний (INT0) мы "ловим" фронты сигнала Zero, формируемые детектором нуля. Нули приходят довольно часто (100 раз в секунду), поэтому для "человеческой" индикации сигналов нуля, мы поступим следующим образом. Будем считать количество импульсов нуля 8-разрядным счетчиком (8-битная переменная cntr). Эта переменная автоматически будет сбрасываться на ноль, когда ее значение, при инкрементировании, превысит 255. Будем зажигать светодиодик, когда значение счетчика равно 0 и выключать, когда - 128. В результате этот светодиодик будет мигать с периодом 1.28 сек.
Сигнал на линии Int заводится на пин аппаратного прерывания INT1. В его обработчике мы будем зажигать второй светодиодик. К линии Int сейчас подключена только аварийная кнопочка крейта. Ей и воспользуемся. При нажатии ее (спад уровня на линии Int) будет генерироваться аппаратное прерывание INT1, в обработчике которого будем зажигать третий светодиодик, который подключен к пину PB1. Ну а выключаться этот светодиодик будет вместе с другим вспомогательным светодиодиком (который на пине PB0) в обработчике прерывайний INT0.
Ну и последний фрагмент прошивки - содержимое функции main(). Там - инициализация всей необходимой периферии (см. комментарии в тексте прошивки), разрешение глобальных прерываний (sei()) и, как положено, бесконечный цикл. Поскольку вся логика работы силового модуля тоже построена исключительно на прерываниях, главный цикл приложения пустой.
Собираем макет и прошиваем МК. Текст прошивки, который мы рассмотрели только что, есть в архиве в приложении к данному топику. Компилируем и прошиваем как обычно из geany. В этом же архиве есть готовый hex-файл.
После прошивки включаем входной автомат который подает на крейт 220 В. Светодиодик, подключенный к PB0, начнет размеренно мигать. Если мы нажмем аварийную кнопочку крейта, должен загореться и через некоторое время потухнуть второй светодиодик. Для дальнейшего тестирования нам нужно запустить тестовый скрипт test_09.py из архива топика:
python test_09.py
Текст этого скрипта ниже: Скрытый текст
# _*_ coding: utf8 _*_ import time # В этом модуле - задержки import smbus # В этом модуле - средства для работы с шиной i2c import math # В этом модуле математические функции
bus = smbus.SMBus(1) # Создаем объект "шина" addrRMS = 0x11 # Адрес датчика RMS на шине i2c addrCont = 0x12 # Адрес контроллера контактора cntr = 0 # Счетчик отсчетов RMS напряжения сети ce = 0; # Счетчик предположительных ошибок (сильных отклонений) a = 0.3838 # Калибровочный множитель для перевода кода в вольты vMin = 300.0; vMax = 0 # Минимум и максимум среднеквадратичного напряжения сети while True: bus.write_byte(addrRMS, 0); # Установка индекса байтов в датчике RMS на 0 crms = bus.read_byte(addrRMS) # Читаем 4 байта с датчика RMS (начиная с crms |= bus.read_byte(addrRMS) << 8 # младшего и собираем 32-разрядное слово crms |= bus.read_byte(addrRMS) << 16 # В этом слове - сумма квадратов кода АЦП crms |= bus.read_byte(addrRMS) << 24 # за 1 сек (5000 отсчетов) v = a*math.sqrt(crms*0.0002) # Вычисляем RMS (0.0002 это 1/5000) cntr += 1 if v < 190 or v > 260: ce += 1 # Возможные ошибки else: # Фиксируем экстремумы ср.кв.напряжения сети if v < vMin: vMin = v if v > vMax: vMax = v print "%d\t%d\t%.1f\t%d\t%.1f\t%.1f" % (cntr, crms, v, ce, vMin, vMax) # Немного помигаем светодиодиком на пине управления моськой bus.write_byte(addrCont, 1); time.sleep(0.3) bus.write_byte(addrCont, 0); time.sleep(0.1) bus.write_byte(addrCont, 1); time.sleep(0.1) bus.write_byte(addrCont, 0); time.sleep(0.1) bus.write_byte(addrCont, 1); time.sleep(0.3) bus.write_byte(addrCont, 0); time.sleep(0.3)
Он очень прост и подробно прокомментирован. После его запуска периодически начнет "сигналить" светодиодик, имитирующий моську.
Если все работает правильно - можно переходить к изготовлению печатный плат силовых модулей, их сборке и проверке. Минимальный набор для варианта LITE - три модуля: контроллер контактора, контроллер ТЭНа и контроллер клапана отбора. Первым будет контроллер контактора. Его мы и рассмотрим в следующем топике.
OldBean, на схеме С3 и С4 какого номинала? 22 чего?
OldBean
Доцент
Красноярск
1K 1.4K
Отв.1110 03 Февр. 18, 13:23, через 36 мин
22 чего?ZagAl, 03 Февр. 18, 12:47
Здесь - пикофарады.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.1111 03 Февр. 18, 17:00
17.3.2. Вариант Lite. Силовые модули. Печатная плата. Варианты разводки и реализации
"Мозги" силового модуля мы протестировали на макете в предыдущем топике. Все работает стабильно. Пора делать печатные платы. Окончательная схема силового модуля показана на рисунке ниже: Ненавязчивая автоматизация ректификационной установки. Автоматика. Схема очень проста. Разводка тоже. Ненавязчивая автоматизация ректификационной установки. Автоматика. Соответствующий lay-файл для Sprint-Layout60 находится в приложении к данному топику. Фотография готовой платы силового модуля, предназначенного для контроллера контактора показана ниже: Ненавязчивая автоматизация ректификационной установки. Автоматика. Напомню, что силовых модулей, в минимальной реализации варианта LITE, нам понадобится три штуки: контроллеры контактора, ТЭНа и клапана отбора. Если предполагается использовать несколько ТЭН-ов, то количество силовых модулей соотвественно увеличивается. Модули унифицированы, но различаются номиналами снабберных резисторов R2 и плавких предохранителей. Катушка контактора представляет собой индуктивную нагрузку. Резистор R2 в контроллере контактора представляет собой два последовательно соединенных резистора по 150 Ом. Предохранитель - 0.5А. Это же касается и контроллера клапана отбора. Номиналы те же. Для контроллера ТЭНа (это активная нагрузка) R2 представляет собой пару резисторов на 18 Ом и 22 Ом, а номинал предохранителя зависит от используемого ТЭНа. У меня рабочий ТЭН на 1.5кВт. Поэтому предохранитель там с небольшим запасом - на 10А.
Прошивки силовых модулей, естественно, тоже различаются. В следующих топиках мы рассмотрим прошивки конкретно для каждого модуля. Начнем с контроллера контактора. Исправления, другие варианты разводки и реализации платы силового модуля Варианты разводки от колеги BogAD (закладки PM-1 и PM-2). Вариант с дополнительными светодиодами здесь. Предыдущий топикВернуться к оглавлениюСледующий топик
Сергей, из [сообщение #13230607] с дополнительными светодиодами на Zero и Int мне понравилось. Сильно не усложняется реализация и визуальные индикаторы для быстрой визуальной диагностики. Собираюсь изменить свой вариант плат и добавить дополнительно 2 светодиода. Жду твоего мнения. Добавляем?
OldBean
Доцент
Красноярск
1K 1.4K
Отв.1113 03 Февр. 18, 19:09
Собираюсь изменить свой вариант плат и добавить дополнительно 2 светодиода.BogAD, 03 Февр. 18, 18:01
Честно говоря, не вижу смысла добавлять светодиоды на Zero и Int (причем, дублирующие!) на силовые модули. Если уж ставить светодиодик для контроля Zero, то один - на источник этого сигнала (т.е. - на датчик RMS с детектором нуля). А шина Int почти всегда подтянута к 3.3V. Что там контролировать? Кнопку?
А вот светодиодики параллельные моськам, которые стоят в силовых модулях, действительно очень удобны для визуального контроля. Как на стадии отладки, так и в реальной работе. При работе со старой системой я в этом четко убедился (там на контроллере ТЭНа светодиод стоит). Кстати, было несколько ситуаций, когда я очень пожалел, что на контроллер клапана отбора в старой системе светодионую индикацию не поставил. Поэтому в LITE светодиодики (параллельные моське) я поставил на все силовые модули.
BogAD
Кандидат наук
Красногорск - Белово
403 184
Отв.1114 03 Февр. 18, 19:28, через 20 мин
Наверно не так спросил (предложил). Шины-шинами, мои мысли на будущее, в смысле развития... Мы же LED не садим на сами шины. Зажигать их будем по заложенному алгоритму. Допустим, Int будет не только от кнопки срабатывать, а часть модулей, по анализу внешних "неисправимых" факторов, сможет аварийно остановить систему. Как понять, кто инициатор посадки Int на 0? Малинка об этом не скажет, если только не она инициатором была. Допустим, если модуль встал по сигналу Int, светим LED непрерывно. А если заставить мигать LEDом на модуле инициализатора аварии, то уже можно, беглым взглядом узнать виновника. По Zero. Синхронность их моргания даст понять, что модуль RMS исправен, сеть есть, а другие модули адекватные и производят корректно расчеты. По LED на МОСьках, тут вообще без споров.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.1115 04 Февр. 18, 05:55
Мы же LED не садим на сами шины. Зажигать их будем по заложенному алгоритму.BogAD, 03 Февр. 18, 19:28
А..., теперь понял. Вы по сути предлагаете снабдить модули дополнительной индикацией общего характера. Т.е. то, от чего мы в концепте LITE как раз и отказались. В варианте LITE вывод всей информации (в том числе и диагностической) производится на терминал малинки. Или - на следующий уровень, в случае 3-уровневой системы. Такой подход должен был закрыть все вопросы диагностики. Т.к., все что модуль знает о себе родимом, он может сообщить и малинке. По i2c. Тем не менее (если, например, какие-то проблемы с i2c), всегда есть возможность подключить к штырькам, соединенным с пинами PB3, PB4 и PB5 (это MOSI, MISO и SCK) дополнительные светодиодики. Да, в принципе, хоть настоящий ЖК-дисплейчик! 5В и земля рядом тоже есть. Главное чтобы дисплей умел общаться по SPI. Этот интерфейс, кроме моментов прошивки самого МК, у нас всегда свободен. Понятно, что весь этот дополнительный сервис исполняется исключительно на уровне софта МК. Т.е. разводку плат корректировать не требуется.
BogAD
Кандидат наук
Красногорск - Белово
403 184
Отв.1116 04 Февр. 18, 11:27
Главное чтобы дисплей умел общаться по SPI. Этот интерфейс, кроме моментов прошивки самого МК, у нас всегда свободен.OldBean, 04 Февр. 18, 05:55
:) И этот вариант вполне. Хотя я хотел попроще, по твоей идеи на макетке:
Данный макет - это мозг силового модуля в чистом виде (т.е. без ТТР), к которому добавлено парочка светодиодиков (к пинам PB0 и PB1) для дополнительной индикации правильности работы модуля с линиями Zero и Int.OldBean, 03 Февр. 18, 05:42
Я предлагал силовые модули оснастить такими дополнительными светодиодиками (Zero и Int) на постоянной основе. А модуль RMS только светодиод Zero... Все LED Zero будет моргать синхронно с периодом 1,28 сек. LED Int - если модуль инициатор аварийного посыла по шине Int, моргаем. Если модуль остановился по сигналу Int - горит постоянно. Ну или наоборот... Разводку свою уже подправил. Вынес LED на передний торец плат. Проверю в выложу в общий доступ. Подсмотрено у промышленных Крейтов - там во всю используют светодиоды на лицевых панелях модулей для индикации наличия ключевых сигналов. Удобно быстро диагностироваться визуально.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.1117 04 Февр. 18, 13:35
Вынес LED на передний торец плат.BogAD, 04 Февр. 18, 11:27
Разноцветные - весьма живенько будет... ;) Если ничему не противоречит - цепляйте их на пины PB3, PB4 и PB5.
OldBean
Доцент
Красноярск
1K 1.4K
Отв.1118 04 Февр. 18, 14:19, через 45 мин
17.3.3. Вариант Lite. Силовые модули. Контроллер контактора. Прошивка
Контроллер контактора имеет самую простую логику работы и, соответственно - самую простую прошивку. По команде малинки он должен включать или выключать контактор. Прошивки других "релейных" устройств (контроллер клапана воды охлаждения, контроллер дополнительных "разгонных" ТЭН-ов и т.п.) будут совершенно аналогичными. Нужно будет только прописывать этим устройствам другие (уникальные) адреса на шине i2c. Для всех контроллеров релейных устройств договоримся так: если контроллер принимает от малинки ненулевой байт, то он включает нагрузку (т.е. на светодиод моськи подается высокий уровень), если нулевой - то выключает (низкий уровень на моську). Текст прошивки приведен ниже. Скрытый текст
Как легко видеть, код прошивки предельно прост. Все-таки глубокое "распараллеливание" системы на модули-атомы (как в железе, так и в софте) - дает положительные результаты! ;) В прошивке активирован только один обработчик прерывания - от модуля TWI, причем, в штатном режиме обрабатывается только одна ситуация - прием одного байта от малинки. Значение принятого байта анализируется тут же и, в зависимости от его значения, устанавливается уровень на пине PD0, к которому подключен светодиод моськи.
Текст прошивки (файл main.c), так же, как и готовый hex-файл (main.hex) есть в архиве топика. Компилируем и прошиваем контроллер контактора точно так же, как мы это делали для датчика RMS: при помощи программатора USBasp и geany (см. рисунок ниже): Ненавязчивая автоматизация ректификационной установки. Автоматика. На всех платах силовых модулей, параллельно светодиоду моськи, установлен вспомогательный индикаторный светодиод. Поэтому проверку модуля и отладку прошивки можно производить не подключая высокое напряжение. Не забываем также подключить модуль к шине i2c (см. рисунок выше).
После прошивки МК, тестируем модуль, как обычно, при помощи скрипта на питоне, который, естественно, запускаем на малинке. Текст скрипта приведен ниже. Соответствующий файл (test_10.py) есть в архиве данного топика. Скрытый текст
# _*_ coding: utf8 _*_ import time # В этом модуле - задержки import smbus # В этом модуле - средства для работы с шиной i2c import kbh # В этом модуле - функция kbhit() для работы с клавиатурой # в неблокирующем режиме #------------------------------------------------------------------------------- # Тестирование firmware контроллера контактора #------------------------------------------------------------------------------- bus = smbus.SMBus(1) # Создаем объект "шина" addrCont = 0x12 # Адрес контроллера контактора tt = kbh.TT(500) # Создаем объект - терминал, работающий в неблокирующем режиме # timeout = 500 ms while True: if tt.kbhit(): # Была нажата какая-то клавиша ch = tt.getch() # Получаем введенный символ if ch == 'q': break # Выход их программы elif ch == '0' : bus.write_byte(addrCont, 0) # Выключить контактор else: bus.write_byte(addrCont, 1) # Включить контактор
Данный скрипт, тек же, как и прошивка, тоже чрезвычайно прост: при нажатии на любую клавишу клавиатуры (кроме нуля), контактор включится и светодиодик на плате загорится. При нажатии клавиши "0", контактор выключится и светодиодик на плате погаснет.
Для того, чтобы нам не нужно было каждый раз после нажатия клавиши нажимать "Enter", я положил в архив небольшой модуль (kbh.py), в котором описан класс TT. При создании объекта этого класса у нас создается "неблокирующая" консоль (т.е. консоль не ждет нажатия клавиши "Enter"). Мы рассмотрим этот модуль подробнее как-нибудь попозже. А на данный момент нам достаточно знать, что при помощи метода kbhit() мы можем определить состояние клавиатуры (т.е. была или не была нажата какая-нибудь клавиша клавиатуры), а при помощи метода getch() - какой символ был введен при этом (т.е. какая клавиша была нажата). В программе мы должны создать объект этого класса - неблокирующий терминал (см. текст скрипта и соответствующие комментарии). После чего уже пользоваться нужными методами созданного объекта. Естественно, файл модуля kbh.py должен находиться в той же директории, что и сам скрипт.
Запускаем тестовый скрипт, нажимаем любую (ненулевую) клавишу. Лампочка на плате контролллера должна загореться. Нашимаем "0" - должна потухнуть. Если это так, то можем включить высокое (сеть) и послушать как щелкает контактор. Конечно, если к этому моменту контактор установлен и правильно подключен ;) Для тех, кто не любит работать с консолью, я подготовил вариант аналогичного тестового скрипта с GUI: Скрытый текст
# _*_ coding: utf8 _*_ import time # В этом модуле - задержки import smbus # В этом модуле - средства для работы с шиной i2c from Tkinter import * # Инструментарий для GUI #------------------------------------------------------------------------------- # Тестирование firmware контроллера контактора #------------------------------------------------------------------------------- addrC = 0x12 # Адрес контроллера контактора #------------------------------------------------------------------------------- def fC(): # Вызывается при изменении состояния чекбокса global vC bus.write_byte(addrC, vC.get()); #------------------------------------------------------------------------------- def wclose(): # Перед закрытием главного окна приложения выключим контактор bus.write_byte(addrC, 0); root.destroy() #------------------------------------------------------------------------------- bus = smbus.SMBus(1) # Создаем объект "шина i2c" root = Tk(); root.geometry('102x22') # Создаем и настраиваем главное окно root.protocol('WM_DELETE_WINDOW', wclose) vC = IntVar() # Состояние чекбокса будет связано с этой переменной # Создаем объект - чекбокс chC = Checkbutton(text = 'Контактор', command = fC, variable = vC) # Размещаем виджеты в главном окне chC.place(x = 0, y = 0) root.mainloop() # Главный цикл приложения
В архиве топика - файл test_10_gui.py. При запуске скрипта из консоли (python test_10_gui.py) на рабочем столе появится совсем крошечное окошечко с одним чекбоксом. Ненавязчивая автоматизация ректификационной установки. Автоматика. Щелкая левой клавишей мышки по чекбоксу мы можем включать и выключать контактор. Смотрим по светодиодику на плате контроллера. Если же контактор уже установлен и контроллер подключен, то мы должны услышать щелканье контактора. Появление или исчезновение напряжения на высоковольтной шине крейта можно проверить, например, вольтметром или лампочкой. Все. На этом изготовление и тестирование контроллера контактора будем считать законченным. Теперь мы можем установить его на законное место в крейте и окончательно проверить (рисунок ниже). Ненавязчивая автоматизация ректификационной установки. Автоматика. Можно двигаться дальше. В следующем топике мы рассмотрим прошивку второго силового модуля - контроллера ТЭНа. Предыдущий топикВернуться к оглавлениюСледующий топик