СПК107 + ПЛК150 по RS-485 Ошибка шины ModBus

Вводные данные:
Codesys 3.5 SP5 Patch 2
СПК 107 прошивка 3.939
Таргет СПК107 3.5.4.20
Версия COM-устройства 3.4.0.0
Версия Master 3.5.4.0
Версия Slave 3.5.4.0

Итак, СПК107 должен через свой СОМ1 по 485 получить температуру с аналогового входа ПЛК150-M-U. На стороне ПЛК150 все настроено правильно, на стороне СПК все скорости, адреса и каналы тоже. Проблема заключается в абсолютно нестабильной работе шины. Соединение появляется только когда коннектишься с компа (начинает мигать СВЯЗЬ на СПК и отображаются нормальные значения). При пропадании питания связь не восстанавливается.
Знаю, что тема избитая, но я уже перепробовал все версии устройств и все настройки. Ничего не пашет. Ставлю Мастер 3.5.5.0 - стает активна галка АВТОРЕКОННЕКТ, ставлю ее, что-то поработет до первого чиха. Вот ведь не задача Мастер должен быть младше таргета СПК! Ставлю обратно Мастер на 3.5.4.0 галка стает недоступна и вообще ничего не восстанавливается при обрыве.

Вопросы:
1 Как настроить этот проект, чтобы добиться устойчивой связи?
2 Какую версию мастера мне можно использовать и как вообще обновлять/добавлять эти ModBus устройства?

Проекты прилагаю.

готов оказать посильную помощь.. стукни в skype: ladimko

http://www.owen.ru/forum/showthread....ight=bus+cycle попробуйте последнее сообщение реализовать.

Пробовал еще позавчера менять Задачи цикла шины как во вкладке ModBus Com, так и в ModBus Slave. Не помогает.

Вложение 16762

Загрузил проект ваш в СПК105, опрос идет нормально. Но у меня просто SP5.

У меня тоже нормально стало, но после пропадания питания ПЛК при работающей СПК связь не хочет восстанавливаться. На что все таки влияет опция "Задача цикла шины" в настройках ModBus и Установках ПЛК?

У меня опрос восстанавливается в вашем проекте.

Все получилось, пока работет. Спасибо.

А что получилось если не секрет. Просто у меня тоже есть проблемы с СПК и модбасом. Зависает периодически МАСТЕР, причем не хорошо так. Симптомы следующие обмен не останавливается, модули принимают и получают значения от СПК, но СПК шлет в сеть одни и те же значения, не зависимо от того как они меняются в программе и отдает в управляющию программу те значения которые получил на момент зависания. Как следствие модули думают что все нормально, программа тоже получает какие то цифры, но реальности они уже не соответствуют. При этом если физически переподключить спк к RS-485, все оживает. А так ни галка автореконект ни программная перезагрузка слейвов не помогает. Немного спасает уменьшение таймаута мастера до 20мс. Зависания так же случаются, но мастер через какое то время выходит из своего не документированного состояния.Но все же это плохо, так как иногда на это уходит полчаса. А все это время модуль вывода продолжает греть тэны по старой уставки шима ( на спк реализовано 10 пид регуляторов). Я понимаю что проблемы всего скорее связанны с помехами так как в шкафу инверторов на 100 кВт, но вот такое поведения модбас мастера печалит. Пока пробую перезагружать программно не слейв а сам мастер при наличие проблем со слейвами. Вроде как вторые сутки без нареканий. Сложность еще в том что оборудование работает 24 часа и переписать обмен с модулями при помощи другой библиотеки на ходу моих знаний не хватает. А проблема именно в библиотека мастера от codesys, так как на другом порту спк крутиться самописный мастер(работает через SysCom) который управляет инверторами, там таких проблем нет

Цитата:

---

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

Все получилось, пока работет. Спасибо.

---

Не могли бы рассказать как устранили ошибку шины. У меня те же проблемы.

Цитата:

---

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

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

---

опачки.... а это уже "косяк" среды исполнения / библиотеки мастера, а не пользовательской программы. Почему техподдержка ничего не ответила по проблеме? Пост старый, а проблемы остались, судя по всему те же в теме по подулям Mx110.

Цитата:

---

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

опачки.... а это уже "косяк" среды исполнения / библиотеки мастера, а не пользовательской программы. Почему техподдержка ничего не ответила по проблеме? Пост старый, а проблемы остались, судя по всему те же в теме по подулям Mx110.

