Связь Pixel-Beckhoff по RS485.

[Dmitry_S]

Добрый день. Есть проект, где на Pixel2511 (мастер) висят слейвами 6 панелей Weintek и контроллер управления приточно-вытяжными системами - какая-то модель Beckhoff в модульном исполнении. Всё это хозяйство прицеплено к порту RS485.
С панелями пиксель дружит без проблем, с Beckhoff проблема. Запросы на чтение проходят, запросы на запись - то идут, то нет. И через полчаса сетевой модуль Beckhoff виснет наглухо, до перезагрузки. Соисполнители, в чьей зоне ответственности ПО Beckhoff утверждают, что забивается буфер чтения-записи.
Я пробовал вместо проблемного Beckhoff подключаться Лектусом, сконфигурированным в слейв и со списком переменных из Beckhoff - Лектус периодически выдаёт в логе ошибку CRC, но пишет и читает всё, что не даётся Beckhoff. Если же освободить порт RS485 от панелей, оставив на нём лишь Лектус, ошибка CRC исчезает, а затем повесив вместо Лектуса Beckhoff - обмен идёт без проблем, все переменные читаются и пишутся.

Вопросов два.
Первый - корректно ли тестировать связь Лектусом (м.б. он занимает собой единственный сокет порта и остальным слейвам достаются объедки).
Второй - не ведёт ли себя Beckhoff как Лектус и не держит ли порт, генерируя эту же ошибку?
Если это так, придётся освободить под Beckhoff 485-й порт, перевесив остальные слейвы на Ethernet?

[Arsie]

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

Добрый день. Есть проект, где на Pixel2511 (мастер) висят слейвами 6 панелей Weintek и контроллер управления приточно-вытяжными системами - какая-то модель Beckhoff в модульном исполнении. Всё это хозяйство прицеплено к порту RS485.
С панелями пиксель дружит без проблем, с Beckhoff проблема. Запросы на чтение проходят, запросы на запись - то идут, то нет. И через полчаса сетевой модуль Beckhoff виснет наглухо, до перезагрузки. Соисполнители, в чьей зоне ответственности ПО Beckhoff утверждают, что забивается буфер чтения-записи.
Я пробовал вместо проблемного Beckhoff подключаться Лектусом, сконфигурированным в слейв и со списком переменных из Beckhoff - Лектус периодически выдаёт в логе ошибку CRC, но пишет и читает всё, что не даётся Beckhoff. Если же освободить порт RS485 от панелей, оставив на нём лишь Лектус, ошибка CRC исчезает, а затем повесив вместо Лектуса Beckhoff - обмен идёт без проблем, все переменные читаются и пишутся.

Вопросов два.
Первый - корректно ли тестировать связь Лектусом (м.б. он занимает собой единственный сокет порта и остальным слейвам достаются объедки).
Второй - не ведёт ли себя Beckhoff как Лектус и не держит ли порт, генерируя эту же ошибку?
Если это так, придётся освободить под Beckhoff 485-й порт, перевесив остальные слейвы на Ethernet?

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

Нормальная реализация по стандарту - это определение начала пакета, определение "на лету", что не свой адрес и последующий пропуск этого пакета мимо буфера.

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

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


Вылечить можно двумя путями:

1) Заставить их нанять более компетентных программеров, что нереально

2) Замедлить работу сети. Т.е. передавать данные панелям пореже. Возможно, поможет просто переход на более низкие битрейты - у проца бекова будет побольше времени переваривать писанину своих программистов

Есть вариант и с разбиванием пакетов на более мелкие - снимите галочку "групповые запросы". Беков их будет побыстрее обрабатывать, но вы легко можете выкатиться за предельные 112 запросов Пикселя.


PS. С лектусом проще, там не сам лектус виноват, а драйвер преобразователя - не успевает он работать в режиме слейва. Это тоже известная тема, слишком мало времени Modbus отводит слейву на обработку и сброс буфера.

[Dmitry_S]

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

2) Замедлить работу сети. Т.е. передавать данные панелям пореже. Возможно, поможет просто переход на более низкие битрейты - у проца бекова будет побольше времени переваривать писанину своих программистов

Пробовали, не взлетело.

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

Есть вариант и с разбиванием пакетов на более мелкие - снимите галочку "групповые запросы". Беков их будет побыстрее обрабатывать, но вы легко можете выкатиться за предельные 112 запросов Пикселя.

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

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

[ATS]

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

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

Интересно куда это они исчезают при физическом удалении панелей и неизменном мастере (Пиксель) на 485-м.
Ответы - естественно, а запросы то с чего?

[Dmitry_S]

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

Интересно куда это они исчезают при физическом удалении панелей и неизменном мастере (Пиксель) на 485-м.
Ответы - естественно, а запросы то с чего?

Физически панели никто никуда не удалял. Висят на своей витухе и помех в сети не создают. Просто из дерева устройств проекта пикселя-мастера удаляются панели-слейвы. В этом случае нет запросов мастера панелям - нет проблем с Beckhoff.

[ATS]

Видимо где-то недосмотрел. Показалось что панели просто отключали от 485-го.
Но ошибки CRC при подключенных панелях ...

[Dmitry_S]

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

предельные 112 запросов Пикселя

А где подробней почитать об этом пределе? Это предел на каждый порт, или суммарный предел на оба порта?

[Arsie]

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

А где подробней почитать об этом пределе? Это предел на каждый порт, или суммарный предел на оба порта?

Суммарный. Читать в справке лоджика.