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

А почему не хотите использовать Arduino pro mini, как в предыдущей версии автоматики? (или я что то пропустил?)

А почему не хотите использовать Arduino pro mingol_avto, 13 Янв. 18, 13:43

Не хочется делать бутерброд из разнокалиберных платок. А с точки зрения функциональности - все равно. МК тот же самый.

И, кстати, по поводу тех же самых земель. Сам не изучал, но колега sevpro очень сильно ругал в свое время разводку ардуинки с этой точки зрения. Ему в этих вопросах вполне можно доверять. Тем более, что у меня есть и некоторые косвенные подтверждения его выводов. В свое время я оценивал уровень шумов на входе АЦП ардуинки. "На глаз", конечно ;) И на макете, который описан чуть выше, тоже смотрел. Вчера. Есть устойчивое ощущение (по памяти), что в последнем случае шумы на входе АЦП заметно ниже. Сигнал "чистенький", красивый. А там (на ардуинке) был довольно "грязный". Я даже хотел увеличить фильтрующую емкость. По максимуму. Так что, лучше давайте сами разведем - сама "обвязка"-то МК минимальная.

Скорее всего - да. Жаль, конечно, уже собранные силовые модули ;( Но, думаю, проблем и возни с ними будет больше, чем спаять другие.OldBean, 13 Янв. 18, 13:28

А мне только что пришли с поднебесной десяток ATtiny и пяток ATMega328P. Хорошо  ATMega328P  5 заказал с запасом. Еще на почте лежат. Облом'с.
Поторопился... куда-то тиньку надо девать.

Так что, лучше давайте сами разведем - сама "обвязка"-то МК минимальная.OldBean, 13 Янв. 18, 14:15

Сделал попытку откорректировать платы под ATMega328P в DIP-корпусе.
Увлекся...  Перерисовал всё! Опять бегу вперед.
Сергей, жду замечаний.

ps Перезалил архив - нашел ошибку

сделал на Меге (ATMega328P). У нее - полная аппаратная реализация TWI/I2COldBean, 13 Янв. 18, 07:40

а не вернется проблема с перебоями в передаче данных по шине IIC, как в существующей версии автоматизации?

Поторопился... куда-то тиньку надо девать.BogAD, 13 Янв. 18, 15:30

Никуда ее девать не нужно. Эта тинька - отличная "рабочая лошадка" для "однопоточных" задач ;) Просто нужно будет как-нибудь сесть и сделать на ней программный 1-Wire Slave. Или - какой-нибудь другой 1-проводной протокол. Чтобы сильных ограничений на длину проводов (как i2c) не было. Может быть даже и USI к этому делу приспособить. В результате может получиться хороший "интеллектуальный" 10-разрядный АЦП для аналоговых датчиков (платиновые термометры, датчики давления и т.п.) с 1-проводным интерфейсом. Так что, я думаю, тиньки не пропадут ;)

жду замечанийBogAD, 13 Янв. 18, 15:30

Сначала есть вопрос по поводу расположения линий общей шины. У меня было так (считая с лицевой стороны, т.е. - с противоположной стороны от радиатора и 220 В шин):
  INT  GND  ZERO  GND  SDA  GND  SCL  GND  +5V  GND +3.3V  GND
А у Вас так:
  +5V  GND +3.3V  GND  SDA  GND  SCL  GND  ZERO  GND  INT  GND
Вопрос - зачем было изменено первоначальное расположение линий на общей шине? Были какие-то серьезные соображения по этому поводу, или получилось случайно?

а не вернется проблема с перебоями в передаче данных по шине IIC, как в существующей версии автоматизации?U-M, 13 Янв. 18, 18:40

Что-то мне подсказывает, что может быть и не вернется... ;)
Первопричина той самой проблемы со старшим битом - в некорректная обработка периферией малинки замедленную реакцию ардуинки при подготовке данных к передаче (ака стречинг). А сейчас, при работе с мегой, мы не используем, в отличие от ардуинки, библиотеку Wire, не производим накаких дополнительных вызовов callback-функций при подготовке данных к передаче малинке. Мы работаем непосредственно с модулем TWI (прямо в обработчике прерывания). Причем - на чистейшем Си ;)

Если не будет никаких "противопоказаний" ;) поставлю после выходных этот макет на многосуточный мониторинг сети. Проверим его в реальной работе. Заодно и посмотрим стабильность работы этой реализации i2c.

Ну и на самый худой конец - мы же ведь уже научились с этой бедой бороться на ардуинках. Этот же подход, если что, сработает и здесь ;)

Вопрос - зачем было изменено первоначальное расположение линий на общей шине? Были какие-то серьезные соображения по этому поводу, или получилось случайно?OldBean, 14 Янв. 18, 07:21