---

опаньки, а с чего это косяком стало непонятно что.
Например как понимать слова принимают и получают
Где описание диагностики неисправности, только выдергивание проводов? Почему не приходит в голову, что это в слейве остается последнее записанное в него значение и ни какой мастер ни чего не передает

Вроде заработало. Разберусь окончательно, отпишусь.

Цитата:

---

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

опаньки, а с чего это косяком стало непонятно что.
Например как понимать слова принимают и получают
Где описание диагностики неисправности, только выдергивание проводов? Почему не приходит в голову, что это в слейве остается последнее записанное в него значение и ни какой мастер ни чего не передает

---

Диагностика есть озвученный результат анализа передаваемых данных. Сергей, Вам-таки приплачивают ? Мне, например, это приходит в голову.

Цитата:

---

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

Диагностика есть озвученный результат анализа передаваемых данных. Сергей, Вам-таки приплачивают ? Мне, например, это приходит в голову.

---

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

Цитата:

---

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

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

---

Если изучить тему: http://www.owen.ru/forum/showthread.php?t=21365
, и сопоставить "симптомы" каждой проблемы в отдельности, становится ясно, что другого более разумного объяснения описанных сбоев не найти. Очевидно, что контроллеры СПК не являются оборудованием для построения надежной связи по протоколу Modbus-RTU при использовании "мастера через конфигурацию" по причине недоработки. В Somachine (Sch. El.) практически такой же мастер (по интерфейсу настроек, а значит это часть инструментария Codesys, а не разработка Овен) и работает без каких-либо нареканий.
По-Вашему автор предполагает ситуацию, а не оперирует результатами диагностики? Это тоже Ваши догадки, не нужно им предавать такой вес.
А поскольку эта тема давно забыта, считаю необходимым своим собщением поднять ее наверх для актуальности. Возможно изготовитель обратит внимание на мое сообщение, и наконец-то проведет тесты с использованием инструментов анализа передаваемых данных, после чего сможет устранить проблему. По своему опыту могу судить, что подобные тесты вообще не проводятся изготовителем перед тем, как начать серийное производство.
http://www.owen.ru/forum/showthread....l=1#post169075
В этой теме Ваши замечания и советы были бы очень актуальны.

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

Цитата:

---

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

Если изучить тему: http://www.owen.ru/forum/showthread.php?t=21365
, и сопоставить "симптомы" каждой проблемы в отдельности, становится ясно, что другого более разумного объяснения описанных сбоев не найти. Очевидно, что контроллеры СПК не являются оборудованием для построения надежной связи по протоколу Modbus-RTU при использовании "мастера через конфигурацию" по причине недоработки. В Somachine (Sch. El.) практически такой же мастер (по интерфейсу настроек, а значит это часть инструментария Codesys, а не разработка Овен) и работает без каких-либо нареканий.
По-Вашему автор предполагает ситуацию, а не оперирует результатами диагностики? Это тоже Ваши догадки, не нужно им предавать такой вес.
А поскольку эта тема давно забыта, считаю необходимым своим собщением поднять ее наверх для актуальности. Возможно изготовитель обратит внимание на мое сообщение, и наконец-то проведет тесты с использованием инструментов анализа передаваемых данных, после чего сможет устранить проблему. По своему опыту могу судить, что подобные тесты вообще не проводятся изготовителем перед тем, как начать серийное производство.
http://www.owen.ru/forum/showthread....l=1#post169075
В этой теме Ваши замечания и советы были бы очень актуальны.

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

---

спокойствие только спокойствие
Разберем
а) работа мастера через конфигуратор:
добираемся до окошечка модбас-kaнал, ищем поле обработка ошибок, меняем с сохранить последнее значение на установить в ZERO, при получении каких то значений, но не нуля, убеждаемся что ошибок нет и мастер получает ответы на свои запросы корректно (кустарщины ни какой)
б) через библиотеку, получив комплит и error равный нулю убеждаемся что ошибок нет (кустарщины ни какой)
в) по поводу самой работы протокола: будете спорить о том, что для того чтоб увидеть изменение какого то параметра, мастер отправляет запросы слейву для чтения одного/двух регистров по фиксированному адресу? Думаю что нет. А теперь читаем автора

Цитата:

---

