Наименьшее время отклика

Сообщение **Novice12** » 18 янв 2018, 17:54

pike, это всё тоже интересно, ноо...как всё-таки определяется время отклика протокола, возвращаясь к моему сообщению от 16.21

Сообщение **hell_boy** » 18 янв 2018, 22:40

Novice12 писал(а): ↑18 янв 2018, 16:21 Соответственно, время отклика протокола тогда определяем по формуле время цикла + время выполнения ПП.
Или время цикла это и есть время отклика протокола?)

Ипользование протокола в простейшем случае предполагает 2 устройства: датчик-устройство1-протокол-устройство2-исполнительный механизм. Или использование супервизора: датчик-устройство1-протокол-супервизор-протокол-устройство2-исполнительный механизм.
Как видно из этих схем, в случае использование супервизора удлиняет время реакции системы на время супервизор+протокол. Если устройство 1 = устройство 2, то схема 1 будет еще короче: датчик-устройство1-исполнительный механизм, а схема 2 - не изменится. Под устройствами можно понимать не только контроллер или модуль ввода-вывода, но реле или электросхему. Время сработки реле или электросхемы тоже ненулевое.
Время цикла - это время выполнения программы на центральном процессоре контроллера. Протокол - протокол внутренней шины контроллера, который почему-то никем не учитывается. Время отклика протокола - неправильный термин, есть протоколы, например UDP, который отклика не предусматривает, или устройство (модуль ввода-вывода), получив пакет (по внутренней шине) с указанием что-то сделать, немедленно выполняет это указание, отклик (отчет о выполнении) уже не важен.
Нарисуйте свою схему управления с учетом всех элементов и проанализируйте.

Novice12 писал(а): ↑18 янв 2018, 16:21 оказывается типовое время цикла для 1000 устройств у profibus 10 мс, хотя в мануале к s7 указано, что можно и 1мс выставить. Кому верить?

Маркетологам

За Profibus не знаю, PROFINET IO Class A cycle of 120 ms Delivery time 128 ms, PROFINET IO Class C IRT with cycle of 1 ms Delivery time 1 ms https://www.felser.ch/papers/ISIE-01-2010.pdf https://www.felser.ch/papers/NES-21-2009.pdf

Сообщение **winb** » 19 янв 2018, 08:29

hell_boy писал(а): ↑18 янв 2018, 22:40Протокол - протокол внутренней шины контроллера, который почему-то никем не учитывается

Подозреваю из-за того, что обычно это время входит во время цикла CPU контроллера.

Сообщение **hell_boy** » 19 янв 2018, 09:39

winb писал(а): ↑19 янв 2018, 08:29Подозреваю из-за того, что обычно это время входит во время цикла CPU контроллера

Не всегда, может быть только если коммуникационный порт в составе CPU. Например, модуль Ethernet/IP у Honeywell C200 он же Allen-Bradley FlexLogic- это отдельный CPU, с основным CPU общается по внутренней шине CAN, если не ошибаюсь.

Сообщение **Novice12** » 19 янв 2018, 11:31

hell_boy, я нарисовал кусочек схемки, давайте проанализируем вместе.

А то я так до лета на этом зависну)

Допустим, есть у нас ПЛК. И соответствующие блоки: DI, DO, AI.(вроде как на один канал можно 8 устройств повесить, но в данной ситуации не очень важно. Лишь бы понять принцип.)
Выбираем схему N1. Энкодер - сообщает текущее положение штанги, датчик - фиксирует препятствие, посредством протокола передаётся сигнал "стоп" на исполнительный механизм (т.е. на мотор)?

Допустим:
задержка на каждом из энкодеров - 150 мкс,
на каждом из датчиков - 100 мкс + 50 мс у них уходит на получение информации о препятствии,
задержка на канал DI, DO, AI. - 100 мкс,
задержка на актуаторе - 50 мкс
вкл/выкл мотор - 1мс

Время цикла - это время выполнения программы на центральном процессоре контроллера.

Значит, логика может быть реализована у того же EtherCATa за 30мкс , а с технологией XFC - 12,5 мкс.

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

То-то, я эту циферку я нигде не встречал. Чему она примерно равна?

Что дальше делаем? Всё складываем?

Схема тут:

[+]: Part.png

Сообщение **pike** » 19 янв 2018, 14:35

Novice12 писал(а): ↑18 янв 2018, 17:54 pike, это всё тоже интересно, ноо...как всё-таки определяется время отклика протокола, возвращаясь к моему сообщению от 16.21

1) С точки зрения норм безопасности\Safety время отклика далеко не самое главное для подобных систем. Safetynet были основаны на более медленных интерфейсах.
2) Что касается Ethercat можете забыть про значения для сфероконического протокола. Отклик будет определяться конкретным оборудованием используемым в сети, ее конфигурацией и кол-во устройств. Опять же сети безопасности, на сколько я помню, работают не только и не столько в режиме циклического опроса.

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

Сообщение **Novice12** » 19 янв 2018, 18:29

pike, с меня требуют цифры :(((((
А именно, величину пройденного пути, с момента определения препятствия до торможения. Скорость движения известна, осталось умножить на время :)
Конкретным оборудованием... Хорошо, давайте, мб, пример рассмотрим, который я описал выше? От 11,31

А что за оборудование в жёлтых корпусах?

Иногда оборудование в красных корпусах.

Сообщение **hell_boy** » 19 янв 2018, 20:51

Novice12 писал(а): ↑19 янв 2018, 11:31Что дальше делаем? Всё складываем?

Да, складывайте. Еще есть выбег мотора.

Сообщение **Novice12** » 19 янв 2018, 21:52

hell_boy, а эту величину мне за сколько принять...? "Протокол - протокол внутренней шины контроллера, который почему-то никем не учитывается"

Сообщение **Serex** » 20 янв 2018, 10:19

Вся эта скорость протоколов - маркетинговые уловки.
Измерения скорости передачи нужно начинать с конечных устройств, если они выдают данные раз в секунду, то и протокол быстродействующий не нужен.
А если реально нужно быстродействие, то фирмы, разрабатывающее прецизионное оборудование могут позволить себе разработку собственных закрытых протоколов с собственными тестами скорости. Зачем использовать коммерческие со всякими подводными камнями?
Что от коммерческих протоколов реально нужно, так это удобство и дешевизна компонентов. Именно этим протоколы, на базе Ethernet и завоевали рынок. Возможность лепить сети "как попало" из компонентов, которые можно купить в обычном компьютерном магазине. Давно бы уже пора разработать 5 или 8 - портовые повторители для RS-485 с автоматическим распознаванием неправильной полюсовки.

Отправлено спустя 4 минуты 6 секунд:

Novice12 писал(а): ↑19 янв 2018, 18:29А именно, величину пройденного пути, с момента определения препятствия до торможения.

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

Сообщение **Ryzhij** » 20 янв 2018, 11:18

Novice12 писал(а): ↑19 янв 2018, 21:52hell_boy, а эту величину мне за сколько принять...? "Протокол - протокол внутренней шины контроллера, который почему-то никем не учитывается"

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

Сообщение **Novice12** » 20 янв 2018, 14:47

Большое спасибо экспертам. :thankyou:

Я всё понял!
Нужно привязываться к конкретному оборудованию и уже эмпирически всё проверять.
Пусть покупают, тогда и посчитаю циферка в циферку)) А пока пусть довольствуются приблизительными, маркетологическими значениями)
Так и напишу.