Форум самогонщиков Сайт Барахолка Магазин Помощь солдатам

Ненавязчивая автоматизация ректификационной установки

Форум самогонщиков Автоматика
1 ... 53 54 55 56 57 58 59 ... 132 56
lesbeg Доктор наук Екатеринбург 657 458
Отв.1100  01 Февр. 18, 21:10
Ткни нормальный ссылок, чтобы без зауми. Так сказать основной популярный документ для быстрого начала использования.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
https://git-scm.com/book/ru/v2, почитать и попрактиковаться придётся, зауми нет, всё пошагово и толково.

Может быть Zabbix.lesbeg, 01 Февр. 18, 21:10
При чём тут Zabbix?
lesbeg Доктор наук Екатеринбург 657 458
Отв.1103  02 Февр. 18, 15:20, через 31 мин
При чём тут Zabbix?gindos, 02 Февр. 18, 14:49

В него достаточно просто отправлять любые метрики откуда угодно и он прост в развертывании. Но возможно придется поплясать с их визуализацией. Мы в своей практике отправляем в заббикс метрики об упавших асинхронных (rabbitmq и celery) задачах и о elapsed time успешно завершенных. Kibana (особенно над Elasticsearch) конечно подходит лучше, о чем я и написал.
gol_avto Доцент Москва - Серпухов - Анапа 1.3K 458
Отв.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, нужно подключить к макету.

Текст тестовой прошивки приведен ниже
Скрытый текст
#include <avr/io.h>
#include <util/twi.h>
#include <avr/interrupt.h>

#define F_CPU 16000000UL
#define ADDR 0x12      // Адрес устройства на шине I2C
                       
static volatile uint8_t v; // Значение принятого байта

static volatile uint8_t cntr = 0;
static volatile uint8_t iBut = 0;

//------------------------------------------------------------------------------
ISR(TWI_vect) { // Обработчик событий модуля TWI
 switch(TW_STATUS) {    // Статус - в 5 старших битах регистра TWSR
   case TW_SR_DATA_ACK: // Данные приняты, ACK отправлен - 0x80
     v = TWDR;
     if(v) PORTD |= _BV(PD0); // Высокий уровень если принят ненулевой байт
     else PORTD &= ~_BV(PD0); // Низкий в противном случае
     break;
   case TW_ST_SLA_ACK:  // Запрос SLA+R, ACK отправлен - 0xA8
     break;
   case TW_BUS_ERROR:   // Неверные условия "старт" или "стоп" - 0x00
     TWCR = _BV(TWIE) | _BV(TWINT) | _BV(TWEA) | _BV(TWEN); // "Сброс" TWI
     break;
 }
 TWCR |= _BV(TWINT);   // Флаг TWINT здесь НЕ очищается автоматически! Очистим.
}
//------------------------------------------------------------------------------
ISR(INT0_vect) { // Внешнее прерывание INT0 (Zero от детектора нуля)
 // Тест сигнала с детектора нуля
 if(++cntr == 0) PORTB |= _BV(PB0); // Включим светодионик на PB0
 if(cntr == 128) PORTB &= ~_BV(PB0); // Выключим
 if(iBut && cntr == 255) {PORTB &= ~_BV(PB1); iBut = 0; } // И его тоже... ;)
}
//------------------------------------------------------------------------------
ISR(INT1_vect) { // Внешнее прерывание INT1 (Сигнал Int на общей шине)
 // Тестирование линии Int (нужно нажимать на кнопочку)
 if(!iBut) { // Кнопочка не нажата
   PORTB |= _BV(PB1);
   iBut = 1;
 }
}
//------------------------------------------------------------------------------
int main(void) {
 DDRD = _BV(PD0); // Пин PD0 - на вывод (управление оптосимистором)
 DDRB = _BV(PB0) | _BV(PB1); // На вывод (для диагностики)
 // Инициализация TWI-модуля --------------------------------------------------
 TWAR = ADDR << 1;   // Адрес устройства - в старших 7 битах
 TWCR = _BV(TWIE);   // Разрешаем прерывания от TWI
 TWCR |= _BV(TWEA);  // Разрешаем подачу импульса ACK
 TWCR |= _BV(TWINT); // Очистим флаг TWINT (очищается при установке в 1)
 TWCR |= _BV(TWEN);  // Разрешаем работу TWI и активирует TWI-интерфейс
 // Инициализация внешнего прерывания INT0
 EICRA = _BV(ISC01) | _BV(ISC00); // Прерывания по фронту на пине PD2/INT0
 EIMSK = _BV(INT0); // Разрешаем внешние прерывания на пине PD2/INT0
 // Инициализация внешнего прерывания INT1
 EICRA |= _BV(ISC11); // Добавляем прерывания по спаду уровня на пине PD2/INT1
 EIMSK |= _BV(INT1); // Добавляем разрешение на внешние прерывания INT1
 
 sei(); // Разрешаем глобальные прерывания
 while(1) { // Бесконечный цикл
 }
 return 0;
}

Логика работы прошивки макета очень проста.

В обработчике прерываний модуля 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 - три модуля: контроллер контактора, контроллер ТЭНа и контроллер клапана отбора. Первым будет контроллер контактора. Его мы и рассмотрим в следующем топике.


Предыдущий топик  Вернуться к оглавлению  Следующий топик
038_pm_proto.JPG
038_pm_proto.JPG Ненавязчивая автоматизация ректификационной установки. Автоматика.

firmware.zip 3.5 Кб
ZagAl Доцент Прибалтика 1.9K 916
Отв.1109  03 Февр. 18, 12:47
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). Вариант с дополнительными светодиодами здесь.

