Друк

[Гість]

Ласкаво просимо, Гість. Будь ласка, увійдіть або зареєструйтеся.
16 Листопада 2024, 16:14:54

1 година 1 день 1 тиждень 1 місяць Назавжди

Увійти

[Новини]

•    Новини
•      Астрономія
•      Астрозаходи
•    Життя клуба
•      Новини
•      Проекти
•      Заходи
•      Звіти про спостереження
•      Документи
•    Статті
•      Обладнання та телескопи
•      Спостереження
•      Астрофотографія
•      Астрософт
•      Астрономія в Україні
•      Астрономи шуткують
•      Інше
•     
•      Файловий архів

Наш канал

Наші сайти

Астро-сайти

Програми

Наш канал

Наші сайти

Астро-сайти

Програми

[Andrei Ioda]

Буду по немного схемы подключения и документацию выкладывать.

Подякували

1 :MaxMan

[Andrei Ioda]

При подключении симки к gsm модулю, возникает возможность получать статус и управлять каналами питания. Прежде чем вставлять симку отключите запрос пин-кода.

Для нормальной работы ЦУП необходима установка сим-карты, в противном случае ЦУП будет подвисать на 20-30 сек каждые 5 минут. Дело в том, что каждые 5 минут ЦУП проверяет GSM модуль на его соединение с сетью, в случае отсутствия соединения, сбрасывает GSM модуль и ждет его инициализации. Вот на это требуются 20-30 секунд. При подключении GSM модуля к сети, светодиод на модуле начинает моргать реже.

Вид командной строки: P1234:R0-

sms команды такие:
R0- - выключить основное реле номер 1
R0+- включить основное реле номер 1
R0/ - выключить основное реле номер 1, пауза 2 секунды, включить
R0= - выключить основное реле номер 1, пауза 15 секунд, включить

P1234:E - сброс Ethernet карты.
P1234:S - получение СМС со статусом.

P.S. для unsafe реле R (relay) меняется на F (force). Что такое Safe и Unsafe? Safe (команда R) будет включать реле только в случае разомкнутого и замкнутого контактов Safe. Если один из этих контактов будет не соответствовать свою начальному значению, реле не включится. Для включения питания канала в режиме Safe (т.е. при активизации этого режима, один из контактов находится в активном режиме) можно воспользоваться кнопкой unSafe (команда F). Данная кнопка и команда включает реле в любом случае.

нужно учитывать следующее:

R0 - 1-й канал 12В
R1 - 2-й канал 12В
……..
R7 - 8-й канал 12В
R8 - 1-й канал 220В
R9 - 2-й канал 220В

[Andrei Ioda]

Web часть и настройки.

[Andrei Ioda]

верхняя часть и настройки.

[Andrei Ioda]

Ниже приведена принципиальная схема подключения ЦУП в моей обсерватории. Все потребители, за исключением купола, запитываются от 12В. Компьютер и монтировка питаются от 19В через DC-DC конвертеры. На выходах блока питания у меня 12.8В (сейчас правда схема немного изменена для тестирования одного нового решения и между БП, аккумуляторами и ЦУП стоит DC-DC конвертер на 12В 20А). На проводах безусловно есть падение напряжения и до потребителей доходит, где-то 12.5В.

[Andrei Ioda]

Каналы на 220В реверсивные. Это значит что при включении ЦУП каналы на 220В по умолчанию включены, тогда как каналы 12В, по умолчанию выключены. Команда API на включение и выключение каналов на 220В также реверсивна.

[Andrei Ioda]

Новая версия ЦУП.

Изменения:

1. Добавлены три реле для коммутации любых слаботочных цепей (без измерения токов, только коммутация).
2. Добавлен EPROM, на который записываются настройки ЦУП (IP адрес, маска, шлюз, пароль к СМС и т.д.).
3. Изменен переключатель питания ЦУП (общий/внешний). Сейчас он на три штырька (две позиции). Одна - общий, вторая - внешнее питание.
4. Отказались от CD карты. За год использования ни разу с нее не читал данные, все данные отправляются на веб сервер в интернете и от туда же считывается вся статистика.
5. Другие косметические изменения.

[Andrei Ioda]

Для документации.

[OlegBr]

Информация для потенциальных покупателей ЦУПа: Андрей оставил один ЦУП у меня.
Так что, если кому надо - обращайтесь 
Пару дней в светлое время суток все желающие могут протестировать работу сего устройства по адресу: http://khl63.net.ua:81/
Можно включать-выключать вентилятор на реле 1-220V и светодиодную лампу на реле 8-12V.
https://photos.app.goo.gl/GeBH9TDFXDw0kM182

