Показать сообщение отдельно
Старый 14.09.2016, 12:26   #4
Arsie
Сотрудник Segnetics
 
Аватара для Arsie
 
Регистрация: Jan 2006
Адрес: Russia, SPb
Сообщения: 18 019
Благодарил(а): 15 раз(а)
Поблагодарили: 655 раз(а) в 599 сообщениях
По умолчанию Ответ: Trase Mode ошибка 10054.

Цитата
Сообщение от OPServisN Посмотреть сообщение
Замечательно. Только в Техподдержке TraseMоde другая версия.

"Проблема нам известна.
В этих контроллерах (фирмы Senetics) искусственно разрывается соединение при возникновении паузы в запросах около 1 с. При большом количестве контроллеров и однопоточном трафике задержки между запросами весьма вероятны.
В текущем релизе Trace Mode 6 есть возможность организовать многопоточный режим обмена по Modbus TCP. В определенных пределах это проблему решает.
Мы обращались в фирму в 2014 г. с предложением изыскать способ увеличения блокировкочного таймаута. Ответа не получили."

Проблема есть, проблема известна, а результата нет. На объекте уже стоят 50 контроллеров. Менять? И отказываться от них в дальнейшем?

Да нет, версия не другая, техподдержка так и говорит - медленный опрос сервером, приводящий к закрыванию соединения сетевым модулем.

Я недавно отвечал на подобный вопрос, поэтому приведу вам часть своего ответа:


Цитата Время, на которое пропадает связь, можно сократить настройкой сервера. Как правило все нормальные серверы делают несколько попыток соединения (типично 3 раза) прежде, чем выдают статус "Нет связи". Далее, если все 3 попытки были неудачны, то следует пауза и следующие 3 попытки связи (типичное время 60 сек). У вас, похоже, количество попыток равно единице, да и сократить паузу до 5 секунд тоже ничего не мешает.


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

Нормальный лог выглядит так:

13:55:03.060 [996] (192.168.0.242:502) Tx: [12] 00 14 00 00 00 06 01 03 A4 12 00 02
13:55:03.067 [996] (192.168.0.242:502) Rx: [13] 00 14 00 00 00 07 01 03 04 00 00 00 00
13:55:04.002 [996] (192.168.0.242:502) Tx: [12] 00 15 00 00 00 06 01 02 38 00 00 06
13:55:07.003 [996] (192.168.0.242:502) Tx: [12] 00 16 00 00 00 06 01 02 38 00 00 06
13:55:10.004 [996] (192.168.0.242:502) Tx: [12] 00 17 00 00 00 06 01 02 38 00 00 06
13:55:13.004 [996] Ошибка: устройство не отвечает (192.168.0.242:502 Адрес:1)

Это я кабель откинул. Видно, что есть 3 попытки и только потом сервер отругался.

В вашем случае было бы что-то типа:

(192.168.0.242:502) Tx: [12] 00 14 00 00 00 06 01 03 A4 12 00 02
(192.168.0.242:502) Ошибка: connection refused
(192.168.0.242:502) Подключение - Ok
(192.168.0.242:502) Tx: [12] 00 14 00 00 00 06 01 03 A4 12 00 02
(192.168.0.242:502) Rx: [13] 00 14 00 00 00 07 01 03 04 00 00 00 00

Не знаю, какая именно у вас причина, но будет либо "Connection refused", либо "Connection reset by peer". В любом случае сервер должен проводить реконнект и ещё две попытки передать данные.

Тут вопрос, почему это делает Пиксель, вторичен. Причин может быть много и зависят они все от компьютера и состава сети. Первичен вопрос о том, почему сервер так реагирует на две некритические ошибки протокола TCP.

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

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

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

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

2) Количество контроллеров переваливает 1000 штук, полный опрос становится дольше часа, сетевые модули массово закрывают коннекты. Сегменты сети вываливаются в "Нет связи" на большие промежутки времени. Опять ничего не работает, опять орут дети, опять причитают женщины, а с головы пуско-наладчика падает клок седых волос.

3) Роутер затупил, потерял пакет данных (это TCP, по протоколу это штатная ситуация, а в случае китайского роутера так вообще ежесекундная обыденность на больших нагрузках), Но модуль настойчиво держит несуществующее уже соединение и сервер не может до него целый час достучаться. Ничего не работает, дети срывают голос, женщины выплакали все слёзы, пуско-наладчик кончает жизнь самоубийством.


Не хочу учить жизни программистов Адастры, но с их стороны нужно немного: внимательно вчитаться в стандарты TCP и сделать так, как там рекомендовано - время жизни пакета 15 секунд и три попытки возобновления коннекта до получения отказа. Повторю - это не какие-то космические исследования и уровень бога в программировании. Это просто обычное тупое чтение стандартов и следование как самим стандартам, так и рекомендациям к ним.

Вам же просто посоветую перейти на любой другой нормальный сервер. МастерOPC с недавних пор очень хорош. Старый добрый Lectus OPC/DDE server тоже играюче справляется с такими детскими ситуациями.

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


__________________
Программа делает то что написал программист, а не то что он хотел.

Добро всегда побеждает зло. Кто победил - тот и добрый.

Последний раз редактировалось Arsie, 14.09.2016 в 12:47
Arsie сейчас на форуме   Ответить с цитированием