Скорей всего случайно.
Платы стал делать (первую версию) 5 декабря по постам твоим, Сергей, Вариант LITE. "Первая примерка" и фото Crate. Информации распиновки линии не было.
Расположил их по своему наитию.
Но были и серьезные соображения.
Придерживался правил: цепи питания +5В, +3В и I2C подальше от шин 220.
Кроме того, стремился уменьшить количество перемычек.
Можно пообсуждать, и прийти к общему стандарту по расспиновке.
В свете смены микропроцессора на ATMega328P, все равно надо делать новые модули.  

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

Для общего развития по поводу снабберных цепочек и супрессоров.
Очень познавательная статейка
Защита от перенапряжения: что выбрать?

Можно пообсуждать, и прийти к общему стандарту по расспиновке.
В свете смены микропроцессора на ATMega328P, все равно надо делать новые модули.BogAD, 14 Янв. 18, 09:59

Это можно. Но, поскольку у меня сам крейт-то уже готов, то я уже не совсем свободен в выборе геометрии плат.

1. Расстояние между цифровой шиной, шинами 220В и срезом платы (с той стороны, где симисторы и радиатор) у меня уже заданы de facto. Вряд ли есть смысл переделывать крейт.
2. Один цифровой модуль (ака "температурный сервер") на ATMega328P у меня уже тоже сделан. Кое что в порядке следования сигнальных линий мне несложно порезать и перекинуть. Например, порядок SCL и SDA. Но, без каких-то веских оснований, сильно злоупотреблять этим тоже не хотелось бы.
3. Ну и по плотности разводки. Поскольку, ориентация у нас традиционная (ЛУТ ;), то желательно полоски делать не сильно тонкими и не пропускать их между ножками микросхем ;) Это было бы негуманно по отношению к тем, кто не очень уверенно работает утюгом. Или делает это крайне редко.

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

Надо переварить...

На тему помехоустойчивости пара ссылок:
http://caxapa.ru/lib/emc_immunity.html
http://easyelectronics.ru/...era-likbez.html
https://myrobot.ru/articles/mc_stab.php

При совпадении инициируется прерывание, в обработчике которого как раз и производится старт преобразования АЦП.OldBean, 13 Янв. 18, 07:40

да ты извращенец ;o))) у ацп тыньки(меги) есть режим Free Running Conversion (непрерывное преобразование).

Почти два дня морщил мозг, пытаясь примирить независимые внешние события друг с другомOldBean, 13 Янв. 18, 07:40

в тыньке как и в меге приоритеты прерываний  нужно разруливать ручками иначе иначе - полный бардак

да ты извращенец ;o))) у ацп тыньки(меги) есть режим Free Running Conversion (непрерывное преобразование).m16, 14 Янв. 18, 20:35

Режим-то известный. Но контролировать частоту отсчетов (измерений) в этом режиме Вам придется за счет изменения времени преобразования ;) ИМХО, это как раз и будет истинным извращением... ;)

приоритеты прерываний  нужно разруливать ручкамиm16, 14 Янв. 18, 20:35

Тоже в курсе. Именно этим я и занимался. Интересно как бы Вы "разрулили" два независимых (случайных) внешних прерывания с одинаковым (причем, максимальным!) приоритетом... ;)
ИМХО, здесь можно только попытаться снизить вероятность конфликтов. Чем я и занимался. Но, увы, снизить частоту коллизий до разумных пределов не удалось. Максимальная безотказная наработка, которая получилась - 15-20 мин.  Поэтому одно событие (импульсы "старта" на шине i2c) пришлось просто физически исключить. Как класс ;) За счет аппаратной реализации TWI в мегах. Вот - суть преамбулы к датчику RMS в начале страницы.

2 BogAD
Я прикинул несколько разных вариантов разводок датчика RMS с детектором нуля. С горизонтальными и вертикальными ориентациями меги. Но вот этот вариант, который в приложении к данному топику, мне нравится больше других. Может быть на нем и остановиться? Есть какие-нибудь замечания по разводке?

---

Внесены следующие изменения:
1. Отказ от стандартного ISP6-разъема. Если отказаться от стандартного (2х3) ISP6-разъема для прошивки, которая нужна всего лишь раз, то разводка упрощается. Например, вместо стандартного переходника ISP10-ISP6 можно использовать нестандартный 1х5 + отдельный проводок не Reset.
2. Вывод сигнала Zero перекинул с PB1 на PB0.
3. Линии SDA и SCL поменял местами.
4. Померил - плату в области шифровой части общей шины можно спокойно миллиметров на 5 опустить вниз. Поэтому всю землю у разъема можно действительно провести снизу (как у Вас) и убрать эти жуткие перемычки по земле. Так что на плате датчика RMS осталась всего одна перемычка по питанию +5V
5. Размер платы 84х48 мм2. Высота для меня не критична, а по ширине - не хотелось бы вылезать за границы крейта (макс - 85).

