Контроллеры Pixel не работают со скадой ТМ6

[Smirnov_TR]

ТМ6 при подключении более 4 контроллеров выдает следующие диагностическое сообщения:
Статус соединения - 6 (ошибка соединения)
Код ошибки WSA - 10054 (Существующее соединение принудительно закрыто удаленной стороной. Обычно это случается в случае неожиданного останова приложения на удаленной стороне, при перезагрузке удаленной машины, или в случае, когда удаленный хост использует "жесткое закрытие" ( setsockopt(SO_LINGER)) удаленного сокета.)

ТМ6 при подключении менее 4 контроллеров выдает следующие диагностические сообщения:
Статус соединения - 2 (Соединение установленно)
Код ошибки WSA - 0 (нет ошибок)

В документации на контроллер Pixel сказано:
"Прежде чем передать данные, протокол TCP/IP устанавливает
соединение между двумя контроллерами на время обмена данными.
Когда обмен данными завершен, соединение разрывается. Сетевой
модуль «Ethernet» контроллера «Pixel» поддерживает подключение
только с одним контроллером в определенный момент времени. То есть к
Slave-контроллеру не может одновременно подключиться более одного
мастера. Если требуется опросить Slave-контроллер несколькими
мастерами, то это необходимо делать последовательно, т.е.
синхронизировать во времени процесс обращения мастеров к одному
Slave. Slave-контроллер отслеживает передачу данных от мастера по
установленному соединению. В случае отсутствия данных в течение
более чем 1,5 сек, Slave-контроллер сам закрывает соединение для
возможности опроса со стороны других мастеров."

Из анализа сложившейся ситуации можно сделать вывод:
ПРИ ПОДКЛЮЧЕНИИ МЕНЕЕ 4 КОНТРОЛЛЕРОВ КОМПЬЮТЕР УСПЕВАЕТ ОПРАШИВАТЬ КОНТРОЛЛЕРЫ ЗА ВРЕМЯ МЕНЕЕ 1,5 СЕК. ТО ЕСТЬ ДАННЫЕ ПОСТОЯННО ИДУТ И КОНТРОЛЛЕР НЕ СБРАСЫВАЕТ СОЕДИНЕНИЕ.
ПРИ ПОДКЛЮЧЕНИИ БОЛЕЕ 4 КОНТРОЛЛЕРОВ КОМПЬЮТЕР ЗАТРАЧИВАЕТ БОЛЬШЕ ВРЕМЕНИ НА ОПРОС КОНТРОЛЛЕРОВ. КАК ТОЛЬКО ПОТОК ДАННЫХ ПРЕРЫВАЕТСЯ НА БОЛЕЕ 1,5 СЕК КОНТРОЛЛЕР СБРАСЫВАЕТ СОЕДИНЕНИЕ.

[Arsie]

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

Из анализа сложившейся ситуации можно сделать вывод:
ПРИ ПОДКЛЮЧЕНИИ МЕНЕЕ 4 КОНТРОЛЛЕРОВ КОМПЬЮТЕР УСПЕВАЕТ ОПРАШИВАТЬ КОНТРОЛЛЕРЫ ЗА ВРЕМЯ МЕНЕЕ 1,5 СЕК. ТО ЕСТЬ ДАННЫЕ ПОСТОЯННО ИДУТ И КОНТРОЛЛЕР НЕ СБРАСЫВАЕТ СОЕДИНЕНИЕ.
ПРИ ПОДКЛЮЧЕНИИ БОЛЕЕ 4 КОНТРОЛЛЕРОВ КОМПЬЮТЕР ЗАТРАЧИВАЕТ БОЛЬШЕ ВРЕМЕНИ НА ОПРОС КОНТРОЛЛЕРОВ. КАК ТОЛЬКО ПОТОК ДАННЫХ ПРЕРЫВАЕТСЯ НА БОЛЕЕ 1,5 СЕК КОНТРОЛЛЕР СБРАСЫВАЕТ СОЕДИНЕНИЕ.

Неожиданно закрытое соединение - это нормальная ситуация в TCP/IP и клиент при обнаружении закрытого соединения всего лишь должен его переоткрыть.


Например, вот так:

13:20:16.453 [2984] (192.168.0.104:502) Подключение - ОК
13:20:16.453 [2984] (192.168.0.104:502) Tx: [12] 00 01 00 00 00 06 01 02 38 00 00 06
13:20:16.468 [2984] (192.168.0.104:502) Rx: [10] 00 01 00 00 00 04 01 02 01 09
13:20:26.828 [2320] (192.168.0.104:502) Закрытие соединения удаленным хостом (Connection Closed Gracefully)
13:20:26.836 [2984] (192.168.0.104:502) Подключение - ОК
13:20:26.836 [2984] (192.168.0.104:502) Tx: [12] 00 0D 00 00 00 06 01 04 A0 92 00 06
13:20:26.871 [2984] (192.168.0.104:502) Rx: [21] 00 0D 00 00 00 0F 01 04 0C 00 00 00 00 00 00 00 00 00 00 00 00


Обратите внимание, на переоткрывание соединения затрачено 0.008 сек.

[Arsie]

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

Из анализа сложившейся ситуации можно сделать вывод:
ПРИ ПОДКЛЮЧЕНИИ МЕНЕЕ 4 КОНТРОЛЛЕРОВ КОМПЬЮТЕР УСПЕВАЕТ ОПРАШИВАТЬ КОНТРОЛЛЕРЫ ЗА ВРЕМЯ МЕНЕЕ 1,5 СЕК. ТО ЕСТЬ ДАННЫЕ ПОСТОЯННО ИДУТ И КОНТРОЛЛЕР НЕ СБРАСЫВАЕТ СОЕДИНЕНИЕ.
ПРИ ПОДКЛЮЧЕНИИ БОЛЕЕ 4 КОНТРОЛЛЕРОВ КОМПЬЮТЕР ЗАТРАЧИВАЕТ БОЛЬШЕ ВРЕМЕНИ НА ОПРОС КОНТРОЛЛЕРОВ. КАК ТОЛЬКО ПОТОК ДАННЫХ ПРЕРЫВАЕТСЯ НА БОЛЕЕ 1,5 СЕК КОНТРОЛЛЕР СБРАСЫВАЕТ СОЕДИНЕНИЕ.

По скорости опроса хочу добавить замечание.

При использовании Автоскады, полный цикл опроса 15 вентустановок занимает около 0.4 секунд.

0.4 сек. - это много меньше, чем 1.5 сек.

[Smirnov_TR]

Тогда объясните почему скада нормально работает с 4 контроллерами а если подключить больше то возникают ошибки?

[Arsie]

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

Тогда объясните почему скада нормально работает с 4 контроллерами а если подключить больше то возникают ошибки?

Думаю, разработчики OPC-сервера не рассчитали все сценарии применения OPC-сервера.

Впадать в истерику при закрывании коннекта, тормозить с опросом настолько сильно, что даже по RS-485 опрос идёт быстрее. Я считаю это недобрым признаком.

В протоколе TCP/IP сервер вообще имеет возможность опросить все контроллеры одновременно, даже если их сотня. Это вопрос исключительно желания и квалификации разработчиков.

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

[Smirnov_TR]

В скаде ТМ6 нет ОПС сервера!

[Arsie]

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

В скаде ТМ6 нет ОПС сервера!

Вы просто о нём не знаете.

[Smirnov_TR]

Вот что пишет техподдержка ТМ6:

"Основная рекомендация - если возможно, то изменить время до разрыва соединения Pixel'ем с 1.5 секунды на более большее значение.

Если это не возможно, то в источниках первых десяти устройств Pixel в строке "Дополнительно" написать ключ "THONE;" без кавычек. В следующих десяти устройствах вписать ключ "TH14;". Далее в следующих десяти вписать ключ "TH15;". А в оставшихся последних десяти устройствах ничего дополнительно не вписывать.

Таким образом, у Вас все устройства будут опрашиваться в четырех отдельных потоках."

[Arsie]

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

Таким образом, у Вас все устройства будут опрашиваться в четырех отдельных потоках."

В наш век многоядерных процессоров ТМ6 по умолчанию работает в однопоточном режиме


Саннивейл, Калифорния -- 31.08.2004 -- Сегодня корпорация AMD объявила о проведении демонстрации первого в отрасли двухъядерного процессора класса x86. На демонстрации, состоявшейся в офисе корпорации в Остине, был представлен сервер HP ProLiant DL585 с четырьмя двухъядерными процессорами AMD Opteron™, изготовленными по технологии "кремний на диэлектрике" с нормой проектирования 90 нм.

[Nick]

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

В скаде ТМ6 нет ОПС сервера!

