ПРоблема ТМ6+MasterOPC+SMH2Gi - Page 2

telem · 25.07.2015, 21:43

Цитата:

Сообщение от Max2114

...Прописываем контроллер в OPC сервере, проверяем - данные приходят правильные. Добавляем данные в скаду. Запускаем скаду - все в норме, все работает. Уходим домой. Утром приходим - на новых экранах с 2Gi какая-то "ересь". Что-то читает, но "не то"...
...Пока не проводили тест с выключением/включением питания контроллера - это еще впереди. Пробовали выключить скаду и запустить опрос непосредственно из OPC сервера. Все нормально. Запускаем скаду - опять "ересь". Перепрошиваем контроллер (скада в это время работает) - данные исправляются. Когда начинаются такие "чудеса" - в это время старые контроллеры показывают данные вполне корректно.
Попробуем сделать выкл/вкл питания контроллера и посмотрим что это даст...

Max2114, а можно у Вас поинтересоваться так, для себя, почему используется связка 2Gi-ОРС-ТМ6? Встроенный в ТМ6 драйвер модбас не корректно работает, или проблемы какие с лицензированием ТМ6, или еще что-то? Повторюсь, из чистого любопытства, чтобы при случае на грабли не наступить.

Max2114 · 26.07.2015, 22:53

Цитата:

Сообщение от telem

Max2114, а можно у Вас поинтересоваться так, для себя, почему используется связка 2Gi-ОРС-ТМ6? Встроенный в ТМ6 драйвер модбас не корректно работает, или проблемы какие с лицензированием ТМ6, или еще что-то? Повторюсь, из чистого любопытства, чтобы при случае на грабли не наступить.

С удовольствием расскажу. В нашей системе сейчас 116 контроллеров работающих по модбасТСП. Из них штук 80-90 pixel и smh2g. Так вот в тм6 есть встроенный драйвер модбаса. И изначально мы им пользовались. На 10 контроллерах он отлично работал. На 20 похуже... На 30 еще хуже... В итоге система почти умерла. Загрузка процессора подходила к 80 %... И система работала без зависаний 1-3 часа. Это происходило из-за того что пиксели постоянно разрывают соединение из-за превышения таймаута и скада только изанималась переподключениями к контроллерам. Эту проблему решать ни адастра ни сегнетики не хотят. В итоге перевод опроса контроллеров в опс сервер решил проблему. Нагрузка процессора сразу упала до 40-50%. Сейчас мы еще оптимизировали работу скады и нагрузка процессора стала 20-30%.

Arsie · 27.07.2015, 11:07

Цитата:

Сообщение от Max2114

С удовольствием расскажу.

На 30 еще хуже... В итоге система почти умерла. Загрузка процессора подходила к 80 %...

Это происходило из-за того что пиксели постоянно разрывают соединение из-за превышения таймаута и скада только изанималась переподключениями к контроллерам.

Эту проблему решать ни адастра ни сегнетики не хотят.

С точки зрения программиста я вообще не вижу в этом проблемы. Запрос "открыть сокет" с последующим уходом в слип до прихода ответа - на древнем Кор Соло 1.86 МГц так за секунду открывается около 9 тысяч соединений при загрузке единственного ядра в 60%.

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

Цитата:

Сообщение от Max2114

В итоге перевод опроса контроллеров в опс сервер решил проблему. Нагрузка процессора сразу упала до 40-50%. Сейчас мы еще оптимизировали работу скады и нагрузка процессора стала 20-30%.

Получается, что в Инсате профессиональный уровень программистов сервера всё же выше, чем в Адастре))

PS. Разрыв соединения - штатное для TCP событие. И для скоростей Пикселя не приводящее к потере производительности. Если, конечно, сервер не написан на вижл бейсике с использованием таких крутых операторов, как GOTO.

Max2114 · 27.07.2015, 11:23

Цитата:

Сообщение от Arsie

Получается, что в Инсате профессиональный уровень программистов сервера всё же выше, чем в Адастре))

Не факт. Просто отдельный небольшой софт типа OPC сервера и написать проще и откорректировать проще, чем большую систему типа ТМ6.
В ТМ6 мне нравится подход к программированию. Все делается в одной оболочке, а не в нескольких программах, как у других. И в одном дереве видно все - и связи с контроллерами и экраны. Но вот есть некоторые моменты (вернее как - изначальные надоработки) которые они принципиально переделывать не хотят. И именно это меня отталкивает от дальнейшей работы с их системой. (К примеру тормознутость графики. Вообще они сами рекомендуют использовать графику по минимуму. Или вот работа с теми же пикселями встроеными драйверами модбаса. Тормознутость обмена по сети тоже напрягает).
PS У вас (сегнетикса) тоже есть ряд недоработок по железу, которые меня сильно напрягают. Однако пока этого недостаточно для того, чтобы я отказался от вашей продукции.

Arsie · 27.07.2015, 12:11

Цитата:

Сообщение от Max2114

Не факт. Просто отдельный небольшой софт типа OPC сервера и написать проще и откорректировать проще, чем большую систему типа ТМ6.

В ТМ6 это точно такой же сервер, как и везде. OPC-сервер, это "драйвер", переводящий протокол контроллера в стандартный упрощённый DDE.

Драйверы протоколов ТМ6 - это не что иное, как те же самые серверы, переводящие протоколы контроллеров во внутренний протокол ТМ6. Это самое простое и верное решение. И я не удивлюсь, что этот самый внутренний протокол - тот же самый DDE.

