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

[spectrum48k]

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


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

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

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

[rwg]

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

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

[spectrum48k]

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

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

[rwg]

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

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

[spectrum48k]

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

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

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

[capzap]

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

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

[spectrum48k]

Для контроллера Modicon M238:

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

Эт как бы дефолт, а не рекомендация. Честно говоря, не понимаю о каком именно производителе Вы говорите?

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

[rwg]

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

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

[spectrum48k]

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

Думаю, небольшое преступление придержать выполнение на 2мс. Если надо ждать больше, то, RETURN, например.

[Yegor]

Про CASE в опросе... Таки да, есть смысл его оптимизировать. По крайней мере с одним тензопреобразователем, у которого свой, но похожий на модбас протокол, наблюдается существенная разница. Задача как раз стоит опрашивать его как можно чаще. Сильно вдаваться в подробности не хочу; простой переделкой кейса как в посте 114 удалось повысить частоту опроса со 180 до 220 сэмплов в секунду.