---

Заодно, пока еще сегодня есть время, "прикинул" вариант силового модуля. Посмотрите, pls, тоже, если будет возможность.

---

15.01.2018 18.18. Исправил в разводке силового модуля ошибку. Перезагрузил файлы pm_xxx.xxx

2 U-M
Запустил обещанный тест (многодневный мониторинг сети). Начало - скриншот в приложении к топику.
Через пару-тройку дней посмотрим. Не стал усложнять тест (файлы писать и т.п.), т.к. отключений сети вроде бы не планируется. Так посмотрим, на терминале ;).

А не подумать ли нам об автономном модуле индикации на Arduino pro mini с 4-х разрядными индикаторами. Дисплей-дисплеем, а в бегущей строке совсем не комфортно выискивать нужные значения. Тем более, что до полноценного GUI так далеко, а может и вообще его не будет. Модули практически готовы, на шине I2C необходимая инфа имеется, только немного их доработать и получится хороший продукт.

Но контролировать частоту отсчетов (измерений) в этом режиме Вам придется за счет изменения времени преобразования OldBean, 15 Янв. 18, 03:09

глупости. зачем мне это знать если у меня в обработчике прерываний от ацп имеется счётчик  количества измерений значение которого используется в рассчёте среднеквадратичного? кстати максимальное количество измерений в режиме непрерывного преобразования за период сети = 307 при тактовой проца = 12,8 мгц. при 8(16)мгц  будет максимум 192 измерения

Интересно как бы Вы "разрулили" два независимых (случайных) внешних прерывания с одинаковым (причем, максимальным!) приоритетом... OldBean, 15 Янв. 18, 03:09

разрешением/запрещением прерываний в теле обработчика

А не подумать ли нам об автономном модуле индикации на Arduino pro mini с 4-х разрядными индикаторами. Дисплей-дисплеем, а в бегущей строке совсем не комфортно выискивать нужные значения. Тем более, что до полноценного GUI так далеко, а может и вообще его не будет.gol_avto, 15 Янв. 18, 08:33

При "живом" дисплее, рука-то подымется такое делать? ;) Если напрягают бегущие цифры - их легко остановить и в терминале. Будет неподвижная строка висеть, а циферки будут меняться. Но Вы же тогда не будете видеть (чувствовать) динамику. ИМХО, "портянка" в этом смысле гораздо удобнее и информативнее. Ну это, наверное, уже - дело привычки...

---

глупости. зачем мне это знатьm16, 15 Янв. 18, 08:48

А я, вообще-то, говорил не "знать", а контролировать. Т.е. - управлять частотой выборки данных. В этой версии у меня делается ровно 50 отсчетов за полупериод и суммирование идет в течение 1 сек. Т.е. всего суммируется 5000 отсчетов. По ним и рассчитывается RMS. Такой период нужен для корректного учета небольших пульсаций напряжения, возникающего при PDM-регулировании мощности (Брезенхеме). Там как раз полный цикл - 1 сек (при 1% точности регулировки). Кстати, все TrueRMS ваттметры (по крайней мере те, которые мне попадались) при некоторых (определенных) значениях PDM просто врут (я про мощность). Как раз из-за того, что период их усреднения меньше периода PDM (ака Брезенхема).

разрешением/запрещением прерываний в теле обработчикаm16, 15 Янв. 18, 08:48

Ну-ну... Либо ноль пропустите, либо шина колом встанет.

для этого нужно выделить временное  окно каждой процедуре  кратное полупериоду сетиm16, 15 Янв. 18, 08:48

После того, как я пришел к такой же грустной мысли засинхронизировать обмен с сетью и даже начал реализовывать этот вариант, я понял, что с этими извращениями нужно завязывать. И как можно скорее. Ибо одна из важнейших целей целей создания распределенных многопроцессорных систем автоматизации (как в данной ветке), это - как раз максимальное упрощение программирования за счет максимальной "атомизации" бизнес-логики. А тут получается все наоборот. После этого как раз и было принято правильное решение отказаться от тиньки в пользу меги.  

---

Не понял картинку :(

при PDM-регулировании мощности (Брезенхеме)OldBean, 15 Янв. 18, 09:31

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

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

Ну ладно. Мифами про страшные мерцания от Брезенхема пугайте кого-нибудь другого. Я с этим методом реально работаю уже давно. Много. И использую его не только в ректификационной установке.
Ну а с остальным (микроконтроллеры, аппаратные прерывания и коллизии), будем считать, что обменялись мнениями. Ну и более-менее разобрались. Спасибо за полезное обсуждение!

моргание бытового освещенияm16, 15 Янв. 18, 12:07

Такой же миф, на самом-то деле.

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

У меня мигает свет так как просадка по сети полюбому будет и так должно быть. За то помех нет.