[Вадим]

Прошу прощения, напомнило:

Подякували

1 :Берендей

[Буйный астроном]

Судя по схеме, приведённой выше, аккумулятор нужно периодически заряжать отдельно, так как от 12-ти вольт, ещё через резистор он априори не может зарядиться.  Или я не так понял его назначение? 

[Andrei Ioda]

Судя по схеме, приведённой выше, аккумулятор нужно периодически заряжать отдельно, так как от 12-ти вольт, ещё через резистор он априори не может зарядиться.  Или я не так понял его назначение? 

Можно и так, но аккумулятор предназначен в данной схеме как резерв на момент остановки всей обсерватории. Т.е. на минут 10, не более. Если есть желание работать намного дольше, то да... надо заряжать более высоким напряжением или ставить еще одни преобразователь DC-DC. Я у себя сейчас тестирую такой DC-DC на входе 13.6В и туда же подключен аккумулятор, а на выходе 12В и туда подключены все потребители обсерватории.

Подякували

1 :Буйный астроном

[@ndy]

Андрей, добрый день! Интересует данный девайс, как можно его получить? Спасибо.

[OlegBr]

К сведению потенциальных покупателей ЦУПа: тот экземпляр, который был у меня уже ушел к новому владельцу 

[Ветер]

Андрей, добрый день! Интересует данный девайс, как можно его получить? Спасибо.

День добрый! Прошлая партия уже разошлась. Сейчас запускаем новую, на модифицированной печатной плате, с учетом найденных нюансов. По срокам - будет готово ориентировочно в августе.

Подякували

1 :@ndy

[Andrei Ioda]

Прошу прощения за поздний ответ. Был в отпуске, в дикой природе. =)

Саша, выше, уже ответил. Работаем над новой версией. Есть небольшие изменения и доработки (не принципиальные). Если есть время подождать, то к концу августа выпустим (зависит, как скоро придут новые платы), если нет - то готовы сделать на текущей конфигурации.

Подякували

1 :@ndy

[gamba69]

Всем привет. У нас на DreamSky Observatory уже используется три устройства управления питанием двух разных
типов, "сведенных" в единую программу управления (C# WinForms). Добавляю в нее возможность получать данные и управлять
PCC (ЦУП), возник набор вопросов и пожеланий.

Вопросы, пожелания и просьбы по ПО и API PCC:
1. Зависимость от Интернета. Хотелось бы получить прошивку, которая не зависит от наличия инетернета. То есть все необходимые
данные, скрипты и т.д. для работы веб-интерфейса уже находятся на самом устройстве.
2. Чем отличаются команды R и F? (интересует максимально подробно и как они могут влиять друг на друга).
3. Можно ли доработать прошивку чтобы получать одним запросом текущее состояние устройства, полное.
Включая температуру, вольтажи-амперажи, состояние всех релешек? (Не критично, но все таки.)
На "сейчас" (для упрощения обмена) даю команду установки времени (с timestamp от now) и сразу запрос "за последние" 10 секунд (с timestamp от now минус 10).
Всяческий парсинг усложняется (не критично), температура приходит не всегда (подозреваю, внутренние опросы датчиков просто реже). Естественно,
имеется в виду JSON.
4. Можно ли доработать прошивку, чтобы веб-сервер отвечал "стандартно"? Работа с API
их С# приводит к ошибкам "неправильный формат ответа", лечится путем включения в проекте опции
<httpWebRequest useUnsafeHeaderParsing="true" />, что не комильфо. Подробности, что проверяется
при запросах здесь https://msdn.microsoft.com/en-us/library/system.net.configuration.httpwebrequestelement.useunsafeheaderparsing(v=vs.110).aspx
Подозреваю, все дело в символе новой строки.
5. Стабильность.
Хочется иметь стабильную работу на плохих/медленных/спутниковых каналах. Например, у меня через спутник до обсерватории часто не более
300 килобит + пинг 900 мсек. Время ответа на запрос (когда интерфейс "устаканился") - 3 секунды. Время прокачки
начальных данных > 1 минуты.
Софт на С# "сваливается" по таймаутам/обрывам примерно раз в 3-4 минуты (иногда чаще). На других устройствах подобного (хронического "свала") в
принципе не наблюдается (хорошо, он происходит на порядок реже, например. Или на два пордка.). Очевидно, что таймауты высокие и т.д. Существует
ли возможность как-то поднять стабильность работы веб-сервера со стороны Arduino (всякие там таймауты, скорость ответа и т.п.)?

[@ndy]

Андрей, спасибо за ответ! Мы с Александром все обсудили в личной переписке)

