Прошивка с UNM (и доп. сюрпризом) сейчас проходит тестирование и как только пройдёт - выложим.
Вид для печати
Могу ли я рассматривать данное предложение как оферту ?
Мои предложения :
Вариант 1.
Да, я готов платить за удовлетворение своего любопытства.
Если сумма для меня будет легкоподъемной и адекватной, могу и наличными.
Вариант 2.
Если сумма покажется мне не совсем подъемной или адекватной, то начну аппелировать к тому, что организация где я работаю только за янв..март 16 года приобрела в Вашей фирме товаров на сумму более 270т.р (Это то, что сразу вспомнил). Без ложной скромности тонко намекну, что хотя в данном случае плательщиком выступал не я (не жена же за шубу платит) , решение о закупке прошло и через меня тоже некоторым боком (жена ведь тоже некоторое участие принимает в выборе шубы для себя)
Хотелось бы, кстати, уточнить - подходит ли данное обстоятельство под категорию "платить" ?
При необходимости, по Вашему запросу, могу предоставить ориентировочную закупочную стоимость Вашего оборудования с пока еще незакончившимися гарантийными обязательствами
Вариант 3.
Совмещение Вариантов 1 и 2.
Мои условия:
Внятно объяснить почему MO2 не может работать с циклом меньшим 1мс, если
1.МО1 - может.
2."индекс производительности" МО2/МО1 по моим оценкам где-то 1.6...1.8 (имел кратковременное знакомство), а МО1 на "систему" требутся 300..400мкс
3.Новое оборудование обычно не только "более быстые такты", но несколько улучшенное ПО. (Я - наивный китайский вьюноша ?)
Уточнение:
1.Речь о КДС2 для МО2.
2.Подразумевается пустой проект
3.При конфендициальности данной технической информации (далее ТИ), могу дать расписку о неразглашении на определенный (не более 10лет, простите) срок с чётко оговоренной финансовой ответственностью сторон :
а) С моей стороны - за разглашение ТИ
б) С Вашей стороны - за соответствие предоставленной ТИ фактическому положению вещей.
?
Отлично! Валенок!Риспект и уважуха ! Так и только так теперь надо с ними разговаривать!
Адекватность в прошлом . Наверное Филоненко очень сильно подняли зарплату . А ... может того настоящего Филоненко уже нет... и есть его жалкий клон.
Тов. Филоненко из человека , когда-то реально помогавшего пользователям , стал человеком , скидывающим мудрость из астрала . Овенцы !!! Отберите у Филоненко кальян ! И не разрешайте ему вообще курить на работе !!!!
Валенок, я думаю наличкой/безналом пойдёт. Кастомное производство прошивок под клиента у нас есть. Дорого не возьмём.
Однако, М01 также не имеет режима freeweeling. Где вы там его нашли?
Тов. Филоненко и теперь помогает клиентам. Но если клиент хочет странного, то хоть денег родная фирма получит. Ведь после получения странного тут будут вопли "Оно не так работает, как я мриял!"
P.S. Стоит сказать что клиент неправ, так сразу истинное лицо некоторых проступает, оскорбления, намёки странные.
Зря вы так, мне вот Владислав реально помогает!
По теме freeweeling-а, я не понимаю зачем стрелять себе в ногу? Ну если ПЛК может, а пользователь хочет и понимает зачем ему это... (Что странного в желании получить максимальное быстродействие?)
Объясните в чём глобальный затык с реализацией такого режима работы? Почему ПЛК с минВЦ=0 работают не стабильно?
Основную ошибку в понимании я выделил жирным. freeweeling - это не максимальное быстродействие, а "как получится", т.е. цикл ПЛК работает по остаточному принципу, сколько ресурсов осталось на цикл ПЛК, так часто (и так же нестабильно) он будет работать.
Вот поэтому его и нет.
И реализовать его можно,только если задача цикла ПЛК имеет самый низкий приоритет.
Так что рекомендую сначала изучить мануал на CoDeSys, а кто не может читать много букв - погуглить CoDeSys freewheeling
И обнаружить там:
Хорошо, тогда поправьте меня, если я не прав:
Для того чтобы получить стабильно работающий ПЛК с минВЦ > 0 я сейчас должен убедиться что время выполнения прикладного кода ПЛК + системной части гарантированно меньше, чем установленное значение минВЦ. Чтобы это гарантировать, я должен перестраховаться и поставить значение минВЦ на >= ~30% больше, чем значение в модуле статистики (накопленное с помощью функции MAX()).
Таким образом я должен ручками учесть любое "как получится", иначе я буду прерывать системные задачи ПЛК своим кодом? Так? Т.е. моя прикладная задача и есть IDLE для ПЛК в целом.
нет, если минВЦ > 0, то и задача цикла не idle-приоритет. И соответственно если система не перегружена, то перекрытия нет.
А если перегружена - то есть (но тут уже ничего не сделаешь, кроме увеличения цикла или снижения нагрузки).
На показания модуля статистики в любом случае надо смотреть, но если есть цикл - система (при отсутствии перегрузки) будет выдерживать цикл принудительно,
а если цикл=0 - она ничего не должна выдерживать и цикл идёт как есть.
Freewheeling обычно используют для визуализации. По остаточному принципу, сначала управляем, а если осталось время - рисуем красявости.
За неимением графини будем иметь служанку.
В данный момент у меня нет живого МО1, но есть живой ПЛК154. Но смею надеятся - это не нарушит чистоты экперимента, т.к. это вроде еще более младшая модель.
Если данное обстоятельство является препятствием (ведь речь о МО1), то предполагаю следующие варианты:
1.Вы подождете некоторое время или проведете самостоятельно нижеуказанный эксперимент с МО1.
2.Признаю свою ошибку, т.к. ухудшение характеристик произошло не при МО1->МО2, а еще ранее - при ПЛК1xx->ПЛК110(МО1). Не заметил. Готов проставится.
3.ПЛК154 является более крутой* моделью по сравнению с ПЛК110(МО1). Признаю свою ошибку. С дуру предположил что при более позднем** выходе в серию прибор является более крутым*
*Под более крутым подразумеваю вычислительные возможности, а не наличие периферии.
**Кроме явноуказываемых случаев типа 63/ПР и т.п.
Если же 154 прокатывает, смотрим дальше.
Простейший код:
var
c,i : int; (*для наблюдения нужен только "c"*)
f : f_trig;
--------------
f(CLK := (time_to_dword(time()) mod 1000) > 500);
if f.q then
c := i;
i := 0;
end_if
i := i + 1;
Обмена - нет. Работы со строками - нет. Работы с Ai/Ao/REAL - нет
1.МинЦ = 1. Запускаем ... и опа. С = 1000. Нормально. Цикл 1мс. Как и ожидал. Статистика показывает свободное время 500..700мкс
2.МинЦ = 0. Запускаем ... и опа. С = 2400 (в среднем). Цикл 400мкс. Как и ожидал исходя из п.1. Настоящий полковник фривилинг
Теперь про freewheeling.
Давайте уточним - что под этим мы подразумеваем. Воспроизвожу любезно предоставленый Вами текст:
"...задача имеет самый низкий приоритет и выполняется в поледнюю очередь, если процессор не занят выполнением остальных задач"
Можно уточнить - а какие такие "остальные задачи" выполняются в п.1, каких нету в п.2 ?
При упоминании задачи в виде обмена самого КДС с ПЛК (ведь в онлайне) - отвечу что данный обмен был одинаковый для п.1 и п.2
Теперь про то что фривилинг "самый быстрый".
1.Ниже сравниваем задачи с одним уровнем приоритета и временем исполнения, в противном случае разговор не имеет смысла.
2.Наивные люди могут считать что задача с временем исполнения в 100мс, и МинЦ=1мс будет выполнятся 1000 раз за секунду. Но мы как взрослые люди понимаем, что задаваемый цикл реализуется фактически как "по возможности, но не чаще периода" - как Вы и сказали.
3.Из п.2 вытекает что при сравнении 2х задач (п.1) с разным МинЦ, цикличность МинЦ=0 (фривилинговой) будет >= цикличности (МинЦ > 0) другой.
Признаю что формулировка "самый быстрый" не совсем точная. Точная формулировка - "быстрее фривилига ничего (п.1) нет"
Т.е. Вы утверждаете что при текущем положении вещей любой замер истинной цикличности всегда покажет равенство с заданной цикличностью ?
Просьба озвучить сумму. Хочется все таки знать сколько стоит разработка революционного кода. Который в том или другом виде уже присутствовал в более ранних разработках. Да и принципе - почему бы и нет. Круг задача иногда меняется - вдруг потребуется.
ваши рассуждения про "сферического коня в вакууме" )) понятно, что когда плк нужно сделать i++ за цикл и не нужно это никуда посылать - то все круто! но в реальной жизни есть куча служебных задач синхронных и асинхронных.. практически все задачи ТАУ требуют точного следования кванту времени, иначе все управление напоминает прогноз погоды "по чукче" ...
ну и кстати, по пункту 2 - так было давно!!! (самая любимая прошивка 2.10.9 где точно так происходит) - сейчас (плк110м02) при вываливании пользовательского кода за выбранное время цикла наказывают "собакой" !
они, как разработчики, отвечают за надежную работу сервисов конфигуратора и прочих встроенных штуковин, вот и подняли приоритет своих задач... ну а пользователь нехай код оптимизирует (ну или делит на 2 устройства!!!)
А вам не кажется что само понятие "система перегружена" мы как раз и создаём, вводя минВЦ?
С одной стороны Вы утверждаете, что у прикладного кода ПЛК должен быть высочайший приоритет и стабильный цикл, с другой минВЦ я обязан подобрать чтобы и системные задачи успевали выполняться, иначе проблемы с сетевым обменом и прочее..
Да и вообще, кому нужно выдерживать определённый цикл ПЛК? Неужели кто-то опирается на него при временнЫх расчётах внутри прикладного кода?
Павел, мин. цикл используется 2 путями:
1. У нас маленькая программа, которую мы хотим вызывать раз в 12 мс стабильно. Ставим цикл ПЛК 12 мс и получаем требуемое.
2. У нас расчёт столкновения 1000 молекул и он занимает 10 мс. Чтобы он выполнялся регулярно, без задержек, предсказуемо, мы ставим цикл 12 мс.
Если нам не нужно общаться с внешним миром с предсказуемым временем реакции - мы ставим freewheeling, наслаждаемся 2,4 кратным "виртуальным" ускорением и на реальной установке внезапно получаем задержку срабатывания тормоза на суппорте и сломанный станок за 10к баксов.
P.S. Заказ кастомных прошивок через менеджеров, они и прайс огласят. Если Вам так нужны "шашечки, а не ехать"
К примеру такая пони :
6 x ПЧВ, 2x8А (на них 12pt1000 + 2x0-10в), 8ДФ, 8У, 16Р, ип320, сп270
ПЛК110-60. Занято 32Di/19Do
Примерно с десяток логически не связанных систем.
Параметров разных где-то под 100. Панельки удаленные и синхронные - все равно где менять параметры.Ни одна из панелей необязана быть все время включённой.
Кстати все на одной линии RS (мне так проще)
Оцените время минимальное/среднее/максимальное время цикла плк и максимальную реакцию на нажатие панельной кнопки ?
Можно несколько разнородных задач из ТАУ которые требуют точного следования кванту времени ?
пункт 2.
Плк110(мо1) 2.12.7, с = 2960..2970 (а ведь и прям шустрей чем 154, да ? и это - мо1)
Т.е. за превышение МинЦа наказывают собакой ?
3. У меня алгоритм работы с 1000 молекулами который предполагает обработку различного кол-ва молекул за цикл - от 100 до 1000. Среднее за тысячу итераций (циклов плк) - 200. И время соотв. может быть от 1мс до 10мс, со средним - 2мс. Выбор кол-ва для об-ки определяется заранее неизвестными входными данными в начале цикла, задача - обработать максимально быстро. Что предложим для Минца?
Вот что бы общатcя с внешним миром предсказуемо, и не получать сломанных станков за 10кБаксов, потому что я поменял всего лишь прошивку, я полностью исключил, например, работу штатного мастера из конфигурации.
Кстати - мне кажется что Ваш "прошиватель" ПЧВ предпочитает именно "шашечки", раз допускает косяк который можно обойти (я то привычный, фигли), а вот если бы кто прикрутил что-нить суръезное, и был бы верящим во все хорошее, и в то, что
то он и привез бы Вам тот станок. Который за 10к.
И меня не интересует. Просто у меня пересадка, а следующий поезд в Овнинск через сутки. Вот и хочется - на такси
Jitter есть неотъемлемая часть любого процесса управления, в котором есть ассинхронные задачи/компоненты или код с варьируемым временем выполнения.
Т.к. Поцессор 1 а задач несколько и они не синхронизованы, загрузка процессора напоминает сильно неровную дорогу. И не важно, что это за задачи.
Мы можем играть приоритетами задач - однако даже имея самую приритетную задачу, даже с аппаратным шедулером (т.е. прерывание) оно, прерывание, не может быть вызвано немедленно, всегда есть задержка, нестабильная и описанная производителем процессора, в единицы тактов.
Чем больше задачи-нем нестабильнее работа.
Есть способы бороться с jitter-ом. Например цикл PRU идеален. Jitter на уровне нестабильности срабатывания оптопар и флуктуаций частоты кварца. Но в PRU 1 задача, никаких прерываний, ветвлений и пр. Уже архивчик не создашь, модули не опросишь.
В М02 помимо естественного ускорения за счёт более мощного процессор основной упор был сделан на стабильность цикла управления. Для чего применена ОС реального времени. Сейчас jitter на пустой программе (без логина,логин всегда сильно влияет на jitter) не превышает 20% от времени цикла.
Ну а желающим ехать на шахид-такси, т.к. на поезд опоздал - остаётся только посочувствовать.
Ну уж задержка на вызов обработчика по аппаратному прерыванию (высшего приоритета) настолько мала (вы правильно говорите - единицы тактов), что про неё даже говорить не стоит...
А в конфигурации задач в режиме онлайн - актуальная информация о джиттере? Например у меня сейчас 4000 мкс. При максимальном цикле ПЛК - 600 мкс.
Онлайн всегда увеличивает jitter - не всегда критично, но увеличивает. Вообще всё увеличивает jitter.
Время реакции любой системы состоит из (как раз вчера лекцию читал)
Твх + 2 Тцикла + Твых.
При этом Тцикла с учётом максимального джиттера.
Ну а если мы делаем нормальную, устойчивую систему управления - добавляем ещё 20 % в случае управления лампочкой в туалете и +50% для более серьёзных применений.
Для safety вообще другие подходы.
Рассмотрим, к примеру, систему управления шахид-мобилем.
Режим freewheeling.
Твх=1мс
Твых=1мс
Т цикла = 0,4 мс +10мс jitter=10,4 мс.
Время реакции 1+1+20,8 = 22,8 мс.
Добавим 50% (это же не лампочка, а шахид-мобиль) - 22.8 + 50%= 34.2 мс.
А водитель шахид-мобиля, посмотрев на синие писалки (2400 итераций i в цикле за секунду), думает, что время реакции меньше 1 мс.
Применяя аналогию из жизни, за рулём шахид-мобиля укуренный вусмерть водитель.
Приятной поездки!
К примеру такая пони :
6 x ПЧВ, 2x8А (на них 12pt1000 + 2x0-10в), 8ДФ, 8У, 16Р, ип320, сп270
ПЛК110-60. Занято 32Di/19Do
Примерно с десяток логически не связанных систем.
Параметров разных где-то под 100. Панельки удаленные и синхронные - все равно где менять параметры.Ни одна из панелей необязана быть все время включённой.
Кстати все на одной линии RS (мне так проще)
Оцените время минимальное/среднее/максимальное время цикла плк и максимальную реакцию на нажатие панельной кнопки ?
время реакции на кнопку (воздействие) в удаленных устройствах и время цикла мало связанные величины - нажатия -> асинхронные процессы, плюс ошибки связи и пр. Кстати, разводя устройства на несколько интерфейсов, кратно уменьшаем максимальное время реакции - удобно должно быть пользователю а не разработчику.
3. У меня алгоритм работы с 1000 молекулами который предполагает обработку различного кол-ва молекул за цикл - от 100 до 1000. Среднее за тысячу итераций (циклов плк) - 200. И время соотв. может быть от 1мс до 10мс, со средним - 2мс. Выбор кол-ва для об-ки определяется заранее неизвестными входными данными в начале цикла, задача - обработать максимально быстро. Что предложим для Минца?
в человеческой программе, при таком разбросе в потребностях вычислений, ставят минц для отработки 200 молекул за раз, реально входной поток делят принудительно и обсчитывают по 100 молекул за цикл. Получается надежно и предсказуемо.
В некотором царстве, в некотором государстве, в стольном граде Овнинск, проживал гражданин В.Ф., работающий министром путей сообщения и, по совместительству, иногда замещающий пресс-секретаря. Не далёко от города Овнинск располагается городочек Автоматьевск, немалое кол-во жителей которого трудятся в Овнинске, благополучно добираясь на работу и домой на электричках, которые регулярно, раз в 5-15минут, мотаются по маршруту А-ск/Ов-ск.
И вот, в ясный солнечный день, министр путей сообщения, движимый видимо благими идеями экономии средств родного министерства, сообщает :
"Уважаемые жители города А-ск, по вашим многочисленным просьбам и в целях повышения качества обслуживания, мы приняли решение заменить все электрички за сутки одним фирменным поездом.
Количество мест в этом поезде равно суммарному кол-ву мест в тех электричках, мы даже добавили еще один вагон. В поезде - бесплатный вайфай, занавески на окнах, разносят кофе проводницы в коротких юбках, можно почистить ботинки и посмотреть кино.
Для сохранения хорошего вида из окон (всегда светло) и в целях удобного квантования суточного времени мы решили отправлять поезд в 12-00"
В этот радостный день на первом канале показали радующихся пенсионеров - им очень комфортабельно им на выходные ездить к внучкам,
радующихся пионеров - им клево теперь, по дороге в музей города Об-ск, резатся в онлайн-тетрис...
Что бы не портить картину, очередь людей
решили пропустить. Странные люди, страннные хотелкии им
PS
Просьба все совпадения в произведении случать не случайными
Что значит "время реакции" в таком контексте?
максимальное время от подачи сигнала на DI до появления значения на DO?
среднее время от подачи сигнала на DI до появления значения на DO?
95% квантиль времени от подачи сигнала на DI до появления значения на DO?
Ещё что-то?
Откуда тут 10мс? Имеется ввиду "10мс фильтр дребезга" или собственный шум цикла ПЛК?
Это матожидание?
Максимальное значение?
Как оно зависит от модели ПЛК?
Какое вообще распределение у этого jitter?
Какова вероятность, что 2 цикла подряд jitter окажется 10мс?
Я к чему: даже вне зависимости от распределения шума самого ПЛК, если мы уберём искусственные ожидания (т.е. сделаем мц=0), то распределение времени отклика должно снизиться.
"время реакции" - максимальное время от подачи сигнала на DI до появления значения на DO. Именно так. На как минимум 10000 циклах.
Всякие статистические оценки интересны начиная с 2 девятки после запятой, т.е. 99.99% - уже пойдет для управления не особо критичного процесса
Вероятность 95% означает, что установка неработоспособна в принципе.
10 мс - это примерное время джиттера в режим freewheeling. По результатам внутренних тестов. Поэтому я и говорю, что работает ПЛК в таком режиме плохо. Валенки на шахид-такси как раз к июню и доедут до магазина. Сломался автомобиль, что делать...
Смелая гипотеза, но без знания архитектуры системы управления только гипотеза. Убираются ведь не искусственные ожидания, а время для более низкоприоритетных задач. И тут 2 варианта: Низкоприоритетные задачи вообще не выполняются ( т.е. прибор не работоспособен целиком или частично) и Низкоприоритетные задачи когда-нибудь будут принудительно переведены в высокоприоритетные, дабы, к примеру, буфер не переполнился - опа, и 10мс, 20мс, х.з. сколько времени цикл управления ждёт...
Но можете провести натурные испытания, всем будет интересно.
В некотором царстве, в некотором государстве....
собственно здесь вы сами ратуете за регулярное движение по расписанию, а не как "машинисту на душу ляжет" )))
Я к чему: даже вне зависимости от распределения шума самого ПЛК, если мы уберём искусственные ожидания (т.е. сделаем мц=0), то распределение времени отклика должно снизиться.
не совсем - появится "белый шум" и график распределения размоется, а точное выдерживание цикла дает периодичность графика
Неправда ваша. Интересен как раз общий профиль.
Вот пример графика, который я хочу увидеть: http://hdrhistogram.org
Результаты где-то опубликованы?
Слышать "99.99% подойдёт для не особо критичного процесса" и при этом не знать сколько обеспечивает сам ПЛК крайне странно.
Сколько девяток гарантирует ПЛК110 М02, в режиме мц=1мс?
Да, могу. М02 у меня есть. Но время на ПЛК разве что в апреле появится.
Вам же говорят: нет низкоприоритетных. Нет от слова "совсем".
Есть одна задача в режиме freewheeling. Ну, конкретный проект так составлен, что задача всего одна.
Какие с ней проблемы?
Давайте так: белый (ну или какой он там) шум гарантировано есть как в режиме мц=1, так и в режиме мц=0.
Сделать систему без шума крайне и крайне невозможно.
Да, соглашусь, что абсолютные значения уровня шума могут отличаться в мц=1 и мц=0 режимах.
Но: есть внятное объяснение почему в режиме мц=0 абсолютное значение уровня шума сильно больше, чем в режиме мц=1?
Если же уровень шума примерно одинаков, то, очевидно, в режиме мц=0 значения задержек 99% 99.9% и т.п. должны быть меньше, чем в режиме мц=1.
Но: есть внятное объяснение почему в режиме мц=0 абсолютное значение уровня шума сильно больше, чем в режиме мц=1?
конечно. даже если вы сделаете свой блок с однозначным временем выполнения, время на фоновые задачи будет разным от цикла к циклу и не предсказуемым, поэтому мс=0 - дает джиттер. А когда вы ставите мс=1 - то джиттера по сути нет, а если он таки есть - значит вы не вложились в 1 мс и нужно ставить мс=2
и что тут внятного, допустим в КДС не так явно выражено, например у семена есть ОВ фонового процесса, когда ОВ1 закончил свою работу, а время до минВЦ еще осталось, крутится фоновый процесс, в случае если минВЦ равен нулю, операции фонового процесса никогда не выполнятся, стоит ли тогда говорить о работоспособности проекта в целом?Цитата:
Сообщение от vladimirisitnikov;199712Но: есть внятное объяснение [B
Обсуждается проект, где всего одна пользовательская задача. Под "фоновыми" понимаем только "обслуживание ввода-вывода, работу тактового генератора самого ПЛК и т.п.". Верно? Или в понятие фоновых включаете ещё что-то?
Почему, скажем, "обслуживание ввода-вывода" будет зависеть от настроек мц?
А почему тактовый генератор будет работать по-другому?
Вариант "меньше мц -> больше тепловыделение -> меняется частота генератора" мне кажется неправдоподобным. По крайней мере, не должен он давать погрешность в миллисекунды.
Следите за руками
1) Если при мц=1 "всё хорошо", то фоновые задачи гарантировано занимают не более 1мс.
2) Если при этом настроить мц=0, то время работы этих "фоновых задач" возрасти не должно. С чего бы им замедляться?
3) Значит, в режиме мц=0, пользовательская программа имеет возможность вызываться чаще, чем в режиме мц=1.
4) Значит, в режиме мц=0 время отклика ниже, чем в режиме мц=1.
1. да 2. да 3. да 4.да, но оно разное от цикла к циклу!
фоновые задачи требуют разного времени, причем не предсказуемого! вот в этом и есть шум! обслуживание ввода вывода будет зависить от настроек мц, в том случае, когда оно не будет в него укладываться - тогда начинается дележка по приоритетности.
Когда у вас установлено время цикла - планировщик фоновых задач может распределять обработку, если время нулевое - не определено, то демон будет делать текущий объем не пытаясь его оптимизировать