а вы возьмите и попробуйте использовать модбус ОРС сервер, и ТМ пусть работает через этот сервер. Так, как мне кажется, будет более правильно. Разработчики скады не могут быть ответственны на 100 за разработчиков оборудования, и вот эти попытки охватить как можно больше девайсов плохой ход со стороны адастры. Все получается криво и громоздко и все ползает и падает, а не работает как надо.

[Smirnov_TR]

У меня уже готовый проект в котором очень много каналов, если я буду работать через ОПС мне прийдется полностью переделывать проект, а времени остается очень мало до сдачи объекта. Трейс модовцы пеняют на контроллеры вы на тресмод. Нейжели нельзя было сделать стандартный протокол который бы работал со всеми устройствами и программами, зачем каждый разработчик старается вы*****ься и изменить стандарт??? Мне кто нибудь что то реальное и вняное может посоветовать?

[Arsie]

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

У меня уже готовый проект в котором очень много каналов, если я буду работать через ОПС мне прийдется полностью переделывать проект, а времени остается очень мало до сдачи объекта. Трейс модовцы пеняют на контроллеры вы на тресмод. Нейжели нельзя было сделать стандартный протокол который бы работал со всеми устройствами и программами, зачем каждый разработчик старается вы*****ься и изменить стандарт??? Мне кто нибудь что то реальное и вняное может посоветовать?

А он у нас стандартен донельзя. Откройте определяющий документ Modbus-TCP и убедитесь в этом.

И у них всё по стандарту.

Вы стали жертвой непродуманности серверной части. Именно из-за продуманности серверы IBM гораздо выше котируются, чем серверы D-Link. Хотя и там и там одна и та же операционка и очень похожие компоненты.

Кстати, на этом ваши мытарства могут не закончится. Если в вашу сеть добавится какой-нибудь локатор узлов, то всё опять завалится. Ведь проблема не устранена. Напоминаю, проблемой в вашей сети является неумение сервера переоткрывать закрытые соединения.

[Nick]

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

Нейжели нельзя было сделать стандартный протокол который бы работал со всеми устройствами и программами, зачем каждый разработчик старается вы*****ься и изменить стандарт??? Мне кто нибудь что то реальное и вняное может посоветовать?

уважаемый Smirnov_TR, изучите матчасть.
Я вам, как раз советую воспользоваться самым, чтоненаесть стандартным способом, который уже дефакто как 20 лет используется всеми разработчиками скада систем. если вы чуток погрузитесь в мир скада систем то увидите, что нормальные разработчики их не парятся связью с контроллерами. вся связь строится через ОПС серверы. И скаде без разницы как ОPС берет данные с PLC.

OPC это как раз то что вы сказали -

стандартный протокол который бы работал со всеми устройствами и программами

+ к сказанному - нами при разработке устройств, для обмена был взят старинный стандартный(стандартнее уж некуда) протокол MODBUS -

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

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

вопрос риторический - куда уж стандартнее?

[Smirnov_TR]

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

[Arsie]

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

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

www.modbus.org - это первоисточник.

Насчёт доступности не поручусь. Обычная техническая документация.

[Nick]

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

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

про OPC
http://ru.wikipedia.org/wiki/OPC
http://www.bookasutp.ru/Chapter9_2.aspx

[Smirnov_TR]

Получил ответ от ТМ6:
«Контроллеры 5, 23 и 24 на один из запросов (типа Rin_byte) возвращают сообщение с кодом ошибки. Код ошибки 0xa0 – в стандарте Modbus не описан. Что он означает, Вам необходимо узнать из описания контроллера. В соответствии с этой информацией надо будет ввести коррективы в проект.»

Что это за код ошибки?

[Smirnov_TR]

А вот полный текст ответа:

По результатам анализа присланных Вами материалов можно сделать следующие выводы.
1. Контроллеры с номерами 9, 12, 13, 14, 15, 16, 17, 22, 42, 51 не отвечают на попытки коннекта и в обмене не участвуют.

2. Контроллеры 5, 23 и 24 на один из запросов (типа Rin_byte) возвращают сообщение с кодом ошибки. Код ошибки 0xa0 – в стандарте Modbus не описан. Что он означает, Вам необходимо узнать из описания контроллера. В соответствии с этой информацией надо будет ввести коррективы в проект.

