| Автор |
Сообщение |
|
Сообщение создано: 24. 02. 2020 [21:44]
|
|
zmulian
Дмитрий Злобин
![]()
Зарегистрирован(а) с: 27.06.2016
Сообщения: 11
|
Доброго времени суток.....
Столкнулся с неприятной особенностью модуля.
Модуль работает замечательно, НО на хороших линиях.
На плохих линиях (сотовая связь паршивая), при потере пакета, данные падают в 0.
То есть данные валидны, но равны нулю.
При шлюзовании такого нет (если данные есть, то они валидны).
Может я что то не так делаю?
Как можно этого избежать?
По большому счету к скаде это не относиться. Но кто и как борется с плохими линиями связи? Связь наладить проблематично, если только направленной антенной (только это еще не пробовал).
Плохая сотовая связь на одном объекте из четырех. В некоторые периоды суток потери пакетов 2 - 4%. И вместо EVAL на OPC UA получаем 0 (соединение не теряется, входной транспорт соединение держит). Со всеми отсюда вытекающими.
История такова. Имеется четыре объекта (котельные), сервер (собирает объекты в кучу), рабочее место (даже часто не одно). На всех OpenSCADA. Все устройства территориально разбросаны. Связь модемная. На одном из объектов очень хреновая. Смена сотовых операторов проблему не решает. Худо бедно работает только мегафон. Остальные или не работают или почти не работают.
Попробовал вместо шлюзования использовать OPC UA для сбора данных с объектов. В принципе работа модуля и с модулем понравилась. Три объекта работают нормально, четвертый кочевряжиться. Из за вышеописанной особенности OPC UA придется снова перейти на шлюзование. Оптимизировать размеры пакетов в запросе и ответе (у наших сотовых телефонистов MTU 1420) путем разбивки контроллеров в шлюзе источников данных на более мелкие (чтобы запросы и ответы этих контроллеров умещались в один пакет (1420 байт в моем случае)).
Может у кого то знает другие варианты решения?
Еще одна особенность.
Данные с OPC UA не архивируются.
Версии 2606 и 2656.
[Сообщение редактировалось 1 раз(а), в последний раз 25.02.2020 в 04:01.]
|
|
Сообщение создано: 25. 02. 2020 [19:42]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"zmulian" wrote:
Столкнулся с неприятной особенностью модуля.
Модуль работает замечательно, НО на хороших линиях.
На плохих линиях (сотовая связь паршивая), при потере пакета, данные падают в 0.
Поскольку никто, кто может править или оплачивал такую работу, его не использовал в таких условиях то может и иметь такую особенность.
"zmulian" wrote:
Может у кого то знает другие варианты решения?
Зачем OPC-UA, если брать из OpenSCADA? Шлюз и используйте, а для уменьшения пакетов включайте упаковку собственного протокола OpenSCADA?!
Или ModBus, если нужно совсем малый трафик.
"zmulian" wrote:
Еще одна особенность.
Данные с OPC UA не архивируются.
Версии 2606 и 2656.
В ДемоБД всё архивирует, а у Вас, с такой связью, похоже нечего архивировать!
А вообще, на таких каналах нужна функция буферирования (небольшой архив) на удалённой стороне и подгрузка его участков для компенсации потери данных, что шлюз делать и умеет. Потенциально есть и у OPC-UA такая служба (Hystory), которая не реализована.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 25. 02. 2020 [21:21]
|
|
zmulian
Дмитрий Злобин
![]()
Зарегистрирован(а) с: 27.06.2016
Сообщения: 11
|
"roman" wrote:
Зачем OPC-UA, если брать из OpenSCADA? Шлюз и используйте, а для уменьшения пакетов включайте упаковку собственного протокола OpenSCADA?!
Или ModBus, если нужно совсем малый трафик.
Хм. Мне это решение в голову не пришло.
То есть на удаленной (с плохой связью) стороне делаем ModBus сервер и к нему цепляемся? Я правильно понимаю?
В принципе очень экономично. Максимальный размер пакета при такой реализации около 900 байт. Хватит с запасом.
Спасибо за подсказку в реализации.
Еще бы как то данные восстанавливать при обрыве (как в шлюзовании)... Вообще такое возможно?
Нужно запихать в один пакет 250 - 300 переменных (пусть и в сыром виде), основная масса и которых float. Это 850 - 900 байт. Возьмем по максимуму 900 байт и все float.
При использовании компрессии собственного протокола OpenSCADA у меня возникают сомнения в возможности сжатия вообще.
Идентификаторы в запросе - ответе передаются в виде строки. При использовании минимального двух символьного буквенно - цифрового идентификатора увеличим размер еще на 500 - 600 байт. Итого 1400- 1500 байт несжатых. При сжатии уложусь в требуемое в любом случае. Плюс пути и имена контроллеров.
Выше приведенные выложил для оценки возможности использовать шлюзование с восстановлением при использовании SelfSystem (все остальное просто повырубаю) с максимальной компрессией чтобы перетащить контроллер (ну скажем из логического уровня) с числом параметров 250 - 300 и с минимальным идентификатором параметра 2 буквенно - цифровых символа.
Мой путь размышления верен? Или я что то еще не учел?
Заранее спасибо...
[Сообщение редактировалось 2 раз(а), в последний раз 25.02.2020 в 22:07.]
|
|
Сообщение создано: 26. 02. 2020 [21:29]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
"zmulian" wrote:
Еще бы как то данные восстанавливать при обрыве (как в шлюзовании)... Вообще такое возможно?
ModBus для такого очень плохо подходит.
"zmulian" wrote:
При использовании компрессии собственного протокола OpenSCADA у меня возникают сомнения в возможности сжатия вообще.
Включить и посмотреть, а вообще на максимальном уровне сжатия там около 3 раз меньше трафик.
"zmulian" wrote:
Идентификаторы в запросе - ответе передаются в виде строки. При использовании минимального двух символьного буквенно - цифрового идентификатора увеличим размер еще на 500 - 600 байт. Итого 1400- 1500 байт несжатых.
У транспорта есть возможность указать максимальный размер TCP-пакета (MSS), именно для таких случаев!
P.S. Какое отношение это вообще уже имеет к теме форума, это уже консультации, чего я тут не предоставляю!
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 09. 05. 2020 [11:55]
|
|
margin
Виталий Слюсаренко
Зарегистрирован(а) с: 08.05.2020
Сообщения: 5
|
Пытаюсь опрашивать контроллер Siemens S7-300 средствами OPC UA OpenSCADA (подключение через C343-1 Lean Ethernet коммуникационный модуль по TCP). Точно знаю, что контроллер слушает 102 порт, поэтому в настройках сервера указал его. При попытке создания подключения получаю сообщение: "0x80ab0000:Remote host error:Error requesting: Connection reset by peer (104)". По смыслу сообщения ясно, что сервер видит контроллер, да и ping проходит и другие OPC серверы устанавливают связь без проблем (на Windows: Softing OPC, IGSS). На контроллере все настройки дефолтные, но он почему-то сбрасывает соединение. Можно ли что-то сделать со стороны сервера?
|
|
Сообщение создано: 09. 05. 2020 [18:50]
|
|
Sfinx2
Zubarev Dmitriy
Зарегистрирован(а) с: 03.02.2018
Сообщения: 29
|
А разве для C343-1 заявлена поддержка OPC UA? Мне кажется что логичнее применять компонент "Сбор данных SIEMENS"
[Сообщение редактировалось 1 раз(а), в последний раз 09.05.2020 в 18:52.]
|
|
Сообщение создано: 09. 05. 2020 [21:19]
|
|
margin
Виталий Слюсаренко
Зарегистрирован(а) с: 08.05.2020
Сообщения: 5
|
"Sfinx2" wrote:
А разве для C343-1 заявлена поддержка OPC UA? Мне кажется что логичнее применять компонент "Сбор данных SIEMENS"
Про поддержку Profinet модулем "Сбор данных SIEMENS" не было написано в старой версии Wiki, коию я читал - моё упущение. Буду пробовать.
Не знал, что именно OPC UA должен поддерживаться хардверно.
Спасибо за лаконичный, но очень информативный для меня ответ.
|
|
Сообщение создано: 31. 05. 2021 [11:38]
|
|
AlexXine
Виталий Кочетков
Зарегистрирован(а) с: 31.05.2021
Сообщения: 1
|
День добрый.
Есть необходимость получать исторические данные с OpenSCADA по протоколу OPC UA.
Не подскажите как это реализовать?
Суть идеи. OpenSCADA получает данные с приборов по ModBUS TCP и архивирует их.
Архивные же данные с каналов будут отдаваться по OPC UA произвольно.
|
