PDA

Просмотр полной версии : Конфигуратор vs modbus.lib



Спорягин Кирилл
18.08.2015, 17:33
Добрый день, уважаемые форумчане.

Предложенная мною тема уже ни раз обсуждалась на форуме. Например:
1. Преимущества работы с портом с помощью библиотек (http://www.owen.ru/forum/showthread.php?t=15166)
2. Эксплуатация библиотеки modbus.lib (http://www.owen.ru/forum/showthread.php?t=11884&page=2)
3. МВ110-16Д modbus.lib (http://www.owen.ru/forum/showthread.php?t=20901)
4. Примеры работы с приборами ОВЕН имеющими интерфейс RS-485 (http://www.owen.ru/forum/showthread.php?t=13584)

Все же, как мне кажется, некоторые моменты остаются не определены.
Сразу оговорюсь, что я сейчас говорю о ситуации, когда контроллер выступает в роли Modbus Masterа.

1. В ссылках [1] и [2] говориться, что опрос с помощью библиотеки дает преимущества в случае, если количество опрашиваемых модулей велико. Но нигде нет количественных характеристик.

Вопросы:
1.1 При каком количестве модулей опрос через библиотеку будет заметнее быстрее, чем через конфигуратор?
1.2 Хотелось бы знать экспертную или опытную оценку периода опроса 10 модулей ввода/вывода через конфигуратор и через библиотеку. Для определенности пусть это будут: 4 модуля МВ110-8АС, 3 модуля МВ110-32ДН и 3 модуля МУ110-32Р (опрос только измерений).

2. Все найденные мною примеры использования библиотеки (например, [3, 4]) показывают как использовать функциональные блоки из библиотеки, но я нигде не смог найти описания или рекомендаций по организации структуры вызовов. Поясню более подробно.
Пусть у меня есть главная и единственная программа - PLC_PRG. В ней последовательно расположены вызовы ФБ для опроса модулей и за ними ФБ логики управления объектом (подразумевается язык ST). При вызове ФБ опроса модулей я проверяю выход Complite у библиотечных ФБ, который показывает, что опрос модуля завершен. Только после этого я могу переходить к опросу другого модуля. Фактически это означает, что для опроса 10 модулей мне нужно как минимум 10 циклов программы PLC_PRG. В этом случае может быть следующая неприятность. Если по результатам опроса первого модуля ФБ логики управления объектом выдал управляющие воздействия, которые должны быть переданы на исполнительные механизмы с помощью десятого модуля, то получиться, что 9 циклов управляющие воздействия будут выработанны, но не переданы на модуль вывода, что замедляет время реакции системы.
Поэтому представляется правильным вынести опрос модулей в отдельную программу (и задачу), исполнение которой осуществлять чаще, чем исполнение логики управления. Причем частота исполнения опроса модулей должна быть в N раз больше частоты исполнения логики объекта, где N - количество модулей.

Вопросы:
2.1 Приведите примеры организации опроса модулей ввода/вывода с использованием modbus.lib;
2.2 Как ведет себя конфигуратор при опросе модулей? С ним не получается такой неприятности как описана выше?

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

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

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

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

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

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


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

Yegor
18.08.2015, 21:03
И момент прихода ответа там виден ясно, по адресу и статусу.И что же там видно в случае когда устройство с одним адресом постоянно отвечает без ошибок?

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



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

Yegor
18.08.2015, 21:27
Ну, вот такой зверёк с очень простым протоколом был, например: http://owen.ru/forum/showthread.php?t=19435 (только порт по-другому открывать надо, но к самой библиотеке и циклу опроса это не относится).

Sashokxxx
18.08.2015, 21:34
Ну, вот такой зверёк с очень простым протоколом был, например: http://owen.ru/forum/showthread.php?t=19435 (только порт по-другому открывать надо, но к самой библиотеке и циклу опроса это не относится).

Знаком такой зверек(Вакууметр), а что с портом, как нужно открывать?

Sashokxxx
18.08.2015, 21:43
Ну, вот такой зверёк с очень простым протоколом был, например: http://owen.ru/forum/showthread.php?t=19435 (только порт по-другому открывать надо, но к самой библиотеке и циклу опроса это не относится).

А у меня получится посмотреть что в этой библиотеке или пользовать ее из Codesys 3.5 SP5. С пакетами и library файлами разобрался, а вот как конвертировать более старые еще нет.))

Sashokxxx
18.08.2015, 21:51
Ну, вот такой зверёк с очень простым протоколом был, например: http://owen.ru/forum/showthread.php?t=19435 (только порт по-другому открывать надо, но к самой библиотеке и циклу опроса это не относится).

А содержимое самой библиотеке можно посмотреть как то? ФБ опроса как организован - и я думаю все станет ясно.

Yegor
18.08.2015, 22:03
а что с портом, как нужно открывать?http://owen.ru/forum/showthread.php?t=16787&p=175848#post175848 Но это может быть неактуально для СПК.
А содержимое самой библиотеке можно посмотреть как то? ФБ опроса как организован - и я думаю все станет ясно.Открывайте файл библиотеки в кодесисе, и всё. Я никаких ограничений не ставил.

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

capzap
19.08.2015, 13:21
Тут поподробней. Я кажется что-то пропустил? Не знаю как создать событие в CDS.
а передний фронт переменной Complite разве нельзя считать событием?

Yegor
19.08.2015, 13:30
Если я правильно понимаю, такая же проблема и при использовании библиотеки. Я ведь должен на каждом скане проверять переменную Complite. У меня нет возможности создать событие, которое вызовет мой обработчик, когда придут данные. Поэтому и нужно, на мой взгляд, выносить опрос модулей в отдельную задачу, которая будет циклически вызываться как можно чаще.Та нееее... С конфигуратором вообще нет прямого способа узнать о приходе данных (только косвенные вроде смены адреса или изменения значения), а с библиотекой хотя бы есть сигнал complete. И временем цикла в таких задачах вполне можно пренебречь. Миллисекунда туда-сюда погоды в таких сетях не делает.
Здесь мне не понятно, почему модули начали затыкаться? Какая им разница с какой частотой их опрашивают?Ну мало ли на что там ресурсов перестаёт хватать. А может и я чего не так намерил. Делал от скуки, а не от науки.

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

Условия задачи оставим прежними - опросить 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 (http://www.owen.ru/forum/showthread.php?t=21799).
Создадим для каждого физического модуля соответствующий Universal Modbus Device и зададим им Pooling Time = 10 мс.
Какой период опроса должен получиться в этом случае в конфигураторе?

capzap
19.08.2015, 16:44
Запрос включает: адрес уст-ва (1 байт) + номер функции (1 байт) + адрес регистра (2 байта) + кол-во регистров (1 байт) + CRC (2 байта) = 7 байт. Ответ включает: адрес уст-ва (1 байт) + номер функции (1 байт) + данные в int (16 байт) + CRC (2 байта) = 20 байт. Итого передать по сети туда-обратно нужно 27 байт. На скорости 115200 бит/сек для этого необходимо: 27*8/115200 = 0,0019 секунды или 1,9 мс.
https://ru.wikipedia.org/wiki/Modbus ознакомтесь сколько байт нужно передать в запросе и ответе, а прогу вызывайте хоть каждую миллисекунду, пока комплит не покажет положительный фронт, запрашиваемые данные не пришли. При 110 мс если данные пришли на 111 минуте, Вы будете ждать еще 109мс чтоб их получить и обработать

Спорягин Кирилл
19.08.2015, 16:59
Capzap, Вы не внимательно читаете, то что я пишу. Программу с обработкой ФБ модулей я предлагаю вызывать каждые 10 мс, т.е. с промежутком времени достаточным для запроса и ответа к одному модулю. Раз в 110 мс обрабатывать основную программу. Мысль моя такова - за 100 мс обрабатываю все модули, затем имея свежие данные исполняю логику управления, затем снова обрабатываю все модули и так далее.

capzap
19.08.2015, 17:09
Capzap, Вы не внимательно читаете, то что я пишу. Программу с обработкой ФБ модулей я предлагаю вызывать каждые 10 мс, т.е. с промежутком времени достаточным для запроса и ответа к одному модулю. Раз в 110 мс обрабатывать основную программу. Мысль моя такова - за 100 мс обрабатываю все модули, затем имея свежие данные исполняю логику управления, затем снова обрабатываю все модули и так далее.

если честно, я хотел написать одним словом ответ - бред, а теерь еще больший бред, какая разница для основной программы изменились данные или "застыли" на месте, почему она должна работать так медленно, от того что каждую цикл( в районе миллисекунды) неизмененное значение не привысит какой нибудь порог логика программы не нарушится

Спорягин Кирилл
19.08.2015, 17:15
если честно, я хотел написать одним словом ответ - бред, а теерь еще больший бред, какая разница для основной программы изменились данные или "застыли" на месте, почему она должна работать так медленно, от того что каждую цикл( в районе миллисекунды) неизмененное значение не привысит какой нибудь порог логика программы не нарушится

Я думаю, Вы просто не вчитываетесь в идею. Могу сказать, что выполнять логику программы зная, что у меня не изменились значения входов и выходов не имеет особого смысла. Если свести пример до элементарного, то представть себе код:
if IX0.0 then
делай что-то
end_if;
Исполнять его заведомо зная, что IX0.0 не мог измениться бессмысленно.

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

capzap
19.08.2015, 17:27
Исполнять его заведомо зная, что IX0.0 не мог измениться бессмысленно.

не забывайте что это система реального времени, следуя Вашим умозаключениям здесь 90% кода бессмыслены

а опрос у меня как у всех, регулярное чтение оперативных параметров, один раз загрузка/выгрузка рецептурных параметров, при наступлении события приоритетная запись.
период опроса меня устраивает и 50мс на одно устройство

Спорягин Кирилл
19.08.2015, 17:46
не забывайте что это система реального времени, следуя Вашим умозаключениям здесь 90% кода бессмыслены

Речь идет не о бессмысленности кода, а о бессмысленности его исполнения в некоторых случаях. Так, например, выше был разговор о том, что модули МВ110-8А обновляют данные своих регистров раз в 600-900 мс на канал. Опрашивать их чаще бессмысленно, потому что мы будем получать старые значения с модуля. Здесь логика таже. Нет смысла выполнять логику управления чаще, чем изменяются входные сигналы и выдаются управляющие воздействия. Другое дело, что еще нужно учитывать общение с уровнем оператора. Но для него 110 мс выше крыши.



а опрос у меня как у всех, регулярное чтение оперативных параметров, один раз загрузка/выгрузка рецептурных параметров, при наступлении события приоритетная запись.
период опроса меня устраивает и 50мс на одно устройство

Это чтение не вынесено в отдельную задачу?
Как реализована приоритетная запись. Хотелось бы конкретней, если возможно.

capzap
19.08.2015, 18:38
как Вас конкретизировать, если Вы не приемлете бессмысленный код. Может Вы и будете получать старые значения, но тогда и об аварийной ситуации Вы узнаете не своевременно
по приоритетности изучите полезный блок семафор, выходы разных семафоров через IF...ELSIF будут распределять что выполнить в первую очередь и ни каких отдельных задач не нужно

Yegor
19.08.2015, 21:49
МВ110-8А обновляют данные своих регистров раз в 600-900 мс на канал. Опрашивать их чаще бессмысленноБессмысленно с точки зрения общей реакции системы — да. С точки зрения простоты и стабильности опрашивающего кода — нет, не бессмысленно. Покуда хватает пропускной способности, экономить на такой ерунде не стоит. Лучше равномерный опрос с «бессмысленными» чтениями, чем быстрый опрос с запинками.

Другое дело, если не хватает времени на опрос остальных модулей. Допустим, есть один 8АС и пять штук 8А, при этом с 8АС надо читать как можно быстрее. Естественно, в этом случае уже принимаем во внимание период обновления 8А и выстраиваем очередь вот так: 8АС - 8А_1 - 8АС - 8А_2 - 8АС - 8А_3 <...> 8А_5. Эта очередь будет проходить быстрее 500 мс, но нас это не волнует — мы просто добиваемся стабильной частоты опроса самого быстрого модуля.

Не надо бояться лишний раз что-то вызвать на ПЛК. Он под это заточен. Те же функции чтения/записи порта сделаны так, что можно обходиться вообще без таймеров и нигде ничего не выжидать. Отправили запрос, поменяли состояние автомата, на следующем проходе программы уже начинаем делать SysComRead способом накопления в буфер — пофигу, что данные ещё не пришли. Как только счётчик буфера достиг нужного значения, интерпретируем данные в буфере и сразу переводим автомат в режим отправки запроса. На очередном проходе уже вызывается SysComWrite и дальше снова всё то же самое. Быстро, просто, надёжно, пусть и не экономно в каком-то смысле.

Филоненко Владислав
20.08.2015, 06:35
Ожидать, что ожидаемые 10 байт ответа придут и как только придёт 10 байт- это ответ а не мусор - это очень опасно.
Надо принимать байт, сразу его логически обрабатывать (заголовочный символ, адрес и т.п.) И когда звезды в машине разбора сошлись - проверять CRC и новый запрос.
А не набираем 10 байт - вот он ответ. Возможен мусор на линии.

rwg
20.08.2015, 07:08
Ожидать, что ожидаемые 10 байт ответа придут и как только придёт 10 байт- это ответ а не мусор - это очень опасно.
Надо принимать байт, сразу его логически обрабатывать (заголовочный символ, адрес и т.п.) И когда звезды в машине разбора сошлись - проверять CRC и новый запрос.
А не набираем 10 байт - вот он ответ. Возможен мусор на линии.

Самое непредсказуемое в разных Modbus Slave - это таймауты. Обработка в Slave в идеале должна делаться именно так, как Вы описали. В этом случае Slave не теряли бы ни одного запроса и могли бы вовремя ответить. Но реально так не получается, приходится экспериментальным путём подбирать в Master таймауты, многократно превосходящие стандартные.

Sergey666
20.08.2015, 07:56
Самое непредсказуемое в разных Modbus Slave - это таймауты. Обработка в Slave в идеале должна делаться именно так, как Вы описали. В этом случае Slave не теряли бы ни одного запроса и могли бы вовремя ответить. Но реально так не получается, приходится экспериментальным путём подбирать в Master таймауты, многократно превосходящие стандартные.
Тайм-аут должен быть один - на ожидание ответа , стандартно 1000мс . "Торможение" на модбас шине происходит когда 1 или несколько слэйвов не отвечают и мастер вынужден выдерживать тайм-аут , непрерывно вычитывая буфер порта(для очистки мусора и совести).
Считаю что обмен должен быть организован по принципу непрерывно-независимого-асинхронного потока , как писал выше товарищ Егор , это нормально и надежно .

Валенок
20.08.2015, 09:06
По теме.
Пока 1...2 переменных 1..2 слейва - устраивает конфигуратор.
Когда увеличивается кол-во переменных/слейвов или перенеся код обнаруживаешь какие-то станные зависимости от прошивок/таржетов или нужно более гибкое управление - переходишь на modbus.lib
Перейдя на modbus.lib через некоторое время уходишь на просто syslibcom.lib, т.к. modbus.lib простой и надежный - но можно и улучшить
А перейдя на биб-ки и привыкнув к возможностям почему-то не хочется юзать конфигуратор (конфигуратор-слейв - нареканий невызывает) даже с 1..2 переменных с 1..2 слейвами

То что описал Егор - нормально. Другого варианта для спецификации модбас и последовательного порта просто нет.

Таймаут вообще странное понятие.
Лично я учитываю время от момента отправки последнего байта запроса до момента прихода первого байта пакета-отклика (может и мусор). Почти всегда 3-10мс. Отдельные девайсы - 50мс. Дольше ждать смысла нет - ответа не будет.

capzap
20.08.2015, 09:33
:) чего сразу syslibcom, если не хочется терять связь с конфигуратором, то и unm не плоха

Sashokxxx
20.08.2015, 12:30
http://owen.ru/forum/showthread.php?t=16787&p=175848#post175848 Но это может быть неактуально для СПК.

В библиотеке SysCom которая подсоединяется при добавлении modbus.lib через дескриптор открывается все, но настроить порт, ровно как и получить данные о настройках порта - не получилось. SetSettings and GetSettings не понятно как работают, открыл и настроил через OwenLib читал через UniRead. Все работает.

Валенок
20.08.2015, 13:26
:) чего сразу syslibcom, если не хочется терять связь с конфигуратором, то и unm не плоха
Портирование 63<->110

Yegor
20.08.2015, 14:19
Я таймаут считаю с момента завершения отправки запроса до схождения контрольной суммы ответа. Точнее, это частный случай слежения за автоматом. Тот же таймер следит и за отправкой запроса. Короче, вот псевдокод с некоторыми упрощениями:


(* Срабатывает, если автомат долго находится в одном состоянии *)
сторожевой_таймер(IN := состояние = _состояние, PT := T#100ms);
_состояние := состояние;

IF NOT сторожевой_таймер.IN THEN
счётчик := 0; (* Чтобы в автомате не забывать это триста раз делать *)
END_IF

IF сторожевой_таймер.Q THEN (* Случился таймаут *)
состояние := таймаут;
END_IF


CASE состояние OF


начало:
открыть_порт;
настроить_порт;
состояние := отправлять_запрос;

отправлять_запрос:
(* Сюда вставить ещё код формирования запроса *)
(* Как правило, запрос отправляется целиком сразу *)
счётчик := счётчик + в_порт(буфер, счётчик, размер_буфера - счётчик);
IF счётчик = размер_буфера THEN
состояние := ждать_ответ;
END_IF

ждать_ответ:
(* Сначала читаем до того места, где указан или может быть вычислен размер ответа *)
(* Не забываем, что ответ может приходить частями *)
IF счётчик < до_маркера_размера THEN
счётчик := счётчик + из_порта(буфер, счётчик, до_маркера_размера - счётчик);
ELSE (* Потом читаем остаток вычисленного размера *)
счётчик := счётчик + из_порта(буфер, счётчик, размер_пакета - счётчик);
IF счётчик = размер_пакета AND сходится_сумма THEN
состояние := успех;
END_IF
END_IF

успех:
результат := из_буфера;
состояние := отправлять_запрос;

таймаут:
состояние := отправлять_запрос;

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

rwg
20.08.2015, 14:45
Тайм-аут должен быть один - на ожидание ответа , стандартно 1000мс .
Это если ASCII Modbus. Если RTU и скорость 9600 и более, то 3,5 мсек. Но к сожалению многие производители Modbus Slave его не соблюдают и заставляют себя подолгу ждать . А ещё есть таймаут между концом приёма ответа и следующим запросом. Если не выждать паузу (по стандарту - те же 3,5 мсек, по факту - кто во что горазд), то Slave просто не услышит обращённый к нему запрос.

Спорягин Кирилл
20.08.2015, 18:53
Хочу добить тему организации опроса в одной задаче или в разных.
Опишу все еще раз, но по-другому.
Исходные данные следующие:
1. Количество модулей 10 шт. (все те же);
2. Время достаточное для опроса модуля по сети Modbus - 10 мс. Еще раз поясню, что за время я имею ввиду. Если я на N-ном цикле вызову, например, ФБ MB_RD_HOLD_REGS, то на цикле N+1, отстоящим от него на 10 мс (или более) выход Complete установится в true. Мои расчеты (см. выше) показывают, что 10 мс должно хватать (то же говорит и Валенок:"Почти всегда 3-10мс.").
3. Среднее время выполнения программы - 50 мс. Под этим временем понимается, то усредненное время, которое необходимо для выполнения всех операторов логики управления. Мне кажется, что для программы которая обрабатывает 10 модулей ввода/вывода, это вполне реальная величина.
4. Модули равнозначны по важности, поэтому - 5-й пункт.
5. Опрос модулей организован последовательно от 1 к 10-му. За опрос отвечают некие ФБ модулей. Так как ФБ модули используют общий ресурс - порт, то необходимо предусмотреть некий механизм, который определяет какой ФБ модуль сейчас занимает порт. Назовем условно этот механизм передачей маркера опроса.

Первый вариант. Все в одной задаче.
PROGRAM PLC_PRG
ФБМодуля1(); (* у кого маркер опроса тот исполняется *)
...
ФБМодуля10(); (* а так if not marker then exit; *)
ФБЛогики управления();

Второй вариант. Две разные задачи с разными циклами исполнения.
В это варианте изменен цикл вызова задачи управления. Он сделан равным 60 мс, т.е. с запасом от среднего времени выполнения - 50 мс.
PROGRAM Module_PRG (* циклическая интервал 10мс *)
ФБМодуля1(); (* у кого маркер опроса тот исполняется *)
...
ФБМодуля10(); (* а так if not marker then exit; *)

PROGRAM PLC_PRG (* циклическая интервал 60мс *)
ФБЛогики управления();

Теперь рассмотрим какое будет время реакции на событие в первом и во втором варианте.
Событием будем считать выход некоторого аналогового параметра за технологическую норму. Пусть данный технологический параметр привязан к первому модулю. Событие происходит удачно, как раз перед отправкой запроса в модуль.
За время реакции будем считать время от события до выдачи сигнала с 10-го модуля вывода на исполнительный механизм (ИМ).
Из прикрепленного рисунка хорошо видно, что время реакции в первом случае 450 мс, во втором 100 мс.
Что на мой взгляд существенно.

Другое дело, что если система небольшая, количество модулей 1-2, а время выполнения программы 5-10 мс, то все это безусловно теряет смысл.

capzap
20.08.2015, 18:58
Хочу добить тему организации опроса в одной задаче или в разных.
Опишу все еще раз, но по-другому.
Исходные данные следующие:
1. Количество модулей 10 шт. (все те же);
2. Время достаточное для опроса модуля по сети Modbus - 10 мс. Еще раз поясню, что за время я имею ввиду. Если я на N-ном цикле вызову, например, ФБ MB_RD_HOLD_REGS, то на цикле N+1, отстоящим от него на 10 мс (или более) выход Complete установится в true. Мои расчеты (см. выше) показывают, что 10 мс должно хватать (то же говорит и Валенок:"Почти всегда 3-10мс.").
3. Среднее время выполнения программы - 50 мс. Под этим временем понимается, то усредненное время, которое необходимо для выполнения всех операторов логики управления. Мне кажется, что для программы которая обрабатывает 10 модулей ввода/вывода, это вполне реальная величина.
4. Модули равнозначны по важности, поэтому - 5-й пункт.
5. Опрос модулей организован последовательно от 1 к 10-му. За опрос отвечают некие ФБ модулей. Так как ФБ модули используют общий ресурс - порт, то необходимо предусмотреть некий механизм, который определяет какой ФБ модуль сейчас занимает порт. Назовем условно этот механизм передачей маркера опроса.

Первый вариант. Все в одной задаче.
PROGRAM PLC_PRG
ФБМодуля1(); (* у кого маркер опроса тот исполняется *)
...
ФБМодуля10(); (* а так if not marker then exit; *)
ФБЛогики управления();

Второй вариант. Две разные задачи с разными циклами исполнения.
В это варианте изменен цикл вызова задачи управления. Он сделан равным 60 мс, т.е. с запасом от среднего времени выполнения - 50 мс.
PROGRAM Module_PRG (* циклическая интервал 10мс *)
ФБМодуля1(); (* у кого маркер опроса тот исполняется *)
...
ФБМодуля10(); (* а так if not marker then exit; *)

PROGRAM PLC_PRG (* циклическая интервал 60мс *)
ФБЛогики управления();

Теперь рассмотрим какое будет время реакции на событие в первом и во втором варианте.
Событием будем считать выход некоторого аналогового параметра за технологическую норму. Пусть данный технологический параметр привязан к первому модулю. Событие происходит удачно, как раз перед отправкой запроса в модуль.
За время реакции будем считать время от события до выдачи сигнала с 10-го модуля вывода на исполнительный механизм (ИМ).
Из прикрепленного рисунка хорошо видно, что время реакции в первом случае 450 мс, во втором 100 мс.
Что на мой взгляд существенно.

Другое дело, что если система небольшая, количество модулей 1-2, а время выполнения программы 5-10 мс, то все это безусловно теряет смысл.
так это у Вас теория или Вы на графиках привели среднеизмеренное время? Если всё в реале остановитесь на втором варианте

Спорягин Кирилл
20.08.2015, 19:05
Пока теория. Но собираюсь испробовать на практике. Только пока нет ни контроллера, ни модулей.

Спорягин Кирилл
20.08.2015, 19:07
Что корифеи скажут? Нет ли в моей теории явных ляпов?

Спорягин Кирилл
20.08.2015, 19:11
И еще сразу вопрос. По моим представлениям конфигуратор реализует некоторую последовательность опроса и в сущности выполняется в некоторой отдельной системной задаче. В общем опрос с конфигуратором выглядит как вариант №2. Так почему его ругают при большом количестве модулей?

smk1635
20.08.2015, 20:15
И еще сразу вопрос. По моим представлениям конфигуратор реализует некоторую последовательность опроса и в сущности выполняется в некоторой отдельной системной задаче. В общем опрос с конфигуратором выглядит как вариант №2. Так почему его ругают при большом количестве модулей?

Я вам один умный вещь скажу – но только вы не обижайтесь ... ©

Погоняйте на практике опрос приборов и сами решите правильно ругают конфигуратор, не правильно. Чего воду в ступе толочь.
Как по мне, то Валенок, в посте 32, дал вполне точный ответ.

Sergey666
20.08.2015, 21:08
Что корифеи скажут? Нет ли в моей теории явных ляпов?

Прям такой-эдакий "недоляп" вы только планируете работать и , как я понял , только структуру продумываете , а как у вас с кодом дела обстоят ?
1.Можно и без ПЛК начать тренироваться , только я вас заранее огорчу работать код будет не так как вы рассчитываете , а ... как есть , с некоторыми "нюансами".
2. При всем уважении к товарищам библиотечникам скажу так десятки проектов работают ч-з конфигуратор с количеством модулей 4...12 . Самый первый проект ч-з конфигуратор ПЛК100 работает по модбасу с 12ю частотниками (485й) и 8 модулей на DCON (232-АС3м) . Плюс слэйв , плюс сетевые переменные (UDP) .
3. Чисто для прикола сделал опрос 4 Z-SG (по 1му реалу) и МДВВ на базе дельты (1 DWORD - маска входов , 1 DWORD - маска выходов) ч-з сислибком (Овен Модбас либ мне не нравится ) и Что ???? Скорость ни капельки не увеличилась по сравнению с конфигуратором !!!

4. Конфигуратор работает НОРМАЛЬНО ! Просто как начудят , как наконфигурируют (мы конфигурировали-конфигурировали да невыконфигурировали:p) , что просто ... короче афтар жжот .

5. Теоретизировать по поводу кода опроса это как секс по книжкам изучать :p , лучше собственно и лично на практике ... пробовать ;).

6. Длительность выполнения программы в 50мс !!! Это что ? Программа управления космическим шаттлом ? Тогда модулей маловато ! Откуда вы берете эти дикие миллисекунды ?

7. Вообще "Если можешь что-то делать - бери и делай!" .

spectrum48k
23.08.2015, 02:07
И еще сразу вопрос. По моим представлениям конфигуратор реализует некоторую последовательность опроса и в сущности выполняется в некоторой отдельной системной задаче. В общем опрос с конфигуратором выглядит как вариант №2. Так почему его ругают при большом количестве модулей?

в конфигураторе определенно или не чистится буффер, или не проверяется соответствие отвечающего ведомого требуемому, что при малых таймаутах (настройка ожидания ответа меньше 100мс) приводило к сказочным результатам при управлении ПЧ и модулями мдвв. Возможно связано с тем, что ответ для ведомого с адресом 2 приходил с опозданием от ведомого 1. хотелось бы увидеть исходный код, отвечающий за работу конфигуратора. Думаю, много кто желает понять причину непредсказуемого поведения конфигуратора и знать наверняка, как обходить его подводные камни.

Спорягин Кирилл
04.09.2015, 13:58
Набрал статистику скорости опроса по сети Modbus.

Мастером выступал ПЛК110. В качестве слейва выступал S7-1214 (он имитировал работу МВ110-8АС).
Опрос проводился с использованием библиотеки modbus.lib. Реализацию опроса прикрепляю (см. проект).
Мастер и слейв соединены проводом длиной 30 см.

Реальное время опроса оказалось значительно больше рассчитанного теоретически. Так для опроса 16 байт данных на скорости 115200 бод затрачивается 8мс, в то время как расчет дает значение в 1,9 мс (см. пост №20). С другой стороны если оценить разницу времени опроса 32 и 16 байт, 48 и 32 байт, то она как раз составляет 2 мс.

Спорягин Кирилл
04.09.2015, 14:41
Для скорости 115 Кбод были получены данные для опроса 64, 80 и 96 байт.
64 байт = 14 мс;
80 байт = 16 мс;
96 байт = 18 мс.
Следовательно, опрос 16 байт, действительно, занимает примерно 1,9 мс. Т.е. практические данные сходятся с рассчитанными теоретически. Единственно, что теоретический расчет не учитывает некоторую постоянную составляющую.
А вот почему она такая большая - для скорости 115 Кбод примерно 6 мс - и почему разная для разных скоростей, мне пока не понятно.

spectrum48k
09.09.2015, 15:19
Для скорости 115 Кбод были получены данные для опроса 64, 80 и 96 байт.
64 байт = 14 мс;
80 байт = 16 мс;
96 байт = 18 мс.
Следовательно, опрос 16 байт, действительно, занимает примерно 1,9 мс. Т.е. практические данные сходятся с рассчитанными теоретически. Единственно, что теоретический расчет не учитывает некоторую постоянную составляющую.
А вот почему она такая большая - для скорости 115 Кбод примерно 6 мс - и почему разная для разных скоростей, мне пока не понятно.

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

Спорягин Кирилл
11.09.2015, 11:13
Во всех экспериментах параметр MinCycleLength был установлен в 0.
Я думаю, что он тут не при чем.

spectrum48k
15.09.2015, 02:03
я не вникал в проект.. а могу чисто интереса ради попросить установить MinCycleLength 10 ? Ну, просто очень любопытно...

Спорягин Кирилл
15.09.2015, 10:33
А что Вы ожидаете увидеть?

spectrum48k
16.09.2015, 08:59
изменение времени опроса в ту или иную сторону.

Спорягин Кирилл
17.09.2015, 12:14
Насколько мне известно, параметр MinCycleLength определяет минимальное время цикла. Более того он дополняет его до указанного значения, если реальное время цикла меньше. Т.е. если MInCycleLength = 1 и некая PLC_PRG исполняется за 0,6 мс, то еще 0,4 мс процессор будет спать. Во время 0,6 мс я включаю и его сервисные операции. Учитывая, что у тестовой программы цикл выполнения был меньше 1 мс, то установка любого MinCycleLength отличного от 0 должна увеличить время опроса.
Вы согласны? Или у Вас другое мнение?

Спорягин Кирилл
17.09.2015, 15:09
я не вникал в проект.. а могу чисто интереса ради попросить установить MinCycleLength 10 ? Ну, просто очень любопытно...

Пока суд да дело, провел интересующие Вас эксперименты.
Привожу данные:
MinCycleLength = 0 СВО = 7
MinCycleLength = 1 СВО = 7
MinCycleLength = 2 СВО = 8
MinCycleLength = 5 СВО = 10
MinCycleLength = 10 СВО = 20
СВО (среднее время опроса 4 байт на 115 Кбод).

Время увеличивается и кратно MinCycleLength, чего и следовало ожидать.

capzap
17.09.2015, 15:48
опять же стоит Вам для нас уточнить, как считаете среднее время опроса, возможно на больших циклах добавляется некая паразитная составляющая. Потому что обмен совершенно ге зависит от цикла основной программв, только получение результата лпроса

Спорягин Кирилл
17.09.2015, 16:15
Проект опроса прикреплен к посту №46.

capzap
17.09.2015, 16:28
смешно, я еду в поезде и этот факт не дает мне предсьавления как организован опрос в Вашем проекте, потому что банально телефон не поддерживает КДС

spectrum48k
17.09.2015, 16:58
SKV,
я просмотрел. навскидку: применяется CASE. не кавай. при переходе к следующему шагу, шаг выполняется в след цикле, насколько я помню... сейчас попробую разобраться детально. Увидел такие вещи как сканнинг и поллинг. Вы меня заинтересовали, буду изучать Ваш подход. Обратите внимание: в modbus.lib CASE не используются (видимо для ускорения). У меня тоже есть нечто подобное на стадии тестирования. Не могу довести до ума, тк нет контроллера. Могу я попросить попользоваться ПЛК через интернет?))

