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

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

Добрый день.

Вопрос чисто такой исследовательский)

Задача такая: "имеется несколько г-образных штанг, вращающихся со скоростью 5 об/мин, вращение отслеживают энкодеры (всего их 8). В случае конфликтной ситуации с пульта оператора поступает сигнал на остановку вращения одной из штанг. Необходимо, чтобы за время реакции оператора + время отклика протокола было пройдено наименьшее ей расстояние, после нажатия на кнопку "стоп" оператором.

Я подобрал три протокола:
1. Эзеркат(самый быстрый из Эзернетовских)
2. Профибас - Сименс, однако)
3. CAN - классика)

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

Несомненно, время реакции оператора на несколько порядков больше, чем время реакции протокола. Но интересно, какое влияние окажет на данную задачу протокол.

Спасибо!

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

viewtopic.php?p=64973#p64973

Сообщение **Novice12** » 16 янв 2018, 22:34

hell_boy писал(а): ↑16 янв 2018, 22:05viewtopic.php?p=64973#p64973

Значит, протокол никакого особого влияния не оказывает на мою задачу?

Я вот такую ещё интересную инфу нашёл, контроллер омрон сисмак нх1

- высочайшее быстродействие для контроллера этого класса — время выполнения команды от 3,3 нсек, время выполнения главной задачи, синхронизированное с обменом по сети EtherCAT и управлением движением (при его наличии) — от 2 мсек;

Т.е. за 30 мкс мы только всё опросим, а торможение наступит только по истечении времени реакции оператора + от 2мс?

Novice12 писал(а): ↑16 янв 2018, 16:31Необходимо, чтобы за время реакции оператора + время отклика протокола было пройдено наименьшее ей расстояние, после нажатия на кнопку "стоп" оператором.

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

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

Alex question, а как можно переформулировать задачу, чтобы влияние протокола было заметно? Убрать время реакции оператора? Типа "на концах штанг установлены оптические/ультразвуковые датчики или даже камера, в случае детектирования помехи производится остановка вращения штанги номер Х?"

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

Сообщение **hell_boy** » 17 янв 2018, 10:55

Novice12 писал(а): ↑16 янв 2018, 22:34омрон сисмак нх1

Маркетологи лукавят. Для Sysmac NX7

время выполнения битовых логических команд составляет от 0,37 нсек, математических команд обработки чисел с плавающей точкой – от 3,2 нсек;

Это говорится про 1 элементарную логическую или про одну элементарную математическую. В программе может быть несколько тысяч таких операций. В сумме даст десятки миллиссекунд.

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

hell_boy, вот мне и интересно, сколько (примерно) пройдёт времени в мс, с момента детектирования препятствия до остановки. Т.к. при увеличении скорости вращения, важность быстрой остановки возрастает.

Допустим, 1 мс - программа,
30 мкс - время цикла EtherCAT
Задержки на энкодерах - несколько нс
Обновление графической информации на терминале 1-5мс
Время сработки ультразвукового датчика(убрали оператора, всё доверим автомату) - 0.2 с
Больше никакие компоненты не вносят свою задержку?

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

Дык, раз Вам так это важно, то ставьте на эту функцию отдельный прибор безопасности, а не тащите всё в РСУ.
На турбинах, например, добрые люди так и делают.

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

Ryzhij, хм, отдельный прибор.
А связь его как будет обеспечиваться с терминалом управления?
Коли уж мы стали рассматривать EtherCAT, то н-р, прибор--> модуль аналогового/цифрового ввода - > терминал EtherCAT? Или он автономен?

Сообщение **Ryzhij** » 17 янв 2018, 12:13

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

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

Novice12 писал(а): ↑17 янв 2018, 11:26Допустим, 1 мс - программа,
30 мкс - время цикла EtherCAT
Задержки на энкодерах - несколько нс
Обновление графической информации на терминале 1-5мс
Время сработки ультразвукового датчика(убрали оператора, всё доверим автомату) - 0.2 с

У меня программа меньше 14 мс не получилась. Терминал уже незачем, если убрали оператора. Если EtherCAT используется для связи ПЛК-HMI, то и скорость протокола тоже неинтересна.

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

Ryzhij, но это же увеличит стоимость системы?

hell_boy, т.е. определяющим моментом будет быстродействие программы, и протокол совсем ничего решать не будет? И мы не можем утверждать, что например, на каком-нибудь симатике с7 она будет выполняться быстрее/тише, чем на ранее упоминаемом омроне? Всё зависит от её оптимизации?

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

Сообщение **Ryzhij** » 17 янв 2018, 12:48

Novice12 писал(а): ↑17 янв 2018, 12:36Ryzhij, но это же увеличит стоимость системы?

Не обязательно и не всегда. Мы же по факту перераспределяем входы-выходы, иногда выносим их на управляемую машину. Используем уже не такой шустрый верхний уровень. Так что, удорожание вовсе не очевидно.
Считать надо.

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

