ДУ311 чтение по ModBus

[=provincial=]

Здравствуйте, через некоторое время после включения и работы прибор "гонит пургу", а именно копии значений приходят в соседние регистры.
А параметр Уровень текущий в % приходит 0.
Работаю на скорости 115200 (остальные настройки по умолчанию). Адрес 21.
Чтение через СПК110, на интерфейсе есть другие устройства, естественно с другими адресами.

[kondor3000]

Здравствуйте, через некоторое время после включения и работы прибор "гонит пургу", а именно копии значений приходят в соседние регистры.
А параметр Уровень текущий в % приходит 0.
Работаю на скорости 115200.

Интересно, что вы ожидаете услышать, не сообщив вообще ничего?
Настройки сети и адреса, кроме скорости? Как читаете, чем читаете, где скрины?

https://owen.ru/product/emkostnoj_urovnemer_du311

[In_Da_Cher_A]

Здравствуйте, через некоторое время после включения и работы прибор "гонит пургу", а именно копии значений приходят в соседние регистры.
А параметр Уровень текущий в % приходит 0.
Работаю на скорости 115200.Понятно. Продолжайте вести наблюдение. Мы с вами свяжемся. Свободны.
79567

[=provincial=]

Сегодня провёл эксперименты и выяснил, что ДУ311 по модбас хорошо работает, если он один slave в сети.
Как только их становится два (больше у меня нет) прут ошибки. Понизил скорость до 9600 стало лучше, но не сильно.

В первом посте описана ситуация, когда ДУ311 был добавлен в сеть с двумя другими устройствами, с результатами описанными выше.
На СПК110 были опробованы варианты с подключением резисторов 120 Ом и без них - результат не менялся. Длина линии 3 метра максимум, витая, если что.

Ну а теперь конкретика.

Фото1: Устройства в Codesys 3.5.SP17 Patch3
Фото2: Два ДУ311 на скорости 9600
Фото3: Два расходомера Взлёт на скорости 115200 (соседний интерфейс)
Фото4: Один ДУ311 простоял эту ночь на скорости 115200 с другими устройствами
Фото5: относится к фото 4, постоянно опрашиваемых параметров в цикле 4, при этом в праметре "Уровень в % текущий" (L_p_1) явно красуется температура (параметр Temp_1).
Фото6: относится к фото 4, наглядное подтверждение тому, что параметры не на "своём месте".
Фото7: Один ДУ311 в сети с другими устройствами после подачи питания, в поле L% не реальная цифра. И это при том, что его не трогаю (уровень воды стабилен во всех опытах).
Фото8: Один ДУ311 в сети, данные верны.
Фото9: Два ДУ311 в сети, поля не двоятся, но ошибки прут (фото 2) и у второго L% куда-то потерялась.
Фото10: Испытательный стенд. Через пару дней приборы заберут на монтаж.

А ещё измерение непосредственно уровня "тормознутое". Видимо, это связано с принципом измерения. Чуть уровень изменил - сразу статус Е2/Е3. В проекте ещё мешалки намечаются.

Придётся с ним взаимодействовать по токовому сигналу. ИМХО "сыроват" прибор.

[МихаилГл]

А вы пробовали считывать сторонней утилитой регистры, а не своей программой?

[=provincial=]

Михаил, а мне это собственно зачем? Каков практический смысл?

[melky]

Так то проблема может быть в программе СПК, а больше не зачем.

[МихаилГл]

Михаил, а мне это собственно зачем? Каков практический смысл?

Ну melky как бы ответил, зачем...

[melky]

У меня из Scada опрашивается два датчика топлива с Modbus протоколом. Второе устройство, независимо какое из них я поставлю дает ошибки при опросе. Думаю, что не хватает задержки между опросами одного и второго устройства (нет в Scada такой настройки). Попросил разработчика добавить в будущем.
Кого поставлю первым - ошибок 0. у второго появляются ошибки.

[imaex]

Кого поставлю первым - ошибок 0. у второго появляются ошибки.

А как Вы определяете - какое 1-е, а какое 2-е? По какому признаку?

[melky]

imaex это в Scada указывается расположением в дереве опроса. Тут все проще :)
Как они физически на линии плевать, поведение прослеживается при смене опроса, без изменения линии. Там еще и Меркурий 236 висит и читается даже чаще, чем эти датчики.

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

[melky]

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

[=provincial=]

Потратил вчера время для кое-каких экспериментов. Взял ModBus Poll и завёл два ДУ311. Программа умеет читать регистры в одном окне только подряд. Указываем начальный адрес и кол-во регистров чтения. Всё читалось хорошо с любыми настройками. Я был готов взять свои слова обратно.

Посмотрев на таблицу регистров в документе на ДУ31 стало видно, что они отсортированы не по адресам. Я их вбивал в таблицу обмена Codesys один в один из руководства.
Затем, сделал чтение регистров не по порядку в ModBus Poll и получил то, что на фото. Периодически прут ошибки. Разнос цикла опроса по каждому окну проблему не решает.

Вообщем, я пока не добился нормальной работы в Codesys (хотя и перебил таблицу с сортировкой по регистрам).

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

А почему тогда работают 2 дозатора и 2 расходомера без ошибок в районе 30% от запросов (у них менее 1%) ? Ответа у меня нет. Таблицы по дозаторам вбиты из РЭ по возрастанию адресов, а вот расходомеров в перемешку.

Кто хочет поучаствовать в тестах - готов поделиться таблицей и структурой для Codesys.
Кто хоть раз делел обмен с произвольным устройством по RS-485 знает, что создавать эти таблицы хлопотное занятие (ни скопировать, ни вставить и тд.).

[kondor3000]

А теперь возьмите и прочитайте все регистры одним массивом, укажите начальный адрес и длину массива в ПЛК, а не по одному как у вас.
И кстати в Модбас пуле тоже полно ошибок. При чём, чем больше регистров читается вместе и меньше период опроса, тем ошибок меньше.
Период надо попробовать от 100 до 500 мс.