http://i.imgur.com/xSP9PEG.png

spectrum48k
17.09.2015, 16:59
С позволения автора, могу в текстовом виде листинг прислать)))

spectrum48k
17.09.2015, 17:26
Вот тут я уже ниасилил....



IF pDisp^.AdressForPooling = Base.Adress THEN
PoolingStat.SecondPoint();
IF GetData THEN AnswerStat.FirstPoint(); END_IF;
pDisp^.GetHoldRegs(
Enable:= GetData,
Mode:= MB_RTU,
DevAddr:= Base.Adress,
FirstAddr:= DataRegister,
Quantity:= RegisterCount,
ComHandle:= pDisp^.Settings.Port,
TimeOut:= TimeOut,
Buffer:= pDisp^.ReciveBuffer);


Указатели в VAR_INPUT можно заменить на внутренние переменные FB в разделе VAR_IN_OUT (это те же указатели в более удобоваримой для этих функций форме, не создают области памяти для себя и не происходит копирования переменных при вызове экземпляра. Поправьте меня, если ошибаюсь)

В принципе без детального изучения... разобрался. Вижу основную проблему быстродействия в CASE. Очередность вызовов диспетчером: диспетчер должен (имхо) не только устанавливать флаг, если время поллинга наступило, но и сразу же осуществлять вызов экземляров фб для записи чтения - для этого модули желательно унифицировать в массив из одноипных FB с массивами регистров внутрях. А массивы уже можно привязать к суказателям на структуры самих модулей в дальнейшем. Я пошел по такому пути.

