Конфигуратор vs modbus.lib

[Спорягин Кирилл]

Странно, а мы как-то считали время опроса Х параметров N-модулей именно через конфигуратор. И момент прихода ответа там виден ясно, по адресу и статусу. (но не на глаз , а при обработке в ПО) Глаз 1 мс не улавливает
А для контроля порядка опроса можно использовать режим по команде.

Владислав, а можно уточнить величины Х и N?
Правильно ли я понимаю, что опрос указанного количества модулей был у Вас в районе 1 мс?

[Scream]

Владислав, а можно уточнить величины Х и N?
Правильно ли я понимаю, что опрос указанного количества модулей был у Вас в районе 1 мс?

Про глаз перебор. Еслиб захотел увидеть Владислав, то и не смог т.к. codesys не обновляется с такой частотой не через usb не через ethernet.
---------------
Вот и у меня претензия к конфигуратору.
Если я опрашиваю модуль с 2мя регистрами с частотой 100 мс, то фактически получается каждый регистр обновляется раз в 200мс, хотя если они стоят рядом друг с другом то можно былоб преминить функцию модбас группового запроса на что ушло намного меньше времени, в даном случае в 2 раза и регистры обновлялись раз в 100 мс. Конфигуратор туп.

[Спорягин Кирилл]

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

Если я правильно понимаю, такая же проблема и при использовании библиотеки. Я ведь должен на каждом скане проверять переменную Complite. У меня нет возможности создать событие, которое вызовет мой обработчик, когда придут данные. Поэтому и нужно, на мой взгляд, выносить опрос модулей в отдельную задачу, которая будет циклически вызываться как можно чаще.

С другой стороны, те же МВ110-8А (не знаю насчёт «АС») у меня начинали затыкаться когда я пытался опрашивать их с периодом менее 15 мс при помощи своей программы на компе (на базе NModbus, скорость вроде была 38400 RTU), поэтому в оптимизации опроса может просто не быть смысла из-за самих модулей.

Здесь мне не понятно, почему модули начали затыкаться? Какая им разница с какой частотой их опрашивают? Другое дело, что если у МВ110-8А внутренний период обновления данных в районе 600 - 900 мс на канал (согласно руководства по эксплуатации модулей), то эти модули опрашивать чаще нет смысла (под внутренним периодом опроса я подразумеваю время с какой частотой физические измерения на входах преобразуются в данные, располагающиеся в регистрах Modbus модуля). И это можно учесть при организации опроса. Но вот для модулей МВ110-8АС внутренне время опроса одного канала - 5 мс. А для модулей дискретного ввода/вывода, частота обновления данных измеряется долями мс. Поэтому их опрашивать имеет смысл чаще. Это все можно и нужно учитывать при организации опроса.
Для этого в конфигураторе есть величина Polling time. В случае работы с библиотекой за этим нужно следить самостоятельно.

[capzap]

Если я правильно понимаю, такая же проблема и при использовании библиотеки. Я ведь должен на каждом скане проверять переменную Complite. У меня нет возможности создать событие, которое вызовет мой обработчик, когда придут данные.

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

[Спорягин Кирилл]

Вот и у меня претензия к конфигуратору.
Если я опрашиваю модуль с 2мя регистрами с частотой 100 мс, то фактически получается каждый регистр обновляется раз в 200мс, хотя если они стоят рядом друг с другом то можно былоб преминить функцию модбас группового запроса на что ушло намного меньше времени, в даном случае в 2 раза и регистры обновлялись раз в 100 мс. Конфигуратор туп.

Эту проблему можно отчасти решить используя для опроса string переменные см. тут - http://www.owen.ru/forum/showthread.php?t=21799

[Спорягин Кирилл]

так положительное состояние Complite это и есть условно время окончания периода,затраченного на опрос одного устройства.

Разница только в том, что не меня зовут, сообщая что работа сделана, а я каждый раз спрашиваю: "Как закончил?".

Вопрос почему это у Вас нет возможности создать событие?

Тут поподробней. Я кажется что-то пропустил? Не знаю как создать событие в CDS.
Настроить конфигуратор задач - не предлагать - это не то.

[capzap]

