тогда из чего складывается 80мс в Вашей задумке?Цитата:
Сообщение от spectrum48k
И почему опрос обязательно должен идти в параллельной задаче?
Вид для печати
тогда из чего складывается 80мс в Вашей задумке?Цитата:
Сообщение от spectrum48k
И почему опрос обязательно должен идти в параллельной задаче?
Мои 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мс).
Вы путаете как работает программа в ЯВУ и плк, ни кто не ждет отсчета работы таймера, в следующем цикле проверяется состояние текущего времени и уставки таймера и если оно превышает подается положительный сигнал на выход таймераЦитата:
Сообщение от spectrum48k
По поводу 8 регистров снял видео, какие там 80мс?
При всем уважении - такой порядок действий у приведенного Вами алгоритма.Цитата:
Сообщение от spectrum48k
А что Вы называет одной задачей ? НЕиспользование местного конфигуратора задач ?
Само собой не ждет! Я не говорил, что ждет! "Таймер 3мс считает, разбор буффера еще не начинался" ---- проверка выхода "Q" таймера, а не остановка выполнения программы! В этом шаге выход "Q" таймера не установлен, и выполняется выход из ФБ чтения регистров, после этого программа выполняется далее.Цитата:
Сообщение от capzap
называю это:Цитата:
Сообщение от Валенок
Вложение 20027
Вложение 20028Цитата:
Сообщение от capzap
Это что, подтасовка под результат? Какая quantity=8 ?? А Вы вот возьмите и считайте 8 не смежных регистров. Или 8 ведомых устройств. 8 запросов и 8 ответов. Почему я по-Вашему умножил время выполнения алгоритма (10мс) на 8 ? Если бы не использовался таймер 3мс, то шагов 6 и 7 вообще бы не было. (Еще раз обращаю внимание, что данный пример учитывает вызов обмена и основной программы в одном Task или в одной PRG). При использовании нескольких задач, это будет неактульно и временные характеристики будут иными.
я тут в соседней теме написал пример собственного таймер, а Вы меняЦитата:
Сообщение от capzap
вот так после этого унижаете)))
Без понимания работы мэковских таймеров, как бы я написал свой??))
как то я сильно сомневаюсь, что несколько параллельны задач, в один и тот же порт, будут слать запросы и им за это ничего не будет, Вы точно говорите про модбас, мастер должен быть один и он должен соблюдать стандарты, кстати если перед и после запроса должны быть паузы тишины, то принятое время по умолчанию 1.75 умножив на два получим больше трех, так что автор бибки еще взял время по меньшеЦитата:
Сообщение от spectrum48k
см. иногозадачность в примере применения в #82
см. "многозадачность" в конце #82
а если на секунду забыть несколько размытое требование в стандарте, которое по моему скромному мнению, определяет именно тот интервал, через который начинает отвечать именно ведомый. После приема ответа мастером, зачем ему выдерживать паузу, если ведомые уже готовы принять телеграмму?Цитата:
Сообщение от capzap
http://i.imgur.com/kCbT9Hj.png
вот какие-то диаграммы, и что с ними делают программисты микроконтроллеров в slave-устройствах ввода-вывода - одним программистам известно. Сомневаюсь что у кого-то "ума хватило" при написании алгоритма ведомого устройства задать "мертвую зону" длиной 3,5 символа после ответа мастеру, в течение которой запросы игнорируются/входной буфер очищается.
т.е. Вы вобще не верите что прерывания в любых устройствах могут задержать ответ по последовательному порту. Эта пауза ни как не связана с обработкой. Она нужна, как и написано, для того чтоб в сети была тишина и все кто хотел что то сказать (мастер или ведомые) вытолкали свой передающий буфер и не создали помех для очередного запроса/ответаЦитата:
Сообщение от spectrum48k
а по поводу всего остального, еще раз обозначу: по физической линии на одной и той же скорости запрос/ответ по времени проходит за одно и тоже значение плюс некоторая составляющая из-за какого нибудь прерывания, эта составляющая на столько мала, что на неё отводят 1,5 символа между фреймами. Появление результата запроса конечно же зависит от времени цикла, первое что приходит в голову это вывести опрос в отдельную задачу. Для меня есть одно но, во первых не попадался мне плк двух и более ядерный, чтоб была настоящая многозадачность, во вторых в таких системах нет понятий как volatile и synchronized, что будет происходить, если опросная задача захватила буфер,а в это время основная задача по прерыванию начала его читать. Остается держать в ОЗУ два дублирующих буфера (в случае одного опрашиваемого ведомого), а избыточная трата ресурсов может привести к нестабильности системы в целом, а не только обмена
Для нормального обмена линия RS-485 должна быть захвачена как минимум с одной стороны. По этой причине после приема пакета от Master Slave должен сразу захватить линию. Master после передачи пакета какое-то время (время тишины) тоже удерживает линию. Далее Master отпускает линию и Slave начинает передачу пакета отклика.Цитата:
Сообщение от spectrum48k
смысл паузы, я понимаю так же как и Вы. Но приведите раумное обоснование необходимости паузы после того, как ведомый ответил и мастер принял ответ полностьюЦитата:
Сообщение от capzap
а смотрите, какая прелесть:Цитата:
Сообщение от capzap
http://i.imgur.com/JctCEIU.png
https://youtu.be/D6aOwL4Km98?list=PL...r-2PC0-F6-duWi
особенности работы полупроводниковых драйверов RS-485.Цитата:
Сообщение от Вольд
Если кто писал свой вариант библиотеки modbus, выдерживаете ли вы паузу после ответа ведомого, используя таймеры? Интересен ваш опыт.
Затем, чтобы другие слейвы подготовились.Цитата:
Сообщение от spectrum48k
В этой теме уже ответили все ветераны форума)) Как именно слейвы должны подготовиться? Есть ли у кого-нибудь пример программы микроконтроллера (ну мало ли откуда)
Я в своем посте ответил на ваши вопросы. Полупроводниковые драйверы RS-485 тут не при чем, все делается на программном уровне.Цитата:
Сообщение от spectrum48k
Затем, чтобы линия RS-485 не была отпущена с обеих сторон. Встань осциллографом на длинную линию RS-485 не захваченную ни с одной стороны и увидишь сколько на ней "мусора".Цитата:
Сообщение от spectrum48k
это вопрос к разработчикам. Возможно у Вас есть факты , на которые опираетесь. У меня таких фактов и опыта разработки подобных устройств (например серия МВ) нет.Цитата:
Master после передачи пакета какое-то время (время тишины) тоже удерживает линию.
Для ПЛК серии 100-150 это неактуально вообще)) Резисторы подтяжки ( смещения/biasing) наглухо впаяны. Все объекты вводил в работу с осциллографом. Без него - эт вообще танцы с бубном (имхо).Цитата:
Сообщение от Вольд
Что они опять должны быть готовы принять запрос.Цитата:
Сообщение от spectrum48k
Могу только предположить, что после отправки ответа они уже как бы готовы)
Какого ответа?
Вы понимаете, что в общем случае слэйв не один? И те, которые не отвечали в текущем цикла, должны понять, что пошел новый цикл, надо слушать линию.
Для понимания нового цикла достаточно отправить буффер ответа и снять сигнал с ноги "DE" и инвертированного "RE" драйвера, отправив передатчик в "высокоимпедансное состояние" .
Разве есть еще какие-то премудрости? Кажца, здесь завелся инсайдер. ))
Отвлеклись от темы.
Предлагаю подытожить тему по 3м вариантам использования: 1) конфигуратор, 2) modbus.lib 3) самописные бибки, нарушающие стандарты :). Плюсы и минусы. А научить меня-выскочку уму-разуму сможете при удобном случае в разделе "Курилка"
Вы совсем не понимаете?
Пример - в сети 2 слейва с адресами 1 и 2.
Мастер опросил 1.
Как 2 определит, что 1 закончил передачу ответа?
По теме
1. Для стандартных случаев.
2. Для нестандартных, если нужен неравномерный опрос и т.п.
3. Если заняться нечем.
Это - многозадачность ? :) :) :)Цитата:
Сообщение от spectrum48k
Это НИЧЕМ не отличается от пары вызовов в PLC_PRG
Slave не надо ничего такого определять, ему надо следить за тем нет ли обращения по его адресу.Цитата:
Сообщение от ASo
Разумных объяснений целых 2:Цитата:
Сообщение от spectrum48k
1. Не все Slave достаточно умные, чтобы понять, что другой Slave закончил ответ и не смогут понять, где находится конец ответа, а где - начало следующего запроса. Такой болезнью, в частности, раньше болели ТРМы. Сейчас не знаю.
2. Без таймаута надпись в паспорте Вашего устройства "Modbus" будет откровенной ложью.
Цитата:
Сообщение от spectrum48k
не переиначивайте! я привел пример одной задачи, а не многозадачности. многозадачность как разделение мэк программ на вызовы с разным временем цикла сейчас вытащу и заскриню. Надеюсь, мы друг друга понимаем и говорим о разделении мэк-(под)программ на задачи с разным временем цикла средствами среды разработки и исполнения Codesys, а не о особенностях операционных систем?
http://i.imgur.com/dRsAfKF.png
Конечно, понимаю, что пауза - это момент определения стартовой позиции адреса ведомого итд, момент синхронизации начала посылки, чтобы правильно разделить ее содержимое на составляющие. Но 3мс не дают мне покоя.) У кого есть идеи как правильно высчитывать выдержку в зависимости от скорости передачи данных в коде программы на ST например? Не расчет времени (с этим все понятно), а реализация. Обычное использование таймера передает управление остальной программе, и она как минимум прокручивается еще раз, прежде чем выполнится отправка след запроса. А это не очень красиво с точки зрения быстройдействия. Цикл WHILE с таймером внутри не предлагать?)Цитата:
Сообщение от ASo
Касательно кейса.
Код: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;
В обязанности Slave не входит анализ чужих запросов и ответов. Нормальный драйвер сом-порта Slave анализирует первый принятый после таймаута байт и, если это не его адрес, ждёт следующий первый после таймаута байт .Цитата:
Сообщение от spectrum48k
Как я ранее выше говорил, есть у меня некоторая самоделка. Как доберусь до железа, попробую непрерывный опрос ведомых с таймаутом и без него. Интересно на практике узнать выдерживается ли таймаут средствами самой среды исполнения кодесис при передачи управления "операционной системе" или модули будут "затыкаться" через раз. У кого есть плк с удаленным доступом?) Предложите вариант выдержки с приостановкой выполнения? через REPEAT или WHILE ?
Сталкивася с тем, что МСД-100 опрашивал ТРМ200 именно через один. В связи с отсутствием настройки нужного таймута вставил в опрашиваемые приборы нечётные несуществующие адреса.Цитата:
Сообщение от spectrum48k
А для организации нужного таймаута достаточно запускать программу циклически. В одном цикле обработать ответ, в следующем, через 3-4мс послать запрос. Только сначала убедиться, что для Slave не требуется таймаут нестандартной большей длины.
Скорее всего попробую организовать таймаут в диспетчере вызова блоков. Пример где-то выше в теме. Добраться бы только до железа. Нет у меня ПЛК, а жаль)
В случае модулей пр-ва Овен я бы вообще настройку проводил исключительно со сниффером ком-порта. Уже напоролись на то, что модули воспринимают все запросы как свои родные и отвечают, когда их не просят)Цитата:
Сообщение от rwg
а на моем видео из 75 поста не видно что количество запросов больше чем ответов, как раз снижал время периода опроса впритык с затраченным временем на опросЦитата:
Сообщение от spectrum48k
а по поводуо чем опять речь, быстродействие плк как раз не нарушается если ждать асинхронного ответа через последовательный портЦитата:
Обычное использование таймера передает управление остальной программе, и она как минимум прокручивается еще раз, прежде чем выполнится отправка след запроса. А это не очень красиво с точки зрения быстройдействия