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

[Yegor]

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

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

2. 10 циклов не слишком загруженного ПЛК110 это совсем небольшая задержка на самом деле, если рассмотреть общее время реакции. К тому же вы всё равно пишете в буфер системы, а она сама решает, когда это отправить.

Я особо не пользовался modbus.lib. Больше приходилось поддерживать нестандартные протоколы, в том числе где читать надо как можно чаще. И естественно, быстрее всего отправлять очередной запрос сразу после получения ответа. Но с каждым новым устройством этот подход надо проверять, т.к. некоторым нужна пауза.

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

[Филоненко Владислав]

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

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

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

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

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

[Scream]

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

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

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

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

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

[Sashokxxx]

Я особо не пользовался modbus.lib. Больше приходилось поддерживать нестандартные протоколы, в том числе где читать надо как можно чаще. И естественно, быстрее всего отправлять очередной запрос сразу после получения ответа. Но с каждым новым устройством этот подход надо проверять, т.к. некоторым нужна пауза.

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

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

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

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

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

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

[capzap]

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

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

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

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

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

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

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

[capzap]

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

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