3. Подключающиеся контроллеры 2, 21, 25, 32, 37, включенные Вами в один поток TH15, регулярно разрывают связь, которая затем восстанавливается.
Причина такой ситуации состоит в том, что контроллер 32 запросы получает (это фиксируется в присланном Вами протоколе сетевого перехвата), но не отвечает на них.
В протоколе профайлера этому соответствуют строки вида
ERR_TCP:ModBus recieve zero bytes from 192.168.0.32:502 Alarm1-ШСВ23.

На ожидание ответа поток останавливается на время таймаута, соизмеримое с временем таймаутом на ожидание запроса, заданным в контроллерах.
Результатом является последовательный разрыв соединений контроллерами, входящими в этот поток.
По стандарту Modbus TCP устройство может не отвечать на полученный запрос только в двух случаях:
- запрос не соответствует заданному формату;
- в запросе указывается номер устройства, не равный номеру, указанному в настройках этого устройства.
Вам необходимо выяснить причину отсутствия ответа и соответственно скорректировать проект.

Если Вы удалите контроллер 32 (или отключите его Modbus-каналы), уже в текущем проекте Вы получите стабильный обмен.

При правильно построенных запросах в проекте указанных ошибок быть не должно.
Однако, нельзя исключать возможные сетевые коллизии, которые могут приводить к однократной потере запроса и/или ответа. В таком случае описанная выше ситуация может повториться.
Чтобы этого избежать, желательно изыскать в контроллерах возможность увеличения времени таймаута на разрыв соединения.

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

[Arsie]

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

Получил ответ от ТМ6:
«Контроллеры 5, 23 и 24 на один из запросов (типа Rin_byte) возвращают сообщение с кодом ошибки. Код ошибки 0xa0 – в стандарте Modbus не описан. Что он означает, Вам необходимо узнать из описания контроллера. В соответствии с этой информацией надо будет ввести коррективы в проект.»

Что это за код ошибки?

Покажите лог, из которого это видно. Т.е. в логе должны быть побайтово отображены запрос и ответ на этот запрос.

По идее, 0хА0 - это либо ответ на функцию 0х20, либо часть пакета просто потеряна.

[Arsie]

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

2. Контроллеры 5, 23 и 24 на один из запросов (типа Rin_byte) возвращают сообщение с кодом ошибки. Код ошибки 0xa0 – в стандарте Modbus не описан. Что он означает, Вам необходимо узнать из описания контроллера. В соответствии с этой информацией надо будет ввести коррективы в проект.

Я похоже понял, что они имеют ввиду. Вы запрашиваете несуществующие данные, на что контроллер отвечает базовым способом: возвратом запроса с установленным старшим битом в номере функции.

Кроме этого способа, существует и расширенный: не возврат запроса, а возврат специального фрейма "exception code". Похоже, что начало адреса "0хА0" сервер воспринимает как код ошибки, хотя ответ не соответствет формату "exception code".

Итого я вижу две проблемы:

1) У вас в скаде забита неправильная карта памяти, либо включена балансировка производительности для нормализации траффика (это умеют некоторые серверы)

2) Сервер трейсмода не умеет обрабатывать ошибки более ранних версий протокола

Это, как раз, хорошо объясняет почему 4 контроллера работают, а 5 нет. Карта памяти у вас очень фрагментирована и когда время опроса вырастает выше определённой величины, балансировщик производительности начинает затыкать "дырки" в карте памяти незначащими данными. Контроллеры отвечают ошибками. А сервер эти ошибки не может обработать.

Обмен заваливается.

[Arsie]

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

На самом деле этоМожно ли получить лог обмена сервера трейсмода я понятия не имею.

Вот именно поэтому я удаляю ваше письмо. Нечего давать постороннюю информацию там, где её не ждут.

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

[Max2114]

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

Вот именно поэтому я удаляю ваше письмо. Нечего давать постороннюю информацию там, где её не ждут.

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

У меня была похожая ситуация. Только у меня система сильно распределенная (12 отдельных зданий соединенных по оптоволокну). Подключил сначала все контроллеры одним потоком по Modbus TCP, часть из них "тормозила". Распределил в итоге все по четрым потокам - стало все отлично. В данный момент к системе подключено 39 контроллеров от Segentics (пиксели, SMH2G), и 11 овенов ПЛК100. Все подключено по ModbusTCP через встроенные драйвера ТрейсМоуда. В итоге подключу еще с десяток овенов (ПЛК100) и 15 пикселей/SMH2g... По итогам отпишусь о качестве свези (если кому будет интересно).

[Arsie]

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

По итогам отпишусь о качестве свези (если кому будет интересно).

Да, это будет интересно.