Предыдущий топик  Вернуться к оглавлению  Следующий топик
039_pm_18.01.15.2_sch.gif
039_pm_18.01.15.2_sch.gif Ненавязчивая автоматизация ректификационной установки. Автоматика.
040_pm_18.01.15.2_pbc_02.gif
040_pm_18.01.15.2_pbc_02.gif Ненавязчивая автоматизация ректификационной установки. Автоматика.
041_pm_готовая_плата.JPG
041_pm_готовая_плата.JPG Ненавязчивая автоматизация ректификационной установки. Автоматика.

pm_18.01.15.2_pcb_02.lay6 47.5 Кб
BogAD Кандидат наук Красногорск - Белово 403 184
Отв.1112  03 Февр. 18, 18:01
Окончательная схема силового модуля показана на рисунке ниже:OldBean, 03 Февр. 18, 17:00

Сергей, из [сообщение #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. Для всех контроллеров релейных устройств договоримся так: если контроллер принимает от малинки ненулевой байт, то он включает нагрузку (т.е. на светодиод моськи подается высокий уровень), если нулевой - то выключает (низкий уровень на моську). Текст прошивки приведен ниже.
Скрытый текст
#include <avr/io.h>
#include <util/twi.h>
#include <avr/interrupt.h>

#define F_CPU 16000000UL
#define ADDR 0x12      // Адрес устройства на шине I2C
                       
static volatile uint8_t v; // Значение принятого байта
//------------------------------------------------------------------------------
ISR(TWI_vect) { // Обработчик событий модуля TWI
 switch(TW_STATUS) {    // Статус - в 5 старших битах регистра TWSR
   case TW_SR_DATA_ACK: // Данные приняты, ACK отправлен - 0x80
     v = TWDR;
     if(v) PORTD |= _BV(PD0); // Если принят ненулевой байт - высокий уровень
     else PORTD &= ~_BV(PD0); // В противном случае - низкий
     break;
   case TW_ST_SLA_ACK:  // Запрос SLA+R, ACK отправлен - 0xA8
     break;
   case TW_BUS_ERROR:   // Неверные условия "старт" или "стоп" - 0x00
     TWCR = _BV(TWIE) | _BV(TWINT) | _BV(TWEA) | _BV(TWEN); // "Сброс" TWI
     break;
 }
 TWCR |= _BV(TWINT);   // Флаг TWINT здесь НЕ очищается автоматически! Очистим.
}
//------------------------------------------------------------------------------
int main(void) {
 DDRD = _BV(PD0); // Пин PD0 - на вывод (управление оптосимистором)
 // Инициализация TWI-модуля --------------------------------------------------
 TWAR = ADDR << 1;   // Адрес устройства - в старших 7 битах
 TWCR = _BV(TWIE);   // Разрешаем прерывания от TWI
 TWCR |= _BV(TWEA);  // Разрешаем подачу импульса ACK
 TWCR |= _BV(TWINT); // Очистим флаг TWINT (очищается при установке в 1)
 TWCR |= _BV(TWEN);  // Разрешаем работу TWI и активирует TWI-интерфейс
 
 sei(); // Разрешаем глобальные прерывания
 while(1) { // Бесконечный цикл
 }
 return 0;
}
Как легко видеть, код прошивки предельно прост. Все-таки глубокое "распараллеливание" системы на модули-атомы (как в железе, так и в софте) - дает положительные результаты! ;) В прошивке активирован только один обработчик прерывания - от модуля 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) на рабочем столе появится совсем крошечное окошечко с одним чекбоксом.
Ненавязчивая автоматизация ректификационной установки
Ненавязчивая автоматизация ректификационной установки. Автоматика.

Щелкая левой клавишей мышки по чекбоксу мы можем включать и выключать контактор. Смотрим по светодиодику на плате контроллера. Если же контактор уже установлен и контроллер подключен, то мы должны услышать щелканье контактора. Появление или исчезновение напряжения на высоковольтной шине крейта можно проверить, например, вольтметром или лампочкой.

Все. На этом изготовление и тестирование контроллера контактора будем считать законченным. Теперь мы можем установить его на законное место в крейте и окончательно проверить (рисунок ниже).
 Ненавязчивая автоматизация ректификационной установки
Ненавязчивая автоматизация ректификационной установки. Автоматика.

Можно двигаться дальше. В следующем топике мы рассмотрим прошивку второго силового модуля - контроллера ТЭНа.

Предыдущий топик  Вернуться к оглавлению  Следующий топик
042_pm_прошивка_и_испытания.JPG
042_pm_прошивка_и_испытания.JPG Ненавязчивая автоматизация ректификационной установки. Автоматика.
043_test_10_gui.png
043_test_10_gui.png Ненавязчивая автоматизация ректификационной установки. Автоматика.
044_pm_контроллер_контактора_в_крейте.JPG
044_pm_контроллер_контактора_в_крейте.JPG Ненавязчивая автоматизация ректификационной установки. Автоматика.

firmware.zip 4.1 Кб
BogAD Кандидат наук Красногорск - Белово 403 184
Отв.1119  04 Февр. 18, 14:20, через 1 мин
цепляйте их на пины PB3, PB4 и PB5.OldBean, 04 Февр. 18, 13:35

Не вопрос! Как вариант:
 Ненавязчивая автоматизация ректификационной установки
Ненавязчивая автоматизация ректификационной установки. Автоматика.

тут заложены 4 LED.
3 на SPI,
1 на оптопару.

Что угодно "зашить" на SPI ножки можно. Согласен.
Допустим, 1 на Zero, 1 - Int, 1 - I2C
PM-1_1.4.jpg
PM-1_1.4.jpg Ненавязчивая автоматизация ректификационной установки. Автоматика.