Спорягин Кирилл
17.09.2015, 17:28
Сегодня я уже должен идти. Завтра с удовольствием прокомментирую свой код.

capzap
17.09.2015, 17:32
а какой смысл в листинге? если человек не может объяснить алгоритм своей программы, это уже ни в какие ворота, а сделав попытку интерпретировать написанную прогу без алгоритма словами, в большинстве случаев приводит к нахождения способов её опьимизации или выявления багов

Вольд
17.09.2015, 18:34
а какой смысл в листинге? если человек не может объяснить алгоритм своей программы, это уже ни в какие ворота, а сделав попытку интерпретировать написанную прогу без алгоритма словами, в большинстве случаев приводит к нахождения способов её опьимизации или выявления багов
SKV vs capzap

Они сошлись. Волна и камень,
Стихи и проза, лед и пламень ...

Как бы до дуэли дело не дошло.:D

capzap, чего ты докопался до него ?

capzap
17.09.2015, 21:08
Я не заметил, чтобы человек не смог или отказался прокомменировать программу. Да и не обязан он комментировать. Попросили проект - пожалуйста, во вложении. Интерпретации словами я тоже не заметил. Мне кажца, тут безосновательный наезд...?)) мое сообщение, признаюсь, - оффтоп. Почищу, после появления контента по теме далее)).