Прошу прощения за поздний ответ. Был в отпуске, в дикой природе. =)

Саша, выше, уже ответил. Работаем над новой версией. Есть небольшие изменения и доработки (не принципиальные). Если есть время подождать, то к концу августа выпустим (зависит, как скоро придут новые платы), если нет - то готовы сделать на текущей конфигурации.

[Andrei Ioda]

1. Зависимость от Интернета. Хотелось бы получить прошивку, которая не зависит от наличия инетернета. То есть все необходимые
данные, скрипты и т.д. для работы веб-интерфейса уже находятся на самом устройстве.

Скорее всего нет. Интернет нужен для скачивания данных с сервера, а не с самого ЦУП. С ЦУП данные идут только в реальном времени. Поднятие статистики с самого ЦУП подвешивает его на время считывания этих данных (часто надолго). Т.е. в это время он практически не работает.

2. Чем отличаются команды R и F? (интересует максимально подробно и как они могут влиять друг на друга).

Команда R включает/выключает реле при условии наличия safe перемычек. Т.е. если сработал разрыв или замыкания контакта safe команда R не пройдет. Команда F пройдет в любом случае.

3. Можно ли доработать прошивку чтобы получать одним запросом текущее состояние устройства, полное.
Включая температуру, вольтажи-амперажи, состояние всех релешек? (Не критично, но все таки.)
На "сейчас" (для упрощения обмена) даю команду установки времени (с timestamp от now) и сразу запрос "за последние" 10 секунд (с timestamp от now минус 10).
Всяческий парсинг усложняется (не критично), температура приходит не всегда (подозреваю, внутренние опросы датчиков просто реже). Естественно,
имеется в виду JSON.

Соединение может обрываться, если параллельно работает еще один процесс считывания данных.
Как часто надо получать данные?

4. Можно ли доработать прошивку, чтобы веб-сервер отвечал "стандартно"? Работа с API
их С# приводит к ошибкам "неправильный формат ответа", лечится путем включения в проекте опции
<httpWebRequest useUnsafeHeaderParsing="true" />, что не комильфо. Подробности, что проверяется
при запросах здесь https://msdn.microsoft.com/en-us/library/system.net.configuration.httpwebrequestelement.useunsafeheaderparsing(v=vs.110).aspx
Подозреваю, все дело в символе новой строки.

Думаю что можно.

5. Стабильность.
Хочется иметь стабильную работу на плохих/медленных/спутниковых каналах. Например, у меня через спутник до обсерватории часто не более
300 килобит + пинг 900 мсек. Время ответа на запрос (когда интерфейс "устаканился") - 3 секунды. Время прокачки
начальных данных > 1 минуты.
Софт на С# "сваливается" по таймаутам/обрывам примерно раз в 3-4 минуты (иногда чаще). На других устройствах подобного (хронического "свала") в
принципе не наблюдается (хорошо, он происходит на порядок реже, например. Или на два пордка.). Очевидно, что таймауты высокие и т.д. Существует
ли возможность как-то поднять стабильность работы веб-сервера со стороны Arduino (всякие там таймауты, скорость ответа и т.п.)?

Для плохих каналов есть SMS. В случае необходимости получения данных по "плохому каналу" надо много переделывать и многий функционал надо выбрасывать. Есть ли в этом смысл? Может проще заказать нормальный канал связи? У меня дома ADSL и по нему у меня проблем нет.

[Ветер]

4. Можно ли доработать прошивку, чтобы веб-сервер отвечал "стандартно"? Работа с API
их С# приводит к ошибкам "неправильный формат ответа", лечится путем включения в проекте опции
<httpWebRequest useUnsafeHeaderParsing="true" />, что не комильфо. Подробности, что проверяется
при запросах здесь https://msdn.microsoft.com/en-us/library/system.net.configuration.httpwebrequestelement.useunsafeheaderparsing(v=vs.110).aspx
Подозреваю, все дело в символе новой строки.

Добрый! Есть ли пожелания по спецификации запроса? Сейчас веб сервер выдает стандартный json, в котором содержатся накопленные данные. Периоды опроса датчиков тока и температуры отличаются.