программа тоже получает какие то цифры, но реальности они уже не соответствуют.

---

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

Цитата:

---

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

---

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

Цитата:

---

По-Вашему автор предполагает ситуацию, а не оперирует результатами диагностики? Это тоже Ваши догадки, не нужно им предавать такой вес.

---

я по моему как раз таки потребовал предоставить доказательства, а не делаю догадки из пустых разговоров

Цитата:

---

При этом если физически переподключить спк к RS-485, все оживает. А так ни галка автореконект ни программная перезагрузка слейвов не помогает

---

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

ЗЫ объекты которые я запускаю, работают на семене, овен это единичные случаи, так скажем раз в год может быть, поэтому улыбнуло Ваше предположение о выгодных условиях. Не буду отрицать у меня есть бесплатные образцы, взятые для тестирования, не знаю правда в чем тут выгода

Доброго дня. Внесу немного ясности. У меня обмен падает двумя способами

1. Штатно. Срабатывает триггера вида mu110_16k_50.xError. Значения при установке "установить в ZERO" устанавливаются в 0. Обмен с потерянным слейвом не идет. как следствие слейв может отработать аварию по таймауту. Выйти из этого можно либо при помощи галочки автореконект либо программно перегрузить слейв.

2. Не штатно. Флаг mu110_16k_50.xError не поднимается. Значения в 0 не падают. Слейвы продолжают получать запросы от мастера и отвечать ему. Но не в программе, не при онлайн режиме кдс актуальных ответов нет. Стоят последние цифры( сброс в 0 стоит). Перезагрузка слейвов не помогает. Опытным путем было найдено решение....В момент такой вот дурости мастера срабатывает флаг modbus_master_com_port.xAllSlavesOk. Как следствие как костыль было найдено такое решение