Просто, когда "драйвер", за это можно снять доп. денег. Вот и весь секрет. И часто это путь в никуда - если бы у них не было поддержки стандартного OPC, вы бы не смогли использовать их СКАДУ в своей задаче.

Max2114 · 27.07.2015, 12:18

Цитата:

Сообщение от Arsie

В ТМ6 это точно такой же сервер, как и везде. OPC-сервер, это "драйвер", переводящий протокол контроллера в стандартный упрощённый DDE.

Драйверы протоколов ТМ6 - это не что иное, как те же самые серверы, переводящие протоколы контроллеров во внутренний протокол ТМ6. Это самое простое и верное решение. И я не удивлюсь, что этот самый внутренний протокол - тот же самый DDE.

Просто, когда "драйвер", за это можно снять доп. денег. Вот и весь секрет. И часто это путь в никуда - если бы у них не было поддержки стандартного OPC, вы бы не смогли использовать их СКАДУ в своей задаче.

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

Arsie · 27.07.2015, 13:29

Цитата:

Сообщение от Max2114

Хотя, насколько я понимаю, они просто просят у вас увеличить таймаут по окончании которого закрывается ТСП соединение.

Именно так. И увеличивать этот интервал нельзя. В нагруженных сетях это вообще убъёт обмен.

Max2114 · 27.07.2015, 13:38

Цитата:

Сообщение от Arsie

Именно так. И увеличивать этот интервал нельзя. В нагруженных сетях это вообще убъёт обмен.

Вот и их нежелание устранять их же "касяки" в итоге привело меня к тому, что я в новых объектах отказался от ТМ6 (хотя мне и удобно в ней работать и у меня есть набор USB-ключей разработчика, и сертификат о прохождении у них расширенного курса обучения).
А больше всего "убил" их ответ... когда мы налаживали последню систему диспетчеризации (в которую сейчас добавили еще SMH2Gi) "Мы не знаю почему ваша система зависает. Попробуйте переустановить Window, поставить серверную версию. Поменяйте видеокарту, откажитесь от графики." Это при том, что мы высылали им исходники и логи всего происходящего. В итоге мы сдавали систему и при комиссии только одна мысль была "лишь бы система не зависла"... однако "пронесло".

Max2114 · 28.07.2015, 07:38

Цитата:

Сообщение от Max2114

Прошло почти 2 часа. Пока все в норме! Видимо проблема решена

(я надеюсь). Завтра утром еще посмотрю и отпишусь все ли нормально. Прикольно видимо новые SMH2Gi все-таки слишком быстро отвечают на запрос (в отличии от пикселей и 2Г), вот опс сервер и путает их местами

В общем, в принципе проблема решена. Однако в ходе её решения мы заметили одну интересную особенность, о которой хотелось бы тут написать.
Как я уже писал, в нашей системе 116 контроллеров. Больше всего там пикселей и SMH2G. Ранее было несколько SMH2Gi, но вот новое здание мы сделали практически все на SMH2Gi, и проблемы появились именно с ними. Детально изучая логи, наш программист нашел момент, когда данные "корявятся" (если выключить контроль Transaction ID). Периодически при опросе контроллера возникают коллизии (контроллер не отвечает за период таймаута). Так вот, если это происходит с SMH2Gi, то получается такая картина:
ОПС сервер посылает запрос
Не получает ответ
ОПС сервер посылает следующий запрос
Приходит ответ от предыдущего запроса
ОПС сервер послаает следующий запрос
Приходит ответ от предыдущего запроса...
И так далее.
Почему-то в ситауции с контроллером SMH2G картина другая:
ОПС сервер посылает запрос
Не получает ответ
ОПС сервер посылает следующий запрос
Приходит ответ на текущий запрос
и так далее

В итоге именно из-за этой особенности SMH2Gi и получается такой "сдвиг" запросов-ответов через некоторое время (после возникновения первой коллизии связи). В случае с Пикселями и СМЧ2Г такого не происходит почему-то. Вопрос - почему так получается?
В приложении лог с комментариями программиста, нашедшего данный "парадокс".
PS. Программист увеличил время ожидания ответа до 2 секунд и в итоге ответ от SMH2Gi приходит в нужный запрос. И в принципе можно даже отключить контроль Transaction ID (но мы оставили его включенным).

Arsie · 28.07.2015, 11:21

Цитата:

Сообщение от Max2114

Детально изучая логи, наш программист нашел момент, когда данные "корявятся" (если выключить контроль Transaction ID). Периодически при опросе контроллера возникают коллизии (контроллер не отвечает за период таймаута). Так вот, если это происходит с SMH2Gi, то получается такая картина:
ОПС сервер посылает запрос
Не получает ответ
ОПС сервер посылает следующий запрос
Приходит ответ от предыдущего запроса
ОПС сервер послаает следующий запрос
Приходит ответ от предыдущего запроса...
И так далее.

Честно говоря, это нормальная ситуация для TCP/IP, у которого "штатные" таймауты в нормальном состоянии до 15 секунд и выше.

А отсутствие слежения сервером за ID пакета - одна из серьёзнейших уязвимостей, постоянно используемая всяческими программами - взламывателями трафика. Называется она "подмена пакета".

Цитата:

Сообщение от Max2114

Почему-то в ситауции с контроллером SMH2G картина другая:
ОПС сервер посылает запрос
Не получает ответ
ОПС сервер посылает следующий запрос
Приходит ответ на текущий запрос
и так далее

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

А 2Gi может параллельно работать с несколькими сокетами, внутри каждого сокета ещё и очередь пакетов своя. Всё как и положено полному TCP/IP.