WAGO, завис TCP. ??

Первоначально опубликовано Petrov

   На одном из объектов зависла связь по TCP с ВАГО 750-841.
Генезис (не 32 ):
  - застыли показания на удаленной станции инженера - пропала связь Gateway с контроллером. Возможно влияние сварочных работ в близости от Ethernet-кабеля. Причем, самое непонятное для меня, - АРМ оператора связь не терял, работает исправно. Контроллер исправно реализует алгоритмы управления.
  - Перезагрузка ЭВМ станции инженера не помогает, кабель прозванивается. Связи Gateway c контроллером по прежнему нет.
  - После перезапуска сетевого коммутатора отпадает и АРМ оператора с теми же признаками.   
  - связь не наблюдается ни при работе через коммутатор, ни при подключении напрямую через перекрестный кабель.
  - Контроллер управляет, благо - все было в автомате. Проуправлял он таким образом - полностью автономно, операторы слепы - чуть более суток. Останавливаться нельзя было - морозы, померзнут трубы. На ручное управление по-месту переходить не желали. 

Пришлось выехать, и вот что я увидел помимо вышеужеописанного:
  - контроллер пингуется как с АРМ оператора, так и со станции инженера
  - доступен веб-интерфейс контроллера
  - а вот Gateway по TCP связываться никак не хотел.
Деалаю выводы, что дело в софте на ЭВМ, т.к. раз контроллер пингуется, веб-интерфейс работает, следовательно, дело не в контроллере и не в сети. Проверяем OPC-сервер, пробуем DDE-сервер, вывод - плох Gateway.
Нашел, что у Gateway на АРМ оператора битый symbol-файл, потому что: - путь к нему не отображался в Gateway>Inspector
- открыв его обнаружил в нем всего три-четыре строчки, причем в последней строке явные "крокозяблики" (точно нерукописные).
На станции инженера с symbol-файлом этих проблем не было, все нормально, но связи нет. 

Сношу ОС и софт на АРМ оператора, ставлю все с нуля - не помогает, хотя symbol-файл в Gateway прописался. Вывод - не в АРМ дело. 
Идем дальше. Достаем резервный 750-841, врубаю его в сеть - все отлично работает, связь есть. 
Переходим на ручной. Перезапускаю откзавший ВАГО (выкл/вкл питания) - пошла связь. От греха подальше быстренько заменили ВАГО-башку на резервную и переводимся обратно в автомат.

За кружечкой крепкого чая делаем выводы и формулируем вопросы участникам форума, специалистам по ВАГО и КоДеСис:
Вывод:  (Другое в голову не приходит, поэтому прошу поправить, если есть соображения, мысли)
Завис код, управляющий протоколом TCP, ведь ping-, http- протоколы работали нормально. Что является причиной такого зависания неизвестно и непонятно, но условно можно списать на проведение сварочных работ, однако сомневаюсь (если бы погорело все - вопросов нет).
Вопросы:
1. Как объяснить, что разные ЭВМ, обращающиеся к одному контроллеру, потеряли связь в разное время? Разница 4-5 часов, отказ АРМ оператора спровоцирован перезапуском свитча (вкл/выкл питания).
2. Как здесь мог испортиться symbol-файл? Подгружается ли он из контроллера при инициализации Gateway? (при прошивке что-то похожее загружается в контроллер).
3. Можно ли и как реализовать fieldbus-watchdog перезапускающий только сетевой обмен и не останавливающий логику управления? Видел его в какой-то библиотеке, но понял, что действия на него программируются пользователем. А другое что-то просто перезапускает контроллер, но так не надо.

Буду рад любым соображениям, высказываниям, мыслям. 
Ставки на ВАГО довольно высоки. Да еще и LabView навязывают, а все заказчики между собой общаются, ничего не скроешь.  Невовремя глюк... 

Уважаемые специалисты Прософта, подскажите куда обращаться, где знающие люди? Как и есть ли смысл поконтачить с немцам? Хотелось бы прояснить ситуацию.