к Вашему сведенью программа подверглась измегениям со слов автора,правда в другой теме и почему я должен обращаться к давно выложенному файлу, чтоб возникло новое гедопонимание, кста на форуме поднималась не раз тема считать затраченое время и выкладывались достойные решения

spectrum48k
17.09.2015, 22:59
capzap, пруфлинк, пожалуйста, на достойное решение с поллингом (диспетчером опроса группы ведомых с разным интервалом опроса для каждого)

Спорягин Кирилл
18.09.2015, 10:22
Spectrum48k, я так понимаю, что Вы уже сами разобрались.
Действительно, ничего сложного. Каждый ФБ модуль имеет параметр PoolingTime, который определяет через какое время модуль требует опроса. В случае истечения этого времени модуль выставляет флаг ReqForPooling. Диспетчер в каждом цикле последовательно бегает по массиву модулей и как только увидел, что какой-то модуль выставил флаг на опрос, передает ему такое право, устанавливая переменную AdressForPooling в
значение адреса данного модуля. Когда модуль завершил опрос, он выставляет флаг готовности и диспетчер снова сканирует массив модулей на предмет запроса на опрос. Это общая схема.
Далее дам свое мнение по Вашим вопросам.



Указатели в VAR_INPUT можно заменить на внутренние переменные FB в разделе VAR_IN_OUT (это те же указатели в более удобоваримой для этих функций форме, не создают области памяти для себя и не происходит копирования переменных при вызове экземпляра. Поправьте меня, если ошибаюсь)

Действительно, можно так поступить. В сущности это будет тоже самое. Копирует он в область Var_input не весь массив, а только указатель. Так же он поступает в случае Var_In_out. Но подход с указателем все же имеет преимущество. Его Вы можете один раз проинициализировать (у меня это делается тут: If FirstScan ...). А вот переменную Var_IN_out вы должны при каждом вызове устанавливать.



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

Я об этом не думал, но задумаюсь над этим. Может, действительно, так сделаю. Но вообще-то это не должно влиять на время опроса, так как у меня последовательность вызовов такая: диспетчер, модуль1, модуль2 и т.д. Т.е. как только диспетчер выдаст кому-то разрешение на опрос, то на этом же скане модуль начнет опрос.



В принципе без детального изучения... разобрался. Вижу основную проблему быстродействия в CASE.

Так как время скана в тестовом примере меньше 1 мс, то любые подобные вещи (Case, вызов модуля из диспетчера) могут увеличить время опроса максимум на 2 мс, а мы видим, что для опроса 4 байт на 115 Кбод требуется 7мс. Я думаю причина где-то глубже.

Спорягин Кирилл
18.09.2015, 10:31
а какой смысл в листинге? если человек не может объяснить алгоритм своей программы, это уже ни в какие ворота, а сделав попытку интерпретировать написанную прогу без алгоритма словами, в большинстве случаев приводит к нахождения способов её опьимизации или выявления багов

Capzap, я тоже не понимаю, почему Вы так недоброжелательно ко мне настроены.
Я делюсь своими наработками, считая, что это кому-то может пригодиться.
Все что я пишу и выкладываю, я в свое время пытался найти на форуме, но не нашел. Надейюсь, что другим будет проще.

Спорягин Кирилл
18.09.2015, 10:41
Так как время скана в тестовом примере меньше 1 мс, то любые подобные вещи (Case, вызов модуля из диспетчера) могут увеличить время опроса максимум на 2 мс, а мы видим, что для опроса 4 байт на 115 Кбод требуется 7мс. Я думаю причина где-то глубже.

Поясню, что для меня это имеет теоретический, а не практический интерес. В целом 7мс на дискретный 32-х канальный модуль и 12 мс на 8-ми канальный аналоговый модуль (с диагностикой!) меня устраивает более чем.

Спорягин Кирилл
18.09.2015, 11:55
Очередность вызовов диспетчером: диспетчер должен (имхо) не только устанавливать флаг, если время поллинга наступило, но и сразу же осуществлять вызов экземляров фб для записи чтения - для этого модули желательно унифицировать в массив из одноипных FB с массивами регистров внутрях.

Вспомнил. Я задумывался над тем, что могу тратить несколько сканов на разрешение опроса модулю. Поэтому, как видно, делаю так, что модуль вызывает диспетчер когда готов:

Base.Ready := TRUE;
pDisp^();

Но в этом случае диспетчер переходит из состояния Pooling в Scaning и не проводит сканирование.

Зато если написать так:
Base.Ready := TRUE;
pDisp^();
pDisp^();

То он еще и сканирование проведет.
А если вот так:
Base.Ready := TRUE;
pDisp^();
pDisp^();
pDisp^();

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

Спасибо за критику.

spectrum48k
18.09.2015, 13:41
SKV, CASE в любом случае нужно убирать и не тиражироать вызовы (CASE заменить на IF Step = .. ;;;; IF Condition THEN Step := Step +1; IF Error THEN Step := 0; и т.д.), тк дисперчер должен после освобождения одного слейва тут же посылать запрос другому. Например, так (фрагмент моего "диспетчера"):



2: (*RUN*)

(*WatchDog*)
TON_WD(IN := TRUE, PT := Set_Poll.WDT);
IF TON_WD.Q THEN ErrCode := ErrCode_WatchDog; Step := 3; RETURN; END_IF
(*Last Cycle 'Busy' Slave: Busy Flag Check*)
IF Busy THEN
SLAVE[BusyNum](Busy => Busy);
IF SLAVE[BusyNum].Done THEN DoneNum := BusyNum; END_IF
END_IF

(*No 'Busy' Slave: Check all slaves for busy again *)

(*ДОБАВИЛ ДЛЯ ПОЯСНЕНИЯ В ЭТОМ ТОПИКЕ: в цикле и далее вызывается Массив из FB-слейвов, в каждом из них буффер чтения, буффер записи, флаги диагностики, таймеры таймаутов, счетчики ошибок, и естественно единственный код опроса на всех напрямую с ком портом без modbus.lib. При вызове обновляются таймеры и если какой-то из них превышает время поллинга больше других слейвов , то он "отправляется на опрос". Также есть вотч-дог диспетчера, если слейвы перестали опрашиваться в течение заданного интервала. *)

IF Busy = FALSE THEN
OverT:= t#0ms;
KickNum := 0;
BusyNum := 0;
FOR Cnt := 1 TO Set_Poll.SlaveCnt DO
IF SLAVE[Cnt].Set.Use THEN
SLAVE[Cnt](
Start:= FALSE,
Poll:= FALSE,
Reset:= FALSE
);
(*'Busy' Slave detected: Set common 'Busy' flag and return*)
IF SLAVE[Cnt].Busy THEN Busy := TRUE; BusyNum := Cnt; RETURN; END_IF
(*Calc Higher OverTime Slave number*)
IF SLAVE[Cnt].ByTime AND SLAVE[Cnt].OverTime > OverT THEN OverT := SLAVE[Cnt].OverTime; KickNum := Cnt; END_IF
END_IF
END_FOR


(*'Kick-start' slave with higher OverTime *)
IF KickNum > 0 THEN
(*New 'Kick-Start' : Reset WatchDog*)
TON_WD(IN := FALSE);
SLAVE[KickNum](Poll:= TRUE, Busy => Busy);
IF Busy THEN BusyNum := KickNum; END_IF
END_IF


END_IF


возможно, когда откатаю на паре объектов, выложу полностью. А пока не готов к жесткой критике со стороны старослужащих))



Еще раз по поводу быстродействия: в modbus.lib есть мистический таймер с вызовом PT:=t#3ms, точно не помню, но какжца, он все тормозит как минимум на один цикл. Модифицировать биб-ку или уходить от нее - это уже дело вкуса)

Валенок
18.09.2015, 14:16
SKV - не слушайте никого про case. Case, case и еще раз case - удобней и читаемей.
А для ликвидации пустых шагов - while true do с return/exit в шагах при необходимости

spectrum48k
18.09.2015, 14:38
Речь не идет о исключении CASE и свитч-технологий из обихода) Речь идет об оптимизации выполнения чтения-записи в одной единственной функции/функциональном блоке. В моем примере видно метку "шага" 2: того же самого CASE.

Валенок, вы опытный и мудрый программист, но здесь не хотите вникать снова )

Спорягин Кирилл
18.09.2015, 14:44
Речь не идет о исключении CASE и свитч-технологий из обихода) Речь идет об оптимизации выполнения чтения-записи в одной единственной функции/функциональном блоке. В моем примере видно метку "шага" 2: того же самого CASE.

Так как я предложил:
pDisp^();
pDisp^();
pDisp^();

Решает проблему с лишними сканами.
Отмечу также, что лишние сканы влияют на время между опросами, а не на время опроса модуля.

Саму идею использования If вместо, case там где нужно, чтобы на том же скане мы переходили на следующий шаг, буду иметь ввиду.

spectrum48k
18.09.2015, 15:29
Обязательно изучите modbus.lib, а именно FB приема на наличие таймера таймаута t#3ms на предмет его необходимости и влияния этого таймера скорость работы биб-ки в части завершения ожидания приема буффера данных.
З.Ы. (да где вообще разработчики взяли это время...это не 1,5 и не 3,5 символа)

capzap
18.09.2015, 18:19
capzap, пруфлинк, пожалуйста, на достойное решение с поллингом (диспетчером опроса группы ведомых с разным интервалом опроса для каждого)

какие у кого решения ищите сами, на вкус и цвет ...
у меня есть свой взгляд на такой опрос и меня он вполне устраивает


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

что касается времен опроса при разных временах мин.цикла, они такие как есть,но я уже писал что на одной и той же скорости сам обмен время не поменяет, проблемы только с отображением результата в текущем циикле, причем это сильно зависит от полноты наполнения проекта, на видео которое выкладываю при работе только одного TON-а среднее время было 8мс, добавив второй таймер среднее время увеличилось на 2мс, уже не говорю если это будет полноценный проект. Кроме того на видео показал время свободное от работы процессора, мин.цикл лучше подбирать, чтоб оставался некоторый запас микросекунд. Я не сторонник нуля в мин.цикле, если хочется свободное выполнение для этого есть конфигуратор задач. Еще Вы что то писали про операции обмена после выполнения PLC_PRG, тогда стоит рассмотреть ситуацию с модбасом мастером в конфигураторе и программой в стопе, удивительно на данные из слейва будут читаться, так что по моему мнению искать связь выполнения программы и обмена не стоит и уменьшение ради этого мин.времени цикла бесполезное занятие и вообще это может привести к нестабильному или приему с большим количеством ошибок


