Обновленный ПЛК110?

[Филоненко Владислав]

"время реакции" - максимальное время от подачи сигнала на DI до появления значения на DO. Именно так. На как минимум 10000 циклах.
Всякие статистические оценки интересны начиная с 2 девятки после запятой, т.е. 99.99% - уже пойдет для управления не особо критичного процесса
Вероятность 95% означает, что установка неработоспособна в принципе.

10 мс - это примерное время джиттера в режим freewheeling. По результатам внутренних тестов. Поэтому я и говорю, что работает ПЛК в таком режиме плохо. Валенки на шахид-такси как раз к июню и доедут до магазина. Сломался автомобиль, что делать...

Что значит "время реакции" в таком контексте?
Я к чему: даже вне зависимости от распределения шума самого ПЛК, если мы уберём искусственные ожидания (т.е. сделаем мц=0), то распределение времени отклика должно снизиться.

Смелая гипотеза, но без знания архитектуры системы управления только гипотеза. Убираются ведь не искусственные ожидания, а время для более низкоприоритетных задач. И тут 2 варианта: Низкоприоритетные задачи вообще не выполняются ( т.е. прибор не работоспособен целиком или частично) и Низкоприоритетные задачи когда-нибудь будут принудительно переведены в высокоприоритетные, дабы, к примеру, буфер не переполнился - опа, и 10мс, 20мс, х.з. сколько времени цикл управления ждёт...

Но можете провести натурные испытания, всем будет интересно.

[Владимир Ситников]

Всякие статистические оценки интересны начиная с 2 девятки после запятой

Неправда ваша. Интересен как раз общий профиль.
Вот пример графика, который я хочу увидеть: http://hdrhistogram.org

"время реакции" - максимальное время от подачи сигнала на DI до появления значения на DO. Именно так. На как минимум 10000 циклах.

10 мс - это примерное время джиттера в режим freewheeling. По результатам внутренних тестов.

Результаты где-то опубликованы?
Слышать "99.99% подойдёт для не особо критичного процесса" и при этом не знать сколько обеспечивает сам ПЛК крайне странно.
Сколько девяток гарантирует ПЛК110 М02, в режиме мц=1мс?

Но можете провести натурные испытания, всем будет интересно.

Да, могу. М02 у меня есть. Но время на ПЛК разве что в апреле появится.

Низкоприоритетные задачи вообще не выполняются ( т.е. прибор не работоспособен целиком или частично)

Вам же говорят: нет низкоприоритетных. Нет от слова "совсем".
Есть одна задача в режиме freewheeling. Ну, конкретный проект так составлен, что задача всего одна.
Какие с ней проблемы?

[Филоненко Владислав]

Сколько девяток гарантирует ПЛК110 М02, в режиме мц=1мс?

Внимательнее читаем форум. 20% джиттер от времени цикла

[Филоненко Владислав]

Вам же говорят: нет низкоприоритетных. Нет от слова "совсем".
Есть одна задача в режиме freewheeling. Ну, конкретный проект так составлен, что задача всего одна.
Какие с ней проблемы?

Тогда зачем мы на форуме ОВЕН обсуждаем приборы других фирм. У нас есть в ПЛК низкоприоритетные задачи

[Дмитрий Артюховский]

Но: есть внятное объяснение почему в режиме мц=0 абсолютное значение уровня шума сильно больше, чем в режиме мц=1?

конечно. даже если вы сделаете свой блок с однозначным временем выполнения, время на фоновые задачи будет разным от цикла к циклу и не предсказуемым, поэтому мс=0 - дает джиттер. А когда вы ставите мс=1 - то джиттера по сути нет, а если он таки есть - значит вы не вложились в 1 мс и нужно ставить мс=2

[Владимир Ситников]

конечно. даже если вы сделаете свой блок с однозначным временем выполнения, время на фоновые задачи будет разным от цикла к циклу и не предсказуемым, поэтому мс=0 - дает джиттер

Обсуждается проект, где всего одна пользовательская задача. Под "фоновыми" понимаем только "обслуживание ввода-вывода, работу тактового генератора самого ПЛК и т.п.". Верно? Или в понятие фоновых включаете ещё что-то?

Почему, скажем, "обслуживание ввода-вывода" будет зависеть от настроек мц?
А почему тактовый генератор будет работать по-другому?

Вариант "меньше мц -> больше тепловыделение -> меняется частота генератора" мне кажется неправдоподобным. По крайней мере, не должен он давать погрешность в миллисекунды.

Следите за руками
1) Если при мц=1 "всё хорошо", то фоновые задачи гарантировано занимают не более 1мс.
2) Если при этом настроить мц=0, то время работы этих "фоновых задач" возрасти не должно. С чего бы им замедляться?
3) Значит, в режиме мц=0, пользовательская программа имеет возможность вызываться чаще, чем в режиме мц=1.
4) Значит, в режиме мц=0 время отклика ниже, чем в режиме мц=1.

[_Pavel_]

2) Если при этом настроить мц=0, то время работы этих "фоновых задач" возрасти не должно. С чего бы им замедляться?

Я так думаю что фоновые задачи будут иметь более низкий приоритет перед программой ПЛК и будут выполняться в момент простоя, таким образом будет гарантирована стабильность цикла. Типа не успели в этом цикле простоя, выполнимся в следующем...

[Филоненко Владислав]

Обсуждается проект, где всего одна пользовательская задача. Под "фоновыми" понимаем только "обслуживание ввода-вывода, работу тактового генератора самого ПЛК и т.п.".

Без этого только "обслуживание ввода-вывода сферическая задача в вакууме получается. Если бы людям нужны были только прикладные задачи - сегнетикс бы завоевал бы весь рынок, там можно писать на С, и вообще все фоновые задачи убрать чтобы холопы не мешали. Однако в автоматизации всем нужен I/O - что автоматически ведет к появлению фоновых задач.

[Филоненко Владислав]

[QUOTE=vladimirisitnikov;199718
Если при этом настроить мц=0, то время работы этих "фоновых задач" возрасти не должно. С чего бы им замедляться?
[/QUOTE]
мц=0 автоматически означает, что или задача цикла должна иметь самый низкий приоритет. И джиттер будет максимальный.
Или задача не имеет минимальный приоритет - следовательно не работают все задачи более низкого приоритета. Например не работаю входа. Прекрасно.

[Дмитрий Артюховский]

мц=0 автоматически означает, что или задача цикла должна иметь самый низкий приоритет. И джиттер будет максимальный.
Или задача не имеет минимальный приоритет - следовательно не работают все задачи более низкого приоритета. Например не работаю входа. Прекрасно.

а вот это утверждение совсем непонятно, зачем так?

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