да, но не забывайте, что время реакции на входы будет связано с текущей частотой выдачи импульсов ШД ))Сообщение от Newcomer
Фантастика. Все решается быстро и просто. Hardella IDE рулит.А.Приходько и В.Филоненко, а вы что скажите ? Может вам объединить свои усилия с В.Ситниковым ? От этого выиграют все и это главное о чем надо думать.
Это смотря как программу написать )
Раз уж вы, Дмитрий, Ящик Пандоры раскрыли, то теперь PRUграммирование это дело техники, и вопрос PRU0.prg/pruAccessLib больше не стоит.
У нас фасовочный аппарат, объёмное дозирование. Пневмоцилиндр тягает поршень (в котором продукт) и упирается в ограничитель, который и двигает ШД.
Позиция энкодера 0 ~ 3 кг продукта
Позиция энкодера 850 ~ 1.5 кг продукта и т.д.
Мне скорость не так важна как точность, так как цена одного оборота = 3 грамма продукта, ошибся на несколько оборотов = брак
Ускорение и замедление делал как раз для точности.
Машина выдаёт продукт, затем тара попадает на весы и если вес нужно подкорректировать, то ПЛК крутит в нужную сторону ШД на рассчитанное кол-во импульсов, таким образом получаем аппарат розлива с автоматической корректировкой веса.
ну, тогда останется только ассемблерный блок уложить в обертку овена и счастливые пользователи получат блоки энкодера и шд в виде картинок FBD )))
Ясно. Буду делать @Export. Вроде, и для вашего случая подходит.
1.Если компилятор не заточен под константное выполнение кода по времени - джиттер всегда будет. И подсчитать время исполнения при всех вариантах входных и промежуточных значениях параметров и переменных (не говоря о проверке корректности исполнения) - задача для компьютера с альфа-центавры. даже 100 бинарных переменных дают 2^100 вариантов. "Подождите, HArdella проводит тестирование кода, осталось 9999 лет 4 месяца 3 дня 5 мкс. Приятного Вам отдыха."
2. Обмен данными не используя механизм pruAccessLib, тем более более 1 регистра за раз - это гарантированные проблемы с реактивностью системы и когерентностью данных в обновляемых структурах.
Крайне трудно отлавливаемые. Это ЖЖ неспроста.
Видимый мною код Владимира об правила синхронизации просто вытирает ноги.
Тролль-наседка, добрый, нежный и ласковый
Есть рабочая программа ШД.
Там джиттер есть?
Я, конечно, понимаю ваш скептицизм и лень смотреть код/проводить испытания, если "и так видно, что код написан не по правилам". Но, уверяю вас, я не на пустом месте уверен в правильности кода (как минимум в части джиттера), поэтому, пожалуйста, лучше прямо говорите где именно джиттер вы там нашли.
Если джиттер реально найдётся, то поправлю эту ошибку. Но беда в том, что разговоров о джиттерах было много, а на практике их пока в моих программах никто не нашел.
Скоро будет и общедоступный механизм PRUграммирования. Вполне возможно, что это случится уже в этом году.
Последний раз редактировалось Владимир Ситников; 11.10.2016 в 22:28.
Джиттер можно легко рассмотреть на хорошем осциллографе. В.Филоненко, дайте вашим тестировщикам задание капитально проверить ФБ для ШД, разработанный В.Ситниковым, и всем спорам конец. Во многих практических случаях, например при управлении ШД, джиттер не страшен, что и подтвердилось при натурных испытаниях.
В.Филоненко, а когда появится ваш правильный ФБ для управления ШД ?
Последний раз редактировалось Вольд; 12.10.2016 в 11:51.
а что тут исследовать? Ситников прямо написал что время цикла выполнения зависит от текущей частоты выдачи шага, плюс язык высокого уровня принципиально не будет выравнивать время выполнения разных ветвей алгоритма... исследовать имеет смысл наличие случайной составляющей, а при заявленной принципиальной несовместимости - о чем речь? Поэтому использовать можно все что угодно, но не забывая что там внутри и чем это грозит в случае вроде бы применения в аналогичном случае.
Предлагаю на это не отвлекаться. Уже все поняли, что Владислав и Дмитрий считают, что джиттер обязан быть.
Считают -- их право.
Интереснее обсуждать как должно выглядеть "task configuration" в случае PRU.
Есть идеи/предложения?
Ваши права
Ответить с цитированием