Разница только в том, что не меня зовут, сообщая что работа сделана, а я каждый раз спрашиваю: "Как закончил?".

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

[capzap]

Тут поподробней. Я кажется что-то пропустил? Не знаю как создать событие в CDS.

а передний фронт переменной Complite разве нельзя считать событием?

[Yegor]

Если я правильно понимаю, такая же проблема и при использовании библиотеки. Я ведь должен на каждом скане проверять переменную Complite. У меня нет возможности создать событие, которое вызовет мой обработчик, когда придут данные. Поэтому и нужно, на мой взгляд, выносить опрос модулей в отдельную задачу, которая будет циклически вызываться как можно чаще.

Та нееее... С конфигуратором вообще нет прямого способа узнать о приходе данных (только косвенные вроде смены адреса или изменения значения), а с библиотекой хотя бы есть сигнал complete. И временем цикла в таких задачах вполне можно пренебречь. Миллисекунда туда-сюда погоды в таких сетях не делает.

Здесь мне не понятно, почему модули начали затыкаться? Какая им разница с какой частотой их опрашивают?

Ну мало ли на что там ресурсов перестаёт хватать. А может и я чего не так намерил. Делал от скуки, а не от науки.

[Спорягин Кирилл]

Да бы не отвлекаться на филосовские дискуссии о "событиях" попробую конкретизировать рассуждения. А опытные пользователи ПЛК и разработчики пусть укажут на ошибки, неточности и слабые места в них.

Условия задачи оставим прежними - опросить 10 модулей ввода/вывода: 4 модуля МВ110-8АС, 3 модуля МВ110-32ДН и 3 модуля МУ110-32Р (опрос только измерений). Для определенности примем, что опрос ведется на скорости 115200 бит/сек.

Рассмотрим возможный вариант опроса через modbus.lib.
Создадим некие ФБ для каждой разновидности модулей. В этих ФБ используем блоки MB_RD_HOLD_REGS и MB_WR_REGS для записи и чтения регистров. Для каждого модуля в системе создаем свой экземпляр. Вызов этих экземпляров осуществляем последовательно в некоторой программе, назовем ее Module_PRG, которую поместим в задачу, выполняющуюся циклически с неким периодом.
Первое, что хочется понять каков должен быть период вызова Module_PRG? Как я понимаю он должен быть таким, чтобы между 2-мя последовательными вызовами система успевала отправить запрос модулю и получить ответ. Для этого рассчитаем время требуемое для пересылки запроса и ответа на него по сети Modbus при скорости 115200 кбит/сек. Будем исходить из потребностей аналогового модуля. Запрос включает: адрес уст-ва (1 байт) + номер функции (1 байт) + адрес регистра (2 байта) + кол-во регистров (1 байт) + CRC (2 байта) = 7 байт. Ответ включает: адрес уст-ва (1 байт) + номер функции (1 байт) + данные в int (16 байт) + CRC (2 байта) = 20 байт. Итого передать по сети туда-обратно нужно 27 байт. На скорости 115200 бит/сек для этого необходимо: 27*8/115200 = 0,0019 секунды или 1,9 мс. Добавим к этому времени возможные неучтенности (пауза, стоповые биты и прочее) в размере 2 мс. Или даже еще более осторожно - в руководстве по эксплуатации ПЛК 110-160 диапазон значений Pooling Time 10 - 1000 мс - примем за достаточную (с большим запасом) величину периода опроса одного модуля - 10 мс. Тогда получается период вызова программы Module_PRG должен составлять 10 мс. А весь цикл опроса 10-ти модулей 100 мс.
Главную программу PLC_PRG в этом случае следует вызывать раз в 110 мс, например.
Возможно ли достижения таких скоростей опроса с использованием библиотеки Modbus.lib?

Опрос через конфигуратор.
Теперь умозрительно создадим аналогичную сеть в конфигураторе. Для опроса аналоговых модулей будем использовать, уже указанный мною выше, прием с переменными String.
Создадим для каждого физического модуля соответствующий Universal Modbus Device и зададим им Pooling Time = 10 мс.
Какой период опроса должен получиться в этом случае в конфигураторе?