Вид для печати
Здравствуйте, через некоторое время после включения и работы прибор "гонит пургу", а именно копии значений приходят в соседние регистры.
А параметр Уровень текущий в % приходит 0.
Работаю на скорости 115200 (остальные настройки по умолчанию). Адрес 21.
Чтение через СПК110, на интерфейсе есть другие устройства, естественно с другими адресами.
Интересно, что вы ожидаете услышать, не сообщив вообще ничего?Цитата:
Сообщение от =provincial=
Настройки сети и адреса, кроме скорости? Как читаете, чем читаете, где скрины?
https://owen.ru/product/emkostnoj_urovnemer_du311
Понятно. Продолжайте вести наблюдение. Мы с вами свяжемся. Свободны.Цитата:
Сообщение от =provincial=
Вложение 79567
Сегодня провёл эксперименты и выяснил, что ДУ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. В проекте ещё мешалки намечаются.
Придётся с ним взаимодействовать по токовому сигналу. ИМХО "сыроват" прибор.
А вы пробовали считывать сторонней утилитой регистры, а не своей программой?
Михаил, а мне это собственно зачем? Каков практический смысл?
Так то проблема может быть в программе СПК, а больше не зачем.
Ну melky как бы ответил, зачем...Цитата:
Сообщение от =provincial=
У меня из Scada опрашивается два датчика топлива с Modbus протоколом. Второе устройство, независимо какое из них я поставлю дает ошибки при опросе. Думаю, что не хватает задержки между опросами одного и второго устройства (нет в Scada такой настройки). Попросил разработчика добавить в будущем.
Кого поставлю первым - ошибок 0. у второго появляются ошибки.
А как Вы определяете - какое 1-е, а какое 2-е? По какому признаку?Цитата:
Сообщение от melky
imaex это в Scada указывается расположением в дереве опроса. Тут все проще :)
Как они физически на линии плевать, поведение прослеживается при смене опроса, без изменения линии. Там еще и Меркурий 236 висит и читается даже чаще, чем эти датчики.
Блин, придумал, я им немного время опроса разнесу, чтобы они один за одним не читались и попробую так проверить.
Валенок не, левые не нужны :) хотя для проверки наверное можно, с другим адресом задать с какой-то паузой и однократным запросом.
Посмотрел, сеансы без ошибок, Задано 2-х кратное чтение при наличии ошибки, значит на второй повторный запрос прибор отвечает уже разумно.
Потратил вчера время для кое-каких экспериментов. Взял ModBus Poll и завёл два ДУ311. Программа умеет читать регистры в одном окне только подряд. Указываем начальный адрес и кол-во регистров чтения. Всё читалось хорошо с любыми настройками. Я был готов взять свои слова обратно.
Посмотрев на таблицу регистров в документе на ДУ31 стало видно, что они отсортированы не по адресам. Я их вбивал в таблицу обмена Codesys один в один из руководства.
Затем, сделал чтение регистров не по порядку в ModBus Poll и получил то, что на фото. Периодически прут ошибки. Разнос цикла опроса по каждому окну проблему не решает.
Вообщем, я пока не добился нормальной работы в Codesys (хотя и перебил таблицу с сортировкой по регистрам).
На текущее положение дел могу предположить, что проблема может быть в Codesys, несмотря на то, что на порядок обмена после компиляции я не влияю. В каком порядке происходит запрос из уже последовательной таблицы не понятно, нужно снифить интерфейс. Пока не готов этим заниматься.
А почему тогда работают 2 дозатора и 2 расходомера без ошибок в районе 30% от запросов (у них менее 1%) ? Ответа у меня нет. Таблицы по дозаторам вбиты из РЭ по возрастанию адресов, а вот расходомеров в перемешку.
Кто хочет поучаствовать в тестах - готов поделиться таблицей и структурой для Codesys.
Кто хоть раз делел обмен с произвольным устройством по RS-485 знает, что создавать эти таблицы хлопотное занятие (ни скопировать, ни вставить и тд.).
А теперь возьмите и прочитайте все регистры одним массивом, укажите начальный адрес и длину массива в ПЛК, а не по одному как у вас.
И кстати в Модбас пуле тоже полно ошибок. При чём, чем больше регистров читается вместе и меньше период опроса, тем ошибок меньше.
Период надо попробовать от 100 до 500 мс.