(да где вообще разработчики взяли это время...это не 1,5 и не 3,5 символа) ну не Вы же написали эту бибку, Вы ей только пользуетесь и цокаете и чем Вы отличаетесь от меня тогда? Поставил человек 3мс и ладно, не сильно это будет тормозить в отличии от 3,5 символов

ЗЫ для видео увеличил время первого таймера до 300мс, но его можно поставить чуть больше среднего времени

spectrum48k
18.09.2015, 21:12
ну не Вы же написали эту бибку, Вы ей только пользуетесь и цокаете и чем Вы отличаетесь от меня тогда? Поставил человек 3мс и ладно, не сильно это будет тормозить в отличии от 3,5 символов


Вынужден расстроить: ей только и не пользуюсь и не пользовался. Перед первым использованием открыл, изучил и передумал использовать. Написал в мае-июне свой луна-паркс блекджеком и плюшками. До этого пользовался конфигуратором. Как я ранее писал, конфигуратор меня очень расстроил. А вообще, я - фанат IOScanner )) Но об этом в другом форуме (se-automation.in.ua).

capzap
18.09.2015, 22:04
да меня это вобще не задевает, чем Вы пользуетесь. Полноценный проект обычно занимает не менее 2мс, пауза между фреймами по стандарту не должна быть меньше этих пресловутых 3,5 символов, но больше то ни кто не запрещает, поэтому 3мс в бибке ни как не скажутся на работе, тем более приведенные здесь статистические данные относятся к 4 байтам, а в рабочих проектах выборка данных на много больше, таким образом гипотетически следующий запрос можно смело посылать в следующем цикле, вот только кто так делает

spectrum48k
18.09.2015, 23:00
да меня это вобще не задевает, чем Вы пользуетесь. Полноценный проект обычно занимает не менее 2мс, пауза между фреймами по стандарту не должна быть меньше этих пресловутых 3,5 символов, но больше то ни кто не запрещает, поэтому 3мс в бибке ни как не скажутся на работе, тем более приведенные здесь статистические данные относятся к 4 байтам, а в рабочих проектах выборка данных на много больше, таким образом гипотетически следующий запрос можно смело посылать в следующем цикле, вот только кто так делает

3,5 символа, это вообще по-хорошему интервал для ведомого, перед ответом ведущему. Мастер же не должен ничего ждать, если размер принятого буффера равен ожидаемому размеру. И после проверки CRC, адреса, функции и дальнейшей разборки пакета, должен в этом же вызове накормить следующий буфер отправки. Вот это было бы логично и быстро. А при использовании modbus.lib, давайте при готовом принятом буфере отдадим ~t#10ms основному вызову проекта каждый раз после принятого буфера. Для 8 регистров это будет каких-то t#80ms. Не мешает? Да пользуйтесь на здоровье. Плачьте и колитесь) Кактуса хватит на всех. А если опрос и проект(алгоритм) не разнесены по разным задачам, то это будет вообще паровоз....

capzap
19.09.2015, 07:57
повторюсь, я веду речь о модбас rtu, цитата из вики:" Сообщение должно начинаться и заканчиваться интервалом тишины, длительностью не менее 3,5 символов при данной скорости передачи. Во время передачи сообщения не должно быть пауз длительностью более 1,5 символов. Для скоростей более 19200 бод допускается использовать интервалы 1,75 и 0,75 мс, соответственно" ни о какой паузе между запросом и ответом речь не идет,хотя и включает в себя эту ситуацию тоже
что касается должен ли чего то ждать мастер, это обусловленно концепцией контроллеров, если в моем примере обработку ответа поставить в начало поу, так и выйдет получив ответ прога может сразу,в этом же цикле, отправить очередной запрос
а последняя часть Вашего опуса вобще какой то бред, неимеющий ни какого отношения к передаче данных

spectrum48k
19.09.2015, 12:52
повторюсь, я веду речь о модбас rtu, цитата из вики:" Сообщение должно начинаться и заканчиваться интервалом тишины, длительностью не менее 3,5 символов при данной скорости передачи. Во время передачи сообщения не должно быть пауз длительностью более 1,5 символов. Для скоростей более 19200 бод допускается использовать интервалы 1,75 и 0,75 мс, соответственно" ни о какой паузе между запросом и ответом речь не идет,хотя и включает в себя эту ситуацию тоже
что касается должен ли чего то ждать мастер, это обусловленно концепцией контроллеров, если в моем примере обработку ответа поставить в начало поу, так и выйдет получив ответ прога может сразу,в этом же цикле, отправить очередной запрос
а последняя часть Вашего опуса вобще какой то бред, неимеющий ни какого отношения к передаче данных

Сергей, не спешите приписывать мне патологическое расстройство сознания - вы не психиатр) Мой "бред" как раз опровергает это:


поэтому 3мс в бибке ни как не скажутся на работе

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

capzap
19.09.2015, 12:56
Сергей, не спешите приписывать мне патологическое расстройство сознания - вы не психиатр) Мой "бред" как раз опровергает это:

тогда из чего складывается 80мс в Вашей задумке?
И почему опрос обязательно должен идти в параллельной задаче?

spectrum48k
19.09.2015, 13:33
Мои 80мс предполагают следующую ситуацию:
1) Буффер отправлен ведомому;
2) Выполняется программа основного алгоритма (~10мс, "с потолка"); (Это еще почти идеальный вариант без PID-регуляторов)
3) MinCycleLenth 1мс;
4) Ответ ведомого: принят полностью (идеальная ситуация);
5) Таймер 3мс считает, разбор буффера еще не начинался;
6) Выполняется программа основного алгоритма (~10мс);
7) MinCycleLenth 1мс;
8) Таймер 3мс Q=TRUE , обработка буффера , DONE;
9) переход к шагу 1;

(Добавочное) Время выполнения для 8 регистров/ 8 ведомых = 8x3 мс + 8x10 мс = 80 --- 104 мс в данном примере.

Такой порядок действий соответствует программе, в которой MODBUS.PRG и CONTROL.PRG выполняются в одной задаче.

Я считаю, что обмен нужно выносить в отдельную задачу для оптимизации обмена. И само собой без таймера 3мс
У меня есть работающий объект, в котором вертится 3 отдельных задачи (Modicon M238, Somachine V3.1=Codesys V3.4): 1)Основной алгоритм (циклическая 100мс) 2) Modbus (циклическая 10мс, местная библиотека, похожая на Mosbus.lib) 3) Низкоприоритетные операции (циклическая 800мс).

capzap
19.09.2015, 13:54
Мои 80мс предполагают следующую ситуацию:
1) Буффер отправлен ведомому;
2) Выполняется программа основного алгоритма (~10мс, "с потолка"); (Это еще почти идеальный вариант без PID-регуляторов)
3) MinCycleLenth 1мс;
4) Ответ ведомого: принят полностью (идеальная ситуация);
5) Таймер 3мс считает, разбор буффера еще не начинался;
6) Выполняется программа основного алгоритма (~10мс);
7) MinCycleLenth 1мс;
8) Таймер 3мс Q=TRUE , обработка буффера , DONE;
9) переход к шагу 1;

(Добавочное) Время выполнения для 8 регистров/ 8 ведомых = 8x3 мс + 8x10 мс = 80 --- 104 мс в данном примере.

Такой порядок действий соответствует программе, в которой MODBUS.PRG и CONTROL.PRG выполняются в одной задаче.

Я считаю, что обмен нужно выносить в отдельную задачу для оптимизации обмена. И само собой без таймера 3мс
У меня есть работающий объект, в котором вертится 3 отдельных задачи (Modicon M238, Somachine V3.1=Codesys V3.4): 1)Основной алгоритм (циклическая 100мс) 2) Modbus (циклическая 10мс, местная библиотека, похожая на Mosbus.lib) 3) Низкоприоритетные операции (циклическая 800мс).

Вы путаете как работает программа в ЯВУ и плк, ни кто не ждет отсчета работы таймера, в следующем цикле проверяется состояние текущего времени и уставки таймера и если оно превышает подается положительный сигнал на выход таймера
По поводу 8 регистров снял видео, какие там 80мс?

Валенок
19.09.2015, 15:16
Мои 80мс предполагают следующую ситуацию:
1) Буффер отправлен ведомому;
..
9) переход к шагу 1;
..
Такой порядок действий соответствует программе, в которой MODBUS.PRG и CONTROL.PRG выполняются в одной задаче.
.

При всем уважении - такой порядок действий у приведенного Вами алгоритма.
А что Вы называет одной задачей ? НЕиспользование местного конфигуратора задач ?

spectrum48k
19.09.2015, 21:10
Вы путаете как работает программа в ЯВУ и плк, ни кто не ждет отсчета работы таймера, в следующем цикле проверяется состояние текущего времени и уставки таймера и если оно превышает подается положительный сигнал на выход таймера
По поводу 8 регистров снял видео, какие там 80мс?

Само собой не ждет! Я не говорил, что ждет! "Таймер 3мс считает, разбор буффера еще не начинался" ---- проверка выхода "Q" таймера, а не остановка выполнения программы! В этом шаге выход "Q" таймера не установлен, и выполняется выход из ФБ чтения регистров, после этого программа выполняется далее.

spectrum48k
19.09.2015, 21:51
При всем уважении - такой порядок действий у приведенного Вами алгоритма.
А что Вы называет одной задачей ? НЕиспользование местного конфигуратора задач ?

называю это:

20027

spectrum48k
19.09.2015, 22:09
По поводу 8 регистров снял видео, какие там 80мс?

20028

Это что, подтасовка под результат? Какая quantity=8 ?? А Вы вот возьмите и считайте 8 не смежных регистров. Или 8 ведомых устройств. 8 запросов и 8 ответов. Почему я по-Вашему умножил время выполнения алгоритма (10мс) на 8 ? Если бы не использовался таймер 3мс, то шагов 6 и 7 вообще бы не было. (Еще раз обращаю внимание, что данный пример учитывает вызов обмена и основной программы в одном Task или в одной PRG). При использовании нескольких задач, это будет неактульно и временные характеристики будут иными.

spectrum48k
19.09.2015, 22:13
Вы путаете как работает программа в ЯВУ и плк, ни кто не ждет отсчета работы таймера,

я тут в соседней теме написал пример собственного таймер, а Вы меня
вот так после этого унижаете)))

Без понимания работы мэковских таймеров, как бы я написал свой??))

capzap
19.09.2015, 23:30
20028

Это что, подтасовка под результат? Какая quantity=8 ?? А Вы вот возьмите и считайте 8 не смежных регистров. Или 8 ведомых устройств. 8 запросов и 8 ответов. Почему я по-Вашему умножил время выполнения алгоритма (10мс) на 8 ? Если бы не использовался таймер 3мс, то шагов 6 и 7 вообще бы не было. (Еще раз обращаю внимание, что данный пример учитывает вызов обмена и основной программы в одном Task или в одной PRG). При использовании нескольких задач, это будет неактульно и временные характеристики будут иными.

как то я сильно сомневаюсь, что несколько параллельны задач, в один и тот же порт, будут слать запросы и им за это ничего не будет, Вы точно говорите про модбас, мастер должен быть один и он должен соблюдать стандарты, кстати если перед и после запроса должны быть паузы тишины, то принятое время по умолчанию 1.75 умножив на два получим больше трех, так что автор бибки еще взял время по меньше

spectrum48k
19.09.2015, 23:36
см. иногозадачность в примере применения в #82

spectrum48k
19.09.2015, 23:37
см. "многозадачность" в конце #82