IF modbus_master_com_port.xAllSlavesOk=FALSE THEN
blink_01(enable:=TRUE,timelow:=T#6S, timehigh:=T#100MS,out=>);
ELSE
blink_01(enable:=FALSE,timelow:=T#6S, timehigh:=T#100MS,out=>);
END_IF
modbus_master_com_port.xResetComPort:=blink_01.OUT ;

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

Второго типа много реже. Пока вариант с перезагрузкой мастера не был найден, где то раз в два дня. Теперь я уже и не слежу.
Так оно и работает, практически круглосуточно уже скоро год. Кратковременная потеря связи для меня не особа критична. На этой панели на одном com порту крутится 14 каналов нагрева и охлаждения экструдера, на втором управление инверторами митсу. Но для себя я сделал вывод что использовать связку модули+СПК для управления механизмами где критична реакция на событие я не стану.

Я не занимаюсь профессионально ПЛК. Просто год назад на предприятие где я главный инженер выгорел родной проприетарный контроллер, и необходимо было в кротчайшие сроки восстановить оборудование. В самописной библиотеке для управления инверторами(там не модбас) вообще нет обработчика ошибок и не разу и не пригодился, все и так работает,а тут прям беда и напасть. Хотя я вполне допускаю что мне досталась просто больная панель....

Цитата:

---

Штатно. Срабатывает триггера вида mu110_16k_50.xError. Значения при установке "установить в ZERO" устанавливаются в 0. Обмен с потерянным слейвом не идет. как следствие слейв может отработать аварию по таймауту. Выйти из этого можно либо при помощи галочки автореконект либо программно перегрузить слейв

---

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

Цитата:

---

Не штатно...

---

дурость контроллера можно победить более коротким способом, как мне кажется кустарщику, например модуль 8А взять, считывая измерение кaнaла захватывать циклическое время измерения, при каждом опросе оно гарантировано должно изменятся, так что такая слепота вычисляется уже при следующем запросе

Цитата:

---

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

[I]
дурость контроллера можно победить более коротким способом, как мне кажется кустарщику, например модуль 8А взять, считывая измерение кaнaла захватывать циклическое время измерения, при каждом опросе оно гарантировано должно изменятся, так что такая слепота вычисляется уже при следующем запросе

---

Можно. Но ввиду отсутствия дискретных выходов у панели. Кроме как стоять и мигать экраном она ничего не может, исполнительные механизмы так и продолжают работать, что меня первый раз в шок повергло(температура тогда, успела с 200 градусов уползти до 240, хорошо все обошлось без последствий. Вот тут мне кажется сильно не хватает в спк одного релейного выхода, который.в случае чего смог бы обеспечить аварийный останов. Была даже мысль разобрать и сделать релейный выход вместо пищалки, но так руки и не дошли. Вообще мне кажется, раз уж это СПК, а не просто панель, то хотя бы одна "живая рука" должна быть

Цитата:

---

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

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

---

Имеется ввиду до аварии? Тогда скажу так АС4 ничего патологического не видет. Мастер отправил корректный запрос, слейв корректно ответил и все...Но возможно АС4 обладает банально лучшим трактом RS-485, и может корректно считать данные с шины а спк нет?. Потому что такое пропадание связи целиком и полностью связанно с помехами, при их отсутствие проблем не наблюдал.
Ну а после авраии тишина там, мастер молчит, слейв тоже. Соответственно модули с дискретными выходами могут отработать авраию по тайм ауту. И так пока все это не перезапустить.

Цитата:

---

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

Имеется ввиду до аварии? Тогда скажу так АС4 ничего патологического не видет. Мастер отправил корректный запрос, слейв корректно ответил и все...Но возможно АС4 обладает банально лучшим трактом RS-485, и может корректно считать данные с шины а спк нет?. Потому что такое пропадание связи целиком и полностью связанно с помехами, при их отсутствие проблем не наблюдал.
Ну а после авраии тишина там, мастер молчит, слейв тоже. Соответственно модули с дискретными выходами могут отработать авраию по тайм ауту. И так пока все это не перезапустить.

---

Вы называли два вида аварийной ситуации, второй случай когда приходят "неправильные" ответы, что наблюдаете через АС-4 тишину или те самые пакеты?
Я уже написал про метки времени, считывайте их сравнивайте с предыдущим значением и пересбрасывайте порт


ЗЫ какая витая пара используется, экранированная ли, заземлена ли она?

Цитата:

---

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

Вы называли два вида аварийной ситуации, второй случай когда приходят "неправильные" ответы, что наблюдаете через АС-4 тишину или те самые пакеты?

ЗЫ какая витая пара используется, экранированная ли, заземлена ли она?

---

Второй вариант "послушать" не получилось. Но обмен идет, мастер последовательно опрашивает слейвы. И слейвы получают уставку от мастера. Речь идет о уставки шим и она не меняется все время пока СПК в такой вот прострации.
Витая пара не экранированная

Цитата:

---

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

Я уже написал про метки времени, считывайте их сравнивайте с предыдущим значением и пересбрасывайте порт

---

Я на это отвечал выше, но это костыль. Тогда уж надо подставить второй костыль и заменить модули вывода на ПР или ПЛК и если от СПК долго идут одни и те же данные, передернуть питание СПК. Но зачем вообще в этой схеме тогда СПК?

мой костыль проще Вашего

Цитата:

---

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

Но зачем вообще в этой схеме тогда СПК?

---

:) так это Вас надо спросить, зачем такую панель взяли, можно было обойтись плк160 и любую чисто-панель от других производителей, не достающие входы/выходы через модуля на которые посадить второстепенные датчики и ИМ

Цитата:

---

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

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

дурость контроллера можно победить более коротким способом, как мне кажется кустарщику, например модуль 8А взять, считывая измерение кaнaла захватывать циклическое время измерения, при каждом опросе оно гарантировано должно изменятся, так что такая слепота вычисляется уже при следующем запросе

---

никакое плохое качество физического уровня не объясняет природу ошибки из второго варианта. Это самая опасная ситуация, когда управляющее воздействие слишком велико (интенсивность нагрева/задание частоты ПЧ) и может привести к аварийным ситуациям и материальному ущербу. Посколько сброс теперь происходит автоматически и объект давно в работе, снять данные с порта скорее всего не представляется возможным? Очень жаль. Мое мнение не поменялось. СПК не является надежным устройством для связи. Автосброс это лишь очередной костыль, да-да, костыль, не кустарщина, согласен. Кустарщина в других ветках форума. ))

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

Цитата:

---

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

мой костыль проще Вашего


:) так это Вас надо спросить, зачем такую панель взяли, можно было обойтись плк160 и любую чисто-панель от других производителей, не достающие входы/выходы через модуля на которые посадить второстепенные датчики и ИМ

---

Если вам действительно интересно: :)