Кстати, интересная тема для любителей спорткаров быстродействующих ПЛК. В доступном ОВЕН ПЛК110.М2 имеется 2 штуки ядра Programmable Real-Time Unit (PRU), которые позволяют создавать логику быстрее 1 мкс. Только штатный CodeSys это сделать не позволяет, но есть альтернативная среда разработки https://hardella.com

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

hell_boy писал(а): ↑17 янв 2018, 14:09В доступном ОВЕН ПЛК110.М2 имеется 2 штуки ядра Programmable Real-Time Unit (PRU), которые позволяют создавать логику быстрее 1 мкс. Только штатный CodeSys это сделать не позволяет, но есть альтернативная среда разработки https://hardella.com

Как только Овен хоть как-то сертифицирует эти свои приборы на применение в ПАЗ, станет ещё интереснее.
А пока такие детали - в ЖКХ и не далее!

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

viewtopic.php?t=8354
Автор hardell-ы был на этом форуме, за труд ему большое спасибо.

Сообщение **Looker** » 17 янв 2018, 15:47

Novice12 писал(а): ↑17 янв 2018, 12:36но это же увеличит стоимость системы

Ryzhij писал(а): ↑17 янв 2018, 12:48Не обязательно и не всегда...

А, какова стоимость "владения"? Для данного случая - остановка вращения одной из штанг произойдет позже, чем надо.

Сообщение **Ryzhij** » 17 янв 2018, 16:39

Looker писал(а): ↑17 янв 2018, 15:47
Novice12 писал(а): ↑17 янв 2018, 12:36но это же увеличит стоимость системы
Ryzhij писал(а): ↑17 янв 2018, 12:48Не обязательно и не всегда...
А, какова стоимость "владения"? Для данного случая - остановка вращения одной из штанг произойдет позже, чем надо.

Это называется иначе. Не "стоимость владения", а "оценка риска".
Итак, какова цена вопроса?
Ибо, как известно, даром - только д...мо за амбаром.

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

hell_boy, с овеном и харделлой понятно, на них можно побыстрее, но... хотелось бы всё-таки рассчитать это расстояние (за время реакции, которое равно, судя по ответам на форуме: время исполнения программы + скорость протокола/время цикла).
Берём из вашего поста 12.19, 14 мс на исполнение программы.
Итого:
Эзеркат: 14 мс + 0.03 мс = 14,03 мс
Профибас: 14мс+2мс = 16 мс
КАНопен: 14мс + 8мс = 22 мс
На моём примере. 5 об/мин угловая скорость

3,7м/с линейная.
После определения препятствия через (оказывается, оно в районе 50 мс с учётом волны туда-сюда) ультразвуковым датчиком и торможения мы получим, что:
Эзеркат: 0,2368м
Профибас: 0,2443м
КАН: 0,2666м
выигрыш 4% и 12 % соответственно.
Но если смотреть по стоимости построения системы, то в таком порядке? КАН-эзеркат-профибас?
Согласны?)

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

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

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

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

Время реакции системы имеет большое значение в случае оптических барьеров и двуручных пультов на прессах.
Есть даже ГОСТ, согласно которому время этой реакции должно рассчитываться.
ГОСТ ИСО 13855-2006 Безопасность оборудования. Расположение защитных устройств с учетом скоростей приближения частей тела человека.

В случае применения промышленных роботов тоже важно.

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

Михайло, файлик интересный, спасибо. Надо тольк в нём разобраться)
Тогда я за Эзеркат, спс)

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

Я ошибся, оказывается типовое время цикла для 1000 устройств у profibus 10 мс, хотя в мануале к s7 указано, что можно и 1мс выставить. Кому верить?
С учётом

The shortest response time is equivalent to the sum of the cycle time plus the input and output delay times.

- EtherCAT очень хорошо выигрывает.
А в случае

The longest response time is equivalent to the sum of twice the cycle time plus the delay times of the inputs and outputs.

- тем более)
Для второго случая, наверное, даже нет смысла проводить расчёт?)

И ещё:

The cycle time is derived from the sum of the following influencing factors:

Transfer time for the process image output (PIQ) and the process image of the inputs (PII)
User program execution time
Operating system execution time at cycle control point
Extension of cycle time due to communication load
Load on cycle times due to interrupts

Т.е. время выполнения пользовательской программы включают во время цикла?
Тогда как

Типичное время цикла EtherCAT составляет 50–250 мкс, в то время как в традиционных промышленных шинах на каждое обновление требуется 5–15 мс, т.е. традиционные промышленные шины работают медленнее от 20 до 300 раз!

если глубокоуважаемый hell_boy говорил, что у минимальное время исполнения программы занимало 14 мс?
Соответственно, время отклика протокола тогда определяем по формуле время цикла + время выполнения ПП.
Или время цикла это и есть время отклика протокола?)
Каша в голове получилась, ухх)))

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

Мне одному кажется, что задача сводится к промышленной безопасности и как следствие специальному оборудованию и сетям:
https://www.ethercat.org/en/safety.html