spectrum48k
19.09.2015, 23:43
кстати если перед и после запроса должны быть паузы тишины, то принятое время по умолчанию 1.75
а если на секунду забыть несколько размытое требование в стандарте, которое по моему скромному мнению, определяет именно тот интервал, через который начинает отвечать именно ведомый. После приема ответа мастером, зачем ему выдерживать паузу, если ведомые уже готовы принять телеграмму?

spectrum48k
19.09.2015, 23:59
http://i.imgur.com/kCbT9Hj.png

вот какие-то диаграммы, и что с ними делают программисты микроконтроллеров в slave-устройствах ввода-вывода - одним программистам известно. Сомневаюсь что у кого-то "ума хватило" при написании алгоритма ведомого устройства задать "мертвую зону" длиной 3,5 символа после ответа мастеру, в течение которой запросы игнорируются/входной буфер очищается.

capzap
20.09.2015, 08:50
что с ними делают программисты микроконтроллеров в slave-устройствах ввода-вывода

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

а по поводу всего остального, еще раз обозначу: по физической линии на одной и той же скорости запрос/ответ по времени проходит за одно и тоже значение плюс некоторая составляющая из-за какого нибудь прерывания, эта составляющая на столько мала, что на неё отводят 1,5 символа между фреймами. Появление результата запроса конечно же зависит от времени цикла, первое что приходит в голову это вывести опрос в отдельную задачу. Для меня есть одно но, во первых не попадался мне плк двух и более ядерный, чтоб была настоящая многозадачность, во вторых в таких системах нет понятий как volatile и synchronized, что будет происходить, если опросная задача захватила буфер,а в это время основная задача по прерыванию начала его читать. Остается держать в ОЗУ два дублирующих буфера (в случае одного опрашиваемого ведомого), а избыточная трата ресурсов может привести к нестабильности системы в целом, а не только обмена

Вольд
20.09.2015, 09:49
а если на секунду забыть несколько размытое требование в стандарте, которое по моему скромному мнению, определяет именно тот интервал, через который начинает отвечать именно ведомый. После приема ответа мастером, зачем ему выдерживать паузу, если ведомые уже готовы принять телеграмму?
Для нормального обмена линия RS-485 должна быть захвачена как минимум с одной стороны. По этой причине после приема пакета от Master Slave должен сразу захватить линию. Master после передачи пакета какое-то время (время тишины) тоже удерживает линию. Далее Master отпускает линию и Slave начинает передачу пакета отклика.

spectrum48k
20.09.2015, 10:13
т.е. Вы вобще не верите что прерывания в любых устройствах могут задержать ответ по последовательному порту. Эта пауза ни как не связана с обработкой. Она нужна, как и написано, для того чтоб в сети была тишина и все кто хотел что то сказать (мастер или ведомые) вытолкали свой передающий буфер и не создали помех для очередного запроса/ответа



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


Для меня есть одно но, во первых не попадался мне плк двух и более ядерный, чтоб была настоящая многозадачность


а смотрите, какая прелесть:
http://i.imgur.com/JctCEIU.png

https://youtu.be/D6aOwL4Km98?list=PLbM9W4wBG-KtwAndrhnr-2PC0-F6-duWi

spectrum48k
20.09.2015, 10:31
Для нормального обмена линия RS-485 должна быть захвачена как минимум с одной стороны. По этой причине после приема пакета от Master Slave должен сразу захватить линию. Master после передачи пакета какое-то время (время тишины) тоже удерживает линию. Далее Master отпускает линию и Slave начинает передачу пакета отклика.

особенности работы полупроводниковых драйверов RS-485.

Если кто писал свой вариант библиотеки modbus, выдерживаете ли вы паузу после ответа ведомого, используя таймеры? Интересен ваш опыт.

ASo
20.09.2015, 10:41
смысл паузы, я понимаю так же как и Вы. Но приведите раумное обоснование необходимости паузы после того, как ведомый ответил и мастер принял ответ полностьюЗатем, чтобы другие слейвы подготовились.

spectrum48k
20.09.2015, 10:55
В этой теме уже ответили все ветераны форума)) Как именно слейвы должны подготовиться? Есть ли у кого-нибудь пример программы микроконтроллера (ну мало ли откуда)

Вольд
20.09.2015, 10:55
особенности работы полупроводниковых драйверов RS-485.

Если кто писал свой вариант библиотеки modbus, выдерживаете ли вы паузу после ответа ведомого, используя таймеры? Интересен ваш опыт.

Я в своем посте ответил на ваши вопросы. Полупроводниковые драйверы RS-485 тут не при чем, все делается на программном уровне.

Вольд
20.09.2015, 10:59
смысл паузы, я понимаю так же как и Вы. Но приведите раумное обоснование необходимости паузы после того, как ведомый ответил и мастер принял ответ полностью

Затем, чтобы линия RS-485 не была отпущена с обеих сторон. Встань осциллографом на длинную линию RS-485 не захваченную ни с одной стороны и увидишь сколько на ней "мусора".

spectrum48k
20.09.2015, 11:06
Master после передачи пакета какое-то время (время тишины) тоже удерживает линию.


это вопрос к разработчикам. Возможно у Вас есть факты , на которые опираетесь. У меня таких фактов и опыта разработки подобных устройств (например серия МВ) нет.

spectrum48k
20.09.2015, 11:14
Встань на длинную линию RS-485 не захваченную ни с одной стороны и увидишь сколько на ней "мусора".
Для ПЛК серии 100-150 это неактуально вообще)) Резисторы подтяжки ( смещения/biasing) наглухо впаяны. Все объекты вводил в работу с осциллографом. Без него - эт вообще танцы с бубном (имхо).

ASo
20.09.2015, 12:49
В этой теме уже ответили все ветераны форума)) Как именно слейвы должны подготовиться? Есть ли у кого-нибудь пример программы микроконтроллера (ну мало ли откуда)
Что они опять должны быть готовы принять запрос.

spectrum48k
20.09.2015, 15:40
Могу только предположить, что после отправки ответа они уже как бы готовы)

ASo
20.09.2015, 15:43
Какого ответа?
Вы понимаете, что в общем случае слэйв не один? И те, которые не отвечали в текущем цикла, должны понять, что пошел новый цикл, надо слушать линию.

spectrum48k
20.09.2015, 16:01
Для понимания нового цикла достаточно отправить буффер ответа и снять сигнал с ноги "DE" и инвертированного "RE" драйвера, отправив передатчик в "высокоимпедансное состояние" .
Разве есть еще какие-то премудрости? Кажца, здесь завелся инсайдер. ))
Отвлеклись от темы.
Предлагаю подытожить тему по 3м вариантам использования: 1) конфигуратор, 2) modbus.lib 3) самописные бибки, нарушающие стандарты :). Плюсы и минусы. А научить меня-выскочку уму-разуму сможете при удобном случае в разделе "Курилка"

ASo
20.09.2015, 16:22
Вы совсем не понимаете?
Пример - в сети 2 слейва с адресами 1 и 2.
Мастер опросил 1.
Как 2 определит, что 1 закончил передачу ответа?

По теме
1. Для стандартных случаев.
2. Для нестандартных, если нужен неравномерный опрос и т.п.
3. Если заняться нечем.

Валенок
20.09.2015, 20:10
называю это:

20027
Это - многозадачность ? :) :) :)
Это НИЧЕМ не отличается от пары вызовов в PLC_PRG

Вольд
21.09.2015, 10:16
Вы совсем не понимаете?
Пример - в сети 2 слейва с адресами 1 и 2.
Мастер опросил 1.
Как 2 определит, что 1 закончил передачу ответа?

Slave не надо ничего такого определять, ему надо следить за тем нет ли обращения по его адресу.

rwg
21.09.2015, 10:56
приведите раумное обоснование необходимости паузы после того, как ведомый ответил и мастер принял ответ полностью
Разумных объяснений целых 2:
1. Не все Slave достаточно умные, чтобы понять, что другой Slave закончил ответ и не смогут понять, где находится конец ответа, а где - начало следующего запроса. Такой болезнью, в частности, раньше болели ТРМы. Сейчас не знаю.
2. Без таймаута надпись в паспорте Вашего устройства "Modbus" будет откровенной ложью.

spectrum48k
21.09.2015, 11:00
называю это:

20027



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

http://i.imgur.com/dRsAfKF.png

spectrum48k
21.09.2015, 11:23
Вы совсем не понимаете?

Как 2 определит, что 1 закончил передачу ответа?



Конечно, понимаю, что пауза - это момент определения стартовой позиции адреса ведомого итд, момент синхронизации начала посылки, чтобы правильно разделить ее содержимое на составляющие. Но 3мс не дают мне покоя.) У кого есть идеи как правильно высчитывать выдержку в зависимости от скорости передачи данных в коде программы на ST например? Не расчет времени (с этим все понятно), а реализация. Обычное использование таймера передает управление остальной программе, и она как минимум прокручивается еще раз, прежде чем выполнится отправка след запроса. А это не очень красиво с точки зрения быстройдействия. Цикл WHILE с таймером внутри не предлагать?)

Yegor
21.09.2015, 11:36
Касательно кейса.


CASE step OF
send:
stuff();
rcv:
stuff();
END_CASE




REPEAT
repeat := FALSE;
CASE step OF
send:
stuff();
rcv:
stuff();
END_CASE
UNTIL
NOT repeat
END_REPEAT;

rwg
21.09.2015, 11:39
длина любого ответа заранее известна в соответствии с запросом.
В обязанности Slave не входит анализ чужих запросов и ответов. Нормальный драйвер сом-порта Slave анализирует первый принятый после таймаута байт и, если это не его адрес, ждёт следующий первый после таймаута байт .

spectrum48k
21.09.2015, 12:04
Как я ранее выше говорил, есть у меня некоторая самоделка. Как доберусь до железа, попробую непрерывный опрос ведомых с таймаутом и без него. Интересно на практике узнать выдерживается ли таймаут средствами самой среды исполнения кодесис при передачи управления "операционной системе" или модули будут "затыкаться" через раз. У кого есть плк с удаленным доступом?) Предложите вариант выдержки с приостановкой выполнения? через REPEAT или WHILE ?

rwg
21.09.2015, 12:17
Как я ранее выше говорил, есть у меня некоторая самоделка. Как доберусь до железа, попробую непрерывный опрос ведомых с таймаутом и без него. Интересно на практике узнать выдерживается ли таймаут средствами самой среды исполнения кодесис при передачи управления "операционной системе" или будут таймауты сыпатсься через раз. У кого есть плк с удаленным доступом?) Предложите вариант выдержки с приостановкой выполнения? через REPEAT или WHILE ?
Сталкивася с тем, что МСД-100 опрашивал ТРМ200 именно через один. В связи с отсутствием настройки нужного таймута вставил в опрашиваемые приборы нечётные несуществующие адреса.
А для организации нужного таймаута достаточно запускать программу циклически. В одном цикле обработать ответ, в следующем, через 3-4мс послать запрос. Только сначала убедиться, что для Slave не требуется таймаут нестандартной большей длины.

spectrum48k
21.09.2015, 12:21
Скорее всего попробую организовать таймаут в диспетчере вызова блоков. Пример где-то выше в теме. Добраться бы только до железа. Нет у меня ПЛК, а жаль)

spectrum48k
21.09.2015, 12:25
Сталкивася с тем, что МСД-100 опрашивал ТРМ200 именно через один. В связи с отсутствием настройки нужного таймута вставил в опрашиваемые приборы нечётные несуществующие адреса.
А для организации нужного таймаута достаточно запускать программу циклически. В одном цикле обработать ответ, в следующем, через 3-4мс послать запрос. Только сначала убедиться, что для Slave не требуется таймаут нестандартной большей длины.

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