1. Опыта с плк нет, а нужно восстановить оборудование ибо заказы стоят. Поэтому выбор пал на овен. Он, в наличие в городе+большой русскоязычный форум. Надеялся что будет проще разобраться
2. Второстепенных входов\выходов нет. Нужно 10 аналоговых входов, 14 выходов на ттр и один свободный порт для инверторов. Как следствие связка плк+панель не подходит, нужны еще модули. Ну а дальше кривая вывернула на СПК+4 модуля. Вариант ПЛК+панель+модули, показался сложнее....

Цитата:

---

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

ну не бывает так, цена устройства относительно низкая, а комплектующие из топовой серии.

---

Стоимость rs-485 драйвера в ценообразование СПК мне видеться крайне низкой....

Цитата:

---

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

Так к слову, значит вина КЛС-овского мастера не доказана?

---

Кем не доказана? мной? Так я и задачу такую никогда не ставил, у меня возникла проблема, в процессе поиска было найдено какое-никакое решение, я озвучил обстоятельства и проблему как мог. А сидеть сутками в шкафу и искать момент ошибки снифиром? Что мне это даст..., я считаю что оборудование так работать не должно и точка. На этом считаю свою миссию полностью выполненной. Поиском остальных виноватых как мне кажется надо бы овену заниматься. Это у него раз в неделю, на форуме, всплывает тема про проблемы со связью.

плк160 имеет на борту как дискретные так и аналоговые входы/выходы, на них можно было бы прицепить что наиболее важно и чувствительно к пропаданию связи, остальное на модули. Панель, если не придираться к красоте картинки, из бюджетных вариантов подошла бы ИП320. Сейчас еще появился такой прибор, как ПР200
понятно что сейчас уже ни чего не изменить, но как бы наличие форума не означает, что изучить предмет стоило бы повнимательнее. Возьмите хотя бы профибасный кабель от семена, может поможет справиться с помехами

Цитата:

---

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

мной?

---

нет не Вами

Цитата:

---

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

А сидеть сутками в шкафу и искать момент ошибки снифиром? Что мне это даст

---

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

Цитата:

---

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

плк160 имеет на борту как дискретные так и аналоговые входы/выходы, на них можно было бы прицепить что наиболее важно и чувствительно к пропаданию связи, остальное на модули. Панель, если не придираться к красоте картинки, из бюджетных вариантов подошла бы ИП320. Сейчас еще появился такой прибор, как ПР200
понятно что сейчас уже ни чего не изменить, но как бы наличие форума не означает, что изучить предмет стоило бы повнимательнее. Возьмите хотя бы профибасный кабель от семена, может поможет справиться с помехами

---

Это экструдер с выдувной головой в нем полторы тонны разогретого металла по которому движется расплав полиэтилена при давление 25 атм и температурой 200 градусов. Состоит из десяти зон нагрева общей мощностью 60 кВт и четырех зон охлаждения. Нет там не чувствительных к пропаданию связи мест. Если массу не разогреть и попытаться запустить шнековый пресс давление уходит в небеса, что способно натворить не мало дел.Если перегреть начнется деструкция материала, если перегреть сильно поплывут прокладки из коксанаполеного фторопласта. Они мало того что денег стоят, так и чтобы поменять их надо разобрать практически все, что само по себе неделю удовольствия. Вопрос финансов так остро не стоял, можно было бы и в два раза дороже взять. Вопрос времени и моего отсутствия опыта в программирование плк, тут овен с кдс показался оптимален.

ИП320 сейчас в связке в делтой прилаживаю вместо еще одной тайваньской платы(тут сильно не нравится штатный функционал)
ПР200 есть, спасибо овену за образец. Но пока беда с софтом, ждет своего часа.

За кабель спасибо, но мне кажется мы сильно ушли от темы.

Цитата:

---

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

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

---

Частотники не включаются, они работают всегда).

Цитата:

---

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

Вроде заработало. Разберусь окончательно, отпишусь.

---

В моем случае проблема со связью возникала тогда, когда я пользовался в конфигураторе каналом "Read/Write Multiple Registers (Код функции 23)". Видимо, функцию 23 не поддерживает ПЛК110 (у меня СПК207-мастер опрашивал ПЛК110-слейв). После того как я создал 2 канала один "Read Holding registers (Код функции 03)", второй "Write Multiple Registers (Код функции 16)", которые ссылались на одни и те же регистры, связь заработала стабильно.