capzap
21.09.2015, 12:52
Интересно на практике узнать выдерживается ли таймаут средствами самой среды исполнения кодесис при передачи управления "операционной системе" или модули будут "затыкаться" через раз.
а на моем видео из 75 поста не видно что количество запросов больше чем ответов, как раз снижал время периода опроса впритык с затраченным временем на опрос


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

spectrum48k
21.09.2015, 13:08
а на моем видео из 75 поста не видно что количество запросов больше чем ответов, как раз снижал время периода опроса впритык с затраченным временем на опрос


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

речь не об этом.
Попробую объяснить:

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

rwg
21.09.2015, 13:23
Вопрос том как выдержать интервал необходимый в соответствие со стандартом, а не такой, какой получится.

Ключевое слово в HELPe "Конфигурация задач".

spectrum48k
21.09.2015, 13:31
Ключевое слово в HELPe "Конфигурация задач".
шутка не засчитана. какой получится=в завимости от объема основной программы

rwg
21.09.2015, 13:37
шутка не засчитана. какой получится=в завимости от объема основной программы

Что же у Вас за программа, которая выполняется более 3мсек? У меня их обычно две, дискретные цепи обрабатываются раз в 10 мсек за 0,5мсек и аналоговые (4 каскадных ПИ-регулятора) - 2 раза в секунду за 2 мсек.

spectrum48k
21.09.2015, 14:08
Что же у Вас за программа, которая выполняется более 3мсек? У меня их обычно две, дискретные цепи обрабатываются раз в 10 мсек за 0,5мсек и аналоговые (4 каскадных ПИ-регулятора) - 2 раза в секунду за 2 мсек.

а у меня их три. скрин выше. но тем не менее)

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

capzap
21.09.2015, 14:10
а у меня их три. скрин выше. но тем не менее)

там у Вас КДС3 вроде, производитель рекомендует минц делать 20мс, о чем тогда тут можно говорить

spectrum48k
21.09.2015, 14:38
Для контроллера Modicon M238:

Задача MAST (главная задача) может конфигурироваться как периодическая или циклическая.
По умолчанию задача MAST автоматически создаётся как циклическая, со средним уровнем
приоритета (15) и с интервалом 20 мс
Эт как бы дефолт, а не рекомендация. Честно говоря, не понимаю о каком именно производителе Вы говорите?

И тут как бы несколько иная ситуация, так что сравнивать вообще неуместно:http://i.imgur.com/QxzPEqL.png

rwg
21.09.2015, 14:39
выдержке ровно столько, сколько нужно и отправка буффера сразу же, без прокрутки логики "алгоритма управления"

Во времена Windows98 и настоящих СОМ-портов делал это на РС путём опроса системного таймера. Получалось формировать импульсы ножками RS232 длительностью более 4мкс точностью 1-2мкс. Если остальные части программы Вам это позволяют, засекайте время прихода байта по TIME и останавливайте выполнение программы на нужное число мсек.

spectrum48k
21.09.2015, 15:07
когда я говорил, что есть идея, именно это имел в виду.
http://i.imgur.com/tluoXIE.png
Думаю, небольшое преступление придержать выполнение на 2мс. Если надо ждать больше, то, RETURN, например.

Yegor
24.09.2015, 11:07
Про CASE в опросе... Таки да, есть смысл его оптимизировать. По крайней мере с одним тензопреобразователем, у которого свой, но похожий на модбас протокол, наблюдается существенная разница. Задача как раз стоит опрашивать его как можно чаще. Сильно вдаваться в подробности не хочу; простой переделкой кейса как в посте 114 (http://owen.ru/forum/showthread.php?t=21940&p=181234&viewfull=1#post181234) удалось повысить частоту опроса со 180 до 220 сэмплов в секунду.

Спорягин Кирилл
27.10.2015, 15:58
Появилось желание посмотреть внутренности библиотеки modbus.lib. Но тот экземпляр, что есть у меня не позволяет просмотреть код ФБ.
Я часто встречал рекомендацию посмотреть код библиотеки, значит раньше он был открыт. Кто-нибудь может поделиться открытым экземпляром?

capzap
27.10.2015, 16:09
Появилось желание посмотреть внутренности библиотеки modbus.lib. Но тот экземпляр, что есть у меня не позволяет просмотреть код ФБ.
Я часто встречал рекомендацию посмотреть код библиотеки, значит раньше он был открыт. Кто-нибудь может поделиться открытым экземпляром?

правой кнопкой по любому ФБ и в свойствах сменить права

Спорягин Кирилл
27.10.2015, 16:52
Спасибо, помогло.

Спорягин Кирилл
31.08.2016, 17:12
Добрый вечер, уважаемые форумчане.
Разобрал библиотеку Modbus.lib.
Хочу поделиться важными замечаниями.

1. Для проведения опроса требуется минимум 3 цикла обращения к соответствующему блоку.
На 1-м цикле: блок формирует посылку, отсылает ее в порт;
На 2-м цикле: блок занимается чтением из порта (циклов чтения может быть много);
На 3-м цикле: завершается опрос.
Данные выводы следуют из анализа ФБ MB_UNI_IO (см. рисунок MB_UNI_IO).

Почему я обращаю на это внимание?
Потому что, если ваша PLC_PRG выполняется, например, 15 мс (у меня есть реальный проект, где такое время выполнения на ПЛК110 старой модификации), то на опрос даже 1 регистра на любой скорости сети!!! вы будете тратить 30 мс.

Для решения данной проблемы необходимо вынести вызов ФБ Modbusа в отдельную задачу, которую вызывать чаще чем основную PLC_PRG (см. этот пост (http://www.owen.ru/forum/showthread.php?t=21940&page=4&p=178607&viewfull=1#post178607)).

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

Валенок
31.08.2016, 18:21
Хочу поделиться важными замечаниями.
1. Для проведения опроса требуется минимум 3 цикла обращения к соответствующему блоку..
Ессно. Или предлагаете не выходя из цикла ждать у моря погоды ?
Тогда не удивительно что

ваша PLC_PRG выполняется, например, 15 мс (у меня есть реальный проект, где такое время выполнения на ПЛК110 старой модификации

По мне, так сижу как на иголках коли цикл на МО1 уходит за 2-3мс.

Про RTU. (Ascii не юзаю, но в том же ключе)
1.Отправили запрос. Ну и кого ждем ? Вышли
2.Умудрились получить все данные. А это не данные, а просто мусор. Даже если очень похож на правильный ответ. В пакет этот мусор превращается после соотв.паузы. А откуда паузу отчитывать если не знаем когда пришел последний байт ? Для нас последний байт пришел именно сейчас. Выходим. Не ждать же паузу в цикле.
3.В порту - тихо, время вышло. Тот кусок мусора оказываецца - пакет. Надоть его разобрать. Разобрали ? Вот тут можно прям в этом цикле перейти к п.1


Для решения данной проблемы необходимо вынести вызов ФБ Modbusа в отдельную задачу, которую вызывать чаще чем основную PLC_PRG
За каким PLC_PRG вызывать реже модбас-блока ? Какое отношение цикл опроса имеет к циклу ПЛК ?
ПЛК встал, поел-попил, глянул почту, и убежал по своим делам. Какое ему дело до графика движения почтальона ?



в том случае, если блок вернул ошибку, то перед повторным вызовом данного блока необходимо заново формировать буфер посылки

А причем тут MB_WR_REGS ? Перед любым вызовом любого блока формируется необходимый на данный момент буфер. Буфер это тарелка в столовой. Каждый ее наполняет чем хочет перед использованием.

Спорягин Кирилл
31.08.2016, 18:30
Важно, что в 2 цикла он не уложится, т.е. на 1-м цикле отослал, а на 2-м получил - так не получается. Всегда есть 3-й цикл, в котором авторы библиотеки Modbus.lib проверяют, что
больше ничего не приходит. Поэтому всегда на опрос устройства тратится время >= 2*MinCycleLength.

Спорягин Кирилл
31.08.2016, 18:31
По мне, так сижу как на иголках коли цикл на МО1 уходит за 2-3мс.


У меня есть проект с временем выполнения 15 мс. Видимо, Ваши проекты меньше.

Спорягин Кирилл
31.08.2016, 18:35
А причем тут MB_WR_REGS ? Перед любым вызовом любого блока формируется необходимый на данный момент буфер. Буфер это тарелка в столовой. Каждый ее наполняет чем хочет перед использованием.

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

Валенок
31.08.2016, 21:34
Важно, что в 2 цикла он не уложится, т.е. на 1-м цикле отослал, а на 2-м получил - так не получается..
1.Кому важно ?
2.Циклы попутали - см.выше
3.А получается - см. выше и ниже. Правда за счет непонятного замедления PLC_PRG. И накой это ?



авторы библиотеки Modbus.lib проверяют, что больше ничего не приходит..
Поправлю :
"авторы Modbus.lib проверяют..."
Иначе это не модбас.
А совместить 1й и 3й можно. И это останется модбасом.

Валенок
31.08.2016, 21:41
У меня есть проект с временем выполнения 15.
Ну есть.. Я могу для 3х строчек и 500мс сделать.


Видимо, Ваши проекты меньше.
В каких единицах мерием ? Если в мс - то да, говорил же что от 3мс напрягает почему-то

Спорягин Кирилл
01.09.2016, 11:22
1. По поводу циклов нет никакой путаницы (по крайней мере у меня). То что для обработки любого запроса тратится минимум 3 цикла (если быть точным - 3 вызова функции, но так как я вызываю функцию 1 раз за цикл, то в моей реализации это одно и то же), равносильно тому, что время на обработку любого запроса будет >= 2*MinCycleLenght.
А далее все зависит от величины MinCycleLength. Если она не велика, то мое замечание теряет смысл. Если значительна, то это необходимо иметь ввиду.

Величину проекта следует измерять, видимо, по количеству функций, выполняемых ПЛК и по кол-ву оборудования, находящегося под управлением ПЛК.
Косвенной характеристикой может служить количество модулей ввода/вывода, подключенных к ПЛК. В том проекте, в котором величина цикла у меня 15 мс, на двух сетях RS-485 сидят 19 абонентов: 3 модуля МУ110-32Р, 2 модуля МВ110-32ДН, 2 модуля МВ110-8А, 6 ЧП фирмы АВВ, 6 индикаторов.
Если у Вас есть проекты, в которых со схожим количеством абонентов время цикла 2-3 мс (или меньше!), то мне, действительно, интересно узнать как Вы организуете свои программы. Если возможно, то с удовольствием, посмотрю Ваш код (ksporyagin@mail.ru).
Отмечу также, что у меня таких проекта 2 (полностью идентичных). Один на старой модификации ПЛК110, другой на ПЛК110 М02. Время цикла выполнения первого я уже неоднократно указывал, время цикла второго 1,3 мс.

2. Что касается замечания по поводу буфера.
Оно исходит из личного опыта. Я столкнулся с собственной ошибкой при использовании.
Заключалась ошибка в следующем. Работу с ФБ MB_WR_REGS я вел следующим образом. На 1-м шаге формировал буфер, переходил на следующий шаг, где вызывал данный блок. Если блок завершался с ошибкой, то я, думая, что буфер никто не трогал (ведь я его не трогал!), оставался на 2-м шаге, где повторно вызывал блок MB_WR_REGS, передавая в него все тот же буфер. Но оказывается, что буфер уже изменен. Что в моем случае приводило к ошибкам в работе оборудования. Правильно (для моей организации программы) вернуться на 1-й шаг и заново сформировать буфер.
Данное замечание в общем случае будет звучать так, как я его сформулировал выше:
"При использовании блока MB_WR_REGS (запись регистров хранения), в том случае, если блок вернул ошибку, то перед повторным вызовом данного блока необходимо заново формировать буфер посылки. В противном случае вы пошлете не то, что ожидаете, так как MB_WR_REG использует переданный ему буфер для формирования полной посылки Modbus."

Почему я выделяю именно ФБ MB_WR_REGS. Потому что, например, для блока MB_WR_SNG_REG, мы вообще не передаем буфер. Для ФБ чтения мы буфер не формируем перед отправкой, а только вычитываем из буфера после завершения работы ФБ.

capzap
01.09.2016, 11:37
1. По поводу циклов нет никакой путаницы (по крайней мере у меня). То что для обработки любого запроса тратится минимум 3 цикла (если быть точным - 3 вызова функции, но так как я вызываю функцию 1 раз за цикл, то в моей реализации это одно и то же), равносильно тому, что время на обработку любого запроса будет >= 2*MinCycleLenght.
А далее все зависит от величины MinCycleLength. Если она не велика, то мое замечание теряет смысл. Если значительна, то это необходимо иметь ввиду.

Величину проекта следует измерять, видимо, по количеству функций, выполняемых ПЛК и по кол-ву оборудования, находящегося под управлением ПЛК.
Косвенной характеристикой может служить количество модулей ввода/вывода, подключенных к ПЛК. В том проекте, в котором величина цикла у меня 15 мс, на двух сетях RS-485 сидят 19 абонентов: 3 модуля МУ110-32Р, 2 модуля МВ110-32ДН, 2 модуля МВ110-8А, 6 ЧП фирмы АВВ, 6 индикаторов.
Если у Вас есть проекты, в которых со схожим количеством абонентов время цикла 2-3 мс (или меньше!), то мне, действительно, интересно узнать как Вы организуете свои программы. Если возможно, то с удовольствием, посмотрю Ваш код (ksporyagin@mail.ru).
Отмечу также, что у меня таких проекта 2 (полностью идентичных). Один на старой модификации ПЛК110, другой на ПЛК110 М02. Время цикла выполнения первого я уже неоднократно указывал, время цикла второго 1,3 мс.

не надейтесь,покрайней мере сильно, на выполнение запросов модбас в отдельной задаче, плк у нас не многозадачные и к тому же Валенок уже объяснял что актуальными данными воспользоваться главная программа сможет только во время своего цикла,так что если между этими выполнениями Вы опросите слейвы хоть раз десять, КПД от них минимальный

Валенок
01.09.2016, 21:39
1Величину проекта следует измерять, видимо, по количеству функций, выполняемых ПЛК и по кол-ву оборудования, находящегося под управлением ПЛК.
Ну где-то 150 физических единиц (датчики, вентиляторы и т.п.)


, на двух сетях RS-485 сидят 19 абонентов: 3 модуля МУ110-32Р, 2 модуля МВ110-32ДН, 2 модуля МВ110-8А, 6 ЧП фирмы АВВ, 6 индикаторов...
Средненький проектик. На обмен 0.4..0.7мс. Работа еще пара-тройка.
А для МО2 вообще за чудо вылезть из 1-й мс.

2xИП320,4x8A,2x8ДФ,2x16Р,3x16Д,1x6У,3xМЭ-3M - вообще на одной линии
или
13xПЧВ,2x8AС,1x32ДН,1xСП270
Соббсно длина писек тут имеет значение ?

За 15мс ПЛК-МО1 выполнит за 10 тыщ операций. Какая надобность в этих тыщах каждый цикл ?

Филоненко Владислав
02.09.2016, 08:56
Ну где-то 150 физических единиц (датчики, вентиляторы и т.п.)


Средненький проектик. На обмен 0.4..0.7мс. Работа еще пара-тройка.
А для МО2 вообще за чудо вылезть из 1-й мс.

2xИП320,4x8A,2x8ДФ,2x16Р,3x16Д,1x6У,3xМЭ-3M - вообще на одной линии
или
13xПЧВ,2x8AС,1x32ДН,1xСП270
Соббсно длина писек тут имеет значение ?

За 15мс ПЛК-МО1 выполнит за 10 тыщ операций. Какая надобность в этих тыщах каждый цикл ?

Валенок, 90% всех программ, что я видел - всё в одном цикле выполняется последовательно каждый цикл. И, как следствие, сколько не дай, вся производительность уходит в свисток.

GTS
02.09.2016, 17:30
Еще бы спецы Овен мануальчик накотали по организации связи через библиотеку modbus, как положено. И сразу бы у многих вопросы отпали в том числе и по кривому конфигуратору. Ведь правильно написали, есть 1, 2 модуля используй конфиг, если больше библиотеку. Но как это сделать грамотно? Как организовать опрос 10 модулей? Вывести в отдельную программу?

GTS
03.09.2016, 07:43
Дак уважаемый Валенок, я имею ввиду что руководство только показывает как открыть порт и, например, считать с одного модуля. А затем выясняется: что для N количества модулей необходимо вынести открытие порта в одну задачу, обращение к N устройствам еще в несколько, а обработку полученных данных в другую задачу. Вы уж простите меня за мой французский, но коль мы про машину и инструкцию. Поэтому я и спрашиваю полноценное руководство, в котором будет написано как грамотно сделать опрос N количества устройств чтобы контроллер нормально опрашивал и не тупил. А про 150 единиц оборудования - это все на rs485 или я что то не понял?

capzap
03.09.2016, 08:12
Дак уважаемый Валенок, я имею ввиду что руководство только показывает как открыть порт и, например, считать с одного модуля. А затем выясняется: что для N количества модулей необходимо вынести открытие порта в одну задачу, обращение к N устройствам еще в несколько, а обработку полученных данных в другую задачу. Вы уж простите меня за мой французский, но коль мы про машину и инструкцию. Поэтому я и спрашиваю полноценное руководство, в котором будет написано как грамотно сделать опрос N количества устройств чтобы контроллер нормально опрашивал и не тупил. А про 150 единиц оборудования - это все на rs485 или я что то не понял?мне кажется из-за Вашей любви к разнесению всего по задачам у Вас и происходит торможение, примеры в опросе нескольких модулей описаны в руководстве http://www.owen.ru/forum/showthread.php?t=23897

GTS
03.09.2016, 17:59
Так этож для 3 кодесиса, или все равно?

capzap
03.09.2016, 22:00
Так этож для 3 кодесиса, или все равно?

сам подход ни чем не отличается

Спорягин Кирилл
05.09.2016, 11:53
Дак уважаемый Валенок, я имею ввиду что руководство только показывает как открыть порт и, например, считать с одного модуля. А затем выясняется: что для N количества модулей необходимо вынести открытие порта в одну задачу, обращение к N устройствам еще в несколько, а обработку полученных данных в другую задачу. Вы уж простите меня за мой французский, но коль мы про машину и инструкцию. Поэтому я и спрашиваю полноценное руководство, в котором будет написано как грамотно сделать опрос N количества устройств чтобы контроллер нормально опрашивал и не тупил. А про 150 единиц оборудования - это все на rs485 или я что то не понял?

GTS, быть может это Вам будет интересно - Универсальный диспетчер для Modbus.lib (http://www.owen.ru/forum/showthread.php?t=25112).

GTS
05.09.2016, 12:54
Да, спасибо, уже читаю!

Yegor
06.09.2016, 19:05
Ну почему? Если например модуль МВ8А опрашивать чаще чем раз 3-5 секунд нет смысла,то период опроса в данном случае актуален. Или нет?Если речь об экономии трафика не идёт, то в чистом виде не актуален.

Допустим, вместе с МВА8 (модуль А) вы опрашиваете какой-нибудь 2АС (модуль Б), который обновляется каждые 5 мс. Можно сделать как обычно - опрашивать Б по 20 мс и раз в 3 секунды прерывать его на опрос А. Получается высокая средняя частота опроса Б, но на практике почти всегда важнее минимальная установившаяся частота, и она будет гораздо ниже средней из-за паузы на опрос А. Даже такой примитивный кейс проявит себя, например, на "плотности" графика, который строится по показаниям Б - на нём будут дыры, и нельзя будет сказать, что период дискретизации этого графика 20 мс.

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

Поэтому я с modbus.lib (в частности) не использую периодический опрос. Вместо этого я включаю модули в последовательность нужное количество раз. Если, допустим, у меня есть 2 шт МВА8 (X и Y) и 1 шт 2АС (Z), то я просто опрашиваю их XZYZXZYZ без пауз. И я с уверенностью могу сказать, что Z опрашивается с такой-то частотой уже без запинок.

приборист
06.09.2016, 20:27
Поэтому я с modbus.lib (в частности) не использую периодический опрос. Вместо этого я включаю модули в последовательность нужное количество раз. Если, допустим, у меня есть 2 шт МВА8 (X и Y) и 1 шт 2АС (Z), то я просто опрашиваю их XZYZXZYZ без пауз. И я с уверенностью могу сказать, что Z опрашивается с такой-то частотой уже без запинок.

Без запинок, если модуль МВА8 в сети и работает.
А если прибор начнет отвечать через раз, а через раз выпадать в таймаут ответа?
Или прибор отключат от сети?

Получим XZ*таймаут*ZXZYZXZ*таймаут*.

energvk
06.09.2016, 21:41
Если речь об экономии трафика не идёт, то в чистом виде не актуален.

Допустим, вместе с МВА8 (модуль А) вы опрашиваете какой-нибудь 2АС (модуль Б), который обновляется каждые 5 мс. Можно сделать как обычно - опрашивать Б по 20 мс и раз в 3 секунды прерывать его на опрос А. Получается высокая средняя частота опроса Б, но на практике почти всегда важнее минимальная установившаяся частота, и она будет гораздо ниже средней из-за паузы на опрос А. Даже такой примитивный кейс проявит себя, например, на "плотности" графика, который строится по показаниям Б - на нём будут дыры, и нельзя будет сказать, что период дискретизации этого графика 20 мс.

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

Поэтому я с modbus.lib (в частности) не использую периодический опрос. Вместо этого я включаю модули в последовательность нужное количество раз. Если, допустим, у меня есть 2 шт МВА8 (X и Y) и 1 шт 2АС (Z), то я просто опрашиваю их XZYZXZYZ без пауз. И я с уверенностью могу сказать, что Z опрашивается с такой-то частотой уже без запинок.

В принципе понял, спасибо большое за подробное разъяснение.

Yegor
07.09.2016, 08:24
Без запинок, если модуль МВА8 в сети и работает.
А если прибор начнет отвечать через раз, а через раз выпадать в таймаут ответа?
Или прибор отключат от сети?

Получим XZ*таймаут*ZXZYZXZ*таймаут*.В моей практике любой отказ такого рода считался достаточно серьёзным, чтобы сразу (в пределах допустимого) останавливать процесс и ремонтировать установку. Но если в вашем случае выпадание модуля не столь критично, то да, опрос по таймеру оставит больше производительности. Я не пытаюсь предложить панацею.

capzap
07.09.2016, 08:58
Без запинок, если модуль МВА8 в сети и работает.
А если прибор начнет отвечать через раз, а через раз выпадать в таймаут ответа?
Или прибор отключат от сети?

Получим XZ*таймаут*ZXZYZXZ*таймаут*.

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

energvk
07.09.2016, 11:10
Абсолютно точно также повлияет, как мне кажется. Поэтому мне кажется подход Yegor'а более правильным, но сколько людей - столько мнений :)